March 2011 - Boost - lists.preview.boost.org

Re: [boost] [xint] Boost.XInt formal review
by Jarrad Waterloo 03 Mar '11

03 Mar '11

This library is useful as is but I would suggest a few additional features for convenience especially among the most common use cases. 1) convenience functions preferably, documented example is acceptable, for extracting a integer, int, long int ... starting at a particular unsigned bit offset for a particular length 2) convenience functions preferably, documented example is acceptable, for creating a mask starting at a particular unsigned bit offset for a particular length 3) examples of using this if possible with boost::date in order to efficient work with dates outside the existing limits 4) conversion to and from dynamic_bitset [already suggested just seconding] 5) conversion to and from bitset For all those other reviewers who may complain about performance when comparing with GMP, please bear in mind that large numbers are useful to domains other than security were assembly level performance is nice but doesn't outweigh other concerns such as portability and ease of use. This library and others much needed even overdue for the C++ non C community.

2 1

Phoenix 3 Review
by Joel Falcou 03 Mar '11

03 Mar '11

So here is my short review on phoenix 3. I wont comment on the quality of the code and the implementation as I followed Thomas durign his GSoC. On an user perspective, i'll place myself on the "advacned user" plate. i see Phoenix as a great to enable lazy evalaution in a large number of situation. its integration in proto is now making it a nice boilerplate code for more advanced libraries. I've played with test adn examples and found them to be good. My overall opinion is that YES, this version of Phoenix fulfills the requirements of th eprevious review adn thomas addressed them in quite an efficient way. Now, as an advanced nitpicker ;) i have a small set of request: - the doc need more examples of proto interoperability either in use cases or in various extension points. IIRC there was sone phoenix-> C cod ein a string example that was never finished, it coudl be good if this could be fleshed out. multistage programming is a Nice technique that need promotion and exposure. Phoenix seems to be perfect for that. - Could the various compile time / runtime performances tests be itnegrated in the doc if they are a/ done and b/ give some insight. If needed i can run some on non-trivial architecture/compiler and report results So, I very welcome the addition of Phoenix 3 as a full citizen of boost.

3 2

1.46 problems
by Nikolay Mladenov 03 Mar '11

03 Mar '11

I am resending this since I accidentally sent an unfinished email. I recently upgraded from 1.43 to 1.46 and this broke our serialization. We could not read archives saved with 1.43. I the investigation I noticed the following issues. 1. in basic_binary_iarchive tracking_type is loaded as integer type or bool, but in basic_binary_oarchive it is stored as primitive type tracking_type. This breaks custom binary archives that have overloads for integer types and bool. this problem probably applies to other internal serialization types (collection_size_type, version_type, etc), but I have not investigated this. 2. We use custom binary archives which have overloads for integer types (loosely) like that: class custom_binary_iarchive : boost::archive::binary_iarchive_impl<custom_binary_iarchive> { public: void load(integral_type &t){...} void load(non_integral_type &t){...} }; When loading std::vector from archive stored with 1.43 the following execution paths occur: std::vector <T> v; custom_binary_iarchive ar(..); ar >> v; .... //goes in load_collection(Archive& ar, Container &s) collection_size_type count; ar>>BOOST_SERIALIZATION_NVP(count); .... //and finally reaches custom_binary_iarchive::load(non_integral_type &t); if instead I use polymorphic archive based on the custom_binary_iarchive I get: std::vector <T> v; polymorphic_iarchive_route<custom_binary_iarchive> ar(..); ar >> v; .... //in load_collection(Archive& ar, Container &s) collection_size_type count; ar>>BOOST_SERIALIZATION_NVP(count); ...... //goes into polymorphic_iarchive_impl::load_override(nvp<collection_size_type> &t) ..... //goes into polymorphic_iarchive_route::load(boost::ulong_long_t &t) //since collection_size_type has conversion to unsigned long long ... //and finally reaches custom_binary_iarchive::load(integral_type &t) The bottom line is that collection_size_type deserializes differently with polymorphic and regular archives. I am now trying to fix the problems by introducing overloads for all the serialization library's internal types, but it seems to me that some of those problems are actually bugs. Please advise on the best way to tackle this issues. Another question I have, and excuse me if this has been discussed (but I could not find it), is when should a custom archive overload save/load and when save_override/load_override? Thanks in advance, Nikolay Mladenov Sitius Automation Inc

1 0

[serialization] 1.46 problems
by Nikolay Mladenov 03 Mar '11

03 Mar '11

I recently upgraded from 1.43 to 1.46 and this broke the serialization. We could not read archives save with 1.43. I the investigation i noticed the following issues. 1. in basic_binary_iarchive tracking_type is loaded as integer type or bool, but in basic_binary_oarchive it is stored as primitive type tracking_type. This breaks custom binary archives that have overloads for integer types and bools to be broken this problem probably applies to other internal serialization types (collection_size_type, version_type, etc), but I have not investigated this. 2. I have a custom binary archives which have overloads for integer types (loosely) like: class custom_binary_iarchive : boost::archive::binary_iarchive_impl<custom_binary_iarchive> { };

