October 2004 - Boost - lists.preview.boost.org

[review] Formal review of the Smart Container library - 5 days left reminder
by Pavol Droba 01 Oct '04

01 Oct '04

Hi All, This the the reminder, that there are only 5 days left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

RE: [boost] Re: Re: Long toolset names
by Stefan Seefeld 01 Oct '04

01 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 12:03 > Even MS IDE has problems in some cases (very inconsistent) when space > characters are present but I thought that in most Wintel and also UNIX > command tools these issues are easily solved with adding quotes? well, that sounds simpler as it is. It's all those little details such as one shell eating quotes, another passing them through when called in a nested way that makes it really hairy. It's a can of worms that can easily be avoided by not using spaces in file names. Regards, Stefan

1 0

White spaces in regression
by Victor A. Wagner Jr. 01 Oct '04

01 Oct '04

As part of my script before I run any of the regression code, I delete all the *.xml files from the results directory. This is done because if there is a _severe_ crash while running the regressions, the *.xml files will still exist when things are "collected". I've been told that it is the responsibility of process_jam_log to create these, BUT: C:\Projects\boost\tools\regression\build>C:\Projects\boost\tools\build\jam_src\bin.ntx86\bjam.exe -sTOOLS=vc7.1 ...found 481 targets... Traceback (most recent call last): File "regression.py", line 712, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 356, in setup build_if_needed( process_jam_log, pjl_toolset, toolsets ) File "regression.py", line 288, in build_if_needed raise 'Failed to find "%s" after build.' % tool[ 'build_path' ] Failed to find "C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\process_jam_log.exe" after build. the reason it cannot find it there is because somehow it got built here instead: C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\threading-multi\process_jam_log.exe I don't know if actually finding the correct version will solve the white space problem, but this clearly isn't correct. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Signals] New regressions
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Doug, It seems that your last checkin broke things on a number of platforms -- see http://tinyurl.com/69npt. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Compilation problem with boost on SunCC (Forte 6.2 & 8)
by Puverle, Tomas (IT) 01 Oct '04

01 Oct '04

Please find attached a small program and a the resulting compilation errors on SunCC. This occurs in iterator_facade.hpp, operator != (), calling to interator_core_access::equal. I have tracked this down to the following problem: f(mpl::true_); f(mpl::false_); f(is_convertible<>()); //will not work is_convertible<> derives from mpl::bool<>, however it seems that a bug in the compiler prevents it from converting to mpl::true_/mpl::false_ in the above scenario (and in the program attached) A workaround for this is to change it to the following: f(mpl::true_); f(mpl::false_); f(mpl::bool_<is_convertible<>::value>()); Presumably this will be present in other places but this is the only one our developers have hit so far. Thanks, Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

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

[Thread] The last step
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Gentlemen, Seems like we've just cleared up Boost.Thread failures/regressions on all but one required toolset! See http://tinyurl.com/6h56q. Congratulations on the great job to everyone involved. You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn) it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes: /usr/lib/libc.a(strtol.o)(.text+0x50): In function `strtol': ^^^^^^^^^^^^^^^^^^^^^^^^^ : multiple definition of `strtol' /opt/intel_cc_80/lib/libcprts.a(strtol.o)(.text+0xea): first defined here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ld: Warning: size of symbol `strtol' changed from 24 in /opt/intel_cc_80/lib/libcprts.a(strtol.o) to 73 in icc -g -openmp -static -o "../bin/boost/libs/thread/test/test_barrier_lib.test/ intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi -L../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/tss_null.o" ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a -lrt Could somebody comment further/take a deeper look at this? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

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

Re: [boost] Re: MultiMethod/Visitor Interest
by Danil Shopyrin 01 Oct '04

01 Oct '04

