September 2004 - Boost - lists.boost.org

[Test] Current failures
by Aleksey Gurtovoy 02 Oct '04

02 Oct '04

Gennadiy, Could you please take a look at/comment on the current Boost.Test failures as per http://tinyurl.com/5wojs? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

5 18

Re:[boost] [Serialization] Remaining failures markup
by Robert Ramey 01 Oct '04

01 Oct '04

Aleksey Gurtovoy wrote: >Robert, >Pending msvc-stlport issue aside, I commented this accordingly. >the serialization library reports show >quite a few failures with other toolsets, in particular: > cw-9.3 > borland-5.6.4 > cw-8.3 > msvc > vc7 >I'm sure you've well aware of these; what I'd like to ask you is to >comment on them in the "explicit-failures-markup.xml" in the similar >way you commented on "*_warchive" tests, so that a) the library users >are not scared away by all these yellow cells, and b) the release >manager and everybody else besides the author have a simple way of >telling whether the library is in the OK state or not. I've been looking at this for a while procrastinated doing anything until I was sure what to do. So far this has been an effective strategy. Many times failures just disappeared as arcane tooI set issues were resolved. I still have some doubts about how to handle the remaining cases. Metrowerks compilers (cw*) seem to suffer from over-zealous optimization that eliminates static variables not referred to explicitly by name. Other compilers do this as well, but I've managed to workaround this in various ways. Cw* is the last hold out on this issue. I had hoped someone who is interested in this can test it might be motivated to look into it but it seems that there isn't enough interest. Unless I hear otherwise, I'll mark these tests as "expected". I would love to see this fixed - but for this Metrowerks would have an almost perfect showing. I do think its very high quality product that handles platforms that others don't. Its pains me that the serialization library test don't reflect this. A number of these (msvc, vc7, borland) have been determined to be manifestations of compiler deficiencies so I will mark them so. Some the borland test don't fail on my own test setup - so for me they are indeed "unexpected failures" - I think leaving this yellow is the correct characterization. That leaves a number of miscellaneous failures which really aren't understood or explained. Personally I would like to leave these as they are as to mey they really are "unexpected failures". I realize that some might be dissuaded from using the library because of this - but I think that's better than having someone use the library and not have it meet expectations. Robert Ramey

3 2

1.32 Status?
by Brian Braatz 01 Oct '04

01 Oct '04

I am anxiously awaiting 1.32 as there are features there that I need. I am holding off though on using them until that is officially released. My question is - is there a target timeframe as to when 1.32 looks like it will be ready. My Suggestion would be that the website (boost.org) have a place on the front page that has the current rough timeframe for when 1.32 may be ready. Thanks Brian Braatz

3 3

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 01 Oct '04

01 Oct '04

Alexander Terekhov <terekhov(a)web.de> wrote: > Ben Hutchings wrote: > [...] > > If atomic_read > > returns 0 that means the use count has dropped to 0 [*] and can > > never increase again, so it must be the latest version. Otherwise > > weak_ptr makes a second test that is properly protected. So it can > > never use an old value. > > > > [*] I think this is right but I'm not certain that it can't return a > > 0 that the processor read during creation of an object that > > uses enable_shared_from_this. > > What makes you uncertain? Simply not having thought enough about it. Now that I have done, I realise that it's impossible for a thread to use a weak_ptr to an object without either (1) constructing a shared_ptr to it, setting the use count to be non-zero, or (2) synchronising with another thread that constructs the shared_ptr and/or weak_ptr, which should provide an appropriate memory barrier that will prevent the use of any invalid pre-fetched value of the memory containing the use count. > > Having said all that, I feel the naming of functions may give a > > false sense of generality and encapsulation when they actually > > only work in the way they are being used currently. > > You mean that > > bool expired() { > return lock(); > } > > is better? Not really. I will expand in my mail to Peter Dimov.

3 17

Re:Re: [boost] Output formatters: different approaches
by Robert Ramey 01 Oct '04

01 Oct '04

