July 2010 - Boost - lists.preview.boost.org

boost.lockfree update
by Tim Blechmann 31 Aug '10

31 Aug '10

hi all, i've did some updates to boost.lockfree the biggest difference to earlier snapshots is, that it includes a fixed-size single-producer/single-consumer ringbuffer. besides, the documentation is based on doxygen now. snapshots are available from [1], docs from [2] and my git repository can be found at [3] and cloned from [4]... cheers, tim [1] http://tim.klingt.org/code/projects/boost-lockfree/files [2] http://tim.klingt.org/boost_lockfree/ [3] http://tim.klingt.org/git?p=boost_lockfree.git [4] git://tim.klingt.org/boost_lockfree.git -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

11 29

[Boost][website] SSL certificate
by admin＠thefireflyproject.us 18 Aug '10

18 Aug '10

I recently switched from Firefox to Chromium, and I've been having issues accessing [1]https://svn.boost.org. It seems that the SSL certificate used for [2]svn.boost.org is either not properly configured, or not issued by one of the major SSL certificate providers (e.g. VeriSign, GoDaddy). Examination of the certificate indicates that it's issued by the Computer Science Department of Indiana University, and the certificate doesn't have a chain that leads back to a well known CA (the chain is just '[3]svn.boost.org => [4]cs.indiana.edu', and most browsers I've tried don't recognize [5]cs.indiana.edu as a legitimate CA by default). If this isn't just a matter of improper configuration (or, for that matter, just a matter of my browsers being screwy), I'd be happy to offer my own SSL certificate to Boost. The certificate is a standard SSL certificate issued by GoDaddy (domain controlled validation, certificate signing algorithm is RSA 2048 bits), and it's paid through 02/20/2011. I'm currently using my cert for my Debian mirror, so I would have to revoke the current certificate, and then submit a CSR from [6]boost.org's server. Ideally, then I would generate a CSR request, and the boost server would sign it; I'd end up with a cert chain of 'mysite => [7]boost.org => GoDaddy'. [8]boost.org and subdomains would have a cert signed directly by GoDaddy, so the [9]svn.boost.org cert would be verify by most browsers automatically. If there's any interest in this, please let me know. - Bryce Lelbach References 1. https://svn.boost.org/ 2. http://svn.boost.org/ 3. http://svn.boost.org/ 4. http://cs.indiana.edu/ 5. http://cs.indiana.edu/ 6. http://boost.org/ 7. http://boost.org/ 8. http://boost.org/ 9. http://svn.boost.org/

9 12

outer class `this` in local classes
by Lorenzo Caminiti 16 Aug '10

16 Aug '10

Hello all, Is there a way to access the outer class `this` from a local class but without using inheritance? Let me explain with an example: class x { // outer class public: void g() {} void f() { this->g(); // (1) struct y: x { // local class *** using inheritance *** y(x* super): x(*super) {} // (2) void h() { this->g(); // (3) } }; y(this).h(); } }; *** Is there a way to do this but without inheriting `y` from `x`? *** At line (3), the local class `y` can access the outer class `x::g()` simply using `this` because `y` inherits from `x`. However, this inheritance requires to construct another object `x` when `y` is constructed as in line (2) adding runtime overhead and requiring `x` to have an accessible copy constructor. In my application, I need line (3) to essentially look like line (1) so you can program code inside `y` members as if it were inside `x` members. A part from that, the local class `y` could look as it is needed to solve this problem -- with some member variables, other member functions, etc. (For example, I tried to redefine `y::operator->()`/`y::operator*()` to return a pointer/reference to `x` but this does not work because `this->`/`*this` always retain its pointer semantics and they do not use the user defined operators...) Thank you very much. -- Lorenzo

2 3

[shared_ptr] Detect shared_ptr argument at compile time
by Ralf Globisch 13 Aug '10

13 Aug '10

Hi, I'm not sure if this is the correct mailing list for this question: Is there a way to determine if a template parameters is of type boost::shared_ptr at compile time? I would like to do something like: template<class A> void doSomething( const A& a) { // if "a" is of type boost::shared_ptr<SomeType> a->someMethod(); // else a.someMethod(); } Is this possible at all? Regards, Ralf

4 3

[1.44] Beta progress?
by Beman Dawes 10 Aug '10

10 Aug '10

It will be Wednesday before I can start pulling the 1.44 beta together. In the meantime, does anyone have any serious issues we need to tackle before the beta? Thanks, --Beman

15 125

Any interest in creating new CORBA IDL to C++ mapping?
by Johnny Willemsen 10 Aug '10

10 Aug '10

Hi all, We are talking with various users of TAO to see if we can create a new modern IDL to C++ mapping. The idea is to drop all old compilers which lead to the current mapping and make a new IDL to C++ mapping that is using the latest draft C++0x standard. We want to use full STL, shared_ptr, r-value, and everything else we could need. The idea is to prototype this first in TAO and than see if on the long term we can propose a new IDL to C++ V2 mapping to the OMG I did find some discussions on this list about 2 years ago, are people interested in this effort, any input is welcome. Johnny Willemsen Remedy IT www.theaceorb.nl

12 22

[1.44] Release notes
by Daniel James 09 Aug '10

09 Aug '10

Hello, If you haven't done so yet, with the beta coming out it's a good time to add your entries to the release notes so that people know what to test. You can edit the file in subversion here: http://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you prefer, you can email me the details and I'll add it for you. If you're able to build the release notes, I better warn you that I've changed the build system a little. Recent versions of quickbook are generating slightly different mark up, and if that's used for old entries, they can appear as new in rss feeds. So to avoid that, it now stores a hash of the quickbook files to only update their entry if the source changes. It should just work, you just need to commit the '*-hashes.txt' files at the same time as the rss files. If you want to force an update, you can delete the appropriate line in the text file. thanks, Daniel

5 7

[mpl] BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF
by Edward Diener 09 Aug '10

09 Aug '10

I found the BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF macro in the latest has_xxx.hpp of mpl on the trunk. Is BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TEMPLATE_DEF ) scheduled to be added to Boost in an upcoming release ? I find it useful for TMP introspection in much the same way as BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF ).

