- Boost-users - lists.boost.org

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 > get_int(int i) { typedef boost::packaged_task< std::unique_ptr< int > > Task; boost::shared_ptr< Task > task = boost::make_shared< Task >(boost::bind(&get_int_impl, 42)); boost::unique_future< std::unique_ptr< int > > future = task->get_future(); // <--- Error from this line. m_service.post(boost::bind(&Task::operator(), task)); return future.get(); } BOOST_AUTO_TEST_CASE(test_get_int) { BOOST_CHECK_EQUAL(*get_int(42), 42); } The error: boost/thread/future.hpp(239): error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>' --- Aaron Wright

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 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.

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 ticket was closed with "worksforme" resolution, which I don't understand - the problem is still out there. Now since Boost's minimal requirements are gcc 3.3 [3] then should I consider it a bug that I should report or is it a known issue? In case the latter is true then what should I do? [1] http://boost.2283326.n4.nabble.com/concept-check-fails-with-types-declared-… [2] https://svn.boost.org/trac/boost/ticket/2037 [3] http://www.boost.org/users/history/version_1_55_0.html WBR, Adam Romanek

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 14 Nov '13

14 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]; } } 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

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

Boost.Log: Set formatter for named_scope attr.
by David Puffer 14 Nov '13

14 Nov '13

Hi, Being new to Boost.Log (and Boost in general) I have spent the last few days trying to implement Boost.Log - which Is working fairly well by now. However - I encountered one problem that I've not been able to solve by now, although it seems to me quite trivial: I have successfully registered the "named_scope" attribute and I am populating its value by a call to BOOST_LOG_FUNCTION. This works well and I can see the function-name in my log-output. However - I also want the line-number and the file-name, and discovered that there's a possibility to set the output-format of the "named_scope" attribute (which already incorporates file-name and line-number info) like so: #include <boost/log/expressions/formatters/named_scope.hpp> sink->set_formatter(expr::stream << expr::format_named_scope("Scopes", "%n")); As documented here: http://www.boost.org/doc/libs/1_54_0/libs/log/doc/html/log/detailed/express… I just don't seem to find any way to get to my sink - which is configured in a settings-file and evaluated by a call to the init_from_stream() function. Is there any way to query for all the sinks - or get a sink by name? How is one supposed to set a sink formatter for a sink which was generated by the library and not the user? Or is there a way to specify the output-format for named attributes via a settings-file as well? As far as I can see it's only possible to format the output of a log record as a whole - but not single attributes. Also: Is it correct, that the above function will only set the format for the "Scopes" attribute - which means I could call this function repeatedly for lets say the "TimeStamp" attribute as well? Best regards, David

2 2

[Log] Error with operator<< in basic_formatting_ostream
by Víctor Yo 14 Nov '13

14 Nov '13

