August 2008 - Boost - lists.preview.boost.org

For those who have/know well the g++ 4.3.0 library
by Gennaro Prota 23 Aug '08

23 Aug '08

Hi, looking at the trunk regression report for dynamic_bitset, there's a stream inserter failure on gcc 4.3.0 which puzzles me :-) It's on Sandia-gcc, and happens only when -std=gnu++0x is absent. Any clue? -- Genny

1 0

[mpl, fusion] minimal conforming sequence
by Peter Dimov 23 Aug '08

23 Aug '08

Hi, Assume that I have a custom type sequence S that has two operations, size<S>::value and element<S,I>::type (with whatever spelling). What needs to be done to adapt S into a conforming MPL or Fusion sequence? In a perfect world, the answer would not require the inclusion any MPL or Fusion headers and would consist of three specializations. ;-)

3 4

New libraries should provide forward declarations?
by Peter Bartlett 22 Aug '08

22 Aug '08

Hi Boost community, Would it practical to add a rule of thumb to the developer guidelines that library developers should offer a fwd declaration header for their library when possible? For me the rationale is as follows: - Boost headers are relatively heavy includes - Pre-compiled headers are only available on a subset of compilers. - Client side forward declarations are often problematic. E.g. - - Boost.Tuple: redeclarations of default template arguments are illegal (although MSVC lets you do it if you are prepared to suffer a warning) so including boost/tuple.hpp after mylibraryutils/boost_tuple_fwd.hpp is illegal. - - Boost.Function : The removal of the allocator template parameter has broken our code when we experimentally checked the 1.36 beta, as our forward declarations of Boost.Functions are now wrong. The existence of boost/tuple/tuple_fwd.hpp and boost/function/function_fwd.hpp would thus have significantly improved the user experience in my case. Thanks for listening, Pete Bartlett

6 10

[log] Filter bug (Andrey? :)
by Boris 22 Aug '08

22 Aug '08

Andrey, can you tell me why the following program writes the second message? ---------- #include <boost/log/sources/severity_logger.hpp> #include <boost/log/logging_core.hpp> #include <boost/log/utility/init/to_console.hpp> #include <boost/log/utility/init/to_file.hpp> #include <boost/log/utility/init/common_attributes.hpp> #include <boost/log/formatters/format.hpp> #include <boost/log/formatters/attr.hpp> #include <boost/log/formatters/date_time.hpp> #include <boost/log/formatters/message.hpp> #include <boost/log/filters/attr.hpp> #include <boost/shared_ptr.hpp> enum severity_level { info, warn, error }; boost::log::sources::severity_logger logger; int main() { boost::shared_ptr<boost::log::sinks::synchronous_sink<boost::log::sinks::text_ostream_backend>> sink = boost::log::init_log_to_file("test.txt"); boost::log::add_common_attributes(); sink->locked_backend()->set_formatter(boost::log::formatters::format("[%1%] %2%") % boost::log::formatters::attr("Severity") % boost::log::formatters::message()); sink->locked_backend()->auto_flush(true); boost::log::logging_core::get()->set_filter(boost::log::filters::attr<int>("Severity") > info); BOOST_LOG_SEV(logger, warn) << "first message"; // Message is not written. boost::log::logging_core::get()->set_filter(boost::log::filters::attr<int>("Severity") < warn); BOOST_LOG(logger) << "second message"; // Why is this message written?? } ---------- The first message is not written as the severity level warn is greater than info. However for the second message the default severity level info is smaller than warn. Thus I would expect the second message is not written either? Is this a bug? Boris

2 4

[range] No iterator_range::const_reference
by Francois Barel 22 Aug '08

22 Aug '08

