August 2011 - Boost - lists.boost.org

[Date Time] bug in documentation example (Localization Demonstration)
by Frédéric Bron 08 Aug '11

08 Aug '11

In "Localization Demonstration": http://www.boost.org/doc/libs/1_47_0/doc/html/date_time/examples.html#date_… 11 should be 12 and 6 should be 7 in the following lines: std::copy(&de_short_month_names[0], &de_short_month_names[11], std::back_inserter(short_months)); std::copy(&de_long_month_names[0], &de_long_month_names[11], std::back_inserter(long_months)); std::copy(&de_short_weekday_names[0], &de_short_weekday_names[6], std::back_inserter(short_weekdays)); std::copy(&de_long_weekday_names[0], &de_long_weekday_names[6], std::back_inserter(long_weekdays)); Regards, Frédéric

1 0

Boost.Atomic, pushing forward and a little request for help
by Helge Bahmann 07 Aug '11

07 Aug '11

Hi folks, from the comments to Boost.Lockfree I understand that you consider a non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not pushed forward for review (considering that "it just works for me", and considering the length of the review queue...), but if you consider it blocking please just let me know what I would need to do to clear the path. What I will do shortly is to provide and uptodate package containing several fixes, several contributed by others (they are in the repo, but not in any release archive) as well as some missing bits to more closely match latest C++0X draft. The big sore point is still support for the various flavours of VC -- I know that there are (especially older) versions for which it is not working, but I am lacking test systems, so if you are affected please let me know and I will do my best to resolve the issues. Cheers, Helge

10 14

[interprocess::file_mapping] Please add resize method
by Dmytro Ovdiienko 07 Aug '11

07 Aug '11

Hello, Could you please add resize method to the file_mapping class? Also please don't fill file with zeros by default? This functionality increases latency spikes. Make it as quick as possible. Thanks. Best regards. Dima -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731

2 5

[containers] review
by Gordon Woodhull 07 Aug '11

07 Aug '11

Hi Ion, John, all, I apologize that I don't have time for a full review, as I'm going offline hiking for the rest of the review period. Obviously the library should be accepted. Move emulation, stateful allocators, emplace, recursive containers, ... so many excellent features. And this code has been tested as part of Interprocess for years. However, I do find the documentation lacking. While the Doxygen reference looks very complete, I want to see the overview documentation expanded, including covering the following topics: Stateful allocators seem to be unmentioned. Do they affect performance or behavior? I know this might be a big topic; links are okay. My understanding is that these are fully supported but other allocator improvements are not yet present? Out of curiosity I'd like to see a bit of text about the future directions, mentioning N1953 & N2045. Could the contents of Joachin's blog post http://bannalia.blogspot.com/2008/08/stable-vectors.html go into an overview section for stable_vector? Recursive container is not defined, also maybe link to http://en.wikipedia.org/wiki/Recursive_data_type What is it used for: directed graph. Some guideline about when it's better to use flat_*. I figure you would use such a structure when you're not doing a lot of inserts or when there are few elements. The advice can be somewhat handwavy and instruct the user to do measurements, but it should be there. Silly question, but I'm not clear how to use this ordered_unique_range_t that's in the Doxygen - is there a constant or do you default construct it or what? As earlier pointed out, a lot of the Doxygen parameters and descriptions have gotten out of sync k/x first/i etc. Well, I've run out of time. Hope this helps a little. Cheers, Gordon

3 3

[Container] boost::container::vector<bool>
by Joel falcou 07 Aug '11

07 Aug '11

It is not clear from the doc but does the vector from boost::container *don't* do the so not useful bool optimization ? Aka can I finally take a pointer to vector<bool> element ? Thanks

2 1

[Containers] Complexity of flat_*::insert(first,last)
by Phil Endecott 07 Aug '11

07 Aug '11

Hi Ion, This library looks great. A quick comment about range-insertion in the flat containers, e.g.: template<typename InputIterator> void insert(InputIterator first, InputIterator last); Requires: i, j are not iterators into *this. Effects: inserts each element from the range [i,j) . Complexity: N log(size()+N) (N is the distance from i to j) search time plus N*size() insertion time. (Note typo: i,j vs, first,last) What implementation are you assuming to get that complexity? It seems to me that it is worse than it could be if you implement it something like this (PSEUDO-CODE): template<typename InputIterator> void insert(InputIterator first, InputIterator last) { iterator m = end(); insert(end(), first, last); sort(m,end()); inplace_merge(begin(),m,end()); } (I've only ever done this with multi* containers. For set and map you'll need something to avoid duplicates.) Regards, Phil. p.s. Having typed that I have developed a feeling of deja vu. Have I asked you this before?

4 11

[fusion] joint_view bug?
by Eric Niebler 07 Aug '11

07 Aug '11