David Abrahams writes: > Yeah. It's hard to imagine how "compile-time multimethods" would be > any different from what C++ already provides in terms of overload > resolution and partial ordering. The main difference is that they work when particular types of participants are unknown at compile time. It is just like trying to implement unary virtual method using overloading. Jesse Jones writes: > Can a static library do better type > checking? In particular can it figure out, at compile time, if there > are no applicable methods or no unambiguous method? Yes. The compile-time library detects ambiguity and absence of proper method. It is compile-time error. P.S. It is looks like this post was lost.

1 0

can emacs cc-mode be made to do boost-style preprocessor indents?
by Jonathan Graehl 01 Oct '04

01 Oct '04

The Boost style of nested indenting for preprocessor directives is nice. I'm using cc-mode for emacs (the sourceforge version), and it doesn't seem to directly support this: #if 1 # if 2 # define A 1 # else # endif #endif I found this cc-mode mailing list discussion that confirmed the lack of support: http://sourceforge.net/mailarchive/forum.php?thread_id=5382045&forum_id=6827 Anyone already got some working elisp for preprocessor autoindent?

2 1

Portable test_and_set, please...
by no_carrier 01 Oct '04

01 Oct '04

Hi all, I see some atomic operations in atomic_count.hpp (usable only by the atomic_count class unfortunately, and not directly) for incrementing and decrementing, but the most important atomic operation seems to be missing: the test_and_set. Without that one it's not possible to create lockfree algorithms in MT. Also, atomic incrementing, decrementing etc. can be performed having the test_and_set but not vice versa. Would anybody please make a wrapper for that? On Windows it's the InterlockedCompareExchange, on Gcc and Linux I think they are called __test_and_set and atomic_test_and_set respectively. I don't know if they would better go in the Boost.Threads or in the atomic_something header files... Thanks

1 0

[Signals] slot/trackable object disconnection question
by Dave Deakins 01 Oct '04

01 Oct '04

I have a question about the disconnection of slots in the signals library. I couldn't find any information about it in previous message threads, but if I missed one you guys can just direct me to the appropriate discussion. In my project I have a serial port communications queue that allows various other objects to transmit a command over the serial port and then have the response routed to a designated callback function. Each command request can specify a different response callback function and often the object posting the command will ask the queue to pass the response data back to one of its member functions for interpretation. I use the automated connection management feature of signals to insure that the response member function is not called if its target object is destroyed before the serial port response is received. This queue typically handles about 10-15 command/response transactions per second and I noticed that, after about 15-20 hours of continuous operation, the system began to run low on available memory. I spent a fair amount of time trying to track down the source of the excessive memory usage and it appeared that it was coming from the trackable object base class. Each time a command is added to the communications queue, a new queue entry is created and we connect the response handling function to the signal in this queue entry. If I understand correctly, signal's connect function will create a temporary slot object to adapt the boost::bind(&AClass::ResponseFunction, pAClass, _1, _2) object that is passed to it. When this temporary slot is created, it uses visit_each to enumerate the bound trackable objects and then uses trackable::signal_connected(...) to have each bound trackable object save a 'controlling' connection to the slot in its connected_signals list. So if any of the bound trackable objects are destroyed, the 'controlling' connection will deactivate the slot and tell all of the bound trackable objects used by the slot that they can erase their connections to this slot. So my question is this: When a slot object (not a signal object) is destroyed, what tells the trackable objects that are used by the slot that they can release their connection to this slot? Signal objects make the connections in their internal slot map 'controlling' so these connections would do the clean up when the signal is destroyed. As mentioned above, trackable objects also make the connections in their internal connected_signals list 'controlling' to enable deactivation and clean up of standalone slots or slots connected to signals when the trackable object is destroyed. But the watch_bound_objects connection in the slot object is not 'controlling' (as far as I can tell) and thus a slot does not seem to have any way to indicate to the bound objects that this connection needs to be cleaned up if the slot is destroyed. The following program roughly illustrates the behaviour I see in my application: #include "boost\bind.hpp" #include "boost\signals.hpp" class CommunicatingObject : public boost::signals::trackable { public: void ProcessResponse() {} }; int main(int argc, char* argv[]) { CommunicatingObject Obj; while (true) { boost::signal0<void> NewResponseData; NewResponseData.connect( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); NewResponseData(); } return 0; } Obj would represent the object making a request on the queue and NewResponseData would represent the signal contained in the queue entry. When I run this test program on my system, the system runs out of memory in fairly short order. I have the same memory draining situation if the while(true) loop is changed to the simpler case of: while (true) { boost::signal0<void>::slot_type( boost::bind(&CommunicatingObject::ProcessResponse, &Obj) ); } Can someone please confirm if this behavior happens on other systems or if maybe there is some pecularity with my system/compiler? If this situation is not peculiar to my system, should there be a: watch_bound_objects.set_controlling(); statement at the very end of the slot_base::create_connection() procedure (after the safe_connection.release() statement) in slot.cpp? Thanks in advance for your help, -Dave

