- Boost - lists.preview.boost.org

the Boost policy for protecting against "too perfect forwarding"
by Andrzej Krzemienski 25 Apr '14

25 Apr '14

Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constru… In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy. There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads. (1) appears cleaner, but some compilers might not support SFINAE. My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE. I can see Boost.Any just uses SFINAE for this purpose without any check. Are there any compilers supported by Boost that have rvalue references but no SFINAE? Regards, &rzej

3 2

[Graph] Pull request for multiplicities support in brandes_betweenness_centrality
by Javier Dehesa 25 Apr '14

25 Apr '14

I've put a pull request for ticket #9935 https://svn.boost.org/trac/boost/ticket/9935 https://github.com/boostorg/graph/pull/6 Explanations included in the ticket and the pull request. I can try to make the implementation for graph_parallel if this get accepted. -- Javier Dehesa

1 0

lazy_enable_if is not sfinae friendly?
by Hui Li 24 Apr '14

24 Apr '14

I was surprised to find that the following code doesn't compile with boost 1.55, where boost::result_of is itself sfinae friendly. template < typename T > typename boost::lazy_enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type test(int){} template < typename > void test(...) {} struct A{}; // boost::result_of<A(int)> is a valid type that doesn't have a member called "type" int main(int argc, const char * argv[]) { test<A>(0); // test<A>(int) meant to be a substitution failure return 0; } For example, on clang++-3.4 with -std=c++11, I got: clang++-mp-3.4 -std=c++11 -I /opt/local/include/ main.cpp In file included from main.cpp:1: In file included from /opt/local/include/boost/type_traits.hpp:65: In file included from /opt/local/include/boost/type_traits/is_nothrow_move_assignable.hpp:22: /opt/local/include/boost/utility/enable_if.hpp:40:25: error: no type named 'type' in 'boost::result_of<A (int)>' typedef typename T::type type; ~~~~~~~~~~~~^~~~ main.cpp:12:1: note: in instantiation of template class 'boost::lazy_enable_if_c<true, boost::result_of<A (int)> >' requested here typename boost::lazy_enable_if_c< ^ main.cpp:16:1: note: while substituting explicitly-specified template arguments into function template 'test' test(int){} ^ 1 error generated. But if lazy_enable_if_c had been implemented as template <bool B, class T> struct lazy_enable_if_c : T {}; // inherits from T template <class T> struct lazy_enable_if_c<false, T> {}; The above test code would compile fine. However, the current implementation template <bool B, class T> struct lazy_enable_if_c { typedef typename T::type type; // this is what caused the compile error }; template <class T> struct lazy_enable_if_c<false, T> {}; seems to evaluate T::type too soon, and results in a compile error rather than a substitution failure. I wonder if the current implementation is chosen deliberately to disallow use cases like the test code? But I imagine allowing lazy_enable_if etc to be (more) sfinae friendly could be very useful. I was able to find a workaround for the test code: template < typename T > typename boost::enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type::type // when T = A, this is a substitution failure test(int){} Hui

1 0

[assign] Merge request for type disambiguation with C++11
by Ben Pope 24 Apr '14

24 Apr '14

https://github.com/boostorg/assign/pull/3 The merge base was somehow ignored, not sure what happened there, but the set of changes is in the last commit. Ben

5 8

[Bug Report] macro definition has \ followed by spaces
by Walter Bright 24 Apr '14

24 Apr '14

In order for line splicing to work, \ has to be followed by a newline. boost/1.51.0/gcc-4.8.1-glibc-2.17-fb/42097cf/include/boost/spirit/home/classic/utility/rule_parser.hpp line 422 ::BOOST_SPIRIT_CLASSIC_NS::type_of::depend_on_type<__Dummy>(x) ) \

2 2

boost::aligned_storage broken on VC12 for alignment values of 8
by Glen Fernandes 24 Apr '14

24 Apr '14

