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

Re: [boost] [Review] Formal Review of Proposed Boost.RatioLibrary IS UNDERWAY
by Tan, Tom (Shanghai) 12 Oct '10

12 Oct '10

Hi, Here my review. ----- Original Message ----- From: "Anthony Williams" <anthony.ajw(a)gmail.com> Subject: [boost] Reminder: [Review] Formal Review of Proposed Boost.RatioLibrary IS UNDERWAY >> Here are some questions you might want to answer in your review: >> >> - What is your evaluation of the design? As others already mentioned, it follows the C++ Standards Committee's current Working Paper. That's good. >> - What is your evaluation of the implementation? - Code is clear and easy to read and understood. - BOOST_INTMAX_C is the only macro that's defined in ratio.hpp but not staring with BOOST_RATIO_. As the name suggests, it'll be better 1) if placed in boost/cstdint.hpp, or 2)be named as BOOST_RATIO_INTMAX_C indicating that it's used for boost.ratio only, I personally prefer option 1). - I would expect the comments are better cleaned up and the style unified. Right now, //, //-, //~, /**/ are all used, which seems confusing. I personally like the style adopted in boost.asio. >> - What is your evaluation of the documentation? - It's always a pleasure to read documents generated with BoostBook Documentation Format, - In the tutorial section, it'll be great if more examples are appended so that one example for each supported arithmetic and comparison operations, considering boost.ratio is a small one, doing so won't explode the tutorial section but gives a more complete picture of the lib. >> - What is your evaluation of the potential usefulness of the library? I can think of two scenarios: 1) It could quite useful in physical measurement of time, length, weight and the like where values of different units are being calculated. 2) It could be useful in expressing large rational number (Can anyone please let me know whether ratio is short for rational or a complete word itself? It seems either is OK, though I still wonder) >> - Did you try to use the library? With what compiler? Did you have any problems? Yes, indirectly through using boost.chrono, which is based on boost.ratio. VC10 on Windows 7, GCC4.4 w/ mingwin on widows 7. GCC4.4 on Ubuntu 10.4 No problem with the latest version from boost sandbox. >> - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I did have some in-depth reading of previous versions of the code & documentation while I was started using boost.chrono, though not line by line. I also did a deep reading of C++ Standards Committee's current Working Paper (n2661in order to understand the why and how of ratio class then. While doing this review, I had a thorough reading of the code and documentation, which costs about half a day (including expressing my comments in English). >> - Are you knowledgeable about the problem domain? Intermediate. >> - Do you think the library should be accepted as a Boost library? Yes.

3 2

construe_cast, call for interest and feedback
by Jeroen Habraken 11 Oct '10

11 Oct '10

