May 2009 - Boost-users - lists.boost.org

[Serialization] BOOST_CLASS_EXPORT_GUID macro failed to compile with C2888 error.
by Vitaly Dolya 12 May '09

12 May '09

Hi, All! BOOST_CLASS_EXPORT_GUID macro failed to compile with error: error C2888: 'boost::archive::detail::`anonymous-namespace'::init_guid<CSomeClass>' : symbol cannot be defined within namespace 'anonymous-namespace'. Same code compiles properly using boost 1.37. Looks like a bug to me. Using: - boost 1.39 - Microsoft Visual Studio 2008 SP1

1 0

Tips on implementing a function queue with unique queue items (compare function problem)
by Peter Åberg 12 May '09

12 May '09

Hi, Anyone have a tip or pointer regarding how to implement a function queue with unique items? Comparing C++ delegates seems to be hard in general (http://www.boost.org/doc/libs/1_39_0/doc/html/function/faq.html#id1877737) but there are probably workarounds that are alright. It would be nice of course if the queue user stays unaffected by the workaround but that is probably not possible. Another layer perhaps. Any suggestion for the code below? class UniqueFunctionQueue { public: typedef boost::function<void()> QueueItem; public: void push(QueueItem item) { /* ToDo, would be nice to do: if (item is already in the queue) return; */ queue.push_back(item); } void execute() { for(std::deque<QueueItem>::iterator i = queue.begin(); i != queue.end(); i++) (*i)(); queue.clear(); } private: std::deque<QueueItem> queue; }; .... UniqueFunctionQueue queue; queue.push(boost::bind(&Synchronizer::sync, &synchronizer, LeftToRight)); queue.push(boost::bind(&Synchronizer::sync, &synchronizer, RightToLeft)); queue.push(boost::bind(&Initializer::init, &initializer)); queue.push(boost::bind(&Synchronizer::sync, &synchronizer, LeftToRight)); // Should not be added since there is one in the queue already. queue.execute(); Thanks, Peter Åberg

3 2

Incomplete types and intrusive_ptr
by Dominique Devienne 12 May '09

12 May '09

Is it possible to achieve the ability of shared_ptr<T> to be used as a class member in a class declaration with an incomplete type T, with intrusive_ptr? For new code, I'm wrapping classes in shared_ptr, instead of deriving from our refcounted base class. I've also started to use intrusive_ptr for all the legacy code that already derives from RefCountedBase, but unlike shared_ptr I'm forced to #include the header for the type wrapped in the intrusive_ptr, something I'd like to avoid, to reduce build times. Isn't it possible to have a mix of shared_ptr and intrusive_ptr which also captures a Destructor instance when the intrusive_ptr is assigned, similarly to what shared_ptr does? Has this been considered before? Thanks, --DD PS: We have full control of RefCountedBase, so would refactoring it to use boost::detail::shared_count internally allow the change I discuss above? If so, how would one go about it?

2 2

[boost.stringalgo] issue
by Sean Farrow 12 May '09

12 May '09

Hi list: I am in the process of using boost::algorithm::replace_all with the following tuple: Boost::tuple<DWORD, boost::filesystem::wpath> If I use the code below: std::wstring temp1, temp2, temp3; temp1 =ProcInfo.get<1>().string(); temp2 =ProcInfo.get<1>().filename(); temp3 =L"dolapi.dll"; boost::algorithm::replace_all(temp1, temp2, temp3); The code compiles fine, How ever if I use: boost::algorithm::replace_all(ProcInfo.get<1>().string(), ProcInfo.get<1>().filename(), L"dolapi.dll"); Compiling... TPProductsSR.cpp c:\program files\boost\boost\algorithm\string\detail\find_format_all.hpp(250) : error C2664: 'boost::algorithm::detail::erase' : cannot convert parameter 2 from 'input_iterator_type' to 'std::_String_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits, _Alloc=std::allocator ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called c:\program files\boost\boost\algorithm\string\detail\find_format_all.hpp(185) : see reference to function template instantiation 'void boost::algorithm::detail::find_format_all_impl2<INPUTT,FINDERT,FORMATTER T,FINDRESULTT,BOOST::ITERATOR_RANGE>(InputT &,FinderT,FormatterT,FindResultT,FormatResultT)' being compiled with [ InputT=const std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, FinderT=boost::algorithm::detail::first_finderF<STD::_STRING_CONST_ITERA TOR<WCHAR_T,STD::CHAR_TRAITS,std::allocator>,boost::algorithm::is_equal> , FormatterT=boost::algorithm::detail::const_formatF<BOOST::ITERATOR_RANGE >, FindResultT=boost::iterator_range<STD::_STRING_CONST_ITERATOR<WCHAR_T,ST D::CHAR_TRAITS,std::allocator>>, IteratorT=const wchar_t *, FormatResultT=boost::iterator_range ] c:\program files\boost\boost\algorithm\string\find_format.hpp(254) : see reference to function template instantiation 'void boost::algorithm::detail::find_format_all_impl<SEQUENCET,FINDERT,FORMATT ERT,BOOST::ITERATOR_RANGE>(InputT &,FinderT,FormatterT,FindResultT)' being compiled with [ SequenceT=const std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, FinderT=boost::algorithm::detail::first_finderF<STD::_STRING_CONST_ITERA TOR<WCHAR_T,STD::CHAR_TRAITS,std::allocator>,boost::algorithm::is_equal> , FormatterT=boost::algorithm::detail::const_formatF<BOOST::ITERATOR_RANGE >, IteratorT=std::_String_const_iterator<WCHAR_T,STD::CHAR_TRAITS,std::allo cator>, InputT=const std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, FindResultT=boost::iterator_range<STD::_STRING_CONST_ITERATOR<WCHAR_T,ST D::CHAR_TRAITS,std::allocator>> ] c:\program files\boost\boost\algorithm\string\replace.hpp(657) : see reference to function template instantiation 'void boost::algorithm::find_format_all<SEQUENCET,BOOST::ALGORITHM::DETAIL::FI RST_FINDERF,boost::algorithm::detail::const_formatF>(SequenceT &,FinderT,FormatterT)' being compiled with [ SequenceT=const std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, SearchIteratorT=std::_String_const_iterator<WCHAR_T,STD::CHAR_TRAITS,std ::allocator>, PredicateT=boost::algorithm::is_equal, RangeT=boost::iterator_range, FinderT=boost::algorithm::detail::first_finderF<STD::_STRING_CONST_ITERA TOR<WCHAR_T,STD::CHAR_TRAITS,std::allocator>,boost::algorithm::is_equal> , FormatterT=boost::algorithm::detail::const_formatF<BOOST::ITERATOR_RANGE > ] d:\work\access for everyone\ghg\tpproductssr\tpproductssr.cpp(41) : see reference to function template instantiation 'void boost::algorithm::replace_all,std::basic_string<_Elem,_Traits,_Ax>,const wchar_t[11]>(SequenceT &,const Range1T &,Range2T (&))' being compiled with [ _Elem=wchar_t, _Traits=std::char_traits, _Ax=std::allocator, SequenceT=const std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, Range1T=std::basic_string<WCHAR_T,STD::CHAR_TRAITS,std::allocator>, Range2T=const wchar_t [11] ] c:\program files\boost\boost\algorithm\string\detail\find_format_all.hpp(255) : error C2664: 'boost::algorithm::detail::insert' : cannot convert parameter 2 from 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' to 'std::_String_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits, _Alloc=std::allocator ] No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Using visual c++ 2008 on a windows xp box, not that this (the o/s at least) matters. How can I avoid creating temporary variables in this case? Any help appreciated. Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4061 (20090507) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 6

Boost.Date_Time design questions
by Suman Kar 12 May '09

12 May '09

I am a little taken aback by the following: * date_time does not have a header-only version * there is no support for constructing a date from a wstring: I was really hoping 'from_string(std::string)' was a function template rather than an ordinary function taking only std::string. Can someone enlighten me with the rationale behind these? Regards, Suman

1 0

[uuid] status?
by Mikko Vainio 12 May '09

12 May '09

Hi all, Is there any results of the mini-review process of the UUID library? Will the library be a part of boost anytime in the near future (say 1.40.0)? Cheers, Mikko

4 3

Re: [Boost-users] Stepping into a boost::function while debugging
by Peter Åberg 12 May '09

12 May '09

Ok, works alright I guess :-) /PÅ > Peter ?berg wrote: > > > Does anyone have a tip, suggestions or workaround on how one should do > > to step into the target function of a boost::function while debugging > > in VS 2008 (VC9), without wading through the boost::function > > implementation? > > > > I have looked around a bit now and have not found any solution except > > putting a breakpiont in the target function which may not be practical > > when one does not know which function it is. > > > > I get the feeling one have to wait for MS to add a feature like "step > > through code I don't want to see". But until then, what do you folks do? > > > > Designing with delegates in C++ feels a bit like a show-stopper for me > > until I can step into a delegate target function without getting lost > > in a haystack. > > Steven Watanabe wrote: > > I just hit step into until I get to familiar code. There isn't actually > a lot of code > to step through when calling a Boost.Function. > > In Christ, > Steven Watanabe

