- Boost - lists.boost.org

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

[interprocess] Mixed 32bit/64bit processes shared memory current status
by Pete Bartlett 07 Oct '11

07 Oct '11

I wrote about: >http://lists.boost.org/Archives/boost/2011/02/177696.php >https://svn.boost.org/trac/boost/ticket/5230 What was obvious to the contributors to the above discussion, but dawned on me only slowly, was that mixed bitness shared memory only stands a chance of working if ones uses offset_ptr< void , boost::int64_t , boost::uint64_t > rather than the default offset_ptr< void > (which is possible on current trunk). I've now begun testing this in my own app and it is looking promising so far. Hope this helps someone googling for the same thing. Pete

2 1

[Containers] How about a list with O(1) splice?
by Phil Endecott 07 Oct '11

07 Oct '11

In another thread, Stephan T. Lavavej wrote: > Two-list partial-splice is now linear time. FDIS 23.3.5.5 > [list.ops]/14: "Complexity: Constant time if &x == this; > otherwise, linear time." Is there an opportunity here for Boost.Containers to provide a std::list replacement that keeps the old O(1) splice and O(N) size? I can imagine a lot of demand for this once people discover that their old splicing code is trashed by a std library upgrade... [OT: does anyone know of a list of "C++1x nasties" like this? It's easy to find lists of new features, but harder to find lists of misfeatures...] Regards, Phil.

8 19

[Review] Review results for Lockfree
by Hartmut Kaiser 07 Oct '11

07 Oct '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics would be good if added to Lockfree, though. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

5 8