October 2011 - Boost - lists.preview.boost.org

Re: [boost] [proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Eric Niebler 10 Oct '11

10 Oct '11

On 10/10/2011 2:08 AM, Joel de Guzman wrote: > On 10/10/2011 1:52 PM, Joel de Guzman wrote: >> On 10/10/2011 12:38 PM, Eric Niebler wrote: >>> >>> Bummer. I suggest adding an rvalue ref overload of operator%= that >>> shares an implementation with the const lvalue one. Should just be a few >>> lines of code. Is that a problem? >> >> Not really a problem. But, %= is just an example of the problems >> (plural with an s). We suspect that it is more widespread. I'll >> see how pervasive the changes need to be and get back to you. > > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. > > Hartmut, I committed the fix for Qi and Karma. Can you please > take a look at the Lex regressions? There's a good chance > that the problem with the examples is also related to the Lex > problem. I just ran the spirit_v2/lex and spirit_v2/lex_regressions test suites on msvc-10.0, and everything passed for me. Is this fixed already? Let me know asap so I know whether to revert my Proto changes. (Note: If they don't make it in this time, these Proto changes will eventually go back in for next release, so Qi/Karma/Lex will need to be fixed eventually.) -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

Re: [boost] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Mathias Gaunard 10 Oct '11

10 Oct '11

On 10/10/2011 11:08, Joel de Guzman wrote: > Ok, adding the %= for rvalue refs for Qi and Karma fixed a lot of > the failing tests. However, I am not sure how to fix the tests > involving Lex (crashes on VC10 but OK on GCC). The compiler > tutorial I am working on also got broken. I am not sure what else > in the examples got broken. It's quite difficult to ascertain > where the problem is because the code builds without errors > but either crashes or does not work as expected at runtime. > This is an insidious critter. Does it work without errors when enabling optimizations? It could be a problem with the lifetime of references.

1 0

multi_index bug?
by Olaf van der Spek 10 Oct '11

10 Oct '11

Hi, I've got this container: typedef boost::multi_index_container< torrent_t, boost::multi_index::indexed_by< // boost::multi_index::hashed_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::ordered_unique<boost::multi_index::member<torrent_t, int, &torrent_t::id>>, boost::multi_index::sequenced<> > > torrents_t; I'm using the find() member to find elements. When I use hashed_unique, it seems to be unable to find some elements, while it finds all if I use ordered_unique. This is with Boost 1.46.1.1 (Debian) and gcc version 4.6.1 (Debian 4.6.1-4) Is this a known issue? Olaf

2 2

Re: [boost] Boost.Algorithm design question
by Joe Mucchiello 10 Oct '11

10 Oct '11

On Fri, 07 Oct 2011 10:30:26 +0200, Thorsten Ottosen <thorsten.ottosen(a)dezide.com> wrote: >Den 06-10-2011 18:27, Phil Endecott skrev: >> Thorsten Ottosen wrote: >>> Even better, don't use vector<const char*>. What o you need that for? >[snip] >> >> Here's a real motivating example where I want to use vector<const >> char*>. I have a large file containing null-terminated strings which I >> memory map. After opening the file, I construct some sort of index of >> those strings in a sorted vector. Then I search for things using >> std::equal_range, std::lower_bound, or similar. > >That's a good example, I grant you. I actually have a helper class for this called cstrptr which is a typedef for the template class basic_cstrptr<char>. It is a "dumb" wrapper around const char * that provides some std::string functions to the normally even dumber bare pointer to char. It's designed for holding those magic strings that creep into production code all the time. sizeof cstrptr == sizeof const char* is always true so the constructor has very little overhead. The calling code is responsible for ensuring the lifetime of the ptr exceeds the lifetime of the cstrptr instance. It implements all the comparison operators against std::basic_string and const char*. It implements a const operator[] and an O(N) length() function. It only implements assignment and copy constructor to allow containers to hold them. I've wondered whether it was worth submitting to boost. It is so small I can't imagine it sitting on its own as a "library".

2 1

[test] backward compatibility issue
by Jürgen Hunold 10 Oct '11

10 Oct '11

Hi Gennadiy, I'm getting some compiler errors when using the new trunk version of Boost.Test with our sources. I'm getting error: ‘global_fixture_impl’ in namespace ‘boost::unit_test::ut_detail’ does not name a type when using BOOST_GLOBAL_FIXTURE and only #including "boost/test/unit_test_suite.hpp" This file #defines at line 179: static boost::unit_test::ut_detail::global_fixture_impl<F> BOOST_JOIN( gf_, F ) ; a simple #include <boost/test/tree/global_fixture.hpp> fixes this. Patch attached. Okay to commit? yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

Boost.Algorithms request
by Zoltán Tóth 10 Oct '11

10 Oct '11

I ask to change the name of function is_ordered(). The "is_" prefix suggests that it is a boolean function which it is not. Also, there are other functions there with prefix "is_" and which are boolean functions, and this non-uniformity hurts the eye. I suggest the name "first_misordered".

4 3

Re: [boost] vsix - template_profiler extension, Templight
by József Mihalicza 09 Oct '11

09 Oct '11

Hello, From: Domagoj Saric: ...you might want to try the Templight route. A couple of years back the Hungarian team behind it tried to do the same thing as you (a "meta program debugger and profiler" Visual Studio add-in, only it was written in C++ rather than in C#). The source for an alpha-ish version was also available somewhere... The biggest problem with our tools is that they are rather prototypes than tools for everyday use. As none of the authors have had enough time to maintain them, they more or less remained in an alpha state. Fortunately this seems to change soon, a team with dedicated resources is being formed to make these tools usable and presumably public domain. What we have so far: * Templight framework: a set of command line utilities, based on Xerces and boost.{wave,spirit}. Supports g++ and VC (patches and warning message interpretation). * Visual Studio add-in, where the user can place breakpoints in templates, view template stack, instantiation history, debug step by step. * Standalone debugger application with the same features as of the VS add-in. C++, Qt, mainly tested on Windows. * Templar: standalone visualizer application: can load previously generated (with the cpp2trace tool) trace files and draws the instantiation forest allowing step by step debugging. C++, Qt, graphviz. The latest binary for Windows is available here: http://people.inf.elte.hu/pocok/ * Ad-hoc solutions for profiling: modified g++, also had some patches for VC to print timestamp at each warning. * A not-yet-implemented approach to cope with inheritance. If B inherits A, currently the reported order is Abegin,Aend,Bbegin,Bend instead of the expected Bbegin,Abegin,Aend,Bend. As we used handcrafted makefiles (on linux) and projects files (VC) with absolute paths to installed libraries, it is not trivial to make the source compilable. This is why we decided not to publish it in its current form. Still, if anyone is interested in any of them, feel free to contact me, I can send the current version. Regards, Jocó

1 0

Re: [boost] [1.46.0] Compilation Issues
by Lars Viklund 08 Oct '11

08 Oct '11

On Sat, Oct 08, 2011 at 11:34:02AM +0530, ranganaths wrote: > Hello, > trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of > Pls let me know how to overcome the same. All the > redefinitions are the clashes with that of the MSVC compiler includes. VC6 is a pre-standard compiler. As such, it has lots of quirks and templates are pretty much unusable on it. I strongly recommend either upgrading the compiler (there's free Express editions and reasonably cheap business and academic versions through BizSpark and DreamSpark), or using older Boost versions who accidentally care more about legacy toolchains. Strong words, but it's not feasible maintaining workarounds for legacy toolchains, not to mention actively fixing things for them. There's a huge thread on what to do with dysfunctional toolchains a few months ago. It's an amusing read. -- Lars Viklund | zao(a)acc.umu.se

1 0

[1.46.0] Compilation Issues
by ranganaths 08 Oct '11

08 Oct '11

Hello, I am new to this forum. I am using the Boost Library in my open source application and I am facing lot of compilation issues when trying to compile on MSVC 6.0, but the same works well in Cygwin. Most of the compilation errors are based on the redefinition. The errors is as below error C2371: 'XXX' : redefinition; different basic types Pls let me know how to overcome the same. All the redefinitions are the clashes with that of the MSVC compiler includes. Eg: Boost has definition for 'round_toward_zero' in e:\Application \boost\detail\limits.hpp(58) : see declaration of 'round_indeterminate' c:\program files\microsoft visual studio\vc98\include\limits(28) : error C2371: 'round_toward_zero' : redefinition; different basic types Regards, Ranganath

1 0

fusion - reverse_view on maps
by Brandon Kohn 07 Oct '11

07 Oct '11

Hello, Awhile back I was using fusion.reverse_view on a fusion.map sequence (I think it was ~<=1.37 or thereabouts.) In later upgrades this became broken as a bidirectional concept was enforced on the reverse_view (quite sensible.) To work around this I made a minor change to my version which allowed reverse_view to work on both bidirectional sequences and those meeting the is_associative trait. Anyway, it got me wondering if there is a good reason that the map type doesn't model a bidirectional sequence? Cheers, Brandon

2 2