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

Issue with compilation using XCode 4.6/GCC
by Tim Burgess 18 Nov '13

18 Nov '13

Hi, I have a project for Windows/Mac that builds fine using VS2010, but generates errors when I build using Xcode 4.6 with the GCC compiler (required, as this project also uses wxWidgets). All of my modules compile cleanly, but I get the following "orphaned" error output that doesn't seem to belong to any module: SurfaceReader Group /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp:28: '<anonymous … [View More]

1 1

Can gil library in boost 1.49 load png palette images?
by Guangchao Wang 18 Nov '13

18 Nov '13

I'm tried to load a png which can be found in the attachment, I find the color of this png is PNG_COLOR_TYPE_PALETTE and its depth is 8, I reviewed the code of png_io_private.hpp and found that no such type of PNG is supported. Can you give me some help about how to load such PNG with boost.gil library? Thank you very much. Best, Guangchao

4 6

Did build of Boost succeed - lib vs. stage/lib?
by Lutz Gehlen 17 Nov '13

17 Nov '13

Hello all, I am trying to build the Boost libraries version 1.55.0 with Visual Studio 2010 Express under Windows XP. Following the instructions in the documentation, I have unpacked the source code distribution, opened a Visual Studio command line window, and executed bootstrap .\b2 I haven't noticed any errors, and I was told in the end that I had successfully built the Boost libraries. So far, so good. I then tried to build the example program in section 6 of the Getting started guide. … [View More]

2 2

the link to the documentation for "explicit bool operator" is broken
by Adam Romanek 17 Nov '13

17 Nov '13

Dear Boosters, I've just discovered that there's a broken link to the documentation of "explicit bool operator" macro on http://www.boost.org/doc/libs/1_55_0/libs/utility/index.html WBR, Adam Romanek

2 1

Can I return std::unique_ptr in a boost::future?
by Aaron_Wright＠selinc.com 15 Nov '13

15 Nov '13

I'm trying to return a std::unique_ptr in a boost::future. I can't get it to compile. Is it possible? The code wraps a packaged_task in a functor to make it copyable enough to pass to a boost::asio::io_service, where the work will be done in another thread. The code works for other return types that are copyable. This is what I have for a small test case: std::unique_ptr< int > get_int_impl(int i) { return std::unique_ptr< int >(new int(i)); } std::unique_ptr< int > … [View More]

4 6

Re: [Boost-users] [Math] BOOST_FPU_EXCEPTION_GUARD on Linux
by David Roberts 15 Nov '13

15 Nov '13

> As I recall this was a hardware issue on early AMD 64-bit CPU's, possibly a > GLIBC issue too. In fact if I recall it was this issue: > http://sourceware.org/bugzilla/show_bug.cgi?id=2445 which didn't get much > help from the glibc guys > > But basically if any of the FPU exception flags are set prior to a call to > pow or exp, you risk getting a garbage answer back. I'll add a link to the > above in the code. > > HTH, John. That Bugzilla link was extremely … [View More]helpful - thanks! I've done a bit more research and I'm pretty sure this WAS a bug in glibc. It's fixed on recent versions of Linux though. Taking your test program from http://sourceware.org/bugzilla/show_bug.cgi?id=2445 and trying it on some different Linux versions and CPUs resulted in this: SLES 10: kernel 2.6.16.21-0.8-smp glibc 2.4 g++ 4.1.0 CPU Xeon E5-2630 FAILS CentOS 6.2: kernel 2.6.32-220.el6.x86_64 glibc 2.12 g++ 4.4.6 CPU Xeon X3450 FAILS Amazon Linux 2013.03: kernel 3.4.57-48.42.amzn1.x86_64 glibc 2.12 g++ 4.6.3 CPU Xeon E5507 FAILS OpenSuSE 12.1: kernel 3.1.10-1.16-ec2 glibc 2.14.1 g++ 4.6.2 CPU Xeon E5-2650 WORKS OpenSuSE 12.2: kernel 3.4.6-2.10-ec2 glibc 2.15 g++ 4.7.1 CPU Xeon E5-2650 WORKS Fedora 20 beta: kernel 3.11.6-300.fc20.x86_64 glibc 2.18 g++ 4.8.2 CPU Xeon E5645 WORKS This shows that the problem definitely occurs on Intel CPUs as well as AMD, and is much more likely to be caused by glibc than the compiler or the kernel. The most likely change to the glibc code that fixed the problem is this one from May 2011: http://repo.or.cz/w/glibc.git/commitdiff/8db736347c7aca3201f61e3f05b5f672bc… There was a place in powl() where 4500 decimal was used instead of 0x4500 hex. 4500 decimal is 0x1194 hex. This number was then tested against the floating point status word. The exception flags are in the low byte of this word (see http://www.nacad.ufrj.br/online/intel/Documentation/en_US/compiler_f/main_f… for the values) and as a result of the typo the presence of either FE_UNDERFLOW = 0x10 or FE_DIVBYZERO = 0x4 will cause the test to pass unintentionally. More experiments with your test program on CentOS 6.2 (glibc 2.12) seem to confirm this - if only the flags FE_INEXACT, FE_OVERFLOW and/or FE_INVALID are set they DON'T cause the weird result to occur. Given the bug was in the x86_64-specific powl() implementation and it seems to be fixed in glibc version 2.14, I think you could get away with tightening up the criteria on your guard from: #if ((defined(__linux__) && !defined(__UCLIBC__)) || defined(__QNX__) || defined(__IBMCPP__)) && !defined(BOOST_NO_FENV_H) to: #if ((defined(__linux__) && defined(__x86_64__) && !defined(__UCLIBC__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2,14))) || defined(__QNX__) || defined(__IBMCPP__)) && !defined(BOOST_NO_FENV_H) That still doesn't help people like me who have to work on current 64 bit enterprise Linux releases, but for the benefit of anyone else who stumbles across this having suffered the same performance problem, here's a hack that works OK if neither your code nor any other 3rd party library you're using cares about the floating point flags. In boost/math/tools/config.hpp change: struct fpu_guard { fpu_guard() { fegetexceptflag(&m_flags, FE_ALL_EXCEPT); feclearexcept(FE_ALL_EXCEPT); } ~fpu_guard() { fesetexceptflag(&m_flags, FE_ALL_EXCEPT); } private: fexcept_t m_flags; }; to: struct fpu_guard { fpu_guard() { if (fetestexcept(FE_UNDERFLOW | FE_DIVBYZERO) != 0) { feclearexcept(FE_ALL_EXCEPT); } } }; This is beneficial for performance because the expensive calls are feclearexcept() and fesetexceptflag(). The (more-or-less identical on Linux) fegetexceptflag() and fetestexcept() functions are much quicker. Not bothering to reset the cleared flags saves one expensive call - obviously this relies on nothing downstream caring about them. Only clearing the flags if one of the problematic ones is set often avoids the other expensive call. I've noticed that the FE_INEXACT flag is almost always set if you do any serious floating point calculation, but the other 4 flags are set much less frequently. I'm not suggesting that you put this hack into the official Boost codeline, but just thought it might be useful to anyone in my situation who finds this post via a search engine. [View Less]

