June 2012 - Boost - lists.preview.boost.org

[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

Boost's on the map
by John Maddock 23 Jun '12

23 Jun '12

Literally in this case: http://softwaremaniacs.org/media/alenacpp/cppmap-2012.png John.

4 3

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

John Maddock: > This actually looks compelling enough to me, that we should probably mandate > use of BOOST_THROW_EXCEPTION. Are you going to take away their library card if an author doesn't want to do this? ;) Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

Fabio Fracassi: > That is how modular development works, you let go of some control in > exchange for synergy effects and free added functionality. > Yes, it creates communication overhead but the win (for the users) is huge. I skipped Boost 1.49 and have been updating these results using Boost 1.50 -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I haven't noticed any performance improvements in the serialization library that's in Boost from 1.48 to the latest version. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Linked map
by Kannan R 23 Jun '12

23 Jun '12

Recently i wrote a json parser. I used stl map to store the json objects. Everything was fine except the order of the objects. Is it worth to build something in boost to have the map which provides an iterator to get the elements in same order? Please advise.

3 2

exception handling in multithreaded applications (was: RE: Boost and exceptions)
by Thomas Klimpel 22 Jun '12

22 Jun '12

Fabio Fracassi wrote: > Yes it is, because in reality boost exception solves problems for the > users of any library that uses it. When using boost exception I can > safely let exceptions escape threads and have them rethrown in the > starting thread, for instance. I would be interested to learn how you do this. With open-mp (and mpi), my current way to add exception handling code really adds much noise: bool cancel = false; #pragma omp parallel shared(cancel) { try { ... the real code } catch (std::exception& r) { cancel = true; store_exception(r); } } if (cancel) { rethrow_exception(); } Regards, Thomas

2 1

emulating concepts in C++11
by lcaminiti 22 Jun '12

22 Jun '12

Hello all, I was not able to find Boost.Generic source code (I asked Matt Calabrese but no reply): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 Are you aware of any trick (e.g., the tricks used by Boost.Generic) to emulate concepts in C++11? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-emulating-concepts-in-C-11-tp46317… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Still a monolithic library? Or a bunch of independent ones?
by hello world 21 Jun '12

21 Jun '12

Hello, It's been a few years since I didn't come around boost.org, and I was just wondering... Is boost still a monolithic library? or Is it a collection of separate libraries now? Or to state it another way: Is it ``easy'' to take only one library's files from the boost distribution and use it. Or do I have to carry everything around even If I'm using just one library? I understand that this must be library specific, but I'm just asking this to know what your general feel overall. Thanks.

3 2

Interest in a "breadth first" algorithm?
by Gary Powell 21 Jun '12

21 Jun '12

A while ago I needed to serialize and de-serialize a std::map and I realized that the only interface was begin(), end() which of course meant that re-creating this same map was the least efficient way possible, as all the elements were added in sorted order. Because I wrote them out using begin() -> end() So I wrote a breadth first template which takes a container, a template to use as the core of a queue, a template for the allocator, the container and a function to apply to the elements. It doesn't quite do a true breadth first traversal because I don't look at the inner data structure of the map, (works with sets as well) but instead does a middle, then right, left push until it's hit all of the nodes. And it doesn't copy the elements, it pushes the iterators, and calls the function on that iterator when the length is 1. It ended up speeding up my map recreation by about 20% (because I start with a center enough node that it should never have to be rebalanced) at a cost of about 5% to write it this way (It's more expensive to create the queue, and traverse the map from center on out), for a roughly 15% gain in speed. Is there any interest this for boost? I've got working code but not any documentation. And rather than spend a huge amount of time on that I'm looking to see if anyone else has an interest in this. -Gary- -- ------------------ powellg(a)gmail.com "Come gather 'round people wherever you roam. And admit that the waters around you have grown. And accept it that soon you'll be drenched to the bone. If your time to you is worth savin'. Ahh you better start swimmin' or you'll sink like a stone. For the times they are a-changin'" Bob Dylan

4 4

Integrating CUDA nvcc into bjam
by jombi01821 21 Jun '12

21 Jun '12

I would like to know how to take an existing project that build with bjam and have it understand how to handle .cu CUDA files -- View this message in context: http://boost.2283326.n4.nabble.com/Integrating-CUDA-nvcc-into-bjam-tp463163… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50] Is it too late for fixes?
by John Maddock 21 Jun '12

21 Jun '12

I have a trivial fix for 1.50 if it's not too late (missing include guards on a header), see https://svn.boost.org/trac/boost/ticket/7001 Is it too late now, suspect it is? Thanks, John.

1 0

[exception] gcc 4.7 non-virtual destructor warning
by Daniel Larimer 21 Jun '12

21 Jun '12

/usr/local/include/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Is there a reason why the destructor isn't virtual? This only shows up when I compile with -Wall, which I like to do because it catches many important errors. Unfortunately, if I have to filter out boost warnings it makes it less effective.. particularly when the warning is actually about 30 lines long in my console. Dan

3 3

[release] merge request for test fix
by Jürgen Hunold 20 Jun '12

20 Jun '12

Hi, I would like to merge r78972 to the release branch. It fixes some test failures introduced by 78802 which renamed UTC_TIME to UTC_TIME_. Trunk tests have cycled for 2 days and the interprocress results start to turn green. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

[svn] post commit hooks broken
by Jürgen Hunold 19 Jun '12

19 Jun '12

Hi, the subversion post commit hooks seem to be broken. The last commit mail I got is Author: garcia Date: 2012-06-07 16:20:43 EDT (Thu, 07 Jun 2012) New Revision: 78856 and there habe been numerous commits since. I have also checked in a followoup to r78802 yesterday, which should have triggered an automated trac entry for #6940. But nothing happens. Can someone with enough karma please take a look at this? As a sidenote: The inofficial git mirror seems stalled, too. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[Locale] VC11 Regressions
by Joshua Boyce 18 Jun '12

18 Jun '12

I am currently porting some code to the VC11 compiler beta, and as part of that process I ran the unit tests on the libraries I use and noticed some failures in Boost.Locale under VC11 that are not present under VC10. Ones of the tests (test_winapi_collate) actually crashes (showing the WER dialog etc). Logs for comparison (tests were run on trunk): http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc10-20120330-2143… http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc11-20120330-2143… Has anyone else observed this or is it a configuration issue on my end?

4 11

Multiprecision vs. xint
by Phil Endecott 18 Jun '12

18 Jun '12

Dear All, I'd like to encourage people who are looking at the proposed Multiprecision library to remind themselves of the xint review last year. See e.g. http://thread.gmane.org/gmane.comp.lib.boost.devel/218624 (result) http://thread.gmane.org/gmane.comp.lib.boost.devel/215968 (my review) etc. etc. To what extent do we believe that this new library addresses the weaknesses of the last proposal? It would be great if Vladimir Prus, review manager for xint, could write a review of Multiprecision. Here's my take on it: Multiprecision addresses many of the problems of xint, and also extends the scope into areas that xint did not address at all. However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me. Furthermore, it doesn't help me to build the int128_t that I want. Although Multiprecision is divided into "front" and "back"-ends, this division is not in the right place to let me substitute my own backend that just provides the 128 bits of storage. In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here. Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms. Regards, Phil.

5 9