Hi, I'm proud to say I've tagged a version 0.2 of construe_cast some minutes ago. For those unfamiliar with the library (it's the first time I'm posting this to the boost mailinglist), it's a library which builds upon boost.spirit to create a cast-like operator aiming to provide an alternative to lexical_cast providing greater speed and flexibility. The current code can be found at http://github.com/VeXocide/construe_cast and should be compatible with boost version 1.42.0 and up. What can it do, in short, boost::construe_cast<int>("23") and boost::construe_cast<std::string>(23); (and a lot of other types, basically the ones boost.spirit supports). Secondly, since this release, boost::construe_cast<std::string, tag::bin>(23) resulting in a std::string("10111") and visa versa. The user has the ability to add functionality here by implementing extra tags, by default tag::bin, tag::oct and tag::hex are implemented, with more to follow. What I'm hoping to add the coming weeks: - Documentation, I'm somewhat ashamed to say this hasn't been written yet, however, this will be tackled shortly. - Support for different encodings, it currently uses standard (ASCII) and standard_wide for wchar_t, with more to follow. - A nothow version, like lexical_cast it currently throws when it encounters a run-time, an interface returning false or a default value will be included (the exact interface hasn't been decided upon yet). Performance, now this is where it gets hard. I've done some basic benchmarking and it's somewhere between one and five times as fast as lexical_cast, depending on what you're casting. Good compilers (I've notices this with gcc 4.4 and up for example) are actually capable of optimizing boost::construe_cast<int>("23") to the integer 23 at compile-time which makes it tricky to benchmark. If anyone with more benchmarking experience is willing to look into this, please do. Again, thanks to everyone who helped me get this far, and Hartmut in particular. There seems to be little to add at the moment, I'm looking forward to your opinions and insights. Regards, Jeroen Habraken P.S. I've had a few responses about the name, construe is an english word (http://www.thefreedictionary.com/construe) and I'm using construe_cast as a working name. If people are ever going to consider this for inclusion with boost, changing the name will surely be the least of my worries.

11 20

[units] missing merge of autoprefix to release
by Jürgen Hunold 11 Oct '10

11 Oct '10

Hi ! I was quite surprised that the "autoprefix" feature is not available in the current release branch. I found that the merge from the development branch to trunk was done in r62532. The issue is https://svn.boost.org/trac/boost/ticket/3660 Any chance this can be merged to release ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 3

[Review] Formal Review of Proposed Boost.Ratio Library FINAL DAY
by Anthony Williams 11 Oct '10

11 Oct '10

Hi everyone, Today is the FINAL DAY for the review of Vicente Botet' Ratio library. If you haven't already posted a review, please do so today. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 1

Boost Evolution
by Robert Ramey 11 Oct '10

11 Oct '10

Boost is getting bigger and bigger. This is a good thing. The Boost header directory and boost namespace is also getting bigger and bigger. This is starting to become a problem. I would like to see: a) new libraries not add headers to boost directory or namespace. - with the possible exception - of "convenience headers" which include all the other headers for a library. Personally I don't like these, but since one doesn't have to use them its not a huge deal. b) authors of existing libraries which are implemented in boost directory/namespace would be encouraged to migrate them to a lower level. c) a couple of "catch all" namespaces/headers would be required such as "utility" for small libraries. I'm somewhat confused about "detail". If it's an implemenation detail of a particular library it should be in that library. If its a useful function which is shared by several libraries, it should be in something like: "unreviewed". And of course these should have thier test and documenations in the corresponding "lib" subdirectory. As boost get's bigger and bigger, it gets harder and harder to install just a part of it. But installing just a part of it is what users need to become confident about it. I realize that we've been circling around this topic for a while, I just want to keep it alive. Robert Ramey

9 16

[Review] Final Few Days for Formal Review of Proposed Boost.Ratio Library
by Anthony Williams 10 Oct '10

10 Oct '10

Hi everyone, If you have already posted a review, then thank you. For the rest of you: the review of Vicente Botet' Ratio library runs until October 11th, 2010 (this coming Monday), so please submit your reviews. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 3

Variadic Data Library in sandbox
by Edward Diener 09 Oct '10

09 Oct '10

I have put in the sandbox the Variadic Macro Data library, or VMD. This library supplies variadic macro functionality and integrates variadic macros with the Boost PP library without changing the latter in any way. The library in the sandbox is in the variadic_macro_data folder. The library is a header-only library of macros. There is documentation and tests and the appropriate jamfiles for both. To build the documentation you need doxygen but I have also provided documentation in an html subfolder. The main use of the library is to be able to pass variadic data to macros, and in particular to extract variadic data elements or convert variadic data to Boost PP data types for use by Boost PP. The library also enhances the Functionality of Boost PP tuple data. Installation is simply to take the boost and lib subfolders of the library and copy them to a Boost installation, preferable the trunk where support for variadic macros has been added in Boost config in the form of a BOOST_NO_VARIADIC_MACROS which is defined for compilers/versions which do NOT support variadic macros. To use the macros in the library, just "#include <boost/variadic_macro_data/VariadicMacroData.hpp>". Compilers which support variadic macros are gcc 3.0 and above and VC8 ( VS2005 ) and above among a few others. There is a discussion in the doc of why you might choose to use variadic macros rather than a Boost PP data type in a macro tailored for end-users. Comments, suggestions, and bug reports are welcome. Edward Diener

2 2

[Locale] Stream manipulator bug
by Alexander Lamaison 09 Oct '10

09 Oct '10

The latest version of Boost.Locale is doing something wierd to stream manipulators. For example, the following code should print 63:2c:7f. If you uncomment the line that sets the global locale to use a boost::locale instance, it prints 990:440:127. It seems to be ignoring the std::hex manipulator and doing something strange with std::width. #include <iomanip> #include <iostream> #include <sstream> #include <string> #include <vector> #include <boost/locale.hpp> std::string hexify() { std::ostringstream hex_hash; hex_hash << std::hex << std::setfill('0'); unsigned int data[] = {99, 44, 127}; for(size_t i = 0; i < 3; ++i) { if (!hex_hash.str().empty()) hex_hash << ":"; hex_hash << std::setw(2) << data[i]; } return hex_hash.str(); } int main() { using boost::locale::generator; generator gen; //std::locale::global(gen("")); std::cout << hexify() << std::endl; } This is on Windows 7 with Boost.Locale compiled to only use the Win32 backend. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

