- Boost - lists.boost.org

[smart_ptr] make_shared perfect forwarding bug
by Frank Mori Hess 18 Apr '09

18 Apr '09

Perfect forwarding doesn't seem to work quite correctly with boost::make_shared. The attached program, which tries to pass a move-only type through make_shared fails to compile with gcc in c++0x mode. To fix it, I had to change the definition of detail::forward in make_shared.hpp to use rvalue references: #if defined( BOOST_HAS_RVALUE_REFS ) template< class T > T&& forward( T &&t ) { return t; } #endif This is just based on looking at how gcc implements std::forward. Is this the right fix?

2 1

[boost::exception] operator >>
by Gaydov Victor 18 Apr '09

18 Apr '09

hello! i'm using boost::exception in one project and did small modification for myself, what do you think about it ? i don't want to create a lot of exception classes, because my 'catches' will use only a few of them anyway. but while exception is throwing, some functions add different information to it (with operator <<) that is useful in diagnostic messages. so when we decide to extract that information from exception, we need to study what useful information it has. instead of using if-else it'll be nice to use inheritance of _errors_ (not exceptions), for example: throw our_exception () << error_1 (); ... catch (our_exception & e) { re-throw e << error_2 (); } ... catch (our_exception & e) { shared_ptr <base_of_error_1_and_2> ptr; while (e >> ptr) cout << ptr->format_error_message(); } i attached 'test.cpp' and 'operator.cpp' with stupid realization and example. if somebody thinks it can be useful of cause i can rewrite it to make it more practical.

2 2

[1.39.0][flyweight] Failing Mac OS test
by Beman Dawes 18 Apr '09

18 Apr '09

On the release branch, test_intermod_holder is failing for all Mac OS testers. See http://beta.boost.org/development/tests/release/developer/flyweight.html The error message is: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): File name too long Can we get this fixed for the release? If not, it needs to be marked up as an expected failure. Thanks, --Beman

3 4

The noexcept Specifier & Block
by Alexander Terekhov 18 Apr '09

18 Apr '09

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html#noexcept I gather that noexcept void f() { throw 0; } is supposed to be ill-formed versus well-formed noexcept void f() { noexcept { throw 0; } } invoking undefined behaviour. Well, this is not helpful. Both forms shall be well-formed with defined behaviour: invocation of unexpected() at throw point. regards, alexander.

7 29

RFC: serialization library in C only for C only
by Francis ANDRE 18 Apr '09

18 Apr '09

Hi Boosters Following a recommendation of Robert RAMEY about a serialization library similar to the Boost Serialization library but targeted only for the C language and using only the C language and/or some assembly routines, I am looking for any comments/advises on the feasibility of such library. The initial scope would be: 1/ Serialize/deserialize all primitive C types. 2/ Serialize/deserialize all constructed type like struct and union. 3/ Serialize/deserialize a tree/forest of C structures instances linked by pointers. What would be the charge/effort/workload of such library? Does anybody already try/succeed in building such library? Thank in advance for any comment. Francis ANDRE PS: Solving this issue by building a wrapper from C to the Boost Serialization library is not an option, hence this RFC.

2 2

[1.39.0][Interprocess] release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Interprocess has a few scattered failures. See http://beta.boost.org/development/tests/release/developer/interprocess.html Please fix or markup. Thanks, --Beman

3 3

[1.39.0][Interval] Release branch test failures
by Beman Dawes 17 Apr '09

17 Apr '09

Numeric/interval is failing three tests on some of the Mac OS platforms. See http://beta.boost.org/development/tests/release/developer/numeric-interval.… Please fix or markup. Thanks, --Beman

2 1

Boost.Conversion: request for interest
by vicente.botet 16 Apr '09

16 Apr '09

