February 2009 - Boost - lists.boost.org

Re: [boost] [optional_io] InputStreamable refinement
by Andrew Troschinetz 04 Mar '09

04 Mar '09

Just heard back from Robert, I figure it's ok to forward this information: On Feb 26, 2009, at 10:00 AM, Robert Ramey wrote: > The serialization library does no depend up optional or it's > implementation. If you > change the implemenation of optional, just make the changes > are consistent with the requirements of the serialization library. > > The fact that the serialization of optional is implemented and tested > as part of the serialization library is an anomoly. In fact, this > code and test should be moved into the optional library. I checked the optional test in the serializable library and it doesn't seem to even include optional_io.hpp. And given Robert's comments, it seems like it would be ok to make changes to optional_io.hpp. With respect to the change I suggested for operator>>() (I think in my last post I typoed and wrote operator<<(), I always get those silly things backwards!): In the case where we fail to extract optional<T>::value_type, I'm not sure what would be the best thing to do with respect to the position of the get pointer or other state bits. I had suggested this: if (in.fail () && !in.eof ()) { in.clear (); in.get (); } The intent of calling get() there is to enable this use case: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; } // which finds 2, 4, and 6 But why move the get pointer up by one? Why one? Does this make sense? I can't provide a reasoning as to why it does, if it does. So another possibility is this: if (in.fail () && !in.eof ()) { in.clear (); in.setstate (std::ios::eofbit); } This has the added benefit of of making the following possible w/o any code change to lexical_cast: // doesn't throw, returns 0 lexical_cast<optional<unsigned> > ("-1").get_value_or (0); And if it's well documented that extracting an uninitialized optional<T> sets the eofbit on the istream, then a prudent user could (if they really wanted to) reformulate the first use case as: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; else { sin.clear (); sin.get (); } } This leaves the why of moving the get pointer up to the user, where I think it really belongs. Because I can image some use cases where you'd want to do something other than just call get(). For example, maybe you'd want to call getline() and ignore an entire line before trying to extract another optional<T>. Or maybe you'd want to read until you found some delimiter before trying again. -- Andrew Troschinetz Applied Research Laboratories

4 9

Re: [boost] An extension to boost::variant
by Catalytic 04 Mar '09

04 Mar '09

Chris Hamilton-3 wrote: > > While boost::variant is very capable at what it does, there is one thing > it doesn't do .. > > ..My question is this: why can't boost::variant be clever about reference > data types.. > > The reason I want this, is to have a nice String variant, that > encapsulates the various forms a string can take in a current project: > std::strings, char*'s, and std::string* and > boost::shared_ptr<std::string>. I want functions to be able to handle > all of these types transparently by using variants as the argument > types. Allowing "const std::string&" as a variant type allows this to > be done while not requiring a wasteful string copy. > .. > (I have a small custom variant class implementing this, and it appears > to work well. It's not as 'full fledged' as the boost::variant class, > but the approach I've taken could surely be grafted on to boost::variant.) > > An example will be better than a lengthy explanation, please have a look at the test-cases in the boost distribution: libs/variant/test/: specially variant_reference_test.cpp IMHO, it will answer all your queries. -Cat -- View this message in context: http://www.nabble.com/An-extension-to-boost%3A%3Avariant-tp21881442p2189668… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 13

[convert] Default Syntax Idea
by Stewart, Robert 04 Mar '09

04 Mar '09

I was thinking a bit about syntax for the default value for the notional boost::convert() and kin. How about the following: int const i(3); string const s("something"); int const j(convert<int>(s) | 5); convert<DestType,SourceType>(SourceType) can return a type which throws on failure in operator DestType(), but has an operator |(SourceType) which returns a second type constructed with the SourceType value. The second type provides its own operator |(SourceType) which returns that value in its operator DestType() on failure. Returning a default value in lieu of an exception is a special case; it ought not be treated like formatting. Thus, while Boost.Parameter might be appropriate to package the extra information desired for formatting, I don't like the idea of writing "default_ = 5" in the call, and I don't think ", 5" in the argument list is as clear as it could be. The syntax above is obvious and concise while being distinct from whatever may be done for formatting. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