2 1

[Review] Boost.Ratio
by joel falcou 09 Oct '10

09 Oct '10

So here is my review of Boost.Ratio *- What is your evaluation of the design?* It's a strictly (or at least as struct as possible) implementation of the standard proposal. Code is clear and easily followed. *- What is your evaluation of the implementation?* It's very OK and straightforward. I'll reiterate the question about providing MPL or Fusion adaptors as an optional features (unless I missed them :x) *- What is your evaluation of the documentation?* Good *- What is your evaluation of the potential usefulness of the library?* Ratio fills a gap in the MPl-like data type and enables new interesting design to be done. *- Did you try to use the library? With what compiler? Did you have any problems? * I tried it using gcc 4.4 and 4.5 and icc 11. No problem so far. *- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * I quickly glanced over the code as I knew it from its inception and followed it so I only had to look some new stuff. I tried some non trivial task , including some attempt at MPL like CT linear system solver using rational. boost.ratio proved itself useful in this task. *- Are you knowledgeable about the problem domain? * Yes. *- Do you think the library should be accepted as a Boost library?* Yes

2 3

[Boost][Proto] Fw:[Spirit-general] Patch for compiling Karma without RTTI
by Bryce Lelbach 08 Oct '10

08 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarding from the spirit-general mailing list. Begin forwarded message: Date: Fri, 08 Oct 2010 12:01:55 +0800 From: Joel de Guzman <joel(a)boost-consulting.com> To: spirit-general(a)lists.sourceforge.net Subject: Re: [Spirit-general] Patch for compiling Karma without RTTI On 10/8/2010 10:34 AM, Bryce Lelbach wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Summary: > > 0x0.) There's a workaround header for compilers without > typeinfo/typeid in boost/detail/sp_typeinfo.hpp. It has a few macros > that uses real typeid/typeinfo if it exists, and the workaround if > not. The workaround was broken on GCC 4.5.1 and clang (rebuilt daily > from upstream trunk). I fixed the problem (static initialization > jazz). > > 0x1.) Spirit's hold_any uses typeinfo/typeid. I changed it to use > the aforementioned macros. > > 0x2.) Some debugging stuff in one proto file used RTTI. I changed > it to use the aforementioned macros. > > I haven't had a need for Qi/Lex yet. I'm currently putting the > finishing touches on the ariel driver. My intention is to use Qi for > my lightweight command line parsing needs, because it will be less > painful than spending half an hour browsing through LLVM doxygen to > figure out how their cl parser works. So, there might be another one > of these patches in the morning. > > Patch was generated via svn diff from the top of my local copy of the > Boost trunk (on Debian GNU/Linux). I suggest sending an email to the Boost mailing list non-spirit related patches (and accompanying explanations). We don't have control over those parts (e.g. proto and boost/detail/sp_typeinfo.hpp) Regards, - -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net - ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Spirit-general mailing list Spirit-general(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spirit-general - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkyumQMACgkQO/fqqIuE2t63WwCg2lT+hIeoy9xISTU73PwRE/FD G9sAoNQwHDIMMPYO1GbDiWYP0lco/crH =iU+P -----END PGP SIGNATURE-----

4 4

Re: [boost] [Spirit-general] construe_cast, call for interest and feedback
by Jeroen Habraken 07 Oct '10

07 Oct '10

On 7 October 2010 22:43, Aaron Graham <aaron(a)aarongraham.com> wrote: > I'm excited about construe_cast. I always liked the flexibility of > lexical_cast, but tend not to use it as much as I could because of its > performance relative to other mechanisms. > Does gcc still convert "23" at compile time if you disable builtins? > (-fno-builtin) > #include <boost/construe_cast.hpp> int main(int, char**) { return boost::construe_cast<int>("23"); } compiled using gcc 4.5.1, g++-4.5 test.cpp -o test -O3 -I . -I ../library/boost-trunk/ -fno-builtin will generate the following code: Dump of assembler code for function main: 0x0000000100000e20 <main+0>: push %rbp 0x0000000100000e21 <main+1>: mov $0x17,%eax 0x0000000100000e26 <main+6>: mov %rsp,%rbp 0x0000000100000e29 <main+9>: leaveq 0x0000000100000e2a <main+10>: retq 0x0000000100000e2b <main+11>: nopl 0x0(%rax,%rax,1) thus as you can see, it's still able to perform the optimization. Jeroen