5 10

[intrusive] recursive intrusive data structures
by Tim Blechmann 09 Aug '10

09 Aug '10

hi all, is there an easy way to define recursive data structures? something like: struct my_node: boost::intrusive::list_base_hook<> { boost::intrusive::list<my_node> children; }; i am currently using a base class as helper, which causes very dirty code, since i explicitly need to cast from the base to the main class all over the place: struct my_node_base: boost::intrusive::list_base_hook<> {}; struct node: my_node_base { boost::intrusive::list<my_node_base> children; }; thanks, tim -- tim(a)klingt.org http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius

2 4

[bcp] Bcp namespace rename causes compile errors on multiple libraries (type_traits, range, spirit, foreach, regex, iostreams) in 1.43
by Cliff Green 04 Aug '10

04 Aug '10

Has bcp namespace renaming been tested against all Boost libraries in 1.43? I'm getting compile errors in (or caused by) the following libraries: type_traits, range, spirit, foreach, regex, iostreams (more details later in this message). The compile errors are from a full bjam build of Boost. I haven't compiled tests or built against my work project code, so I suspect there's more errors in header-only libraries. I'm using g++ 4.1.2 on Linux (although these errors are not compiler specific - I'll also be compiling with VC++ 8.0 at some point). All of these errors are easily fixed, and are "boost" text substitution problems. I was able to get all libraries to build after my changes, but I would rather not use hacked-up source (I prefer to work with the Boost developers and install non-modified Boost source into our Clearcase COTS VOB). However, with these (obvious) compile errors, I'm wondering if the bcp namespace facilities are being tested with all Boost libraries? If not, can I work with John Maddock or someone to set up a test process? Besides doing a full extract / rename and build of the libraries, as many examples and tests as possible should also be compiled to find errors in header-only libraries not brought in to the library source build. Of course it's possible all of the errors I've found have been introduced with new code in 1.43 (which still brings up the need to do a full bcp test before a Boost release), or that I somehow incorrectly used bcp, or there's fixes that haven't been applied to the mainline in SVN. My use case is a perfect fit for the bcp namespace facilities - my work team delivers an SDK (which links to and uses various Boost libraries) to another group which also links to and uses Boost libraries in their own application (everything builds into the same executable). Currently our work team is constrained to using the same Boost version, but we'd like to break this constraint (in particular, for other groups to use our SDK). We use (or will use) enough Boost libraries that bcp on the ones we care about pulls in about 80% of Boost, so I went ahead and ran bcp on all of Boost. Details of the compile failures: -- In type_traits: integral_promotion.hpp, promote.hpp, floating_point_promotion.hpp, header guard probs - original code #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_boost_type_traits_integral_promotion_hpp_INCLUDED After running bcp with "MyProj_Boost" for the namespace, the header guard is: #ifndef FILE_boost_type_traits_integral_promotion_hpp_INCLUDED #define FILE_MyProj_Boost_type_traits_integral_promotion_hpp_INCLUDED -- In range/config.hpp there's two macros where bcp namespace substitution is incorrectly being applied to the "boost" prefix in boost_range_array: #define BOOST_RANGE_ARRAY_REF() (boost_range_array) #define BOOST_RANGE_ARRAY_REF() (&boost_range_array) Similarly, in range/detail/implementation_help.hpp, the following lines have incorrect substitution: boost_range_silence_warning( boost_range_array ); -- In Phoenix and Wave, there's a bit of namespace substitution problems, where "namespace phoenix" (in multiple files, such as spirit/home/classic/phoenix) is being replaced with "MyProjectphoenix", and in wave/grammars/cpp_intlit_grammer.hpp and cpp_chlit_grammar.hpp there's "namespace phx=phoenix". -- In regex/v4/regex_traits.hpp: BOOST_MPL_HAS_XXX_TRAIT_DEF(boost_extensions_tag) The "boost" prefix in boost_extensions_tag is improperly substituted. -- In foreach.hpp, "boost_foreach_argument_dependent_lookup_hack_value" is not substituted in the enum, but in macros where the enum is used, the substitution is occurring. In iostreams/close.hpp, close_boost_stream on line 143 is being improperly substituted. --- As already mentioned, there's easy changes for each of these. But, is a better answer to make the bcp search and substitution smarter? (I have no idea how easy or hard that would be.) Cliff

3 5