May 2010 - Boost - lists.boost.org

1.43 build broken on MSVC 8.0
by Stephan Menzel 14 Jun '10

14 Jun '10

Hi there, I was just trying to compile 1.43 on Windows 64 bit for some hours now and unfortunately from my perspective it looks like the modified build system may be a bit broken. First of all, bootstrap.bat didn't work anymore. As usual I was using it to create bjam.exe but this time it just went into causing heavy load and after about 15 minutes it returns telling me the command line is too long. As always, I just did this: ./bootstrap.sh This used to work but not anymore. So I downloaded a precompiled bjam.exe (3.18) and went with that instead. Alas, it created a 32 bit build just fine but failed to produce a 64 bit build. It appears like it is compiling all objects for 64 bit but then tries to link with /MACHINE:X86 , causing the linker to complain: ... common.mkdir bin.v2\libs\math\config\msvc-8.0\debug\threading-multi compile-c-c++ bin.v2\libs\math\config\msvc-8.0\debug\threading-multi\has_long_double_support.obj has_long_double_support.cpp compile-c-c++ bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\sph_neumannf.obj sph_neumannf.cpp msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\assoc_laguerref.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\vcvarsamd64.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\math\build\msvc-8.0\debug\thr eading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll" /IMPLIB:"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_m ath_tr1f-vc80-mt-gd-1_43.lib" @"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43 .dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2 \libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.lib bin.v2\libs\math\build\msvc-8.0\debu g\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.pdb... ... I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do: ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage Please let me add that I've been doing this since 1.34 and somehow always managed to get the job done so I have reason to assume there's something that must have changed in this release that broke it. I also tried the switch ---architechture=amd64 and many others I thought might help. I also delete everything already compiled before retrying. The system is Windows XP, current SP and MSVC 8, also current SP. Here's my user-config.jam: ...... using msvc : 8.0 : "C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\cl.exe" : <setup>"C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\vcvarsamd64.bat" ; using python : 2.5 ; # Make both versions of Python available using python : 2.5 : "C:\\Program Files\\Python25_64\\python.exe" : "C:\\Program Files\\Python25_64\\include" : "C:\\Program Files\\Python25_64\\libs" : <toolset>msvc ; ....... I also tried to copy the 'tools' folder from 1.42 where it used to work and also the Jamroot and project-config.jam but it still produced the same error. Can anyone give me a hint if there's an issue with the build system in this release? Cheers, Stephan

7 16

[GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
by Thomas Heller 14 Jun '10

14 Jun '10

Regarding arguments to phoenix expressions there are two possibilities. The first is: Arguments are mutable. The current phoenix is implemented to be able to this. Example: int i( 1 ); ( ++phoenix::arg_names::arg1 )( i ); The result of ++phoenix::arg_names::arg1 will be 2, i will have the value 2 after the expression is evaluated. The other approach would follow a more functional programming style as the data will not be mutable int i( 1 ); [1] ( ++phoenix::arg_names::arg1 )( i ); [2] ( ++phoenix::arg_names::arg1 + phoenix::arg_names::arg1 )( i ); The result of [1] will be 2, however i does not get changed (it remains to be 1). The result of [2] will be 3. i still unchanged. This example would be working "out-of-the-box" with the current prototypes. To get the mutability back into phoenix i propose the use of phoenix::ref. I favor the second approach. However, this would break API compatibility between the existing implementation. The question i want to ask the current and prospective users if it feasible to break your existing code? Is there a lot of existing code depending on this behaviour? Does it make sense to break code in such a way? Regards, Thomas

10 28

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

[polygon] tutorial done and library ready for release
by Simonson, Lucanus J 05 Jun '10

05 Jun '10

I have just added a tutorial to the documentation. The tutorial walks the reader through the requirements, design and implementation of a toy layout versus schematic comparision application. I would like feedback from the community on whether this is what you are looking for in a tutorial. Also I'd like to check with my review manager, Fernando, if this tutorial satisfies the acceptance requirement that I add a tutorial to the documentation. The tutorial can be found here: https://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_tutorial.htm At this stage I think I have satisfied the acceptance requirements from the review and would like to coordinate merging the library onto the trunk and release branch to get into the next release of boost. A little guidance from the release manager would be appreciated. Thanks, Luke

9 28

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 03 Jun '10

03 Jun '10

I wanted to throw a few things into the discussion: 1) Typed vs untyped. We have had various discussions about whether the network endian object should be a different type to the machine endian. I have a pretty strong opinion on this, and I think you should work with the same type. There are 2 core reasons for this: a. Performance when network endian is the same as machine endian - I'll discuss more on this later. b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden. c. Given that you tend to convert to machine endian at the boundaries, you can treat the untyped interface in a very similar way to a boost::shared_ptr style interface. You call swap_in_place on the return value from the function that creates the initial struct - and therefore you never have access to the network endian version in anything except your most basic read function. As such, I think the type safety of network endian data is a bit of a red herring. It is no different from creating a raw pointer, then half a dozen lines of code later constructing a boost::shared_ptr from it. It is against the principle of the interface, and would create some evil bugs, but hasn't been formally prohibited by the interface. d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level. 2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place. Secondly, we should definitely not accept an interface that copies just on the grounds that the most common operation is from a big endian network to a little endian machine that does always require mutation. The platforms that boost runs on includes plenty of big-endian machine types; and I have come across numerous cases where (for performance reasons on a largely little endian machine environment) data has been left little-endian on the network. Having a do nothing (not even copy) case for when machine and network endianness match is very important. If you are reading a big stream of data from the network, not copying anything is a very important case, and key for writing high performance production code. 3) A final thought is that I am much more keen to use template arguments to decide on which endian swap to use than explicitly coding them in function template names. It makes endian swapping code in a big code base easier to spot, and makes the interface of the endian swapper itself more logical. When I change from big to little endian, I am tweaking a parameter of the endian swapper, not calling a wholly different function. I think from a design perspective, a template parameter makes most sense. Overall, I like Tom's interface, but I have been using it for quite a while (as a disclaimer). Dave

10 57

Mutexes claim a Windows event handle
by Peters, Richard 03 Jun '10

03 Jun '10

Hi! I have a problem with boost::recursive_mutex "sometimes" keeping a handle to a Windows Event. My application uses a lot of objects, each containing a recursive_mutex. The objects are accessed from different threads using a scoped_lock (see code below). In Boost 1.34 there was no problem, but after we switched to 1.39 it seems that the process collects more and more handles to Windows Events. Only when the objects that contain the recursive_mutex are destroyed, the handles are released again. The problem is that I must support 100,000 objects containg multiple mutexes, so if each mutex can cost one handle the total number of handles in use may become huge. I tried the latest Boost version (1.43) but that makes no difference. The strange thing is that not every object keeps a handle, i.e.: the number of handles collected is less than the number of objects created. When increasing the nrActions the number of handles collected comes closer to the number of objects. I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each? Thanks for your advice! Code example: #include <list> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <boost/enable_shared_from_this.hpp> class ActiveObject : public boost::enable_shared_from_this<ActiveObject> { private: boost::recursive_mutex mActionLock; void action() { boost::recursive_mutex::scoped_lock asyncLock(mActionLock); } public: void startAction() { boost::recursive_mutex::scoped_lock syncLock(mActionLock); boost::thread th(boost::bind(&ActiveObject::action, shared_from_this())); } }; int main() { { std::list< boost::shared_ptr<ActiveObject> > jobList; for (int nrObjects = 0; nrObjects < 1000; ++nrObjects) { boost::shared_ptr<ActiveObject> pActiveObject( new ActiveObject() ); jobList.push_back(pActiveObject); for (int nrActions = 0; nrActions < 3; ++nrActions) { pActiveObject->startAction(); } } // At this point, a lot of handles are in use. } // Here, the handles are released again. exit(0); } This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

5 9

Maintaining boost.org
by Dean Michael Berris 03 Jun '10

03 Jun '10