Hi ewveryone, I'm working lately with Boost.Log (I'm a newbie) library and I want to write a logger with some parameters and formatting options. I followed the documentation, I created a backend and a frontend and I tried to format the output in the frontend with the set_formatter() function. I tried with the Lambda style and with the Boost.Format style but I'm getting an error that I can not locate. Iwas working on it for the last two whole days but I couldn't find a solution. It is related with the basic_formatting_ostream, but I don't understand what that means. I defined the backend and attached to it two streams (to a file and to cout) typedef boost::log::sinks::text_ostream_backend our_backend; typedef boost::log::sinks::synchronous_sink<our_backend> our_frontend; //............................................................................................................................................ boost::shared_ptr<our_backend> backend = boost::make_shared<our_backend>(); //Stream definitions boost::shared_ptr<std::ostream> stream_out(&std::cout, boost::log::empty_deleter()); boost::shared_ptr<std::ostream> stream_file(new std::ofstream("file_logger.log")); backend -> add_stream(stream_out); backend -> add_stream(stream_file); Created the frontend (and wrapping the backend to it) //Wrap the backend into the frontend and register in the core. //The frontend provides synchronization for the backend. boost::shared_ptr<our_frontend> frontend(new our_frontend(backend)); And now come the offending code which is supposed to format the output (note that the first commented block was my first try). None of them works and the error is the same in both cases: */*frontend -> set_formatter* * (* * boost::log::expressions::format("[%1%] %2%, File: %3%, Line: %4% <%5%>: %6% ")* * % boost::log::attributes::counter< unsigned int >(1)* * % boost::log::attributes::local_clock()* * % boost::log::expressions::attr< severity_level >("Severity")* * % boost::log::expressions::message* * );*/* //We are going to define the formatter in a different style to try to get formatted output frontend -> set_formatter ( boost::log::expressions::stream << boost::log::attributes::counter< unsigned int >(1) <<" ["<< boost::log::attributes::local_clock() <<"] <"<< boost::log::expressions::attr< severity_level >("Severity") <<"> "<< boost::log::expressions::message ); The error I get is the next one: */home/victor/Programacion/workspace/opice/build-parallel/../libs/include/boost/log/utility/formatting_ostream.hpp:664:5: error: no match for ‘operator<<’ in ‘(& strm)->boost::log::v2_mt_posix::basic_formatting_ostream<CharT, TraitsT, AllocatorT>::stream [with CharT = char, TraitsT = std::char_traits<char>, AllocatorT = std::allocator<char>, boost::log::v2_mt_posix::basic_formatting_ostream<CharT, TraitsT, AllocatorT>::ostream_type = std::basic_ostream<char>]() << value’* And I really don't know what is happening. I also included a lot of files (I'm sure I included too much files, indeed) to be sure it was not caused by some undefined operator or something similar. However I still have the same problem. The includes are: #include <iostream> #include <fstream> #include <string> #include <boost/thread/shared_mutex.hpp> #include <boost/log/core.hpp> #include <boost/log/common.hpp> #include <boost/make_shared.hpp> #include <boost/log/expressions.hpp> #include <boost/log/utility/setup/file.hpp> #include <boost/log/utility/setup/console.hpp> //puede ser innecesario #include <boost/log/utility/setup/common_attributes.hpp> //puede ser innecesario #include <boost/log/utility/empty_deleter.hpp> #include<boost/thread/mutex.hpp> #include <boost/log/attributes/timer.hpp> #include <boost/log/attributes/mutable_constant.hpp> #include <boost/log/sources/severity_logger.hpp> #include <boost/log/utility/formatting_ostream.hpp> #include <boost/log/sinks/text_ostream_backend.hpp> #include <boost/log/sinks/sync_frontend.hpp> #include <boost/log/support/date_time.hpp> As you can see, they are probably redundant or innecessary but I could rip off that files when I could get the program compiled. Now, I'm out of ideas so any help you could bring me should be very appreciated. Thank you in advance. Victor Hevia

2 4

[1.55] PDF Documentation build available.
by John Maddock 14 Nov '13

14 Nov '13

The final PDF documentation build for Boost-1.55 is now available at https://sourceforge.net/projects/boost/files/boost-docs/1.55.0/ As ever this only contains documentation for the subset of Boost libraries that use quickbook/boostbook/docbook based documentation. Enjoy! John.

1 0

Boost 1.54.0 Header Warnings: Shadowed Variables
by Tom Browder 13 Nov '13

13 Nov '13

I am trying to use Boost 1.54.0 to replace a previous version (1.47) and am using g++ 4.7 with most warnings turned on. I am getting many -Wshadow errors and wonder why they exist. Surely the developers test for such. Here is one example from xpressive/detail/utility/hash_peek_bitset.hpp: Both 'icase' and 'count' are reported to shadow members of 'this'. Note that the bool arg is named 'icase' but the compiler reports 'this' has a member named 'icase' (as can be plainly seen below). In this example it's fairly clear what is intended, but then again maybe not (and it doesn't give the user much confidence in the code). It isn't good practice IMHO to do such so that is why I like to use some prefix or suffix to disambiguate the two variables. // Make sure all sub-expressions being merged have the same case-sensitivity bool test_icase_(bool icase) { std::size_t count = this->bset_.count(); if(256 == count) { return false; // all set already, nothing to do } else if(0 != count && this->icase_ != icase) { this->set_all(); // icase mismatch! set all and bail return false; } this->icase_ = icase; return true; } I could file many bugs but it begs the question of why the warnings are allowed in the first place. Suggestions? Thanks and best regards, -Tom

8 17