May 2010 - Boost - lists.preview.boost.org

[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

[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

[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

[Fusion] Permission to update release branch and roll in dependencies
by Tobias Schwinger 08 Jul '10

08 Jul '10

Dear release team, we're about to freeze the next release. I'd like to kindly ask for your permission to address the issues discussed in this thread http://thread.gmane.org/gmane.comp.lib.boost.devel/198532/ before it's too late, again. Reportedly the outdated files do - other than hoped in that thread - NOT work anymore - and neither do the new and documented ones for the lack of dependencies. So, what I'd like to do is: o merge trunk changes into the Functional module of Fusion o add Forward o optionally add Factory Please check the new mini libraries for "release compliance" and give me a go on the fix. Would be too bad to go with a partially defunct Fusion in two releases for bureaucratic reasons. Please also note that rolling back to a proper previous version might involve more changes and will complicate future merges for us. Regards, Tobias

6 8

[typeof] 2 questions
by Eric Niebler 27 Jun '10

27 Jun '10

1) Some compilers don't support typeof in any form, even emulated. From looking at typeof.hpp, it looks like just #include'ing typeof.hpp on those compilers results in a hard error. I'd like a way to test whether typeof is supported and use it if so, otherwise do something else. How can I do that? 2) I can't find "decltype" by grepping the typeof code. Why doesn't typeof use the decltype keyword on compilers that support it? And I lied. I have another question. How expensive at compile-time is emulated typeof? TIA, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 7

Book "The Boost C++ Libraries" now in English
by Boris Schaeling 23 Jun '10

23 Jun '10

Andreas and I are pleased to announce that the book "The Boost C++ Libraries" is now available in English: <http://en.highscore.de/cpp/boost/> At this point I have to thank Andreas who started translating the 16 chapters of my book nearly a year ago and managed to finish this tremendous amount of work after all that time. Without him there wouldn't be a single sentence of my book available in English. Thank you, Andreas! :-) While you can simply click on <http://en.highscore.de/cpp/boost/> and have a look, here are some explanations in case someone is interested: * The book is licensed under a Creative Commons License and can be copied, distributed and transmitted for non-commercial use. As the part "for non-commercial use" might raise some concerns: You are definitely allowed to use the book at work (print it, hand it out to colleagues, publish it on intranet web servers etc.). We also welcome trainers who want to use the book in classes about the Boost C++ libraries (even if you are paid as a trainer). There is no need to ask us for permission either. What we don't want to see though is e.g. a commercial IT magazine simply filling pages by printing the book. * The book currently consists of 16 chapters. While there are some chapters which present only one library, others introduce a couple of libraries. I decided not to write one chapter per library because some libraries are so small that it's all explained within a few paragraphs. If you want to lookup libraries though you find direct links in the overview at <http://en.highscore.de/cpp/boost/introduction.html#introduction_overview>. * There is a link "Found an error? Fix it in your browser!" below the table of contents in every chapter (your browser must support Javascript to display the link). If you click on the link the webpage becomes editable. This makes it rather easy to fix typos or other mistakes. Changes are saved on the server and will be reviewed (to protect against spam). * If you click on "Found an error? Fix it in your browser!" there is another option called "Mark keywords". If you select this option you can mark words (by clicking on them). The idea is to create an index by marking those words which you think should be included in an index. As it's quite a lot of work to create a good index we welcome proposals of what to include. * For those who know German there is still the original version of the book at <http://www.highscore.de/cpp/boost/>. The content is the very same (even same sample codes). We will also keep the books in sync (it's not that the German version won't be updated anymore). * You can download the HTML version of the book from <http://en.highscore.de/cpp/boost/The%20Boost%20C++%20Libraries.zip>. The ZIP file contains all the web pages and other resources you need to read the book offline. For those who'd like to get a PDF or ePub version of the book there are links to download them. You'll notice that the download of those versions is not for free. The money is used to pay server costs and to finance new chapters. We hope you agree that the prices are reasonable. * If you purchase the ePub version of the book I am very interested in your feedback. As the eBook market is still rather small it's difficult to get the feedback you need to understand what to improve. Given that there have been many discussions lately about what's wrong with Boost, we hope that this book will give the Boost libraries and C++ another, well, boost. :-) Boris

14 16

[website] Smaller favicon.ico file
by Jeremiah Willcock 21 Jun '10

21 Jun '10

Our current favicon.ico file (on www.boost.org) is very large (22k), and includes several icons that are too large for the standard 16x16 size for a favicon. Looking at some directions for compressing them, I have created the attached icon which is only 318 bytes and looks almost as good as the current icon. It might be worthwhile to consider replacing the current favicon with this file. It is also available as https://svn.boost.org/htdocs/site/favicon.ico (the favicon for svn.boost.org, but your browser is unlikely to use the new icon if you've downloaded the old one); Dong Inn and I put that in last week as part of some other performance optimizations in Trac. Purging old favicons from Firefox's cache is difficult, though, so you may just want to download it directly and view it in an image viewer. -- Jeremiah Willcock

2 1

[contract] non-public subcontracting (N1962)
by Lorenzo Caminiti 14 Jun '10

14 Jun '10

Hello all (and N1962 authors especially), How should subcontracting work for non-public base classes? I have listed a few examples below. Assume contracts were written for all these example classes (invariants) and their functions (pre/post conditions). My questions are: A) `c::p()` should subcontract; but what about any of the other member functions of `c`, should any of them subcontract also? B) Am I missing any other combination of member/inheritance access level significant for deciding when to subcontract? class bp { public: virtual void p(void) { std::cout << "bp called" << std::endl; } }; class bf { protected: virtual void f(void) { std::cout << "bg called" << std::endl; } }; class bg { public: virtual void g(void) { std::cout << "bg called" << std::endl; } }; class bh { public: virtual void h(void) { std::cout << "bh called" << std::endl; } }; class c: public bp, public bf, protected bg, private bh { public: // This should subcontract. virtual void p(void) { bp::p(); } // Should any of the following subcontract also? virtual void f(void) { bf::f(); } virtual void g(void) { bg::g(); } virtual void h(void) { bh::h(); } // Am I missing any other relevant combination? }; (I do not think multiple inheritance is relevant for my questions. I am using multiple inheritance in this example just so to have only one derived class `c` which exercises all the use cases.) My notes and questions: 1) All member functions of `c` are public so they will check their pre/post conditions as in `c` and `c` class invariants. 2) But shall any `c` member functions also check their base class invariants and/or base function pre/post conditions? 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because it is a public function publicly inheriting from a base public function. ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not `bf` invariant... (because `bf::f` is protected thus it does not have to check `bf` invariant). ** ** 5) Should `c::g()` and `c::h()` subcontract given that their inheritance is not public? ** Thank you very much. -- Lorenzo

2 5