Very surprising, but easily reproducible with VC12 (2013), Release or Debug configuration, Win32 platform: the following program will often* throw: #include <boost/type_traits/aligned_storage.hpp> #include <cstdint> int main() { boost::aligned_storage<8, 8>::type a; if (((std::uintptr_t)&a % 8) != 0) { throw 1; } } * Four of every five times it failed because the storage was only 4-byte aligned, not 8-byte aligned. Does not reproduce for x64 builds, just x86 builds. Does not reproduce with alignment values other than 8. Glen

4 7

Regression test relying on undefined compiler behavior (c++11)
by Chris Cooper 24 Apr '14

24 Apr '14

libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). See discussion here: http://stackoverflow.com/questions/23250651/strange-behavior-with-c-recursi… In addition, it looks like the existing code also relies on the compiler filling the vacated bits with one’s, which I don’t think is what actually happens. The solution I’ve come up with, is to do the shifting using unsigned values, thus avoiding the compiler no-no, and then putting the result back in the specified type. In other words, replacing line 73 BOOST_STATIC_CONSTANT(Number, min = Number(Number(prev::min) << CHAR_BIT)); With BOOST_STATIC_CONSTANT(Number, min = boost::detail::is_signed<Number>::value ? (Number)(((unsigned long)(prev::min) << 8) | 0x00FF) : Number(Number(prev::min) << CHAR_BIT) ); I’m using constants ‘8’ and ‘0x00FF’ rather than CHAR_BIT since the code would get really ugly if CHAR_BIT != 8. Thoughts? Thanks, Chris

3 5

