June 2010 - Boost - lists.boost.org

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[Boost-users] [BGL] Stoer–Wagner min-cut algorithm
by Daniel Trebbien 26 Sep '10

26 Sep '10

> The usual idiom for that in BGL algorithms is to use an > iterator_property_map on the graph's vertices, built using a vector and > indexed by the vertex_index property map of the graph. You can also use a > shared_array_property_map, which manages its storage internally. If you > are doing a generic algorithm, the logic to manage these maps correctly is > somewhat difficult. One place to look for a template of what to do is the > distance map handling at the bottom of > <boost/graph/dijkstra_shortest_paths.hpp>, particularly > dijkstra_shortest_paths() and detail::dijkstra_dispatch1(). The basic > logic is to look at the named parameter structure that the user passes is > and see if there is an assignment map there. If so, use it; otherwise, > look for a vertex_index map in the named parameter structure, defaulting > to get(vertex_index, g), then use the found vertex_index map to create an > iterator_property_map or shared_array_property_map. Now that compilers > are more compliant, there are probably simpler ways to implement the logic > than to use multiple dispatch functions, but the approach in > dijkstra_shortest_paths.hpp is known to work. > > When you get this algorithm done, you may want to contribute it to BGL to > be added to Boost. We are always interested in new algorithms. > > -- Jeremiah Willcock Hello Jeremiah, I would very much like to contribute my implementation of the Stoer–Wagner min-cut algorithm to BGL. In preparation for this, I have attached a "pre-release" version to this e-mail which has everything needed to build the test case with g++ and GNU Make. Before I add in all of the template code to support "default" template parameters and other niceties, I figured that it would be good to have a review of the code to make sure that I am headed in the right direction. Also, I have tested my code against the example from Stoer & Wagner (1997). It appears to be working correctly, but there might be bugs. I think that it would be good to have more testing. Would someone please review my code? Also, is anyone aware of good examples for testing min-cut implementations? Daniel

4 57

[Review] Formal Review: Boost.Move
by OvermindDL1 19 Sep '10

19 Sep '10

Greetings Boost Developers and Users, It's my pleasure to announce that the review of Ion Gaztañagas' Move library starts May 10th and lasts until May 24th, 2010, unless an extension occurs. What is it? =========== The Boost.Move library would supply an emulated C++1x Move semantics interface, aka RValue References, allowing for a wide variety of easy to use and easy to add in optimization abilities. The most used function it would add would be: val_b = boost::move( val_a ); Which would move val_a to val_b; val_a should not be used after this line. This semantic allows for a vast amount of optimizations, especially in regards to temporaries, see the documentation for further examples and use. Other patterns emulated are && rvalue references for functions/members and constructors. There are also a number of STL containers in the sandbox that support move semantics using this library for higher efficiency. Getting the library =================== The latest version of this library may be downloaded from SVN: http://svn.boost.org/svn/boost/sandbox/move/ and the docs may be viewed here Docs: http://igaztanaga.drivehq.com/libs/move/doc/html/index.html and do note, this library is header-only and is designed to be absolutely generic to be useful in all areas of C++ programming. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ====================== If you want or need a primer on the subject, please look at the working draft for C++1x. This linked site has also been shown to be quite useful in describing move usefulness: Want Speed? Pass by Value.: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ Move It With Rvalue References: http://cpp-next.com/archive/2009/09/move-it-with-rvalue-references/ And there are further links in that series, but those two will get you started in the domain. Best regards, OvermindDL1, Review Manager (Boost.Move)

15 78

[Boost][website] SSL certificate
by admin＠thefireflyproject.us 18 Aug '10

18 Aug '10

I recently switched from Firefox to Chromium, and I've been having issues accessing [1]https://svn.boost.org. It seems that the SSL certificate used for [2]svn.boost.org is either not properly configured, or not issued by one of the major SSL certificate providers (e.g. VeriSign, GoDaddy). Examination of the certificate indicates that it's issued by the Computer Science Department of Indiana University, and the certificate doesn't have a chain that leads back to a well known CA (the chain is just '[3]svn.boost.org => [4]cs.indiana.edu', and most browsers I've tried don't recognize [5]cs.indiana.edu as a legitimate CA by default). If this isn't just a matter of improper configuration (or, for that matter, just a matter of my browsers being screwy), I'd be happy to offer my own SSL certificate to Boost. The certificate is a standard SSL certificate issued by GoDaddy (domain controlled validation, certificate signing algorithm is RSA 2048 bits), and it's paid through 02/20/2011. I'm currently using my cert for my Debian mirror, so I would have to revoke the current certificate, and then submit a CSR from [6]boost.org's server. Ideally, then I would generate a CSR request, and the boost server would sign it; I'd end up with a cert chain of 'mysite => [7]boost.org => GoDaddy'. [8]boost.org and subdomains would have a cert signed directly by GoDaddy, so the [9]svn.boost.org cert would be verify by most browsers automatically. If there's any interest in this, please let me know. - Bryce Lelbach References 1. https://svn.boost.org/ 2. http://svn.boost.org/ 3. http://svn.boost.org/ 4. http://cs.indiana.edu/ 5. http://cs.indiana.edu/ 6. http://boost.org/ 7. http://boost.org/ 8. http://boost.org/ 9. http://svn.boost.org/

9 12

outer class `this` in local classes
by Lorenzo Caminiti 16 Aug '10