1 0

[Review] Formal Review of Proposed Boost.Ratio Library Starts TODAY
by Anthony Williams 07 Oct '10

07 Oct '10

Hi everyone, The review of Vicente Botet' Ratio library starts TODAY (October 2nd) and lasts until October 11th, 2010, unless an extension occurs. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

6 12

[Concept Check] ContiguousIterator
by joel falcou 07 Oct '10

07 Oct '10

Using BCC, s there any way to refine RandomAccessIterator so the cocnept captures the fact that the address of two consecutive value iterated over are contiguous in memory ? I can't get any proper expression to check for this in a proper way.

6 7

[xpressive] Support for multi-capture and balancing groups
by Erik Rydgren 07 Oct '10

07 Oct '10

Hi! My company have been using pcre for a long while but there has been gripes about it only returning the last matched value from a capture group. Because of this I have been searching for a C++ regex engine that can handle the same stuff as the .NET implementation can do, to no avail. During my searches I've stumbled on several forum threads where others have been searching for the same thing but it doesn't seem to exist a regular expression library in C/C++ that handles both named captures and multicapture. Found boost.xpressive and it had almost everything we need. It's open source, fast, got flexible api and named captures. But alas, just as all other C and C++ based implementations I have found, it lacked multiple captures. So, I added it. On top of that I added support for balancing groups (http://blog.stevenlevithan.com/archives/balancing-groups) But the syntax for the pop capture and capture conditional is slightly different then the .NET version to better fit xpressive. Syntax for pop capture: dynamic: (?P<-name>stuff) static: (name -= stuff) Syntax for capture conditional: dynamic: (?P(name)stuff) static: (name &= stuff) There is no support for the (?<name-othername>stuff) construct. All captures made by a group is stored in sub_match::captures which is a vector of sub_match_capture objects. A sub_match_capture behaves like a stripped down sub_match. It can be put in an ostream and has a length and helper function for returning a string. The changes are in the vault and can be found here: http://tinyurl.com/3aak7mp It can be unpacked against trunk from 2010-10-02 or the 1.44.0 release. I've run the dynamic regression tests without errors and I have added some tests for the new functionality. The code it only tested on Visual Studio 2010 since I don't have access to any other compiler. Please give feedback on my changes since I would love to see them in an official release. Thanks in advance. Regards, Erik

3 6

[fusion] for_each
by Christophe Henry 06 Oct '10

06 Oct '10

Hi, I have 2 fusion containers: a small vector (my_vec) and a bigger set (my_set). I want to overwrite the elements of the set with elements from the vector whenever they have the same type. Sounds simple: struct update { update(my_set_type& to_overwrite_):to_overwrite(to_overwrite_){} template<typename T> void operator()(T& elt) /*const?*/ { boost::fusion::at_key<T>(to_overwrite)=elt; } my_set_type& to_overwrite; }; boost::fusion::for_each(my_vec,update(my_set)); Except that this won't compile because the operator() is required to be const, which is sad, because it was very simple. This leaves me with the unattractive option of inverting the set and the vector inside update. Now, I iterate on the set's elements and overwrite them when found in the vector. This is unattractive because 1) the code gets really ugly 2) it could be slower (the set is bigger) and 3) it has a much bigger compile-time cost (I resorted to an enable_if of fusion::result_of::find and I make it short, it is actually much worse). I thought of using transform, but this will be slower as I will need to transform every element of the set, even for a vector of size 1. Am I missing something? If not, would it be possible to remove this constraint? Thanks, Christophe

4 6

[Range] Composite Range
by Robert Jones 06 Oct '10

06 Oct '10

Is there any facility supported in Boost to provide a 'composite' range? I.e., a range that might be a vector, followed by a bit of list, followed by a pair of iterators? I guess the iterator classification of such a range would be the lowest common denominator of the classifications of all the component iterators, and I don't even want to think about how sort() would work, but it might be quite handy. - Rob.

3 4

[Review] Formal Review: Boost.Ratio
by Anthony Williams 06 Oct '10

06 Oct '10