Fwd: [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Antony Polukhin 24 Apr '14

24 Apr '14

2014-04-23 17:33 GMT+04:00 Paul A. Bristow <pbristow(a)hetp.u-net.com>: <...> > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: > but I > don't have any much better ideas. Perhaps someone else has? > > Nor am I clear that this namespace bti helps the reader. > > "Through all the examples, we'll assume that the following namespace alias > is in > effect: > > namespace bti = boost::typeind; > > " > > IMO, the frequency of use of the namespace bti is probably so low that > spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable > Agreed: boost::typeindex would be more user friendly. It suggests to the reader which library to look for. Other notes will be also addressed. Thanks for the review! -- Best regards, Antony Polukhin

1 0

Re: [boost] Application need a Review Manager. Anyone is interested?
by Brian Wood 24 Apr '14

24 Apr '14

Niall Douglas: > Yeah, I'd definitely redouble my advice to break up Application into > smaller, standalone, reusable bits. The problem with any overarching > framework is that it's a vision (i.e. your vision), and other > people's visions never peer review well, whether in academia, here in > Boost, or anywhere. Also, unless you're a member of Boost's steering > committee and/or on the C++ standards committee, any vision you > propose probably won't be given any benefit of the doubt > unfortunately. Some might think: If you can't beat 'em, join 'em. My motto though is: If you can't join 'em, beat 'em. -- Brian Ebenezer Enterprises - "A fool with a plan can beat a genius with no plan." T. Boone Pickens http://webEbenezer.net

1 0

Can't compile valarray.cpp - any ideas why?
by Chris Cooper 23 Apr '14

23 Apr '14

On my Mac (OSX 10.9.2, running clang++ "Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)”), I can’t get the libs/accumulators/test/valarray.cpp regression test to compile. The error it gives is of course lengthy, but goes something like this: In file included from valarray.cpp:18: ../../../boost/accumulators/statistics/weighted_mean.hpp:73:13: error: no matching constructor for initialization of 'result_type' (aka 'valarray<typename divides<left_value_type, const double>::result_type>') : mean( ../../../boost/accumulators/framework/depends_on.hpp:319:17: note: in instantiation of function template specialization 'boost::accumulators::impl::immediate_weighted_mean_impl<SNIP>' requested here : Accumulator(args) ../../../boost/accumulators/framework/depends_on.hpp:252:29: note: in instantiation of function template specialization 'boost::accumulators::detail::accumulator_wrapper<SNIP>' requested here return type(args, next_build_acc_list::call(args, fusion::next(f), l)); ../../../boost/accumulators/framework/depends_on.hpp:252:56: note: in instantiation of function template specialization 'boost::accumulators::detail::build_acc_list<SNIP>' requested here return type(args, next_build_acc_list::call(args, fusion::next(f), l)); ../../../boost/accumulators/framework/depends_on.hpp:271:51: note: in instantiation of function template specialization 'boost::accumulators::detail::build_acc_list<SNIP>' requested here return meta::make_acc_list<Sequence>::call(args, fusion::begin(seq), fusion::end(seq)); ../../../boost/accumulators/framework/accumulator_set.hpp:159:21: note: in instantiation of function template specialization 'boost::accumulators::detail::make_acc_list<SNIP>' requested here detail::make_acc_list( valarray.cpp:150:78: note: in instantiation of function template specialization 'boost::accumulators::accumulator_set<SNIP>' requested here /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/valarray:806:5: note: candidate constructor not viable: no known conversion from 'typename result<SNIP>' to 'const std::__1::valarray<double>' for 1st argument valarray(const valarray& __v); That last little bit makes it look like “result_type mean” is of type valarray<double> and boost is trying to pass a valarray<int> into its copy constructor and not succeeding. I’ve narrowed down the offending code (in valarray.cpp) and this is the code that won’t compile: typedef std::valarray<int> sample_t; typedef boost::accumulators::stats<boost::accumulators::tag::weighted_mean(boost::accumulators::immediate)> mystats; boost::accumulators::accumulator_set<sample_t, mystats, int> acc2; Which is basically the same as: sample_t s; typedef boost::numeric::functional::multiplies<sample_t, int>::result_type weighted_sample; typedef boost::numeric::functional::fdiv<weighted_sample, int>::result_type result_type; result_type mean(s); which also doesn’t compile and gives a pretty-much-identical error message. I’m completely unfamiliar with the boost accumulators code, any suggestions on why this is failing, and what I can do to patch valarray.cpp so the regression test will compile? Thanks, Chris

1 0

[Git] Are past releases tagged somehow?
by John Maddock 23 Apr '14

23 Apr '14

Is there a way to identify and checkout past releases from Git? I couldn't find anything on the Wiki? Thanks, John.

4 3

[container] pull request for fixing propagate_on_container_move_assignment (add ::value)
by Ben Pope 23 Apr '14

23 Apr '14

I noticed that this was only just changed, but hey ho. https://github.com/boostorg/container/pull/1 Ben

1 0

[GSoC] A C++11 enabled TMP library (accepted)
by Louis Dionne 23 Apr '14

23 Apr '14

Dear community, I am pleased to announce that my proposal named "A C++11 template metaprogramming library"[1] was accepted for GSoC 2014. I want to thank the community for putting trust in the proposal, and I am committed to do everything I can to make this project succeed. As explained in my proposal, the goal of the project is to build a high quality template metaprogramming library using modern techniques to achieve both higher expressiveness and lower compilation times. Since the ultimate goal is to make such a library part of the Boost distribution, I will try to involve the community and maintain a tight feedback loop. With your support, I am confident that we can achieve a lot in the direction of better template metaprogramming. This is also a good time to mention (advertise?) that I will be presenting the project at the upcoming C++Now conference. :-) I am knee-deep in my finals right now, but updates should come shortly. Stay tuned! Louis Dionne [1]: http://goo.gl/ZlYeFi

4 5

[assign] [tokenizer] Please pull two trivial patches
by Gregor Jasny 23 Apr '14

23 Apr '14

Hello, since four months two trivial patches to replace a plain throw with BOOST_THROW_EXCEPTION sit in the trac and github (as pull requests). Could anyone please review and submit them? I'd like to see them in the next release or the one after. #9504 - https://github.com/boostorg/assign/pull/1 #9505 - https://github.com/boostorg/tokenizer/pull/1 Thanks, Gregor

1 0

[utility] Pull request: Use an unsigned type as an intermediate result instead of left shifting a negative integral constant
by Ben Pope 22 Apr '14

22 Apr '14

https://github.com/boostorg/utility/pull/4 No maintainer listed in maintainers.txt so cross posting this one. Ben

4 5

[gsoc2014] This year's students announced
by Niall Douglas 22 Apr '14

22 Apr '14

Dear Boost, We are pleased to announce that the following eight students will be this year's Google Summer of Code for 2014: 1. Anton Bikineev Mentor: Christopher Kormanyos Topic:Boost.Math Generalized Hypergeometric Functions 2. Ian Forbes Mentor: Tim Blechmann Topic: Boost.Thread Scheduled Executors 3. Louis Dionne Mentor: Joel Falcou Topic: A C++11 template metaprogramming library 4. Mark Lingle Mentor: David Bellot Topic: Boost.uBlas: Optimization via Smart Templating and a Tree Optimizer class 5. Roshan Mentor: Kyle Lutz Topic: Expand and Improve Boost.Compute 6. Saksham Maheshwari Mentor: Stefan Seefeld Topic: Boost.XML - A Standard XML Library 7. Thaler Benedek Mentor: Vicente J. Botet Escriba Topic: Boost.Pipeline 8. Vinícius dos Santos Oliveira Mentor: Bjorn Reese Topic: HTTP server on Boost At US$5,000 funding per student, this represents an investment of US$40,000 into Boost by Google this year, for which we are extremely grateful. Our thanks to everyone in Google who makes this happen every year. With so few slots available from Google some very good candidates and proposals could not be selected, so if you were not selected this year, better luck next year (remember to come early!). Congratulations to the students who did make it, and our collective thanks go to the primary mentors above for taking the time this summer, as well to the secondary mentors not listed above as well as everyone who helped out with the proposal review and the ranking and voting this year. Niall & Boris --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

8 7

Strange use of random values in regression test ...
by Chris Cooper 21 Apr '14

21 Apr '14

The test_main() of libs/utility/operators_test.cpp loops 1000 times, running a variety of tests on random values. However, since the randomizer (boost::minstd_rand) is instantiated inside the loop, it appears that the randomizer is re-seeded for each loop, meaning it runs the test 1000x with the exact same values each time. I’m not 100% familiar with the boost random value generators, am I missing something? Or should the boost::minstd_rand be instantiated outside the loop? I’m happy to add this as a boost bug if my understanding is correct … Thanks, Chris

2 1

[type traits] has_complement, enum class, and gcc 4.9
by Nevin Liber 21 Apr '14

21 Apr '14

We are seeing build problems with gcc 4.9 RC1 and Boost 1.55. Given the following test program: #include <boost/type_traits.hpp> #include <iostream> enum class E {}; int main() { std::cout << boost::has_complement<E>() << std::endl; } Using g++ -std=c++11, we get: In file included from */opt/local/include/boost/config.hpp:57:0*, from */opt/local/include/boost/type_traits/add_const.hpp:13*, from */opt/local/include/boost/type_traits.hpp:13*, from *a.cpp:1*: /opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp: In instantiation of '*const bool boost::detail::has_complement_impl::operator_exists<E>::value*': */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:173:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl1<E, boost::detail::has_complement_impl::dont_care, false>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:195:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl<E, boost::detail::has_complement_impl::dont_care>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:202:1:* required from '*struct boost::has_complement<E>*' *a.cpp:7:41:* required from here */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:152:56:* *error: *no match for '*operator~*' (operand type is '*E*') BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); * ^* /opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp: In instantiation of '*const bool boost::detail::has_complement_impl::operator_returns_void<E>::value*': */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:173:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl1<E, boost::detail::has_complement_impl::dont_care, false>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:195:4:* required from '*const bool boost::detail::has_complement_impl::trait_impl<E, boost::detail::has_complement_impl::dont_care>::value*' */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:202:1:* required from '*struct boost::has_complement<E>*' *a.cpp:7:41:* required from here */opt/local/include/boost/type_traits/detail/has_prefix_operator.hpp:89:102:* *error: *no match for '*operator~*' (operand type is '*E*') BOOST_STATIC_CONSTANT(bool, value = (sizeof(::boost::type_traits::yes_type)==sizeof(returns_void((BOOST_TT_TRAIT_OP make<Rhs>(),returns_void_t()))))); * ^* *a.cpp:* In function '*int main()*': *a.cpp:7:41:* *error: *cannot bind '*std::ostream {aka std::basic_ostream<char>}*' lvalue to '*std::basic_ostream<char>&&*' { std::cout << boost::has_complement<E>() << std::endl; } * ^* In file included from */opt/local/include/gcc49/c++/istream:39:0*, from */opt/local/include/gcc49/c++/sstream:38*, from */opt/local/include/gcc49/c++/complex:45*, from */opt/local/include/boost/type_traits/is_complex.hpp:12*, from */opt/local/include/boost/type_traits.hpp:49*, from *a.cpp:1*: */opt/local/include/gcc49/c++/ostream:602:5:* *note: *initializing argument 1 of '*std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT = char; _Traits = std::char_traits<char>; _Tp = boost::has_complement<E>]*' operator<<(basic_ostream<_CharT, _Traits>&& __os, const _Tp& __x) * ^* It compiles fine under gcc 4.7.2 and clang 3.4. It also compiles fine for plain enums. Any ideas? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

2 2

Corruption in container::string when used with boost::interprocess
by Lars Hagström 21 Apr '14

21 Apr '14

Found this bug recently, but since theres been no activity on it on Trac I'm double-posting here. https://svn.boost.org/trac/boost/ticket/9855 Cheers Lars

2 1

Boost.Align review begins today
by Ahmed Charles 21 Apr '14

21 Apr '14

Hi all, The review of Boost.Align by Glen Fernandes commences today, Friday, 11 April, and concludes Sunday, 20 April. Boost.Align provides: 1. Function align() to align a pointer, for implementations which do not provide C++11's std::align(). 2. Functions aligned_alloc() and aligned_free() for dynamic allocation with specified alignment. { For use in place of ::operator new() and ::operator delete(). } 3. Class template aligned_allocator as an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of std::allocator. } 4. Class template aligned_allocator_adaptor to turn any existing allocator into an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of any existing allocator type. } 5. Function is_aligned() to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. Notes: This library also meets needs in existing Boost libraries. - Boost.Smart_Ptr has its own implementation of align(). - Boost.Interprocess and Boost.Log each have their own implementation of aligned_alloc() and aligned_free(). Source: doc: http://glenfe.github.io/align git: http://github.com/glenfe/align zip: http://github.com/glenfe/align/archive/master.zip Please always state in your review whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - 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? Ahmed Charles Review Manager

10 26

Boost.Align review results
by Ahmed Charles 21 Apr '14

21 Apr '14

The review of the proposed Boost.Align library ended on April 20, 2014. The result is: Accepted with conditions. Glen and I would like to thank everyone for contributing to the review for Boost.Align. either with a review or comments in the discussions. The summary of formal votes is as follows (alphabetical order): Andrey Semashev - Yes (conditional) Antony Polukhin - Yes (conditional) Bjorn Reese - Yes Lars Viklund - Yes Michael Spencer - Yes For a total of 5 votes for acceptance and 0 votes for rejection. The conditional acceptance is based on the quality of documentation, as the feedback given on code and design has already been addressed. The conditions below are agreeable to the author: 1. QuickBook documentation should be used, following typical Boost documentation structure. 2. Additional examples should be used to make the understanding/use of the library easier. 3. Additional minor comments from the reviews should be addressed. I would like to thank Glen for making this an easy first review manager experience and I look forward to reviewing other libraries in the future.

2 1

Application need a Review Manager. Anyone is interested?
by Renato Forti 21 Apr '14

21 Apr '14

>> So do a ton of other libraries waiting in the review queue. >> One trend I've noticed in recent reviews is that the libraries which find review managers are small, sometimes very small. It might be worth breaking up Application into smaller libraries if you want a faster review. I think that I can split it. >> Equally, AFIO has 1000 active lines of code, and I very much doubt it'll see a review manager any time soon. I'm thinking maybe next year it might >> (I will speak at C++ Now introducing the session on the Future of Boost, which will mention AFIO :) ). Nice! I will check! >> FYI, I'd just love if Application's design rationale told me why and how it's similar or different to Boost.Process. Process is one of the most popular non-official Boost libraries out there. Well, I think that are totally different. Quick, Boost.Process is used to start a new process, Boost.Application is the process in fact. Boost.Application provides a model/environment to build any application, not start an application. Some features are: With it you can deploy your application as server (service on windows, and daemon on unix). It provides a plug-in system tool and other facilities (like aspects) that will help developer on application development. It provides a way to create other applications modes, e.g. Apache http server module. Some references: http://www.codeproject.com/Articles/756866/Build-a-Server-Application-using… http://www.codeproject.com/Articles/695937/Creating-a-New-Application-Mode Thanks alot for your comments.

4 4

GSoC 2014 - Functional - Monad
by Ding Xiangfei 19 Apr '14

19 Apr '14

Hello, Boost. This is Xiangfei, a first year CS student from National University of Sinagpore. I am familiar with C++ template programming and have learnt a little functional programming language by myself. Therefore I find the monad project in boost will be very interesting and useful. This is my first time applying for GSoC. I have past boost use experience, but it is my first time also to contribute in Boost library. I have a question for the implementation of monad. What is the degree of integration of this module with other Boost utilities other than sequences and containers? Thank you. Regards, Xiangfei

2 10

Re: [boost] [serialization] proposed improvements: forward-compatibility of serialization
by Brian Wood 18 Apr '14

18 Apr '14

On Fri, Apr 18, 2014 at 10:52 AM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > > On Friday, April 18, 2014 6:40:32 AM UTC-7, Brian Wood wrote: >> >> niXman writes: >> >> > Hi, >> > >> > YAS(https://github.com/niXman/yas) ? >> >> The test results on your page are impressive, but there's >> not much info on what or how you tested. Please give >> some more info on that. >> > > Looks like the YAS version uses a special mem_ostream/mem_istream classes > rather than std::strstream. Since the largest part of any of these > benchmarks is spent on the i/o part this would account for a huge > difference. > > >> >> Also it looks to me like the results you list for text >> serialization are off by a factor of ten. >> > > This is common when the benchmark is compiled in debug mode. The boost > serialization library has a huge amount of extra checking in debug mode > which generally slows things down by a factor of 10. I don't know if > that's the case here though. > > He has this table: | boost | YAS | +------+---------+---------+---------+ | save | 8090 ms | 277 ms | +28000% | +------+---------+---------+---------+ | load | 8794 ms | 265 ms | +33000% | +------------------------------------+ I think the last column is off. It should be +2800% and +3300%. Personally I wouldn't use the percents and would use 28 and 33. -- Brian Ebenezer Enterprises - Heavenly code. http://webEbenezer.net

1 0

Re: [boost] [serialization] proposed improvements: forward-compatibility of serialization
by Brian Wood 18 Apr '14

18 Apr '14

niXman writes: > Hi, > > YAS(https://github.com/niXman/yas) ? The test results on your page are impressive, but there's not much info on what or how you tested. Please give some more info on that. Also it looks to me like the results you list for text serialization are off by a factor of ten. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

1 0