- Boost - lists.boost.org

[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

Invitation to connect on LinkedIn
by Gautam Sewani via LinkedIn 04 Aug '11

04 Aug '11

LinkedIn ------------ Gautam Sewani requested to add you as a connection on LinkedIn: ------------------------------------------ Yuriy, I'd like to add you to my professional network on LinkedIn. - Gautam Accept invitation from Gautam Sewani http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… View invitation from Gautam Sewani http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/uV9CsZkavY-uKU5A7C-1JbkavY-u5P… ------------------------------------------ DID YOU KNOW LinkedIn can help you find the right service providers using recommendations from your trusted network? Using LinkedIn Services, you can take the risky guesswork out of selecting service providers by reading the recommendations of credible, trustworthy members of your network. http://www.linkedin.com/e/bv6hcz-gqy2wc24-30/svp/inv-25/ -- (c) 2011, LinkedIn Corporation

1 0

Re: [boost] [log] how to set attributes under multi-threaded application
by Sean Chittenden 04 Aug '11

04 Aug '11

>> In boost::log documentation, there's some code as following: >> >> * typedef attrs::mutable_constant< int> int_constant_t; >> boost::shared_ptr< int_constant_t> attr(new int_constant_t(-5)); >> lg.add_attribute("MyInteger", attr); >> BOOST_LOG(lg)<< "This record has MyInteger == -5"; >> >> **// Change the attribute value >> attr->set_value(100); >> BOOST_LOG(lg)<< "This record has MyInteger == 100"; >> * >> Now I have a situation in my multi-threading app: >> the 'attr->set_value()' could be called in different threads, so the >> following 'BOOST_LOG(lg)...' could access wrong attributes that is set by >> another thread. If I use a mutex to protect this, it would be stupid, >> because the log line might be filtered out, that means the 'locking mutex' >> is not neccessary. > > If thread synchronizaion is what bothers you, mutable constant has > internal locking ability, you can specify mutex and lock types in the > mutable_constant template parameters. You can find an example in the docs: > > <http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/attributes.…> > > So, when internal locking is used, you don't have to externally > synchronize access to this attribute, neither when you update its value > nor when you write log records involving it. > > > On the other hand, if you simply try to tag a specific log record with > an attribute (e.g. you want to make sure that a particular record has > MyInteger value -5 attached) then thread-specific attributes would be a > better option. You can add a scoped thread-specific attribute for this > record, this will not affect log records generated by other threads and > will not require any synchronization either. You can read more about > scoped attributes here: > > <http://boost-log.sourceforge.net/libs/log/doc/html/log/detailed/utilities.h…> 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*). Anyway, Andrey, it'd be keen if you could include a note along these lines in the docs. Maybe a quickbook type for "Implementors." Cheers. -sc -- Sean Chittenden sean(a)chittenden.org

2 1