9 32

boost::bind, problem with result type deduction and calling conventions
by Ingo.Loehken＠boc-eu.com 03 Mar '09

03 Mar '09

hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ? template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; }; so that code like class A { public: int __stdcall x() { return 0; } void const y() {} explicit A() { typedef boost::function<int()> fun_t; fun_t const f(boost::bind(&A::x,this)); } }; ends up with an warning at bind 1>G:\boost\boost_1_37_0\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored 1> G:\boost\boost_1_37_0\boost/bind.hpp(1682) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> I=1 1> ] 1> G:\dev\workspace\files\ado\ado_bind.hxx(36) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> A1=Ado::A * 1> ] because the proposed specialization is not choosen by the compiler. Adding an __stdcall to the function signature type in add_cref fixes that problem, but still i do no understand, why the defintion is not like template< class M, class T > struct add_cref< M (__stdcall T::*) (), 1 > { typedef M const& type; }; and of course that fix is only applicable for __stdcall, where specialzations for other calling conventions can easily be generated, like for mem_fn_cc in respect to requested support for calling conventions. Thanks for your help, ILo. compiler : msvc 8.0 library : boost 1.38

2 1

[Review] Reminder: Boost.RangeEx review is going on
by Thorsten Ottosen 02 Mar '09

02 Mar '09

Dear Developers and Users, The review of Neil Groves' RangeEx library lasts until March 3, 2009. Please find the time to do a review if you are interested in this library. The discussion so far may be found here: http://archives.free.net.ph/message/20090220.122836.73bdbd04.en.html Below you will find a description of the library and information on how to write a review. best regards Thorsten, review manager What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

4 5

N2346 - Defaulted and Deleted Functions emulation
by vicente.botet 02 Mar '09

02 Mar '09

Hi, is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks. Attached a draft for the default and deleted functions. Only one remark the macors must be used on the public part and without trailing ';', e.g. class X { BOOST_NEW_DELETE(X) Any coments are welcome, Vicente

3 6

[geometry] gtl review pre-announcement
by Tom Brinkman 02 Mar '09

02 Mar '09

I'm doing a session at boostcon about GIL and making a bunch of examples, including some about GTL. You can include those as part of your unit test cases if you like. //Tom

3 2

RPC library in the sandbox
by Jon Shuler 02 Mar '09

02 Mar '09

Does any know if the author(s) of this library are still around and plan to make any more updates to it? Jon

2 1

[thread] static thread_specific_ptr?
by k-oli＠gmx.de 01 Mar '09

01 Mar '09

Hello, can I create an static thread specific pointer for class which will initalized by different threads? struct X { static thread_specific_ptr< U > tss_ptr_; }; in some threads: X::tss_ptr_.reset( new U); And for each thread X::tss_ptr_ will point to a different object in the freestore? Oliver

6 8

rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>?
by Peter Dimov 01 Mar '09

01 Mar '09

I'm trying and failing to run the smart_ptr tests because of: D:\boost\trunk\libs\smart_ptr\test>bjam ..\..\..\libs\math\build\Jamfile.v2:8: in modules.load rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>. D:/boost/trunk/tools/build/v2/build\project.jam:313: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in project.load D:/boost/trunk/tools/build/v2/build\project.jam:742: in project.use D:/boost/trunk/tools/build/v2/build\project.jam:89: in load-used-projects D:/boost/trunk/tools/build/v2/build\project.jam:73: in load D:/boost/trunk/tools/build/v2/build\project.jam:115: in load-parent D:/boost/trunk/tools/build/v2/build\project.jam:448: in initialize D:/boost/trunk/tools/build/v2/build\project.jam:303: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in load D:/boost/trunk/tools/build/v2/build\project.jam:168: in project.find D:/boost/trunk/tools/build/v2\build-system.jam:535: in load D:\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import D:\boost\trunk\tools\build\v2/kernel/bootstrap.jam:138: in boost-build D:\boost\trunk\boost-build.jam:17: in module scope -- Peter Dimov http://www.pdplayer.com

4 7