December 2009 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Compilation errors 1.39, 1.41
by Pfligersdorffer, Christian 07 Dec '09

07 Dec '09

Hello again, I just found out that the issue with double targets only occurs when I build debug and release at once (as I usually do): bjam debug release stage I also found out, that with version 1.41 the math libraries correctly detect missing support for long double on my platform, so I guess the issue was solved. Thanks, -- Christian Pfligersdorffer Software Engineering http://www.eos.info

2 2

Updated performance results using Boost Serialization 1.41
by Brian Wood 07 Dec '09

07 Dec '09

I've recently updated the performance section of a comparison between the Boost Serialization library and the C++ Middleware Writer -- http://webEbenezer.net/comparison.html#perf<http://webebenezer.net/comparison.html#perf>. The new tests were done on Fedora 12 and Windows Vista. The previous version of that file is here http://webEbenezer.net/comp138.html#perf<http://webebenezer.net/comp138.html#perf>. The most dramatic change occurred on Windows. Previously the Boost versions were around 2.7 times slower than the Ebenezer versions. Now they are between 3.8 and 4.0 times slower than the Ebenezer versions. I believe that difference is due to our dropping return codes for exceptions. I'm not sure why it shows up more on Windows than on Linux. Cheers, Brian Wood Ebenezer Enterprises http://www.webEbenezer.net "When a man's ways please the L-RD, he makes even his enemies to be at peace with him." Proverbs 16:7

3 2

Mysterious failure of libboost_thread in 1_41_0
by Stonewall Ballard 06 Dec '09

06 Dec '09

I'm trying to switch from 1_40_0 to 1_41_0, but have run into a mysterious problem in the thread lib. My test app that I used to find the problem with thread_group::interrupt_all() failed disastrously in 1_41_0. Debugging revealed that threads were being created uninterruptable. I couldn't figure out how that was happening, though. Tracing didn't show anything setting the interruptable flags to false in the threads, but they showed up that way right after the threads started. It looks like it might be some sort of memory corruption, like a write through a bogus pointer. Adding the three 1_41_0 thread library files directly to my build (and not using the library) worked fine. Using libboost_thread and the headers from 1_40_0 worked fine as well. The failure occurred when I used the 1_41_0 headers and libboost_thread. Both the static and the dynamic libs failed in exactly the same way. The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi This is with OS X 10.6.2, using gcc 4.2, building a simple command-line tool. In both cases, I built the boost libraries using address-model=32, though building with 32_64 in 1_41_0 didn't make any difference. Using 32_64 was broken in 1_40_0, so I suspect that the problem might be there. If anyone wants to take a look at this, I parked the XCode project here: <http://dl.dropbox.com/u/297034/ThreadTest_41.zip>, 20KB. I'm sure it can be built without the XCode project, but this may be an OS X specific problem. The project is configured to use the boost version installed in /usr/local. When run, it hits an assert right after the thread starts, showing that the thread is uninterruptable. The work-around is simply to include the three files from the library directly in the project. I have to wonder if this will happen with other boost libs as well. Any help would be greatly appreciated. - Stoney -- Stonewall Ballard stoney(a)sb.org http://stoney.sb.org/

2 3

[GIL] rotated90cw_view - jpeg lossless rotation
by Jose 06 Dec '09

06 Dec '09

I rotate jpeg photos to portrait by reading the file and saving it like this: boost::gil::jpeg_write_view(file, boost::gil::rotated90cw_view(boost::gil::view(img))); results: original size: 4106172 image/jpeg 3264 2448 rotated size: 5594681 image/jpeg 2448 3264 The rotation should be lossless (as the image is a multiple of the jpeg MCU) but the size has increased significantly and the exif tags disappeared. My questions: Has it been tested that the rotation is lossless ? What can I do make sure the exif tags are preserved ? thanks jose

4 6

[GIL] gil_function_requires( view that contains alpha )
by Eloi Du Bois 06 Dec '09

06 Dec '09

Hi everybody, I would like to know if there is an easy way to check if a view type contains an alpha channel. I would do something like that (not tested): BOOST_STATIC_ASSERT(mpl::contains<typename color_space_type<Pixel>::type, alpha_t>::value); But I don't know if it is a good idea. Is there a way to do that with gil_function_requires ? Thanks & respect ! Eloi.