Hi list, boost::iterator_range currently contains both 'iterator' and 'reference' typedefs, and yet only a 'const_iterator' one (no 'const_reference'). This can be a problem with Spirit actions (compilation errors, see trac ticket #2234 - http://svn.boost.org/trac/boost/ticket/2234) After removing Spirit code, it boils down to: //////////////////// #include <boost/spirit/include/phoenix_stl.hpp> #include <boost/range/iterator_range.hpp> int main() { typedef const boost::iterator_range< const char* > cir; boost::phoenix::stl::front::result< cir > foo; // compilation error return 0; } //////////////////// The problem comes from the instantiation of boost::phoenix::stl::front::result< const iterator_range<...> > which, since its template argument is const, accesses its const_reference typedef -- which doesn't exist in iterator_range. Does it make sense / is it possible to add a const_reference typedef in iterator_range? Thanks, Francois

3 2

boost for embedded?
by Fleming, Edward 22 Aug '08

22 Aug '08

Newbie question if anyone can help: Is there a makefile for building boost (especially regex) with a Microsoft compiler for Windows Embedded CE/Mobile (ARM platform)? Any information would be appreciated! (howto, location of makefile, etc.) Thanks, Ed ------------------------- This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation

3 2

_ReadWriteBarrier as memory fence, or not?
by Simon Thornington 22 Aug '08

22 Aug '08

Hi folks, Quick question about the use of _ReadWriteBarrier (Win32 MSVC): According to http://msdn.microsoft.com/en-us/library/ms684208(VS.85).aspx , this compiler intrinsic doesn't generate any memory fencing instructions at all, it's strictly a compiler optimization barrier. I was wondering if someone had any documentation to contradict this, or if boost is relying on the new volatile semantics in VC2005 to ensure the fence? It sure looks like it's being used as if it were a real memory fence, but I am not sure that's the case. I'm not an expert though. Cheers, Simon.

5 8

[fsm review] Not quite a review
by Darryl Green 22 Aug '08

22 Aug '08

I don't know if I will have time to do a proper review of the library. The following are my notes on it so far. I've read the documentation for the libary, but haven't tried to use it. Good points: Simple. Relatively fast at runtime. Docs are quite good, but perhaps lack enough rationale style documentation on how the library models FSM concepts. Would benefit from some "how to" examples of more realistic usage and some "how to" docs on translating FSMs expressed using UML (or Harel) statecharts into a form implementable using FSM. Bad points: Unusual terminology. While there are obvious performance reasons for avoiding the Boost Statechart approach of applying an RAII model to state activation, it is not clear why at least basic concepts and terminology have not been used in FSM - especially as most Statechart terminology and FSM behavioural concepts are straight from UML terminology (it is a standard, you could pick another one, but why not stick with this one)? Note that this is *not* a request that the library include more features - just for some consistent ones. Some idiosyncratic behaviour. The FSM delivers the event to the on_process() handler in the "switched to" state when the transition is specified using the transition map, while delivering it to the on_process() handler in the current state if no transition map entry matches. There are warnings against mixing the transition map and switch_to() approaches to FSM specification, but even so it seems that the 2 uses of the on_process() handler are completely different. Would it not be better to have a model similar to Boost.Statechart where a custom reaction (implemented by a react() method) in a state is used to perform actions within the start state, generally including making a (gated) transition, while any action to occur on a transition is specified as part of the transition? Further, that transition action should be performed after the exit action of the current state and before the entry action of the new state. No event queuing mechanism, so no way to post an event while processing an event - although I see there has been some discussion about adding event deferral - which might be (almost) enough. Slow at compile time. I have not tested as yet, but if it is as slow as the mpl example state machine implementation, this will be a problem (I have previously had to abandon use of the MPL FSM due to compilation time issues on only moderately complex FSMs). Lacks real world use? I don't know if that is true, but I haven't seen anything other than toy examples. I was thinking that in the cases where the performance of Statechart was inadequate for complex augumented FSM implementation I would consider using FSM - but it would mean building a fair bit of additional scaffolding around FSM - maybe this should be part of the library? Or at least some examples of ideomatic use should be included? I found myself wondering if anyone had actually tried to use it in this way? Conversely, I don't find it compelling for implementing something like a lexer or even the terminal emulator example. What is the application domain? Not quite a conclusion: This is a hard one. At one extreme, Boost.Statechart is extremely powerful and well worth using in certain application domains (but there are performance implications), and at the other, as has been illustrated, various hand-rolled solutions of varying degrees of elegance get the job done. There seems to be a lot of space in between, and I'm not sure that the proposed FSM library fills enough of it.

2 3

[lambda][bind] trivial bind fails when lambda and bind are in the same source file
by Michael Marcin 22 Aug '08

22 Aug '08

My environment is VC9 SP1 and Boost 1.35. This problem also occurs in boost 1.36. I had some code using lambda which worked fine for several weeks until today when someone else included my header in his code which used bind. He told me my code was broken but my tests ran fine. It took us a few minutes to find the problem and I've distilled it to this trivial reproducible case. #include <boost/bind.hpp> #include <boost/lambda/bind.hpp> void foo( int ) { } int main() { using namespace boost::lambda; bind( &foo, _1 ); } Compiling this gives: error C2872: '_1' : ambiguous symbol 1> could be 'c:\vfx\third_party\boost\1_35_0\boost\lambda\core.hpp(69) : boost::lambda::placeholder1_type &boost::lambda::`anonymous-namespace'::_1' 1> or 'c:\vfx\third_party\boost\1_35_0\boost\bind\placeholders.hpp(42) : boost::arg<I> `anonymous-namespace'::_1' 1> with 1> [ 1> I=1 1> ] I can make the problem go away by changing main to int main() { using boost::lambda::_1; using boost::lambda::bind; bind( &foo, _1 ); } but the actual code uses a lot more lambda and the amount of using directives I would need makes the code longer than rolling my own functor. I could also alias lambda to make main look something like int main() { namespace bll = boost::lambda; bll::bind( &foo, bll::_1 ); } but this introduces a lot of noise into the lambda expression and makes complex lambdas unreadable. Is this accepted behavior? Thanks, Michael Marcin

4 5

[boost exception]complaint
by Robert Ramey 22 Aug '08

22 Aug '08

In the course of investigating some issues with the serialization library I had occasion to investigate boost/throw exception.hpp . I understood the original purpose of this header was to provide support for throw for both compilers which implemented exceptions and those that didn't (e.g. some embedded systems environment). Looking through this header - it seems that its function has changed completely. It now drags in a lot of machinery that no one who was using it before will need. It seems that the whole purpose of the header has been changed. I did review the documentation for boost exception and indeed, it now seems that boost/throw_exception does implement a different purpose. Besides imposing the requirement for RTTI - I have no idea what else this might break. Should all users of throw_exception be advised to recode? Could we not restore the orginal boost/throw_exception and make a differently named file like boost/exception/???.hpp. This would provide all the benefits of the new library to those who want and require them without requiring changes all over the rest of boost. Robert Ramey

7 15