Good day everyone! If you were at the BoostCon 2010 panel session, I suggested that maintaining boost.org can be a less painful process and that I was willing to help out in transitioning the current site from the way it is currently set up to maybe use Wordpress to host the site. There are other options that I would like to explore only after looking at many different tools and the current process of maintaining it. I tried sending mail to the Boost-docs list but I haven't gotten any responses yet so I chose to send another email to the developers mailing list. There are a couple of questions I would like to ask and would really appreciated getting an answer about: 1. Is there currently a boost.org web team? If so, who are in the team? 2. What is the current process of building the boost.org site? What is the toolchain used and how are changes managed? Before I go into the detail of a proposal of making boost.org a little more "interactive" and "inclusive" I would first like to know the state of the system and whether there are any low hanging fruit that can be taken care of before I even suggest changing it. FWIW, I volunteer to help manage boost.org to make it more inviting to the community and more dynamic than it currently is. Although the boost.org website does host the web-based library documentation, I would like to be able to see more information on it about the community, the process, and news on what's going on. Pending a "full" proposal I would definitely appreciate thoughts about the matter too. -- Dean Michael Berris deanberris.com

12 40

[boost::endian] Request for comments/interest
by Tomas Puverle 01 Jun '10

01 Jun '10

I wrote an endian library on the flight back from boostcon but it has taken a little time to clear the submission with the firm. I realize that Beman's endian swapper library is already in the review queue but I hope my approach is different and interesting enough to warrant consideration. It's located here in the vault (Utilities/endian-puverle.zip): http://www.boostpro.com/vault/index.php?action=downloadfile&filename=endian… The highlights of the library are the following: - Very simple interface: swap<machine_to_little/big>(), swap_in_place<machine_to_little/big>() - Support for built-in and user-defined data types and ranges thereof. E.g. you can swap ranges of structs containing/deriving from other structs - endian::iterator, which will iterate across a range swapping values as necessary. It works with any swappable type. The library is described/documented/tested in the file main.cpp at the root of the zip archive. Unfinished items: - Right now, the library only includes the "vanilla" swapper, meaning it doesn't take advantage of special instructions on architectures which natively support endian conversion. I didn't include this in order to prevent cluttering the code with #ifdefs. This functionality would, however, be part of the final library. - Ideally, the metafunction is_mutable_range<> should be moved out of endian::detail and become part of Boost.Range of Boost.TypeTraits. I have donned by bulletproof vest and I'm ready for any feedback you may have. :) Tom

15 55

[gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?
by Christian Henning 01 Jun '10

01 Jun '10

Hi there, I'm having an interesting discussion over at the MSDN forums regarding compiler errors with MSVC10 that show up when using standard algorithms and bit_aligned images. Basically the question is why MSVC10 doesn't understand that bit_aligned_pixel_iterator is a random access iterator. For some reasons it thinks it's an input iterator and though std::copy, in this case, cannot find the correct copy implementation. One of the folks over at MSDN thinks that bit_aligned_pixel_iterator isn't implemented correctly with the interator_facade. He/She also thinks that iterator isn't fully standard compliant since it doesn't give a real reference but a proxy object instead when deferencing. I'm not sure if that's correct. Anyone knows if that's true or not. Here is the full text: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3c9eac4f-86e… In any event it seems I need to do some adjustment in the the gil code to have it working with my gil io extension and MSVC10. Right now I have the compiler errors all over my test suite. Regards, Christian

4 8

[range_ex] proper attribution
by Eric Niebler 31 May '10

31 May '10

The history of range algorithms in Boost goes back a long way. I'd like to see http://tinyurl.com/2d778f4 reflect that. When I wrote my earlier incomplete RangeEx library, I was careful to acknowledge (http://tinyurl.com/2dwdrhg) that I had borrowed heavily from the Container Algorithms library first written by Jeremy Siek and Vladimir Prus. If, as seems likely, Boost.RangeEx owes a debt to my RangeEx library, that should be noted, as well as the debt owed to Jeremy and Vladimir. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 2