2 1

concept_check() fails for types from unnamed namespace on gcc 4.2.3
by Adam Romanek 15 Nov '13

15 Nov '13

Dear Boosters! I have a problem compiling some source code that uses Boost 1.54 and gcc 4.2.3 (it's a toolchain for a MIPS platform but that's irrelevant). Basically there is a problem with checking concepts on types that come from unnamed namespaces. See the attached code example and compiler error message. Note that the same code compiles without any problems on gcc 4.6.3. I've found a question on boost-dev list [1] and a ticket [2] related to this particular issue. Note that the … [View More]

1 0

Can gil library in boost 1.49 load png palette images?
by Guangchao Wang 15 Nov '13

15 Nov '13

I'm tried to load a png which can be fund in the attachment, I find the color of this png is PNG_COLOR_TYPE_PALETTE and its depth is 8, I reviewed the code of png_io_private.hpp and found that no such type of PNG is supported. Can you give me some help about how to load such PNG with boost.gil library? Thank you very much. Best, Guangchao

1 0

boost::serialization warnings for template class
by Michele Vallisneri 15 Nov '13

15 Nov '13

Dear Boost experts, I'm serializing (intrusively) a template class Matrix<T> that includes a double-pointer buffer of data of type T. So my save/load pair looks like template<class Archive> void save(Archive & ar, const unsigned int version) const { ar & row_dim; ar & col_dim; for ( size_t i = 0; i < row_dim; i++ ) for ( size_t j = 0; j < col_dim; j++ ) { ar & value[i][j]; … [View More] } } template<class Archive> void load(Archive & ar, const unsigned int version) { size_t rowdim, coldim; ar & rowdim; ar & coldim; resize( rowdim, coldim ); for ( size_t i = 0; i < rowdim; i++ ) for ( size_t j = 0; j < coldim; j++ ) ar & value[i][j]; } The type of value is T**. The serialization works OK, but I'm getting some warnings that lead me to suspect that Boost is trying to track the addresses of the value[i][j] elements, which is not needed, and presumably a problem for performance. g++ -c -m64 -O3 -Wall -I../../include -I/usr/depot/redhatel5_64/boost/1.48.0/include -o Linux-x86_64/obj/test_Matrix.o test_Matrix.cpp /usr/depot/redhatel5_64/boost/1.48.0/include/boost/mpl/print.hpp: In instantiation of 'boost::mpl::print<boost::serialization::BOOST_SERIALIZATION_STATIC_WARNING_LINE<98> >': /usr/depot/redhatel5_64/boost/1.48.0/include/boost/serialization/static_warning.hpp:92: instantiated from 'boost::serialization::static_warning_test<false, 98>' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/detail/check.hpp:98: instantiated from 'void boost::archive::detail::check_object_tracking() [with T = gcore::Matrix<int>]' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/detail/oserializer.hpp:313: instantiated from 'static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = gcore::Matrix<int>, Archive = boost::archive::text_oarchive]' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/detail/oserializer.hpp:525: instantiated from 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive, T = gcore::Matrix<int>]' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/detail/common_oarchive.hpp:69: instantiated from 'void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = gcore::Matrix<int>, Archive = boost::archive::text_oarchive]' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/basic_text_oarchive.hpp:80: instantiated from 'void boost::archive::basic_text_oarchive<Archive>::save_override(T&, int) [with T = gcore::Matrix<int>, Archive = boost::archive::text_oarchive]' /usr/depot/redhatel5_64/boost/1.48.0/include/boost/archive/detail/interface_oarchive.hpp:63: instantiated from 'Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = gcore::Matrix<int>, Archive = boost::archive::text_oarchive]' test_Matrix.cpp:43: instantiated from here /usr/depot/redhatel5_64/boost/1.48.0/include/boost/mpl/print.hpp:55: warning: comparison between signed and unsigned integer expressions Is my suspicion correct, and how do I change my code to avoid the warnings (and performance hits, if any)? Thanks! Michele [View Less]

1 0

Boost 1.55 and warning in Boost.Circular
by gast128 14 Nov '13

14 Nov '13

Hello all, I just dl 1.55 and I got a warning: D:\Develop\SDK and Libraries\boost_1_55_0\boost/circular_buffer/base.hpp(199): warning C4172: returning address of local variable or temporary Code is crytpic due to all the templates. Is this a client error?

1 2