- Boost - lists.boost.org

[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

[Containers] String performance and compatibility
by Phil Endecott 05 Aug '11

05 Aug '11

Hi Ion, I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now. Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.) Phil.

4 4

Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
by Brian Wood 05 Aug '11

05 Aug '11

Daniel Larimer: On Jul 30, 2011, at 7:16 PM, Brian Wood wrote: > Daniel Larimer <dlarimer(a)gmail.com> > >> 1) No code generation required (best for C++ to C++, but with a proper > JSON interface can communicate with any language) > > Code generation is being done by something here. In this case it is > probably being done by a C++ compiler that starts from scratch for > every file it has to compile. > > I think there is a big difference between using the pre-processor / templates and > using another program, another language, another dependency, another build step. Yes, there's another dependency and build step, but at least if you're using the approach I advocate you are rewarded with a cleaner build. I've been comparing the differences (between Boost.Serialization and the C++ Middleware Writer) for a number of years now. The most recent comparison using Boost 1.47.0 shows the Boost executables are between 1.7 and 2.8 times larger than the functionally equivalent Ebenezer executables. I haven't compared the build times though so can't say which is faster, but obviously it takes more time to produce a chubby file than a svelte file. > Besides, even if you use a 3rd party tool like google protocol buffers, ICE, etc that does > code generation, the C++ compiler still must start from scratch every time one of the > generated headers is included. Only a fraction of the code is in headers. As much as possible is in source files that don't have to be processed again and again. > Often times you end up deriving from the generated interface and your code breaks if you > change the interface file, etc. Furthermore, now you must maintain the code for the > generator, find bugs, bootstrap by building the generator, etc. I don't think there is any more maintaining the code or finding bugs involved with this approach than with the approach you are describing. The code is just in an executable form as opposed to in a library. With most serialization libraries you bootstrap by building a large library. What I advocate takes 1/10 as long to get bootstrapped as the Boost Serialization library. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

3 5

[containers] Implement std::forward_list?
by Lars Viklund 05 Aug '11

05 Aug '11

Hi. Will there be any analogous type in the proposed containers library for the C++0x std::forward_list [23.3.4 in n3290]? It's essentially a slist but without any of the costly operations like size(). -- Lars Viklund | zao(a)acc.umu.se

2 1

Documentation (was Re: [log] how to set attributes under multi-threaded application)
by Dean Michael Berris 04 Aug '11

04 Aug '11

On Fri, Aug 5, 2011 at 3:13 AM, Sean Chittenden <sean(a)chittenden.org> wrote: > > > This is a general comment about the documentation across the boost project and isn't entirely specific to the boost-log project, but wisdom such as this "the application of XYZ feature is ideally suited for the situation ABC" doesn't exist frequently in much of the boost documentation. I don't know if it's in some style guideline someplace, but having been a boost user for ~5yrs now and having forced boost on other developers for a few years now, this is one of the things that I acutely notice/get push back on regarding the boost project (especially when referencing its documentation). > > I actually just made this comment to Boris, the author of the "Boost Libraries" that one of the things that I like about his book is it actually distills practical examples because the boost docs are more geared toward other Boost developers vs consumers of the libraries. The biggest piece of feedback I get is summed up as, "Boost is high quality, but it requires a high degree of skill to apply. A lot of this is because the docs are frequently very dense and assume equivalent levels of STL competency to decipher what's written. Nine times out of ten, I don't need to customize boost or extend it, I just need to use it and there isn't something that I can easily reference and get what I'm looking for within 15-30min." And I'll admit, it took a good year of hammering away at examples and stubbing out little bits of code here and there before I became familiar and comfortable with implementing boost. Call it a byproduct of the PHP-ization of developers, I dunno, but I think there > 's a nugget of truth to be had in there (maybe add a quickbook type called "Implementors" with tips/hints? *shrug*). > FWIW, I try to do this in cpp-netlib and I have to agree with Andrey's assertion that this is not practical nor sustainable. It's actually one of the things that I'm thinking of "fixing" as far as the documentation is concerned. I think a library's documentation should surface three things in general: 1) Why the library exists. 2) How to use the library. 3) Expose important details that may not otherwise be obvious in the API. I think if #1 and #2 are done properly then I'd say examples of usage would be mere gravy. Because all if not most of Boost libraries tend to be fairly generic or broad (sometimes both) I'd say explicitly saying "This library can be used in <insert situation X>" greatly limits the applicability and/or perceived utility of the library. Just my $0.02. -- Dean Michael Berris http://about.me/deanberris

1 0