- Boost - lists.boost.org

[serialization] Reading newer archives - was throwing unsupported_class_version, now crashes
by Nikolay Mladenov 25 Jun '12

25 Jun '12

Hi Robert, I remember that in the past the serialization library was throwing unsupported_class_version exception when reading of archives with future class versions. This no longer seems to be the case. We had older version of software crash when reading newer archive. The only place that I found to mention unsupported_class_version is commented out and I do not understand the attached note: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // note: we now comment this out. Before we permited archive // version # to be very large. Now we don't. To permit // readers of these old archives, we have to suppress this // code. Perhaps in the future we might re-enable it but // permit its suppression with a runtime switch. #if 0 // trap case where the program cannot handle the current version if(file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); #endif // make sure call is routed through the higest interface that might // be specialized by the user. boost::serialization::serialize_adl( boost::serialization::smart_cast_reference<Archive &>(ar), * static_cast<T *>(x), file_version ); } To allow class to read serialized objects of newer version by default seems very dangerous. I generally requires extra work from the class author and without it will most likely crash. So isn't it better to have an additional trait that a class author needs to define, if a class should be allowed read future versions? something like namespace boost{ namespace serialization { template<class T> struct allow_future_versions : mpl::false_ {}; }} #define BOOST_SERIALIZATION_ALLOW_FUTURE_VERSIONS(T) \ namespace boost{ namespace serialization \ { \ template<> struct allow_future_versions<T> : mpl::true_ {}; \ }} and change the code above to: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // trap case where the program cannot handle the current version if( ! boost::serialization::allow_future_versions<T>::value && file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); ...... Thanks in advance, Nikolay Mladenov Sitius Automation Inc.

3 10

[move] GCC bug and aliasing questions
by Tr3wory 25 Jun '12

25 Jun '12

Hi, Yesterday I started using Boost.Move in my project. On gcc I had the same problem like the guys here: http://lists.boost.org/Archives/boost/2011/07/184263.php Namely, I can't define the move constructor nor the assignment operators outside my class... After some time I managed to create a minimal example (19 lines) and sent a bug report to the gcc guys: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 So far, so good. In the minimizing process I found something interesting: the problem vanishes if I remove the __may_alias__ attribute from the rv<> class. This got me thinking. Do we need this attribute at all? The problematic expression is this: (It's in macros normally placed inside a class, TYPE is the name of this class.) operator ::boost::rv<TYPE>&() { return *static_cast< ::boost::rv<TYPE>*> (this); } But rv<TYPE> is derived from TYPE so to me it looks like the two type is compatible, therefore the code didn't violate the strict aliasing rules, so the attribute is not necessary. (BTW can we violate the strict aliasing rules trough static_cast if we don't do any chained conversion trough void*?) On the other hand, if it's really breaks the rules then we solved the problem for gcc, but we still have undefined behavior on every other compiler. Can we fix this somehow? Cheers, tr3w

3 5

An alternative approach to TypeErasure
by Pyry Jahkola 25 Jun '12

25 Jun '12

Hi all, I was quite impressed by Sean Parent's Friday talk in C++Now! 2012 (see slides in [1], code in [2]) and was left wondering whether the generation of his polymorphic object wrapper could be made simple somehow in C++11. [1]: https://github.com/boostcon/cppnow_presentations_2012/raw/master/fri/value_… [2]: https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value… What I ended up with is tricking ADL into allowing the overloading of arbitrary (specifically crafted) function objects that I call _callables_, and then letting the user define interfaces by specifying sets of ("member") function signatures with a callable. You can find the code, and my rambling introductory README file, in GitHub: https://github.com/pyrtsa/poly Comments are welcome! * * * Here's a somewhat shorter intro: 1) Create a callable F by simply deriving it from poly::callable<F>: struct draw_ : poly::callable<draw_> {}; constexpr draw_ draw = {}; 2) Or use the convenience macro POLY_CALLABLE(name) to do the same: POLY_CALLABLE(to_string); // type `to_string_` and object `to_string` 3) Overload your callables by overloading the function named `call`, with the callable as first argument: template <typename T> void call(draw_, T const & x, std::ostream & out, std::size_t position) { out << std::string(position, ' ') << x << std::endl; } std::string call(to_string_, int i) { return std::to_string(i); } template <typename T> std::string call(to_string_, std::vector<T> const & xs) { std::ostringstream s; s << '['; auto i = begin(xs), e = end(xs); if (i != e) s << *i++; while (i != e) s << ", " << *i++; s << ']'; return s.str(); } Now you can call ::draw(x, o, p) and ::to_string(x) for several different types of x: ::draw(123, std::cout, 2); // prints " 123" to stdout ::to_string(std::vector<int>(1, 2, 3)); // "[1, 2, 3]" But you can likewise extend ::draw and ::to_string further by overloading them for your own types too. 4) Define an interface by specifying the set of function signatures as template arguments to poly::interface: using drawable = poly::interface< void(draw_, poly::self const &, std::ostream &, std::size_t, std::string(to_string_, poly::self const &)>; Now, the following calls got automatically defined, and forwarded to whatever type you successfully construct a `drawable` from: void call(draw_, drawable const &, std::ostream &, std::size_t); std::string call(to_string_, drawable const &); * * * I am aware that Steven Watanabe has put some astonishing work on his proposed Boost.TypeErasure. I'm open for discussion whether and how his or mine is a better approach, or if we could combine these into an eventual Boost.Interface library or such! * * * PS. Like I mention in my GitHub page, this kind of type erasure is common in functional languages like Haskell or Clojure. The problem they are solving there is known as the Expression Problem. IMO it makes very much sense to have the corresponding construct in C++ too, as we're moving towards a more and more functional style with parallelism and such. Best Regards, -- Pyry Jahkola pyry.jahkola(a)iki.fi https://twitter.com/pyrtsa