1 0

Next layer: Boost.Asio mixins?
by Boris Schaeling 11 May '09

11 May '09

Did anyone create and use Boost.Asio mixins and can share his experience? I especially wonder if there is a benefit or if it's just an exercise in templates. The reason I started to think about Boost.Asio mixins is that I see the very same code in various classes which all use Boost.Asio objects. I would assume that this is not only true in my projects but also in others. Here's an example. Let's say we create a client class to connect to another host. We could come up with something like this: class client { public: void resolve(std::string host, std::string service); void connect(boost::asio::ip::tcp::resolver::iterator endpoint_iterator); void send(std::string msg); void receive(); private: boost::asio::ip::tcp::resolver r; boost::asio::ip::tcp::socket s; }; If we create another class to encapsulate a POSIX file descriptor we don't need resolve() and connect() but send() and receive(): class posix_fd { public: void send(std::string msg); void receive(); private: boost::asio::posix::stream_descriptor fd; }; While the two classes are based on different I/O objects the implementation of send() and receive() could be the same. That lead me to create mixins with which I can define client and posix_fd like this: class client : public resolver<boost::asio::ip::tcp::resolver, handler>, public connector<boost::asio::ip::tcp::socket, handler>, public sender<boost::asio::ip::tcp::socket, handler>, public receiver<boost::asio::ip::tcp::socket, handler> { // Inherited from parent classes: // void resolve(std::string host, std::string service); // void connect(boost::asio::ip::tcp::resolver::iterator endpoint_iterator); // void send(std::string msg); // void receive(); }; class posix_fd : public sender<boost::asio::posix::stream_descriptor, handler>, public receiver<boost::asio::posix::stream_descriptor, handler> { // Inherited from parent classes: // void send(std::string msg); // void receive(); }; Sending and receiving data asynchronously has been implemented now once and for all in the sender and receiver template classes. As the implementation doesn't differ for Boost.Asio I/O objects they can be reused. And if we had concepts already in C++ the mixins could be based on them. It all seems to fit nicely together. While there are some problems, too, I haven't made my mind yet if these Boost.Asio mixins are an improvement or make code more complicated. I'm not asking about mixins in general but wonder if anyone had a good or bad experience using them with Boost.Asio? Or are all Boost.Asio users simply calling the very same async_write() and async_read() functions again and again, creating yet another buffer, checking again the error code in the handlers etc.? Boris

1 0

Re: [Boost-users] iterators must go
by John Dlugosz 11 May '09

11 May '09

> Date: Sun, 10 May 2009 09:24:42 -0400 > From: Neal Becker <ndbecker2(a)gmail.com> > Subject: [Boost-users] iterators must go > To: boost-users(a)lists.boost.org > Message-ID: <gu6kiq$2km$1(a)ger.gmane.org> > Content-Type: text/plain; charset="US-ASCII" > > Interesting presentation: > > http://www.boostcon.com/site- > media/var/sphene/sphwiki/attachment/2009/05/08/iterators-must-go.pdf > ******************************************** Re slide #21, he didn't mention the biggest one. I had a rather negative reaction to the design when I first saw the proposal and design that was to become the STL. The two iterators of a range have no connection to each other, and it is easy to get them mixed up with no way to test that the second is in the same collection as the first. Rather than (begin,end), I much prefer (begin, length) as a specification. And in implementation, iterators are literally as bad as pointers. I've preached that they must be treated like pointers, hidden away behind walls of encapsulation. When I first saw Boost ranges, I thought that was indeed much better. Way back when, abstracting a "range" and still allowing more generality was way beyond the ability of templates or template programmers. Slide #26: Yes! That discussion should have been had way back when. But the fait accompli of an existing library to serve as a starting point, and politics, shut down any hint of backtalk. Slide #47: shades of Perl 6...makes me think how the previous few slides of operations on ranges is like Perl. (#48) But in Perl6, even "Int" types can hold exceptional values, so list.size() would have no trouble returning Inf. --John (sorry about the footer; it's not my idea) TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

1 0

Re: [Boost-users] [regex] problem with linking to boost_regex
by Phani Deepak Parasuramuni 11 May '09

11 May '09

>n addition , I believe that the correct option is >-lboost_regex-gcc43-mt, since gcc will add the >lib prefix automatically. Thanks, This solved the problem. >In Christ, >Steven Watanabe

1 0