2 5

enable_if operator+ exists
by Zachary Turner 06 Dec '09

06 Dec '09

Is there a way to use enable_if so that one specialization gets selected if operator+ exists between two types, and another specialization if operator+ does not exist? For example: template<class A, class B, boost::enable_if<operator_plus_exists<A,B> >::type* dummy = 0> void operator()(const A& a, const B& b) { std::cout << "a + b = " << (a + b) << std::endl; } template<class A, class B, boost::disable_if<operator_plus_exists<A,B> >::type* dummy = 0> void operator()(const A& a, const B& b) { } How would I implement the operator_plus_exists class?

3 3

Re: [Boost-users] [test] Non-aligned pointer being freed
by Pete Bartlett 06 Dec '09

06 Dec '09

>>> I went ahead and applied manually the patch to the 1.41.0 release. Has >>> this patch made it into SVN Trunk? >> I think so. >> https://svn.boost.org/trac/boost/changeset/56467 >> In Christ, >> Steven Watanabe >So I see that the milestones just keep getting pushed back. Just when >exactly is this going to get rolled into an actual release? OS X 10.6 >has been out since late August and any one who uses OS X 10.6 or >compiles in 64 bit on 10.5 WILL experience this bug. I think I saw a message or two a while ago from Gennadiy asking if the release branch was open again - but didn't see any without replies. I also saw a message from Beman saying the release branch was open. So it looks like now is a really good time to get the goodies on trunk pushed across to release, if Gennadiy has the time to spare in his schedule? Pete

2 1

[spirit] alpha numeric characters
by Ovanes Markarian 06 Dec '09

06 Dec '09

Hello *, I currently use boost 1.36 to parse some input line like a->b->c-> ... I thought a, b, c can be strings containing letters or digits. Until now I thought that this defines alpha numeric characters. But when using the spirit rule: +((+alnum_p)[some_callback_func] >> str_p("->")) the some_callback_func gets as input the whole input sequence (a->b->c->...). Furthermore, it than gets called for b->c->... and than c->d->... Maybe my rule is wrong, but I can't get where. Thanks for advice, Ovanes

3 4

Non-aligned pointer being freed
by Michael Jackson 05 Dec '09

05 Dec '09

So I am running into the same issue as this thread: <http://old.nabble.com/-Boost.Test--Error:-Non-aligned-pointer-being-freed-t… > Is the patch included in that thread still safe to apply to the 1.41.0 release? _________________________________________________________ Mike Jackson mike.jackson(a)bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio

4 5

1.41.0 fails to compile on Windows 7 with Visual Studion 2008 tools
by Mike Jackson 05 Dec '09

05 Dec '09

1> C:\Users\mjackson\Workspace\boost-1.41.0.cmake0\boost/test/impl/exception_safety.ipp(518) : see reference to class template instantiation 'boost::unit_test::callback0<>' being compiled 1>C:\Users\mjackson\Workspace\boost-1.41.0.cmake0\boost/smart_ptr/shared_ptr.hpp(231) : error C2872: 'detail' : ambiguous symbol 1> could be 'boost::detail' 1> or 'boost::unit_test::detail' 1>C:\Users\mjackson\Workspace\boost-1.41.0.cmake0\boost/smart_ptr/shared_ptr.hpp(231) : error C2872: 'detail' : ambiguous symbol 1> could be 'boost::detail' 1> or 'boost::unit_test::detail' 1>C:\Users\mjackson\Workspace\boost-1.41.0.cmake0\boost/smart_ptr/shared_ptr.hpp(231) : error C2872: 'detail' : ambiguous symbol 1> could be 'boost::detail' 1> or 'boost::unit_test::detail' 1>C:\Users\mjackson\Workspace\boost-1.41.0.cmake0\boost/smart_ptr/shared_ptr.hpp(451) : error C2872: 'detail' : ambiguous symbol 1> could be 'boost::detail' 1> or 'boost::unit_test::detail' I tried both the CMake versions of 1.41.0 and the normal bjam versions. Both gave the same error. _________________________________________________________ Mike Jackson mike.jackson(a)bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio

3 6