7 16

Multiprecision Review
by Phil Endecott 25 Jun '12

25 Jun '12

Dear All, Here is my review of the proposed Multiprecision review. First a rant: why have so few people contributed to the discussion or written reviews? I have waited until now before writing this in the hope that others would say something useful, but there has been very little to read. Boost will suffer as a result of this. It has been depressing to see that at the same time the mailing list has been full of other discussions, so the problem is not that people don't have the time to contribute. In particular, the long thread about Boost.Exception makes me want to shout "Why Didn't You Say All This When It Was Reviewed?". My view of the proposed library can be summarised as follows: it doesn't do what I want, but maybe it does enough things that other users would like to justify its acceptance anyway. Except probably it doesn't, because if it did those other users would have said so, which they haven't. In particular, I'd like to be able to implement integers of perhaps 128 or 256 bits that behave like the built-in integers. I can quickly throw together something myself that works OK but: - It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown. - Writing all the operator overloading etc. is tedious. - It's also error prone, as a mistake in e.g. carry propagation might be detected once in very 2^32 operations. It would have been great if this library could have helped with this. Instead, it has produced something worse than my "quick throw-together". It's worse because it has tried to unify this smallish fixed-size type with very large variable-size types, and the compromises necessary to achieve this have sabotaged the performance. It's also worse because it had a subtle bug - which has since been corrected, but I would still not be confident of getting correct answers without verifying against another implementation. Ideally, there would still be some parts of the library that could be useful to me. If the library had been decomposed into data structures vs. algorithms then perhaps I could have applied the algorithms to my simpler data structures. Unfortunately the library has not been organised in this way, and even if it had done the use of sign-magnitude representation might have scuppered any re-use. As far as I can see, the only part of the library that I could re-use would be the expression template front-end, which doesn't seem to improve performance for types of this size anyway. Here are my answers to the standard review questions: What is your evaluation of the design? Not great for my purposes; see above. What is your evaluation of the implementation? I spent half a day chasing down a bug. My observations are that (a) there are subtle bugs, and (b) the code lacks comments or other clues for people like me to quickly pick up what it's all doing. What is your evaluation of the documentation? Satisfactory. What is your evaluation of the potential usefulness of the library? Not useful for me; see above. Did you try to use the library? With what compiler? Did you have any problems? I spent perhaps a day working on a small but real benchmark which was discussed on the mailing list. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About a day-and-a-half in all. I've not looked beyond the areas that I've discussed and I'm aware that there is a lot more to the library i.e. non-integer types. Are you knowledgeable about the problem domain? Not especially. Do you think the library should be accepted as a Boost library? No, because (a) I'm not convinced from this discussion that lots of people are waiting for this functionality (see above). (b) Based on previous experience, I'm sceptical about the possibility of the performance of Boost libraries being improved after acceptance. Despite that, I thank John and Chris for their work which is a considerable leap forward from the last "big number" submission, "xint". Regards, Phil.

5 5

Contribute
by Merve Temizer 25 Jun '12

25 Jun '12