Hi everyone, The review of Vicente Botet' Ratio library starts October 2nd and lasts until October 11th, 2010, unless an extension occurs. What is it? ======== Portable implementation of the C++0x Standard Library's compile-time rational arithmetic working on C++03 and C++0x compilers. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf Boost.Ratio provides: * A class template, ratio, for specifying compile time rational constants such as 1/3 of a nanosecond or the number of inches per meter. ratio represents a compile time ratio of compile time constants with support for compile time arithmetic with overflow and division by zero protection * It provides a textual representation of boost::ratio<N, D> in the form of a std::basic_string. Other types such as boost::duration can use these strings to aid in their I/O. This library is header-only and is designed to be generic and useful in a lot of areas of math and numerics C++ programming, in particular it is absolutely needed for the proposed Boost.Chrono and Boost.Stopwatches libraries which are currently in the review queue. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… SVN: http://svn.boost.org/svn/boost/sandbox/chrono (directories boost/ratio and libs/ratio) and the docs may be viewed here html: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/html/index.html pdf: http://svn.boost.org/svn/boost/sandbox/chrono/libs/ratio/doc/ratio.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Ratio It is worth noting that the tests included in the zip file are relatively sparse. Vicente has an extensive suite of tests licensed under the LLVM license. He has posted a message on the Boost Developers mailing list regarding the license requirements for tests (See http://thread.gmane.org/gmane.comp.lib.boost.devel/208978) and is awaiting the outcome of that discussion before making the tests available. 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. Anthony Review Manager for the proposed Boost.Ratio library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

5 6

[fusion] for_each
by Christophe Henry 06 Oct '10

06 Oct '10

I think it's at least partly my mistake. It took me some time to manage a limited example not compiling: #include <boost/fusion/container/set.hpp> #include <boost/fusion/container/vector.hpp> #include <boost/fusion/include/at_key.hpp> #include <boost/fusion/include/for_each.hpp> #include <boost/fusion/include/as_vector.hpp> struct A { int adata; }; struct B { int bdata; }; struct C { int cdata; }; typedef boost::fusion::set<A, B, C> my_set_type; typedef boost::fusion::vector<A, B> my_vector_type; struct update { update(my_set_type& to_overwrite_):to_overwrite(to_overwrite_){} template<typename T> void operator()(T& elt) const { boost::fusion::at_key<T>(to_overwrite)=elt; } my_set_type& to_overwrite; }; int main() { my_set_type my_set; my_vector_type my_vec; boost::fusion::for_each(boost::fusion::as_vector(my_vec),update(my_set)); } Now it will compile if you replace boost::fusion::as_vector(my_vec) by my_vec or T& by T const&. Ok so it seems my problem description is wrong and I needed to know that as_vector returns a const vector, right? Thanks, Christophe

1 0

Differences between Boost.Thread and std?
by David Abrahams 05 Oct '10

05 Oct '10

Hi All, Is there a document somewhere describing the differences between Boost.Thread and what's being proposed for C++0x? Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

Re: [boost] [fusion] for_each
by Christophe Henry 05 Oct '10

05 Oct '10

>> I have 2 fusion containers: a small vector (my_vec) and a bigger set >> (my_set). I want to overwrite the elements of the set with elements >> from the vector whenever they have the same type. Sounds simple: >> >> struct update >> { >> update(my_set_type& to_overwrite_):to_overwrite(to_overwrite_){} >> template<typename T> >> void operator()(T& elt) /*const?*/ >> { >> boost::fusion::at_key<T>(to_overwrite)=elt; >> } >> my_set_type& to_overwrite; >> }; >> >> boost::fusion::for_each(my_vec,update(my_set)); >> >> Except that this won't compile because the operator() is required to >> be const, which is sad, because it was very simple. > > And it won't compile *with* the const? I don't think the const'ness of > the member function affects the const'ness of the referent of to_overwrite. No, it won't compile ;-)

2 1

[serialization] assert missing
by Andrew Sutton 05 Oct '10

05 Oct '10

The header 'boost/serialization/item_version_type.hpp' seems to be missing an include on boost/assert.hpp (or cassert) that was causing some compilation failures in the graph_parallel tests (under GCC-4.4.3 on GNU/Linux x86_64). The test case brings this in by including serialization/list.hpp. My first thought was to simply stick an appropriate #include in the item_version_type. Would there be any problems committing this change? Andrew

1 0

[Review] Formal Review of Proposed Boost.Ratio Library Starts TODAY
by nimaca2001＠libero.it 05 Oct '10

05 Oct '10

