- Boost - lists.boost.org

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

[trac] trac/boost/browser/ no longer available?
by joaquin＠tid.es 04 Aug '11

04 Aug '11

Say I'm having a look at some changeset such as: https://svn.boost.org/trac/boost/changeset/73525 The names of modified files are displayed with a link to a full-code browsing page, for instance: https://svn.boost.org/trac/boost/browser/sandbox/variadic_macro_data/boost/… yet this page fails with No handler matched request to /browser/sandbox/variadic_macro_data/boost/variadic_macro_data/vmd.hpp I think this trac/boost/browser has been missing for some months now. I seem to remeber there was a link to it also from the trac home page, now also missing. Any clue about this? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 4

[network] Bagged, Tagged, New Release 0.9.1
by Dean Michael Berris 04 Aug '11

04 Aug '11

Good day everyone! If you're not interested in cpp-netlib's progress, please stop reading now. :) I'm happy to announce that cpp-netlib (the library that's hoping to be Boost.Network someday) is now available for general availability. You can get the latest from https://github.com/cpp-netlib/cpp-netlib/downloads and find out what's new at http://cpp-netlib.github.com/0.9.1/whats_new.html . This is an updated release that's inching closer to the "1.0" release that's going to be up for review. I've also written a more detail-filled announcement that you can read over at http://cplusplus-soup.com/2011/08/04/cpp-netlib-0-9-1-released/ -- please feel free to comment and share as you see fit. I'm looking to work with Michael Caisse who has agreed to be the review manager for Boost.Network to hopefully have a review at a convenient time for both of us. Right now I'm gunning for Q4 of 2011, but that's still fairly a ways away so things may still change. Cheers everyone, I do hope this helps! -- Dean Michael Berris http://about.me/deanberris

1 0