- Boost - lists.boost.org

[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

[functional/hash] integer hash function
by Tim Blechmann 05 Oct '11

05 Oct '11

i was quite amazed that the default hash function for integers seems to be the identity function: from boost/functional/hash/hash.hpp: inline std::size_t hash_value(int v) { return static_cast<std::size_t>(v); } while this is probably the most efficient hash function, it is also the worst possible. is this done intentionally? tim

5 6

[operators] The future
by Daniel Frey 04 Oct '11

04 Oct '11

Hello, I would like to gather some feedback on my plan for the future of the Boost.Operators library. As the maintainer, I have to admit it was a pretty easy job for the last years, as not much has happened. The codebase is full of work-arounds, but it seems to be pretty stable. Another member of the list recently suggested an enhancement, see <https://svn.boost.org/trac/boost/ticket/5929>, which I think shows the first of two points that I would like to straighten out in the future: 1) The library currently mixes two domains, arithmetic operators and iterator helpers 2) No rvalue-support The first point, as already mentioned in the above ticket, could be solved by separating the two parts. I imagine the future Boost.Operators library to concentrate on arithmetic operators, while another, new library could concentrate on iterator and container helpers. Maybe there is an overlap with other libraries (Boost.Iterators), but I'll leave that to others. The (new) Boost.Operators library could provide a base for implementing the iterator helpers just like the current Boost.Operators library does - while there is no dependency in the reversed direction, i.e., the Boost.Operators library does not depend on iterators. The second point is actually a strong argument for a rewrite and a different interface. I have an implementation ready and as it turns out, rvalue-support could be used to optimize some cases *only* if the type itself is commutative. This property of a type is not taken into account in the current Boost.Operators library, which is why the new implementation has different bases, including a new set of grouped operators. See the end of this post for a list of the proposed bases. Note that the new grouped operators are also a consequence of taking commutativity into account, i.e., a field as a commutative_ring+dividable. Dropping some of the old grouped operators should not be a big deal, since grouped operators are more-or-less convenience only, the real functionality is in the "Simple Arithmetic Operators" (see current documentation). If there is a strong need, we could also preserve the old implementation as <boost/legacy/operators.hpp>, but I think it's also practical to drop it completely - old Boost versions are still available for those who need them. To sum up the plan: - Concentrate on arithmetic operators - Add rvalue-support - New set of convenience/grouped operators due to rvalue-support - Drop the old implementation, iterator support Someone else (Olaf?) then takes care of the iterator helpers. So, what do you think? Regards, Daniel ----------------------------- Proposed new base classes: equality_comparable less_than_comparable totally_ordered equivalent partially_ordered addable commutative_addable subtractable subtractable_left multipliable commutative_multipliable dividable dividable_left modable modable_left ring commutative_ring field andable andable_left commutative_andable orable orable_left commutative_orable xorable xorable_left commutative_xorable bitwise bitwise_left commutative_bitwise left_shifttable right_shiftable shiftable incrementable decrementable unit_steppable

10 18

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

04 Oct '11

Dear Ion and Boost.Interprocessors, I'm very interested in the status of support for using shared memory across processes of mixed bitnesses particularly on Windows. I see from the thread here: http://lists.boost.org/Archives/boost/2011/02/177696.php and the trac here https://svn.boost.org/trac/boost/ticket/5230 that this has been looked at before. The ticket is marked as fixed in 1.47, but I believe the changes are actually only on trunk at the moment? I appreciate Ion saying in that Trac ticket that support is experimental and requires feedback from real-world users. I'd be happy to be such a guinea pig user. But to help me along the way, I have a couple of queries: - with trunk, what features from Boost.Interprocess are intended to work across bitness? (I'd plan to build both the 32-bit and 64-bit with the same version of MSVC). For instance, might interprocess::managed_shared_memory, interprocess::vector and interprocess::basic_string be expected to work? - Is it possible to back port the changes from trunk to 1.47 or 1.46.1? If so what would I need to copy? AlignedStorage, Move and Interprocess? Many thanks for any help on this, Pete Bartlett

1 0

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7