April 2009 - Boost - lists.boost.org

[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 17 Apr '09

17 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

[1.39.0] getting started update
by Vladimir Prus 16 Apr '09

16 Apr '09

The attached patch updates getting started to the changes I've did to simplify build process, described in: http://permalink.gmane.org/gmane.comp.lib.boost.devel/188461 and some other existing reality. Specifically: 1. The bootstrap + bjam procedure is documented. 2. The Boost.System library is added to the list of libraries needing compilation. 3. Unix docs are adjusted to use stage/lib everywhere, as opposed to using 'lib' in some cases. Dave, can you review this? I have regenerated HTML and visually inspected them, but HTML diffs are not included for clarity. Thanks, Volodya

2 2

Improved build process
by Vladimir Prus 16 Apr '09

16 Apr '09

Hello, I have completed a set of changes meant to make building C++ Boost somewhat more streamlined, and avoid common pitfalls reported on IRC and mailing lists. In short, C++ Boost can now be build, on Windows, with: bootstrap.bat bjam and on Linux, with ./bootstrap.sh ./bjam I'd imagine that 95% of users won't need anything else, and two commands is a fairly straigh-forward approach. More specifically, the changes I've made are: 1. Some time ago we discussed the configure/make solution: http://article.gmane.org/gmane.comp.lib.boost.devel/181839/ There are two problems with it: - The naming suggests it's automake/autoconf solution, which is not, and users keep on trying automake idioms to find they don't work. - If you just run "bjam" then whatever settings configure made are not considered -- which is very annoying when user has to tweak things beyond what configure offers. Per that thread, I have did two changes: - Renamed configure to bootstrap.sh, avoiding autoconf connotations - Made bootstrap.sh, instead of generating Makefile, generate project-config.jam -- which is automatically read by Boost.Build. 2. Many users forget to specify 'stage' explicitly, and get a pile of libraries in random places. Now, 'stage' is default, and a message saying where libraries go is printed. See: http://article.gmane.org/gmane.comp.lib.boost.devel/188450 3. On Windows, users had to get or build Boost.Jam, and then copy it in %PATH% and then invoke it. Now, bootstrap.bat is a tiny wrapper that builds Boost.Jam and puts it in the root of C++ Boost source tree. 4. On Windows, release libraries were built by default, and debug were not build at all, which does not match default IDE & autolink behaviour. (I think that on Linux, building release by default is fine, since generally debug and release versions are link-compatible). We now build these two variants by default: <variant>debug <threading>multi <link>static <runtime-link>shared <variant>release <threading>multi <link>static <runtime-link>shared These changes are presently on trunk. Most of them are essentially the matter of proper defaults, and proper messages and proper wrappers, not deep hacking, so they are unlikely to disturbing for release. On the other hand, I would very much appreciate comments on "look&feel". So, if you have some time, give it a try and report your experience. I'll take a look at regression results to see if some unexpected breakage appears, and do other round of manual testing on Monday, and then merge this to release branch. Dave, I understand this requires changes to getting started -- for Unix, they are textual replacements only and I have a local patch for that. For Windows, new text is needed that I'll work on as well and should have a patch for your review by Monday. - Volodya

2 1