- Boost - lists.boost.org

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

[boost.program_options] another constructor for option_description
by Guilherme Maciel Ferreira 07 Oct '11

07 Oct '11

Hi list, Through options_description_easy_init::operator()(const char* name, const char* description), I can create an option_description with just the option name and description, without the value_semantic. However, all option_description class constructors require this value_semantic. Checking the code, I saw that options_description_easy_init uses untyped_value to create an option_description without type. Why not providing a set of constructors consistent with the options_description_easy_init::operator() operators? Kind regards, Guilherme -- Guilherme Maciel Ferreira Gtalk: guigasurf MSN: guigasurf(a)hotmail.com Mobile Brazil: +55 48 9904 3728 e +55 48 9134 4651 Skype: guilherme.maciel.ferreira

1 0

[property_tree] include directive for non-info files
by Ivan Le Lann 07 Oct '11

07 Oct '11

Hi, In Boost.PropertyTree, INFO format has the nice #include directive. But it seems you cannot include other formats. Typically such INFO file, key { #include_xml "my.xml" } with "my.xml" : <root><child>kid</child></root> could give : get<std::string> ("key.root.child") == "kid" A very quick look at info parser makes me think that it would be easy to implement. Any comment ? Regards, Ivan

2 1

[filesystem] New operational function added: canonical()
by Beman Dawes 06 Oct '11

06 Oct '11

A canonical() function has been added at the suggest of David Svoboda from CERT. Boost.Filesystem's class path had such a function at one time, but it was deprecated because it didn't handle symlinks correctly. The new canonical() free function walks the path resolving symlinks, so now works correctly even when symlinks are present. For the curious, David's rationale for the function follows. --Beman Canonicalized pathnames are an important security measure when you want to do validity checking on your path (eg does this path live in /home/goodguy or /home/badguy?). There are several implementations of canonicalization functions, ranging from POSIX's realpath() function, to the GNU library's canonicalize_file_name(). For platform-independent implementations, Java provides the File.getCanonicalFile() method. CERT advocates the use of canonicalized filenames in its Secure Coding rules for both C FIO02-C. Canonicalize path names originating from untrusted sources https://www.securecoding.cert.org/confluence/x/EAY and Java IDS02-J. Canonicalize path names before validating them https://www.securecoding.cert.org/confluence/x/S4EVAQ

1 0

Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
by Andrew Hundt 06 Oct '11

06 Oct '11

I've implemented a small companion class to boost.array that functions like a stack allocated vector with fixed capacity. The motivation for this class came when I was using boost.array in an interprocess library, when I realized that I actually desired an adjustable size boost.array, without the complexity of the vector class in the interprocess library. The result is StaticVector, which is boost.array directly modified with a size in front of the array, and added facilities to match std::vector. The Implementation is available at: https://github.com/ahundt/Boost.StaticVector Sample Code: StaticVector<std::size_t,3> three; three.push_back(5); three.push_back(2); // size: 2 capacity: 3 three.push_back(3); three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded So here is the big question: Is there any interest in the class? Cheers! Andrew Hundt

7 12

[Review:Algorithms] all.hpp vs std::count
by Andrew Hundt 05 Oct '11

05 Oct '11

What is the advantage of the functions in all.hpp over std::count? I feel like one could simply call (in pseudocode) std::count == 0, std::count == 1, std::count == class.size() to achieve the same effect. Cheers! Andrew Hundt Robotics Engineer National Robotics Engineering Center Carnegie Mellon University 908-720-5501

5 11

[website] URL for most recent version of BoostBook docs?
by Beman Dawes 05 Oct '11

05 Oct '11

http://www.boost.org/doc/libs/1_47_0/doc/html/boostbook.html is the URL for 1.47.0. What URL always points to the most recent version? --Beman

4 4