Hello, I am not sure if this is right place to write but, how can i contribute as a newbie programmer? My main intention is learning C++ deeper by contributing to some open source organizations. Sorry for if it is wrong place. Thanks in advance.

2 1

[fusion] for_each on gcc 4.7
by Daniel Larimer 24 Jun '12

24 Jun '12

I recently attempted to update to gcc 4.7 and code that compiled with 4.5.3 broke. It appears that boost::fusion expects boost::fusion::random_access_traversal_tag to implicitly cast to mpl::bool_<false>. Switching the 3rd argument from mpl::bool_<false> to an extra template arg (that was ignored), seems to fix the compilation errors. Compiled with std=c++11 /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: error: no matching function for call to 'for_each(boost::fusion::vector2<double, double>&, const mace::rpc::detail::unpack_sequence<mace::rpc::function_filter<mace::rpc::connection<mace::rpc::json::io> > >&, boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type)' /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: candidate is: In file included from /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:11:0, from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template<class Sequence, class F> void boost::fusion::detail::for_each(Sequence&, const F&, mpl_::false_) /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template argument deduction/substitution failed: In file included from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12:0, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: cannot convert 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type()' (type 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type {aka boost::fusion::random_access_traversal_tag}') to type 'mpl_::false_ {aka mpl_::bool_<false>}'

5 8

Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
by Keith Burton 24 Jun '12

24 Jun '12

Instant reactions on reading though the documentation : 1) Introduction : I would prefer to see e.g. mp::int128_t rather than mp::mp_int128_t, given the stated purpose of the library. 2) cpp_dec_float : Narrowing conversions are truncating. This is a no-no for the usage I have in mind at the moment. 3) Constructing and interconverting : >> // There is a need to be careful with integer types though: >> cpp_int i = 2; >> // Ooops, this really just multiplies by 3: >> i *= 3.14; One of the priorities for my numeric class implementations has always been to protect naive users from equivalent mistakes. What is your evaluation of the design? It is so far beyond anything I have attempted that I cannot usefully comment. The limitations on conversions and mixed precision operations are disappointing but entirely understandable. The ccp_dec_float narrowing conversions being truncating reinforces the my view that the limitations are probably the correct design. What is your evaluation of the implementation? No useful comments. What is your evaluation of the documentation? Good enough to give me confidence to start using the library. I would never expect more than that. What is your evaluation of the potential usefulness of the library? A vital addition to C++ especially for relatively small tasks in commercial software where the Boost backends can be used because performance is not an overriding concern. Did you try to use the library? With what compiler? Did you have any problems? I have started to use the library to embed test code for my special purpose decimal fixed point classes into an application under development. The only issue, using VS2008 /W4 and Boost 1.48, was the need to disable warning 4996. Unfortunately this has been pre-empted by other work. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? More than a quick reading Are you knowledgeable about the problem domain? I have written several numeric classes but all with a narrow scope and protection of naïve users and accuracy as the priority. These were primarily decimal fixed point. Do you think the library should be accepted as a Boost library? Yes

3 2

[multiprecision] Last chance for a review.
by John Maddock 24 Jun '12

24 Jun '12

Just to remind everyone that the multiprecision library review is about to come to an end, so it's time to speak up or shut up ;-) Actually we're a little short on reviews generally, so I'd encourage anyone who hasn't taken a look yet to do so, code is the sandbox under /big_number/, docs are viewable online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… Many thanks, John.

3 2

Trimming Dependencies (was Boost and exceptions)
by Daniel James 24 Jun '12

24 Jun '12

On 24 June 2012 01:55, Dave Abrahams <dave(a)boostpro.com> wrote: > > on Sat Jun 23 2012, Daniel James <dnljms-AT-gmail.com> wrote: > >> >> That's pretty crazy. Do you know if separating test dependencies would >> make much of a difference? > > They're already separated, along with documentation dependencies. You > *really* don't want to see the graph that includes the test dependencies > ;-) OK, I assumed from the dependencies on Test that they were included, but some headers do depend on Test.

2 1

Boost and exceptions
by Dirk Ulrich 24 Jun '12

24 Jun '12

Dear all, when looking at Boost as a whole its obvious that it uses C++ exceptions to report exceptional conditions because its the C++ way of doing it and it has to interact with the C++ standard library. On the other hand it seems also obvious that some libraries (Boost.Units, Boost.MPL, etc.) do probably not use C++ exceptions at all since they are pure compile time libraries or provide services which do not have exceptional cases. I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math. Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)? What would it take to use these libraries as a stand-alone "minimal" Boost library? Thanks

18 71