- Boost - lists.boost.org

Re: [boost] [Boost-users] Overloading boost::for_each()
by David Abrahams 30 Aug '10

30 Aug '10

At Mon, 30 Aug 2010 00:43:57 +0100, Mathias Gaunard wrote: > > Of course, for certain data structures, providing a step-generator, as I > call it, can still be too complicated, and they could only have a > 'global' generator, which, in the case or our deque, would be: > > template<typename T> > struct deque_generator > { > typedef T output_type; > > deque_generator(deque& deq_) : deq(deq_) {} > > template<typename Out> > Out operator()(Out out) > { > for(typename deque::const_iterator it = deq.begin(); it != > deq.end(); ++it) > out = copy(*it++, out); > return out; > } > > private: > typedef vector< array<T, whatever> > deque; > deque &deq; > }; > > In the case of a global generator, implementing algorithms such as > std::accumulate should be basically the same thing as the > string_appender example here: > <http://www.boost.org/doc/libs/1_44_0/libs/iterator/doc/function_output_iter…> > In the case of the step one, it's the same except you need to do it in a > loop. [Followup-To set to the developers' list, as this doesn't seem like a boost-users discussioin anymore.] Hi Mathias, Thanks, but you only answered the first part of my question. I don't understand how you'd use such a thing. Thanks again. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

Attibutes and Qi
by Steffen.Roeber＠hella.com 30 Aug '10

30 Aug '10

Hi, I used the classic spirit in the past. Now I want to migrate to Spirit 2.4 but I don't get the things together.Reading the different docus in the web did not help. What I want to do at first is to parse a simple string into a QString: My pseudo code looks like: QString t; qi::rule<string::iterator, QString()> r1 = (+qi::char_)(qi::_val = qi::_1); qi::rule<string::iterator , void()> r = r1[ref(t) = _1]; std::string temp("Hallo"); phrase_parse(temp.begin(), temp.end(), r, qi::space); But the compiler does no like this. Can anybody help me? Hella Aglaia Mobile Vision GmbH Steffen Roeber Firmware & Tools Treskowstr. 14, D-13089 Berlin Amtsgericht Berlin-Charlottenburg HRB 66976 B Geschäftsführer: Kay Talmi Fon: +49 30 200 04 29? 412 Fax: +49 30 200 04 29? 109 Mail: Steffen.Roeber(a)hella.com URL: www.aglaia-gmbh.de URL: www.mobilevision.de Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe sowie Vervielfältigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdrücklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere für den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights.

3 4

[Smart Pointers] compilation error with ver 1.44 and VC 9
by Löw, Tobias (Evonik Energy Services GmbH) 29 Aug '10

29 Aug '10