>Vladimir Prus wrote: >> During the review of the output formatters library, there were suggested >> several alternative approaches. For example, Gennadiy thinks the library is >> too complicated, and Hartmut suggests creating a library dual to Spirit -- >> which would be extra powerfull. > >> That's not all. Independently, I've talked with Vaclav Blazek, who's the >> author of the Teng text template engine (http://teng.sourceforge.net/) which >> is also a similiar domain -- it's too about formatting objects. >I will try to take a look at it next week. >> >> It would be great if we had some common foundation, so that I could output >> ptr_vector<Function> using both a simple formatter, or a flexible one, or >> even some template engine. > > >> 2. A mechanism to iterate over elements of composite type. After some though, >> I believe that the mechanism should be boost::serializaton. >This sounds nice, but I don't know how achievable it is. >Basically, when writing a composite type, you might want to write things >in-between. Like, for a pair, you might want to write: > [first, second] >or ><<first | second>> > (where first and second are the members of the pair) >Same goes for each composite type. >I'm not very familiar with boost::serialize - still it is something to >think about ;) The serialization library provides formatting/recovery for all composite types with no special effort by the programmer. This is usually suitable for the type of output file being used. In cases where it isn't, the output/input can be overloaded on a type by type basis. In practice few have found it necessary or valuable to do this. >> The idea of the library, as I see it, is to provide object serialization, but >> - without the overhead serialization library has >> - with extra layout tweaks >Yes, it would be nice. For objects of the type being discussed, (i.e. no pointers, no class versioning, no memory tracking of duplicates, etc) the serialization library has no extra runtime overhead. I would be very surprised if the serialization library did not result in smaller and faster code than the libraries being discussed. >> I don't see why it's necessary to reinvent the object traversal code which is >> already in boost::serialization. For example, boost::serialization support >> scoped_ptr. It would not make sense to add separate support for scoped_ptr in >> outfmt. The serialization library has all that and much, much more. >I would need to delve further into boost::serialize to have an oppoinion >- and the unfortunate thing is that I won't have any available time soon :( Too bad, it would have consumed much less time than has been already spent on this topic If function output formatters is helpful for making output more easily presentable, fine. Though G. Rozenthal's, experiment makes me doubt this. If the purpose is to save and restore the state of some assortment of class instances - it's the same as the serialization system and should evaluated as an alternative with a full blown comparison. I believe the demos and documentation in the serialization package show that it to be much, much easier to use than the proposed library for this purpose. Robert Ramey

3 2

Thread VC 7.1 failures (Bronek Kozicki)
by Stefan Slapeta 01 Oct '04

01 Oct '04

Any idea why some tests fail in this environment? They do all pass on my machine and appearantly also on Victor's. Stefan

4 4

Python/GCC 3.4.1/Linux failures
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

There are a few of them, see http://tinyurl.com/5z3hy. What we are going to do about it? -- Aleksey Gurtovoy MetaCommunications Engineering

5 13

[tokenizer] fix for msvc-stlport
by Joaquín Mª López Muñoz 01 Oct '04

01 Oct '04

tokenizer currently fails with tests example (regression) and simple_example_3 and simple_example_4 (expected) under msvc-stlport: http://tinyurl.com/3mkvx http://tinyurl.com/44pbx http://tinyurl.com/5xd8z I've tracked down the failure to a problem of MSVC 6.0 with templatized memfuns of an imported class (thanks to Francois Dumont): http://www.stlport.com/dcforum/DCForumID6/1763.html The following workaround in boost/token_functions.hpp solves the problem for all tests. As the patch is strictly msvc-stlport-specific, I don't think it can have nasty side effects somewhere else. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 11a12,13 > // 30 Sep 2004 Joaquín M López Muñoz > // Workaround for a problem with string::assign in msvc-stlport 38a41 > #include <boost/detail/workaround.hpp> 210a214,224 > > #if BOOST_WORKAROUND(BOOST_MSVC, == 1200) &&\ > BOOST_WORKAROUND(__SGI_STL_PORT, < 0x500) &&\ > defined(_STLP_DEBUG) > // Problem with string::assign for msvc-stlport in debug mode: the > // linker is not able to import the templatized version of this memfun. > // See http://www.stlport.com/dcforum/DCForumID6/1763.html for details. > > t = Token(); > while(b != e) t += *b++; > #else 211a226,227 > #endif >

2 1

Call for Volunteers: the Synopsis project
by Stefan Seefeld 01 Oct '04

01 Oct '04

Hi there, The Synopsis project is looking for volunteers to enhance its C++ parser and source code introspection facilities. The Synopsis project (http://synopsis.fresco.org) started some years ago with the goal to provide a more robust and flexible alternative to code documentation tools such as doxygen and javadoc. As it evolved, it became clear that the infrastructure could serve in a much broader context, and so the current goal is to provide a framework for code introspection. Some obvious use cases include semi-automatic language-binding generation (such as done by boost.python's pyste) as well as reverse engineering and refactoring tools. Synopsis with its current code base is able to parse most of boost (as I posted earlier I have been working with David Abrahams to generate a reference manual for boost.python), though there are some C++ constructs it can not yet fully analyse. My goal is to provide a fully standard compliant C++ parser with C++ and python APIs to access the processing pipeline as well as the abstract syntax tree for maximum power and flexibility. You'll find the project mailing lists at http://synopsis.fresco.org/mailinglists.html Kind regards, Stefan

4 4

Boost.Strings
by Martin 01 Oct '04

01 Oct '04

The fixed_string is already in the review schedule and a proposal for immutable strings was published recently. Wouldn't it be good to combine these (and also maybe the flex string) into a boost.strings library. That way it would be easier to ensure that all string types work properly together. It could also be possible to do some optimizations in the interfaces since each string class can assume the others are available e.g. a fixed_string constructor in the immutable string.

5 6