The following code asserts at compile time for me. Am I doing something wrong? typedef fusion::vector2<int,int> pair; pair p(1,2); fusion::joint_view<pair, pair> x(p, p); auto begin = fusion::begin(x); auto end = fusion::end(x); int i = fusion::distance(begin, end); The assert is on line 39 of fusion/iterator/distance.hpp: template <typename Tag> struct distance_impl { // default implementation template <typename First, typename Last> struct apply : distance_detail::linear_distance<First, Last> { BOOST_MPL_ASSERT_NOT((traits::is_random_access<First>)); BOOST_MPL_ASSERT_NOT((traits::is_random_access<Last>)); }; }; In this case, First is a joint_view iterator and Last is a vector iterator, which is indeed random-access. If I simply comment out the compile-time asserts, the code compiles and works as expected. I think these asserts are bogus. OK to remove them? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

[log] Documentation improvement suggestions - was :how to set attributes under multi-threaded application
by Klaim - Joël Lamotte 06 Aug '11

06 Aug '11

Hi, Andrey Semashev said: I think the common formula "library design + tutorial + features description > + reference" is the golden middle for medium-sized projects, like Boost.Log. > Also, quite a few common case examples will help to get things started. The > rest will come with experience. > > I would like to give my limited feedback with the log docs about this very point : What I think might be a bit overhelming and don't help beginners with boost.log is the library design page itself. http://boost-log.sourceforge.net/libs/log/doc/html/log/design.html I mean the content organisation of the page, not the fact that it exists and I agree with you that it should be up front. The main problems with the page : A. there is a BIG bloc of text with almost no apparent hierarchy - that's a showstopper for a lot of people that will just click the "tutorial" link to see what it's really about; B. the scheme is clear technically but might be easier to read if it was to be read from left to right instead of right to left (at least because it uses english text); an alternative would have been from top to bottom : reading the scheme should follow the way data goes from loggers to sinks (in fact the current scheme looks like an inverted comics page to me...) Here are some suggestions to improve this page : 1. Structure the big block of text in several distinct parts, with titles. I think those parts already exists but they just lack obvious separations like just big titles. 2. Add links in the text to definitions from the previous page (Definitions). Reading the definitions first doesn't always make things really clear immediately. Often you read them used in context and then understand...or not if your forgot what it was. There are 9 definitions with several having the same beginning. It might be easier to the user to link to those simple definitions when they need them, when reading the library design text (might not be necessary after that?). 3. Invert the reading sens of the scheme or make it top to bottom. Obviously I'm an humble user, not an authority in the matter, but I hope it helps getting more users not stop at this page. Joël Lamotte

3 4

boost::iostreams::detail::basic_buffer int usage
by Judson Weissert 05 Aug '11

05 Aug '11

Hello, I believe there is a type conflict in boost/iostreams/detail/buffer.hpp. ------ Snippet from buffer.hpp ------ class basic_buffer { ... basic_buffer (int buffer_size); ... std::streamsize size_; }; ------ End snippet ------ Here is some example code that triggers the same warnings I was receiving: // Tested with boost 1.46.1 // Compiler Microsoft VC2010 SP1. // Compiled with cl /EHsc /W3 repro.cpp #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/array.hpp> #include <boost/iostreams/filtering_streambuf.hpp> int main (int, char *[]) { static const char b[] = { 'A', 'B', 'C' }; boost::iostreams::array_source as (b, 3); boost::iostreams::filtering_streambuf <boost::iostreams::input> in; in.push (as); // This line generates a 'std::streamsize' to 'int' warning. // See also boost/iostreams/detail/buffer.hpp boost::iostreams::copy (in, std::cout); return 0; } Perhaps the fix is as simple as s/int/std::streamsize/g within buffer.hpp. Any thoughts? Thanks, Judson

1 0

[type trait extension] I hate volatile...
by Frédéric Bron 05 Aug '11

05 Aug '11

I am still working on the implementation of the traits to detect operators. I have an issue with operators returning a volatile object (being a reference or not). This breaks the code I wrote to detect if the return type is void or not. In particular, the following code compiles with RET=int but not with RET=ret. Can somebody tell me why? It seems that any volatile object (reference or not) cannot be bound to a const reference apart for fundamental types. So is there any useful case to return a volatile object? If not, I can maybe just ignore those cases or it becomes to be a nightmare. By the way, it is 1:30am. I am going to bed! Frédéric struct ret { }; #define RET int RET result; RET r() { return result; } RET const rc() { return result; } RET volatile rv() { return result; } // fails to compile RET const volatile rcv() { return result; } // fails to compile RET & rr() { return result; } RET const & rcr() { return result; } RET volatile & rvr() { return result; } // fails to compile RET const volatile & rcvr() { return result; } // fails to compile int main() { RET x; x=r(); x=rc(); x=rv(); // fails with RET=ret x=rcv(); // fails with RET=ret x=rr(); x=rcr(); x=rvr(); x=rcvr(); return 0; }

4 13