Hi, after switching to version 1.44 my projects using make_shared won't compile anymore. I'm using the VC 9 compiler on a Windows 2003 Server. I'm confused that nobody else seems to have the same problem with make_shared, so here is a small example: /////////////////////////////////////////////////////////////////////////////// #define BOOST_NO_TYPEID #include <boost/smart_ptr.hpp> #include <boost/make_shared.hpp> struct test { test(){} int i; }; int main(int argc, char* argv[]) { boost::shared_ptr<test> spt = boost::make_shared<test>(); return 0; } ///////////////////////////////////////////////////////////////////////////////// this compiles fine with Boost 1.43, but with version 1.44 I get the following error: boost/detail/sp_typeinfo.hpp(77) : error C2440: 'Initialisierung': 'const char *' kann nicht in 'boost::detail::sp_typeinfo' konvertiert werden (in english: 'const char *' cannot be converted to 'boost::detail::sp_typeinfo') In version 1.43 the line in sp_typeinfo.hpp(77) was: template<class T> sp_typeinfo sp_typeid_≤ T >::ti_( sp_typeid_≤ T >::name() ); so, the explicit-marked ctor was called. In version 1.44 it changed to template<class T> sp_typeinfo sp_typeid_≤ T >::ti_ = sp_typeid_≤ T >::name(); and the explicit-marked ctor won't be called anymore. The change message (https://svn.boost.org/trac/boost/changeset/62245/trunk/boost/detail/sp_type…) refers to some fix for Sun C++. IMO the change should better be guarded by some compiler/platform-detection macro. Tobias PS: I already posted this message on 18 Aug but accidentially as a reply to another thread.

2 2

[Potentially OT] String Concatenation Operator
by Dean Michael Berris 29 Aug '10

29 Aug '10

Good day everyone, I am currently taking some time to implement some functionality into cpp-netlib [0] (shameless plug) and somehow I've stumbled into a sort of conundrum. First, some background: I'm trying to abstract away the string building routines of the network library to come up with the most efficient way of doing the following: 1. Efficiently allocate space to contain a string being built from literals and variable length strings. 2. Be able to build/traverse the string lazily (i.e., it doesn't matter that the string is contiguous in memory as in the case of C-strings, or whether they are built/backed by a stream as in Haskell ByteString). 3. As much as possible be "automagically" network-safe (i.e. can be dealt with by Boost.Asio without having to do much acrobatics with it). At the heart of the issue is the semantics of the '+' operator to signify string concatenation. Trying not to sound pedantic about it, the addition operator in traditional mathematical notions is both commutative and associative, while string concatenation is not commutative but right associative. Trying to remember my C++ operator precedence and associativity rules, it looks like operator% and/or operator^ might be good candidates for this, but only in expression templates where you fold from the right. Now I don't want to start beating on the STL's standard string implementation, but I'd like to know if anyone is already working on a string implementation that meets the above requirements? I'd be happy to wait on compile times with Proto, if it means I can save big at runtime. What I wanted to be able to do (and am reproducing at the moment) is a means of doing the following: string_handle f = /* some means of building a string */; string_handle s = str("Literal:") ^ f ^ str("\r\n\r\n"); std::string some_string = string_handle; // convert to string and build lazily If for instance f were also a literal, then s can efficiently already hold the string in some fixed sized byte array whose size is determined at compile time. Somehow the function str() would only be able to take a literal and look something like this: template <size_t N> inline bounded_fragment<N> str(char const s[N]) { return bounded_fragment<N>(s); } The evaluation of the assignment (or copy constructor) of the string_handle will then evaluate the expression template and already know at compile time: A. Whether the string is just a long literal and allocate enough space to effectively hold the whole string at compile time, or at least reserve enough space statically (a boost::array perhaps) so that a simple range copy can be done (and optimized by the compiler as well) B. Whether the string is a list of variable length strings, having a list of handles built C. Whether it is a mix and have all the adjacent literals joined effectively at compile time and those variable sized strings retrieved when required Pointers to ongoing work would be most appreciated -- I'm currently too preoccupied to chase this particular rabbit down the hole (I'm chasing a different rabbit in a different hole) but maybe this is an interesting enough problem for the template metaprogramming guru's to look into? Thanks in advance and I look forward to any thoughts/pointers. -- Dean Michael Berris deanberris.com

6 14

[Castor] FYI : Castor 1.1 & Boost
by Roshan 29 Aug '10

29 Aug '10

A quick update for the many who expressed interest in the Castor library at the "Logic Paradigm for C++" talk at this year's BoostCon and also folks on the dev mailing list when I polled for interest. Castor 1.1 that was recently released and it will form the basis for the version that will be proposed to Boost. http://www.mpprogramming.com/announce.aspx Among other things, version 1.1 enables support for Coroutines and Query Expressions in C++. There are a couple of videos describing 1.1 specific enhancements at http://www.mpprogramming.com/cpp/default.aspx#Videos Boost Porting: The initial Boost related work has begun (thanks to Zach Laine who has done pretty much all of the work so far). Besides incorporating user feedback and changes that make it conformant to Boost guidelines... my intention is to hopefully include a few significant enhancements. Volunteers welcome! Project sources are currently hosted at http://sourceforge.net/projects/castor-logic/ - Roshan Naik

4 8

[python] 32-bits target build errors with MSVC under Windows x64
by KTC 29 Aug '10

29 Aug '10

Hi, Attempts to build 32-bits target libraries/dll of Boost.Python with MSVC running under Windows 7 x64 ends with errors. The 6 *.lib & *.dll of the form boost_python-vc*-mt* are not built. No problems is experienced if MSVC is running under 32-bits version of Windows (XP Pro SP3 & 7 Ultimate tested), or the target is 64-bits libraries even when running under Win7 x64. The below (sample) errors was produced with Windows 7 Ultimate x64, Visual Studio (2008 Pro & 2010 Ultimate tested), and ActiveState ActivePython (2.6 & 2.7 tested). msvc.link.dll x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.dll Creating library x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.lib and object x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.exp function.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Format referenced in function "void __cdecl boost::python::numeric::`anonymous namespace'::throw_load_failure(void)" (?throw_load_failure@?A0x9a30ad83@numeric@python@boost@@YAXXZ) from_python.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format registry.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2001: unresolved external symbol __imp__PyExc_ImportError numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Clear referenced in function "bool __cdecl boost::python::numeric::`anonymous namespace'::load(bool)" (?load@?A0x9a30ad83@numeric@python@boost@@YA_N_N@Z) class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Clear <snip> (Full log can be view at <http://pastebin.com/b62UaEJV>.) Any ideas of a workaround or fix? Regards, KTC

1 0

Some modifications to the Boost random library
by Eric Hopper 28 Aug '10

28 Aug '10

I have written a new class for small random integers and made some slight modifications to the mersenne twister generator that allow me to generate random numbers approximately 2-4 times faster than the current small integer distribution. Would there be interest in these modifications? I have made some attempt to make the code conform to boost standards, but in reality the new class won't work on any compiler that doesn't have robust support for static constant integers. Thanks, -- A word is nothing more or less than the series of historical connotations given to it. That's HOW we derive meaning, and to claim that there is an arbitrary meaning of words above and beyond the way people use them is a blatant misunderstanding of the nature of language. -- Anonymous blogger -- Eric Hopper (hopper(a)omnifarious.org http://www.omnifarious.org/~hopper)--

2 1

[fusion] Problems with push_back/push_front/insert into map
by Alexander Fokin 28 Aug '10

28 Aug '10

Consider the following program: #include <iostream> #include <boost/fusion/algorithm.hpp> #include <boost/fusion/container.hpp> #include <boost/fusion/sequence.hpp> int main() { using namespace boost::fusion; map<> m; result_of::push_back<const map<>, pair<int, int> >::type m1 = push_back(m, pair<int, int>(0)); bool b1 = has_key<int>(m1); // b1 == false bool b2 = has_key<int>(as_map(m1)); // b2 == true int sz = size(m1); // sz == 1 return 0; } According to documentation [1], result of push_back is a model of Associative Sequence if its sequence parameter implements the Associative Sequence model. Therefore, I'd expect the variable b1 to be evaluated to true, not false. Is this the intended behavior? I get the same results with push_front and insert. Tested with boost 1.43 and 1.44. [1] http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/algorithm/… -- Best regards, Alexander Fokin, ru.elric(a)gmail.com.

2 2

Re: [boost] [msm] Async transition
by Christophe Henry 27 Aug '10

27 Aug '10

> Thanks for your answer. > > It was in fact a question from my employer that asked if msm allows to > do the same as the last example of the statechart doc : > http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/tutorial.html > (at the end of the page). It depends. As the event processing function of msm is reentrant thanks to the message queue, you have no risk in single threaded programs. In multithreaded programs, you will need to protect the access to process_event. > It's not a requirement, just a technical question because from my > understanding of UML, state regions should be managed separately and I > thought maybe they were threaded in some way. We wanted to be sure of > the whole behaviour before starting testing it. What UML writes about regions is that they are "logically" concurrent, meaning (IIUC) that they each get a chance to handle an event. MSM is implemented this way, each region being called in turn (in the order of the initial_state typedef). Of course, doing this concurrently would speed up event processing at the cost of predictability (if regions sent events to each other, you could not know which is processed first). > Anyway I see that I should treat the state machine like a STL > component in regards to thread-safety and asynchronous event > management. Yes, I also tend to see it that way. >As it's not a requirement, it's not a problem for me but I > was asking myself if there would be an interest in having the event > processing being thread-safe, allowing multiple threads to send > events? Maybe like haveing a msm2 like signals2? > I'm not experienced enough to see if it would be a good idea and I > don't need it so it's just a theorical question. As I don't see msm as a library closed for changes, there is no need for a msm2 yet ;-) I'm working on the next version so if there is a need, I will happily implement it. I've been thinking about thread safety for a while but failed to see a huge gain. I could replace: lock() // whatever you need for locking fsm.process_event(event()); unlock(); by: fsm.process_event(); where process_event would lock at the beginning and unlock at the end, but it seems pretty limited. This leaves us with the valid use case of concurrent region processing. I don't see any other yet, but I'd be interested if someone does as it's a subject I'll want to handle of at some point. Regards, Christophe

2 1

[serialization] register_type order dependent?
by Jeff Flinn 27 Aug '10

27 Aug '10

Is it expected that the calls to register_type need to be identical on both the save and load side of a serialization exchange? I thought I read that the registration facility sets up a map. But the following caused a archive_exception. struct C {}; struct B : C {}; struct A : B {}; --- save boost::archive::text_oarchive oa(some_ostream); oa.register_type(static_cast<A*>(0)); oa.register_type(static_cast<B*>(0)); oa.register_type(static_cast<C*>(0)); oa & aC_ptr; --- load boost::archive::text_iarchive ia(some_istream); ia.register_type(static_cast<B*>(0)); ia.register_type(static_cast<A*>(0)); ia.register_type(static_cast<C*>(0)); oa & aC_ptr; Thanks, Jeff

3 3