16 Aug '10

Hello all, Is there a way to access the outer class `this` from a local class but without using inheritance? Let me explain with an example: class x { // outer class public: void g() {} void f() { this->g(); // (1) struct y: x { // local class *** using inheritance *** y(x* super): x(*super) {} // (2) void h() { this->g(); // (3) } }; y(this).h(); } }; *** Is there a way to do this but without inheriting `y` from `x`? *** At line (3), the local class `y` can access the outer class `x::g()` simply using `this` because `y` inherits from `x`. However, this inheritance requires to construct another object `x` when `y` is constructed as in line (2) adding runtime overhead and requiring `x` to have an accessible copy constructor. In my application, I need line (3) to essentially look like line (1) so you can program code inside `y` members as if it were inside `x` members. A part from that, the local class `y` could look as it is needed to solve this problem -- with some member variables, other member functions, etc. (For example, I tried to redefine `y::operator->()`/`y::operator*()` to return a pointer/reference to `x` but this does not work because `this->`/`*this` always retain its pointer semantics and they do not use the user defined operators...) Thank you very much. -- Lorenzo

2 3

[intrusive] recursive intrusive data structures
by Tim Blechmann 09 Aug '10

09 Aug '10

hi all, is there an easy way to define recursive data structures? something like: struct my_node: boost::intrusive::list_base_hook<> { boost::intrusive::list<my_node> children; }; i am currently using a base class as helper, which causes very dirty code, since i explicitly need to cast from the base to the main class all over the place: struct my_node_base: boost::intrusive::list_base_hook<> {}; struct node: my_node_base { boost::intrusive::list<my_node_base> children; }; thanks, tim -- tim(a)klingt.org http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius

2 4

[bcp] Bcp namespace rename causes compile errors on multiple libraries (type_traits, range, spirit, foreach, regex, iostreams) in 1.43
by Cliff Green 04 Aug '10

04 Aug '10

Has bcp namespace renaming been tested against all Boost libraries in 1.43? I'm getting compile errors in (or caused by) the following libraries: type_traits, range, spirit, foreach, regex, iostreams (more details later in this message). The compile errors are from a full bjam build of Boost. I haven't compiled tests or built against my work project code, so I suspect there's more errors in header-only libraries. I'm using g++ 4.1.2 on Linux (although these errors are not compiler specific - I'll also be compiling with VC++ 8.0 at some point). All of these errors are easily fixed, and are "boost" text substitution problems. I was able to get all libraries to build after my changes, but I would rather not use hacked-up source (I prefer to work with the Boost developers and install non-modified Boost source into our Clearcase COTS VOB). However, with these (obvious) compile errors, I'm wondering if the bcp namespace facilities are being tested with all Boost libraries? If not, can I work with John Maddock or someone to set up a test process? Besides doing a full extract / rename and build of the libraries, as many examples and tests as possible should also be compiled to find errors in header-only libraries not brought in to the library source build. Of course it's possible all of the errors I've found have been introduced with new code in 1.43 (which still brings up the need to do a full bcp test before a Boost release), or that I somehow incorrectly used bcp, or there's fixes that haven't been applied to the mainline in SVN. My use case is a perfect fit for the bcp namespace facilities - my work team delivers an SDK (which links to and uses various Boost libraries) to another group which also links to and uses Boost libraries in their own application (everything builds into the same executable). Currently our work team is constrained to using the same Boost version, but we'd like to break this constraint (in particular, for other groups to use our SDK). We use (or will use) enough Boost libraries that bcp on the ones we care about pulls in about 80% of Boost, so I went ahead and ran bcp on all of Boost. Details of the compile failures: -- In type_traits: integral_promotion.hpp, promote.hpp, floating_point_promotion.hpp, header guard probs - original code #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_boost_type_traits_integral_promotion_hpp_INCLUDED After running bcp with "MyProj_Boost" for the namespace, the header guard is: #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_MyProj_Boost_type_traits_integral_promotion_hpp_INCLUDED -- In range/config.hpp there's two macros where bcp namespace substitution is incorrectly being applied to the "boost" prefix in boost_range_array: #define BOOST_RANGE_ARRAY_REF() (boost_range_array) #define BOOST_RANGE_ARRAY_REF() (&boost_range_array) Similarly, in range/detail/implementation_help.hpp, the following lines have incorrect substitution: boost_range_silence_warning( boost_range_array ); -- In Phoenix and Wave, there's a bit of namespace substitution problems, where "namespace phoenix" (in multiple files, such as spirit/home/classic/phoenix) is being replaced with "MyProjectphoenix", and in wave/grammars/cpp_intlit_grammer.hpp and cpp_chlit_grammar.hpp there's "namespace phx=phoenix". -- In regex/v4/regex_traits.hpp: BOOST_MPL_HAS_XXX_TRAIT_DEF(boost_extensions_tag) The "boost" prefix in boost_extensions_tag is improperly substituted. -- In foreach.hpp, "boost_foreach_argument_dependent_lookup_hack_value" is not substituted in the enum, but in macros where the enum is used, the substitution is occurring. In iostreams/close.hpp, close_boost_stream on line 143 is being improperly substituted. --- As already mentioned, there's easy changes for each of these. But, is a better answer to make the bcp search and substitution smarter? (I have no idea how easy or hard that would be.) Cliff

3 5