1 0

[log] Current status
by Gregory Symons 02 Mar '11

02 Mar '11

Hi, I've been looking at Boost.Log, and I was wondering what it's current status is? It was provisionally accepted almost a year ago; any ideas when it will make it into a boost release? -- Gregory Symons <gsymons(a)drillinginfo.com> Developer DrillingInfo <http://www.drillinginfo.com>

3 3

differences between sandbox and 1.46.0
by Frédéric Bron 02 Mar '11

02 Mar '11

I am working in the sandbox on an addition to the type trait library. I have run a diff between boost/type_traits directory in version 1.46.0 and in the sandbox. To my surprise, many files which I did not change myself are different: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… So my questions are: - is the sandbox supposed to be up to date compared to the trunk? - if not, there is a risk that people spend time working with wrong code; can we think of a procedure to update the sandbox when new versions are issued? Frédéric

3 2

[preprocessor] Lists vs. nil-sequences?
by Lorenzo Caminiti 02 Mar '11

02 Mar '11

Hello all, I have a curiosity about Boost.Preprocessor: What is the difference between pp-lists and pp-sequences starting with a NIL element? PP-Lists can be empty or nil (e.g., have 0 size, etc) while pp-sequences cannot. However, I could use sequences that always start with a nil element `(NIL) ...` and write macros that ignore this 1st element so to handle empty pp-sequences: #define NILSEQ_SIZE(nilseq) BOOST_PP_DEC(BOOST_PP_SEQ_SIZE(nilseq)) NILSEQ_SIZE( (NIL) ) // 0 NILSEQ_SIZE( (NIL)(a) ) // 1 NILSEQ_SIZE( (NIL)(a)(b) ) // 2 BOOST_PP_LIST_SIZE( BOOST_PP_NIL ) // 0 BOOST_PP_LIST_SIZE( (a, BOOST_PP_NIL) ) // 1 BOOST_PP_LIST_SIZE( (a, (b, BOOST_PP_NIL)) ) // 1 Similarly, I could program NILSEQ_FOR_EACH, NILSEQ_ENUM, etc. What are the pros and cons of using pp-nil-sequences vs pp-lists given that both allow for emptiness? Thank you very much. -- Lorenzo

3 2

[lexical_cast] locale dependent result? (was: [lexical_cast] locale dependent result?)
by Alexander Lamaison 02 Mar '11

02 Mar '11

No response on the boost.user list so I'm trying here in case the devs know: Is the result of lexical_cast<std::string> locale-dependent? One of my contributors has submitted a fix for a problem he says is caused by lexical_cast adding commas to a port number, e.g.: 65535 becomes "65,535". I'm unable to reproduce this but it may be something specific to his locale. If this is the case, what would be the correct way to get a canonical, locale-independent string from an integer? Thanks. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

3 5

GSoC SIMD project
by Mathias Gaunard 02 Mar '11

02 Mar '11

Joel Falcou and I have a SIMD library in the works that we plan to submit to Boost by May; we've also submitted a boostcon talk on the subject. Would it be acceptable to propose a GSoC project within Boost which could involve porting the library to new architectures, writing more tests, documentation, and examples, playing with it to implement fast vectorized functions for common tasks, etc.?

8 17

Re: [boost] Boost and pkg-config support
by Steve M. Robbins 02 Mar '11

02 Mar '11

Boosters, please see the following for background: [1] https://svn.boost.org/trac/boost/ticket/1094 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593876 On Sun, Feb 27, 2011 at 08:08:42PM +0000, Roger Leigh wrote: > https://svn.boost.org/trac/boost/ticket/1094 > is the upstream ticket for adding pkg-config support. I've already > done the bulk of the work, the patches are all there. Do you have > any knowledge of bjam? Vladimir is the bjam expert ;-) > boost-pkg-config-gen.cc is the program to acquire the information > and generate the .pc file. It just needs building with these defines: > TEST_HEADER - the header to include for a given boost library > PREFIX - the bjam prefix (however you get at it) > LIBDIR - the bjam libdir (however you get at it) I have spent some time trying to patch bjam and have no inclination to spend any more time with that code. For Debian purposes, could we obtain PREFIX and LIBDIR directly from debian/rules? (In fact, they would be constants, of course). What about TEST_HEADER? > So the program just needs building and running once for each Boost > library (bjam must have a list of libraries, or at least provide some > means for us to get at the information). Bjam has a list of the libraries that are *compiled* to a so/dll. Is that enough? The root of the problem [3] is inlined code and there's no guarantee that a header-only library won't similarly inline something that requires, say, -lboost_system. Boost Developers: is there a machine readable list of libraries somewhere in the boost source tree? Thanks, -Steve

3 3