2 6

Re: [boost] [Random] GCC 2.95.3 regressions
by Michael Stevens 01 Oct '04

01 Oct '04

> Aleksey Gurtovoy writes: > > > > Given that the code compiles with the latests versions of the > > compiler, the following (from http://tinyurl.com/58lll) is most likely > > to be a compiler bug, but since the test used to pass some time ago, I > > was wondering if anyone is interested in making it work again or simply > > commenting on it before I mark it green: > > [snip errors] > > OK, seems like nobody is interested in these, marked up as expected. I took a quick look. It seems like gcc-2.95 has namespace problems when BOOST_USING_STD_MIN/MAX Since Random never worked on systems without min/max in std I have simplified and use std::min/max instead. This fixes gcc-2.95 and should not regress on any of the good compilers. If this looks good in the tests tomorrow I will remove the failure markup. Michael

2 1

use of strcpy, strcat, etc in Boost libraries
by Reece Dunn 01 Oct '04

01 Oct '04

Hi All, In my post on the "vc8.0 toolset (bjam)" thread, I commented that VC8 also warns when using the str[n]xxx APIs, because MS declares them deprecated. There are several issues here: [1] How does this impact Boost code that uses the <cstring> API? Especially since they deprecate the strn variations as well, which are safer, and considering that the "safe" versions are not yet a part of the standard. Would it be possible to put this in the Boost <cstring> header? I.e. using the safe versions for VC8 and using the C9x API for the other compilers/libraries. [2] Does this affect the Intel compiler using the Dinkumware libraries because Intel does not like how the library declares items deprecated. (This is already an issue using the <locale> header and <hash_xxx> extensions). [3] What are the wider security issues of using strcpy, etc in Boost code? The libraries should use the strnxxx variants for better protection against buffer overrun attacks, but I found several instances where strcpy was used (I haven't checked for strcat, strcmp and others) instead of strncpy: boost/regex/v4/regex_cstring.hpp (104): use of strcpy [via re_strcpy] libs/regex -- various files using strcpy libs/serialization/test/test_tools.hpp (69): use of strcpy [via STRCPY] libs/smart_ptr/test/smart_ptr_test.cpp (139/223): use of strcpy tools/build/jam_src -- execnt.c; regexp.c; variable.c [4] Doing this, I found that regex was using re_strcpy as a workaround for Borland using strxxx as macros when using intrinsics. Serialization uses STRCPY for a similar workaround, and my fixed_string library uses the following: # if defined(__BORLANDC__) && defined(strcpy) // replace Borland instrinsic string function # undef strcpy inline char * strcpy( char * dest, const char * src ) { return( __strcpy__( dest, src )); } # endif So: should the workarounds be placed in <cstring> and affected libraries use the Boost version. NOTE: I suggested telling Boost.Build to disable the deprecated API warning for the upcoming release and then address these issues for the next (1.33) release. Thoughts? Comments? Regards, Reece

4 6