Hi, I've developed a utility library Boost.Conversion. I would like to know if the Boost community is interested in this library. If this is the case, this library could be scheduled for review quite soon. This library is related to LexicalCast, NumericConversion and (String)Convert, but much less specific. It provides a convert_to generic function (like swap) which can be specialized by the user to convert specific unrelated types, and why not, he could use one of the preceding libraries. This convert_to function can be seen as an extrinsec explicit conversion operator. The livrary provides also an assign_to generic function that can be seen as an extrinsec explicit assignement operator. Please let me know what do you think. What is wrong? What is missing? How can I improve it? Thanks, Vicente == Boost.Conversion == Links:http://www.boostpro.com/vault/index.php?action=downloadfile&filename=… Categories: Utilities Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic convert_to function which can be specialized by the user to make explicit conversion between unrelated types. * a generic assign_to function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between std::pair of explicitly convertible types. * conversion between boost::optional of explicitly convertible types. * conversion between boost::chrono::time_point and boost::ptime. * conversion between boost::chrono::duration and boost::time_duration. Soon conversion between std::vector, boost::array, and boost::tuple of explicitly convertible types. Motivation Imagine you need to convert unrelated types Source and Target. You can get it by defining a specific function such as Target SourceToTarget(Source& v); Imagine now that you need to convert a std::pair<Source, Source> to a std::pair<Target, Target>. Well you can again define a specific function std::pair<Target,Target> PairOfSourceToPairOfTarget(std::pair<Source,Source>& v) { return std::make_pair(SourceToTarget(v.fisrt), SourceToTarget(v.second)); } While the SourceToTarget could be specific, the PairOfSourceToPairOfTarget sould be generic template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v); In order to do that we need that the pair template parameters define a common function, let it call convert_to, template <typename Target, typename Source) Target convert_to(Source& v); so ConvertPair can be defined as template <typename Target1, typename Target2, typename Source1, typename Source2) std::pair<Target1,Target2> ConvertPair(std::pair<Source1,Source2>& v) { return std::make_pair(convert_to(v.fisrt), convert_to(v.second)); } The issue is that we need to specialize the convert_to function for the classes Source and Target. We can do it as follows template <> Target convert_to<Target, Source>(Source& v) {return SourceToTarget(v);} What about converting std::pair<Source,std::pair<Source,Source>> to std::pair<Target,std::pair<Target,Target>>? The issue now is that convert_to(std::make_pair<to, std::make_pair<to,to>>) do not compiles because the conversion of std::pair is named ConvertPair. So we need to specialize the function convert_to for pairs. With C++0x there is no major problem as it allows partial specialization of function templates. With C++98, we need to use a trick; as it allows partial specialization of classes we can define convert_to by as relying to a specific function of a class, as follows: namespace partial_specialization_workaround { template < typename Target, typename Source > struct convert_to { static Target apply(const Source& val); }; } template < typename Target, typename Source > Target convert_to(const Source& val) { return partial_specialization_workaround::convert_to<Target,Source>::apply(val); } So now we can specialize partial_specialization_workaround::convert_to for pairs as follows: namespace partial_specialization_workaround { template <typename Target1, typename Target2, typename Source1, typename Source2) struct convert_to< std::pair<Target1,Target2>, std::pair<Source1,Source2> > { inline static std::pair<Target1,Target2> apply(std::pair<Source1,Source2>& v) { { return std::pair<T1,T2>(convert_to<T1>(from.first), convert_to<T2>(from.second)); } }; } There is one more issue. The preceding design works well with unrelated classes, but what about classes that already define some kind of conversion, using a constructor or a conversion operator. Do we need to make specialization for these conversion? The answer is no. We need just to define the default implementation of the partial_specialization_workaround::convert_to::apply function to just return the explicit conversion. namespace partial_specialization_work_around { template < typename T, typename U> struct convert_to { inline static T apply(const U& val) { return T(val); } }; } What have we learned? Classes or algorithms relying on a conversion by construction or by the conversion operator can be made more generic by relaying in a function that explicitly states this conversion. So instead of requiring Target(from) requires convert_to<Target>(from) The same applies to classes or algorithms relying on the assignment operator. So instead of requiring to = from requires assign_to(from, to); The default implementation of assign_to relies on the assignement operator namespace partial_specialization_workaround { template < typename Target, typename Source > struct assign_to { inline static To& apply(const Source& from, Target& to) { to = from; return to; } }; } template < typename Target, typename Source > To& assign_to(const Source& from, Target& to) { return partial_specialization_workaround::assign_to<Target,Source>::apply(from, to); } So one of the advantages of using this common functions is uniformity. The other is that now we are able to find all the explicit conversions to one type, as we can do with explict casts.

1 0

Re: [boost] Patches in trac...
by Henrik Sundberg 16 Apr '09

16 Apr '09

On Wed, Apr 8, 2009 at 6:24 PM, Marshall Clow <marshall(a)idio.com> wrote: > The conclusion that was reached at the end of the discussion was that we > wanted to get rid of the "Patches" label for Trac tickets, and to move all > the existing patches to either "Bugs" or "Feature Requests". > > What do people think? You might want to add a keyword "patch" to all tickets containing a patch. Just to make it searchable. /$

3 3

Bugfixing Sprints in Cyberspace?
by David Abrahams 16 Apr '09

16 Apr '09

Hi all, At last count, the Boost Trac had over 700 open tickets. I've been thinking I personally could really use an excuse to concentrate on reducing that number (especially the ones assigned to me ;->). It might be fun to try some kind of organized event along the lines that the Ubuntu people use: https://wiki.ubuntu.com/UbuntuBugDay. Does something like this sound like it could work for us? [Okay, maybe we don't have "virtual hugs" and would have to substitute something.] -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 3