November 2009 - Boost - lists.preview.boost.org

[1.41.0] Release candidate 3
by Beman Dawes 18 Nov '09

18 Nov '09

The third, and hopefully final, release candidate is now available. The VC++ build problems are resolved, at least on my system. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip - Windows line endings Please download and do a test build, reporting successes as well as failures. The release procedures have been updated so that in the future the release manager will do at least one build locally, to try to head off repeats of today's fiasco. --Beman

6 14

The Bug sprint has begun!
by Marshall Clow 18 Nov '09

18 Nov '09

The bug sprint will from today until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. As of 8:00 AM PST today, there are currently have 859 open tickets. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 -- Marshall

1 0

2nd try, New library proposal: PolicyLoader
by Rob Meijer 18 Nov '09

18 Nov '09

I posted this to this list ones before (as the site sugests), and didn't get any response, possibly becource it is simply to useless for you guys to reply to, but I'm not sure. If it is indeed useless please let me know, so I know not to put any effort in it. The Open Computer Forensics Architecture Library (OcfaLib) hides a litle piece of template code for loading a class from a dynamically loaded library. Although this code is currently bound to OcfaLib and usage on *NIX systems, I wondered if the concept used would not be extendable to a generically usable library for this purpose. I've tried to strip the OCFA specific code to show the simple templating concept of this library. I would like to know if it is a good idea to work on this code in order to make it a powerfull cross-platform boost library that addresses this issue in an even more generic way. If it is useless, please also let me know. First lets show an example of usage: typedef SinglePointerConstructor<AbstractRepository,const char> CRepositoryType; PolicyLoader<CRepositoryType> pl(myLib,"createRepository"); CRepositoryType *constructor=pl.constructor(); _instance = (*constructor)(repRoot.c_str()); Here the 'AbstractRepository *' type _instance gets assigned a new object of a class that implements AbstractRepository to it, that is created with the "createRepository" function in the so file designated by myLib. Here is the stripped down template code: ---------------------------------- template <class T,class U> class SinglePointerConstructor { public: typedef T * (*fp)(U *); SinglePointerConstructor (fp func) : mFunction(func) {} T *operator() (U *val) { return (mFunction)(val); } private: fp mFunction; }; template <class T> class VoidToFunction { public: static T *cast(void *p) { #ifdef VOID_FP_CAST_WORKAROUND #ifdef POINTERS_64BIT return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<long long>(p))); #else return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<int>(p))); #endif #else return new T(reinterpret_cast<typename T::fp>(p)); #endif }; }; class PolicyLoader: { public: PolicyLoader(std::string myLib,std::string loadername):mLibHandle(0),mConstructor(0) { mLibHandle=dlopen(myLib.c_str(),RTLD_NOW|RTLD_GLOBAL); if (mLibHandle == 0) { throw std::runtime_error( std::string("Problem loading library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")") ); } mConstructor = VoidToFunction<TConstructor>::cast(dlsym(mLibHandle,loadername.c_str())); if (mConstructor == 0) { std::string errString=std::string("Problem looking up symbol '") + loadername + std::string("' in library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")"); dlclose(mLibHandle); throw std::runtime_error(errString); } } ~PolicyLoader() { delete mConstructor; } void closeLib() { if (mLibHandle) { dlclose(mLibHandle); } mLibHandle=0; } TConstructor *constructor() { return mConstructor; } private: void *mLibHandle; TConstructor *mConstructor; }; -----------------

3 3

[foreach] Request for auto type deduction
by Andrzej Krzemienski 18 Nov '09

18 Nov '09

Hi, Boost already provides a tool for emulating C++0x auto syntax: auto iter = map_of_strings.begin(); // C++0x BOOST_AUTO( iter, map_of_strings.begin() ); // boost It even works in more complex contexts like: if( BOOST_AUTO(ptr, get_pointer()) ) { ptr->run(); } or: BOOST_AUTO( const& val, vect.front() ); It already provides a tool for emulating C++0x range-based for syntax: for( int & x : vect ) { ...} // C++0x BOOST_FOREACH( int & x, vect ) { ... }; // boost However currently it is impossible to emulate the following C++0x syntax: for( auto & x : collection ) { ... } // C++0x Therefore, I would like to request a new tool in Boost.Foreach that would emulate the above construct, and would look something like: BOOST_FOREACH_AUTO( const& x, collection ) {...} I do not anticipate any technical difficulties with implementing this, as it can already be achiever with a verbose: BOOST_FOREACH( BOOST_TYPEOF( boost::begin(collection) ) const& x, collection ) {..} Regards, &rzej

3 2

[datetime] feature request
by Sean Farrow 17 Nov '09

17 Nov '09

Hi; I'm currently working with a company who have locked there systems down to such an extent that users can only write to/read from certain areas. I am using the date/time library. What i need to be able to do is to load the date_time_zonespec.csv file from an rc file under windows. I can write the rc loading stuff, but how do I then go about submitting this, and more importantly only compiling this .cpp file under windows within the build framework. Chances are the code will be apart of the timeZoneDatabase class. Any help appreciated. Sean.

1 0

[1.41.0] Release candidate 2
by Beman Dawes 17 Nov '09

17 Nov '09

1.41.0 release candidate 2 packages are available. The only change from RC1 is the fix for the serialization snafu. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz<http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz>- Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z<http://boost.cowic.de/rc/boost_1_41_1_beta1.7z>- Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip<http://boost.cowic.de/rc/boost_1_41_1_beta1.zip>- Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