> > - What is your evaluation of the design? > - What is your evaluation of the implementation? Take this as the review from an average C++ user that uses uses simple boost stuff like shared_ptr or bind but is scared of things like MPL or Spirit. > - What is your evaluation of the documentation? Well written, I would have omitted some appendixes (F and G). > > - Did you try to use the library? With what compiler? Did you have any problems? Tried the provided samples and some self written one on MSVC 9 without problems despite the fact I was using an old version of boost (1.41) as base. > > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? About one hour to read the docs and compile a few tests > > And finally, every review should answer this question: > > - Do you think the library should be accepted as a Boost library? Yes

2 1

[fusion] [intro] ADAPT_STRUCT extensions
by Stefan Strasser 04 Oct '10

04 Oct '10

Hi, in the discussion about the library I called "Intro" at the time it has been suggested to use BOOST_FUSION_ADAPT_STRUCT of Boost.Fusion for data member access. based on that I'd like to propose two extensions to ADAPT_STRUCT, which I think are useful beyond my use case: 1) ADAPT_STRUCT can adapt public data members only. with the modifications I uploaded here: http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ all data members can be adapted. for example: class A{ private: friend class fusion::access; int a; }; BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) 2) adaption of a class including its base class members. for example: struct A{ int a; }; struct B{ int b; }; struct C : A,B{ int c; } BOOST_FUSION_ADAPT_STRUCT(A,(int,a) ) BOOST_FUSION_ADAPT_STRUCT(B,(int,b) ) BOOST_FUSION_ADAPT_DERIVED( C, (A)(B), (int,c) ) an instance of C is now a fusion sequence of size 3. http://svn.boost.org/svn/boost/sandbox/intro/boost/fusion/adapted/struct/ad… private inheritance is supported as above, virtual inheritance is not. I'm not sure if virtual inheritance can be supported.

8 30

Boost.SQL?
by Roland Bock 04 Oct '10

04 Oct '10

Hi, currently I am working on a set of header files which are supposed to make the life of C++ developers easier when in comes to interacting with databases (based on SQL). Goals are: * Stay close to SQL syntax * Do as much type checking as possible * prevent oversights and typical security holes, e.g. by forgetting to escape strings The basic idea is, that given a table definition, it should be possible to * offer a lot of checks at compile time for building a query * make it hard to misinterpret the results Until now, I have been concentrating on table definitions and select statements. Here's a very simplistic example, assuming a table definition "my_table" and a database connection "db": // ------------------------------------------------------------------------- using boost; typedef my_table<> t; typedef sql::select_record<t> record; std::string name("Peter"); ... std::vector<record> records = db.select<record>( sql::where(t::id() > 1000 && t::first_name() == name), sql::order_by(t::priority()(sql::desc)), sql::limit(17)); // the values can be accessed by their name // and are of the correct type, e.g. records.front().first_name_; // is a string records.front().middle_name_; // optional<string> because the table definition says that it can be NULL // In case of a select from more than one table, the values can also be accessed like this records.front().my_table_.first_name; // ------------------------------------------------------------------------- I wonder if there would be interest for such a library in boost.

17 44

[config] additions for gcc 4.0.1 and IBM V11.1.0.0duetoMSM compile errors
by Christophe Henry 04 Oct '10

04 Oct '10

John Maddock wrote: > The updated test is passing as well, looks like this may be a case of adding > a BOOST_WORKAROUND for Apple's GCC and see if it fixes things. I added some #if for Apple's gcc and the IBM compiler. A look at the regression tests (http://www.boost.org/development/tests/trunk/developer/msm.html) shows: - all problems with Apple's gcc 4.0.1 are gone (waow cool! Better than expected) - IBM's compiler manages a few test cases more (for others, it just crashes or gives a run-time error status 139 which does not bring me much further) This is in my eyes a proof that for these compilers, BOOST_NO_NESTED_FRIENDSHIP and BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined. If these features only work sometimes, then they should not be seen as supported. We now have 2 possibilities: - we change boost.config to reflect this situation and I update my code accordingly - we don't and I have to keep my #if. Solution 2 is not great for me because I'm duplicating boost.config and it litters my code with stuff less clear than BOOST_NO_NESTED_FRIENDSHIP and BOOST_NO_MEMBER_TEMPLATE_FRIENDS. In any case, it'd be good if we could decide on it this week on it so that this makes it to the 1.45. Thanks, Christophe

1 0