3 7

[program_options] Feature request for untyped variables
by Dave Johnson 17 Nov '09

17 Nov '09

I usually store option values in a global structure so that I can access them by field name rather than by doing a map lookup with a string. This has the benefit that typos in option names are caught at compile time rather than run time. For example, I can use Options.input instead of vm["input"]. For untyped options, typically used as boolean flags (i.e. --help, --verbose), there is no way to specify where to store a value (or a count). This means I need to access them by map lookup or manually copy them to my global options structure. I'm not happy with either one. Ideally I'd like some way to specify that this option does not have a value, but I'd like to give the parser a pointer to where I want it to put a count of its instances in the command line or maybe a pointer to a bool instead. Example: // Global struct for command line options struct { bool help; bool verbose; string inputFile; ... } Options; // Parse command line options_description desc("Allowed options"); desc.add_options() ("help" , "produce help message") ("verbose" , "create more detailed output") ("input", po::value<string>(&Options.inputFile), "Name of the input file") ... ; variables_map vm; store(po::parse_command_line(argc, argv, desc), vm); notify(vm); // Hack! Need to manually assign bool options! // Options.input is automatically assigned Options.help = vm.count("help"); Options.verbose = vm.count("verbose");

2 2

[iterator] Interest check in specialized reproduction_iterator
by Christoph Heindl 17 Nov '09

17 Nov '09

Good afternoon, Would there be interest in adding a specialized iterator, called reproduction_iterator, that allows specifying a single element which is iterated n-times. Example: const std::vector<int> values = boost::assign::list_of(1)(2)(3)(5); const int c = 3; std::vector<int> result; std::transform( extboost::make_reproduction_iterator(c), extboost::make_reproduction_iterator(c, values.size()), values.begin(), std::back_inserter(result), std::multiplies<int>() ); // result contains 3, 6, 9, 15 The rationale for implementing the iterator is to provide a mechanism for the cheap iteration over a 'sequence' of equal objects. This is used (in my case) for adaption of functions that otherwise take two ranges and where I can bind one range to a single object. In the example above one can achieve the same effect by using a binder and std::transform that takes a single range. This is IMHO not always possible. 'reproduction_iterator' is implemented as random access iterator using boost::iterator_facade. Best regards, Christoph

1 0

[BGL] [variant] problem (and perhaps solution?) with strong_components.hpp and variant
by Nil Geisweiller 17 Nov '09

17 Nov '09

Hi, it seems the problem is indeed a conflict between the get function of variant.hpp and the get function of two_bit_color_map. After renaming get by getTEST in 1) two_bit_color_map.hpp line 61 2) breadth_first_search.hpp line 78 3) property_map.hpp line 164 the compiling error has disappeared. Of course it is certainly not the right way to fix that bug, maybe wrapping two_bit_color_map get (and alike) function name under some namespace... but I'm not confident enough to take such decision. Maybe there is a better way. Please if someone is more knowledgeable could help me fix that bug. Thanks for your help Nil On Tue, Oct 27, 2009 at 7:31 AM, Nil Geisweiller <ngeiswei(a)googlemail.com> wrote: > Hi, > > I resend that email with the right title header. > > ---------- Forwarded message ---------- > From: Nil Geisweiller <ngeiswei(a)googlemail.com> > Date: Sun, Oct 25, 2009 at 6:11 PM > Subject: [Graph] problem with strong_components.hpp and variant > To: boost(a)lists.boost.org > > > Hi, > > it seems there is a conflict between strong_components.hpp and > variant, maybe the method boost::get is wrongly overloaded. > > The problem occurs with 1.40 but not with 1.37, and it is still occurs > with the last svn. > > I attach a minimal code to reproduce the bug + compile error > > ###### > test.cpp > ###### > > //uncomment the line below to get the bug > #include <boost/graph/strong_components.hpp> > #include <boost/variant.hpp> > > typedef boost::variant < int, float > intorfloat; > > int main() { > int i(2); > intorfloat iof(i); > return boost::get<int>(iof); //problem is here > } > > ########### > compile error > ########### > > a-lin@a-lin-desktop:~/OpenCog/test/bin$ make > [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o > In file included from /usr/include/boost/graph/graph_concepts.hpp:17, > from /usr/include/boost/graph/depth_first_search.hpp:18, > from /usr/include/boost/graph/strong_components.hpp:17, > from /home/a-lin/OpenCog/test/test.cpp:2: > /usr/include/boost/property_map/property_map.hpp: In instantiation of > ‘boost::property_traits<int>’: > /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from > ‘boost::two_bit_color_map<int>’ > /home/a-lin/OpenCog/test/test.cpp:10: instantiated from here > /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is > not a class, struct, or union type > make[2]: *** [CMakeFiles/test.dir/test.cpp.o] Error 1 > make[1]: *** [CMakeFiles/test.dir/all] Error 2 > make: *** [all] Error 2 > > Is it a bug? Thanks a lot! > Nil >

4 5

Fall bug sprint starts tomorrow! (Assuming that the release happens today)
by Marshall Clow 17 Nov '09

17 Nov '09

Here's the deal on the bug sprint: It will run until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 General information about the ticket process is at What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 which shows that we currently have 856 open tickets. As soon as the release is final, I will be posting the "release branch" vs. "trunk" comparison as well, so we can find things that need to be merged. -- Marshall

1 0