- Boost - lists.boost.org

[function] [1.47.0] #4717: Non-const local static variable stored_vtable
by Kazutoshi Satoda 01 Jun '11

01 Jun '11

I want the fix for the following ticket (regression, I think) included in 1.47. "#4717: Non-const local static variable stored_vtable" https://svn.boost.org/trac/boost/ticket/4717 Here is a quote of a essential part of the fix. - static vtable_type stored_vtable = + static const vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; https://svn.boost.org/trac/boost/attachment/ticket/4717/djw_function_const_… I did same request for 1.46 and 1.46.1, and got no response. http://lists.boost.org/Archives/boost/2011/03/177769.php http://lists.boost.org/Archives/boost/2011/01/175248.php Please let me know if there is more effective way to push the fix, or if I'm doing something wrong. -- k_satoda

2 2

[shared_ptr] Some design advice
by Johnny Willemsen 31 May '11

31 May '11

Hi, I want to create some refcounted objects using shared_ptr. For example if I have class A_impl, I want my users only to use A. So, I created the following code: class A_impl { public: virtual ~A_impl () {}; void dosomething () {}; }; typedef shared_ptr <A_impl> A; The challenge is now that I want to provide some typedefs on A (which is a shared_ptr()). So that my users can use: A::my_value_type; I am aware of the reference_type, but I need to have some additonal typedefs and constants as part of A. I have started with a partial template specialization of shared_ptr, but I have my doubts whether this is the correct way. Another option would be to create our own shared_ptr that just embeds the boost_shared_ptr and exposes just some of its methods. Any specific ideas on this? Regards, Johnny

2 1

Re: [boost] [tokenizer] tokenizing by strings rather than chars
by Andrzej Krzemienski 31 May '11

31 May '11

> Andrzej Krzemienski wrote: > > I want to parse numbers separated by "new-lines", however, on > > my windows system, a "new-line" is represented by two > > consecutive characters: 13, 10 (or in other words by string > > "\n\r"). So, only if I encounter a sequence of these two chars > > do I want to cut the token. > > Spirit.Qi would do that handily. Something like this should work: > namespace qi = boost::spirit::qi; > std::vector<int> data; > qi::phrase_parse(input.begin(), input.end(), qi::int_, qi::eol, data); Thanks for the reply. And could I ask a similar question? I wanted to simplify my real task to make it shorter and clearer to understand, and it look like I changed it to a different one. My apologies. My real task is to check if the data in Windows clip-board is a column of data (copied from a grid or table). Such a column is just text separated with "\n\r" sequences. So, for example these are valid data: "12" - a column of height 1 with data "12", " a\n\r b" - a column of height 2 with two with data " a" and " b" "-1\n\r\n\r3" - a column of height 3 with datum "-1", empty cell, and datum "3". The spirit solution above will skip the empty cell in my third example. On the other hand, I do need the information about empty cells too. It really looks more like a tokenizing task. Or is there a way to do it easily in Spirit? Regards, &rzej

2 1

Re: [boost] [pimpl] Mini Review
by Ivan Le Lann 31 May '11

31 May '11

----- "Artyom Beilis" <artyomtnk(a)yahoo.com> a écrit : > Hello All, > > Because a pre-review runs this days in collaborator tool I still want > to provide some feedback on this library I was looking on long > time ago. > > - What is your evaluation of the design? > > --------------------------------------------- > This is the major problem of the library: > It tries to do simple things overcomplicated. > --------------------------------------------- > > > Take as an example: > > struct Book : public pimpl<Book>::value_semantics { ... }; > > Is an attempt to do things in "fancy" way where it is not needed. > > struct Book { > public: > private: > struct implementation; > smart_ptr<implementation> pimpl_; > }; > > Is much clearer. Your code would rather simulate pimpl<>::pointer_semantics. And you do not mention the boilerplate code generated. > > The proposed solution is overcomplicated hard to read and in general > makes > more troubles then helps, makes the code less readable by average > programmers. > > ------------------------------------ > shared_ptr as pointer model is Wrong > ------------------------------------ > (snip lots of smart_ptr related lines) Unless you want pointer_semancics ... As for value_semantics, shared_ptr is not used. > 2. clone_ptr - pointer that clones underlying object on its copy. > i.e. something like > > copy_ptr(copy_ptr const &other) : p_(other->clone()) {} Precisely what seems to be used in the library for value_semantics. > > The only advantage I can see in boost.pimpl over scoped_ptr or > auto_ptr > is that it does not require explicit destructor. An important advantage as many developpers get trapped here. And it is "only" a warning to do so ... > Spare Pointer use case > ------------------------ > > Another important use case in the case when pimpl is used to handle > ABI > stability and > in general the object has spare "pimpl" or d-pointer for future uses. > > Consider: > > struct book { > public: > book(); > book(book const &); > ~book(book const &); > book const &operator=(book const &); > std::string title() const; > std::string author() const; > void title(std::string const &); > void author(std::string const &); > private: > std::string author_; > std::string title_; > struct data; > copy_ptr<data> d; > }; > > > Now in book.cpp we define data as > struct book::data {}; And with Pimpl, you would put author_ and title_ in book::data. I failed to see the point here. You seem to say that Pimpl cannot be used for ABI stability, which seems wrong to me. Regards, Ivan.

5 13

Re: [boost] [random] recent changes causing failures in accumulators tests
by Steven Watanabe 31 May '11

31 May '11

AMDG On 05/30/2011 09:23 PM, Eric Niebler wrote: > On 5/27/2011 12:24 PM, Steven Watanabe wrote: >> On 05/26/2011 09:49 PM, Eric Niebler wrote: >>> Many accumulators tests are now failing on both trunk and release. I >>> have tracked it down to recent changes in Boost.Random. I don't know for >>> how long this has been happening. > <snip> >>> >>> Steven, this seems like a regression. Can you look into this? >>> > >> I think the only thing I changed was the seeding algorithm. >> The number of random bits was reduced from 53 to 48, but >> that's all lagged_fibonacci607 ever claimed to provide. > >> Your limits may be too low. I switched extended_p_square.cpp >> to use mt19937_64 and random_device with >> generate_canonical<double, 53> and it still failed >> with both. It's getting a bit late tonight. I'll >> work through the math tomorrow. > > Hi Steven, have you had a chance to look into this? I'm not so much > concerned about accumulators as I am about the potential regression in > random, especially since the release branch is effected and we're > closing in on a release. > For extended_p_square, the check for 0.25 with epsilon = 2, works out ot a 75% confidence interval. I bumped epsilon up to 3. I think this is somewhere between a 90 and 95% confidence interval. I adjusted the tests at 0.01 and 0.001 also. Once I got the test to pass with random_device consistently, it also passed with lagged_fibonacci607. (I'm not absolutely sure about the confidence intervals. I was estimating them using the binomial distribution, which is a poor approximation towards the edges). I'm pretty sure from this that the problem was that the probability that the test would pass with random values was too low, so the change in the seeding algorithm was enough to make it fail. I'll try to make time to check the other failing tests soon. In Christ, Steven Watanabe

1 0

[pimpl] Mini Review
by Artyom Beilis 31 May '11

31 May '11

Hello All, Because a pre-review runs this days in collaborator tool I still want to provide some feedback on this library I was looking on long time ago. - What is your evaluation of the design? --------------------------------------------- This is the major problem of the library: It tries to do simple things overcomplicated. --------------------------------------------- Take as an example: struct Book : public pimpl<Book>::value_semantics { ... }; Is an attempt to do things in "fancy" way where it is not needed. struct Book { public: private: struct implementation; smart_ptr<implementation> pimpl_; }; Is much clearer. The proposed solution is overcomplicated hard to read and in general makes more troubles then helps, makes the code less readable by average programmers. ------------------------------------ shared_ptr as pointer model is Wrong ------------------------------------ You almost never want to have shared object semantics for pimplized object. I use pimpl ideom widely in my projects CppCMS, CppDB and even in Boost.Locale and I used shared semantics only once where it was explicitly shared. In rest of the cases I had found myself using following smart pointers: 1. copy_ptr - pointer the copies underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(new Object(*other)) {} Copy the object on copy. 2. clone_ptr - pointer that clones underlying object on its copy. i.e. something like copy_ptr(copy_ptr const &other) : p_(other->clone()) {} 3. hold_ptr - pointer with same const-semantics as an object it points to T const &operator*() const; T &operator*() ; T const *operator->() const; T *operator->() ; They cover almost all use cases, so with addon of shared_ptr it covers ALL use cases. In any case current boost::scoped_ptr or std::auto_ptr is much more suitable smart pointer for implementing pimpl then Boost.pimpl. The only advantage I can see in boost.pimpl over scoped_ptr or auto_ptr is that it does not require explicit destructor. i.e. class Foo : boost::noncopyable { public: Foo(); int x() const; void x(int v); private: struct data; std::auto_ptr<data> d; }; No good. You need to add ~Foo(); So it would know to destroy Foo::Data correctly. But this can be easily solved on hold_ptr, copy_ptr and clone_ptr level same as it solved for shared_ptr and in reality even this not needed as it is better to add empty destructor in cpp. Spare Pointer use case ------------------------ Another important use case in the case when pimpl is used to handle ABI stability and in general the object has spare "pimpl" or d-pointer for future uses. Consider: struct book { public: book(); book(book const &); ~book(book const &); book const &operator=(book const &); std::string title() const; std::string author() const; void title(std::string const &); void author(std::string const &); private: std::string author_; std::string title_; struct data; copy_ptr<data> d; }; Now in book.cpp we define data as struct book::data {}; And we do not initialize d at all. It is fast and efficient object that does not use data at all. Now when we decide to add new member "isbn" without breaking ABI. in book.cpp we define in book.cpp struct book::data { std::string isbn_; } And now we initialized the d pointer in constructor. And add new members in book.h std::string isbn() const void isbn(std::String const &); And implement them std::string book::isbn() const { return d->isbn_; } void isbn(std::string const &s) { d->isbn_ = s; } This is very important use case the the author does not even relate to. - What is your evaluation of the implementation? Generally not looked into too deeply but it is does not follow boost standards: - Naming conventions - Documentation - Build So it is not even ready for the review (even thou it can be easily changed as it is a small library) - What is your evaluation of the documentation? 1. The documentation should be in HTML file not on some Internet web site. 2. Rationale part missing The documentation in not Boost-Ready - What is your evaluation of the potential usefulness of the library? Useless for 90% of pimpl use cases. - Did you try to use the library? With what compiler? Did you have any problems? No I hadn't - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4-5 hours of studying - Are you knowledgeable about the problem domain? Yes, I work with pimpl-ized object on daily bases in many different approaches including implementing my own smart pointers for pimpl (clone_ptr, hold_ptr, copy_ptr) - ABI Stability - Compilation time reduction, - Decoupling of the interface from implementation details. Should The library be accepted in Boost: ======================================== No it should not. It is "a fancy" library that was written without a knowledge of the problem domain. It tries to solve problem in smart way making it overcomplicated. IMHO old std::auto_ptr is much more suitable for writing pimpl-objects then Boost.Pimple. For easy pimpl-ideom you do not need a fancy class but rather a set of pimpl-suitable smart pointers. Best Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

10 31

[Config] Big changes in C++0x detection...
by John Maddock 31 May '11

31 May '11

Just a heads up, that the latest Boost.Config changes: * Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP! Thanks for your patience! John.

9 34

boost-test, why is there no DOUBLES_EQUAL?
by Sebastian Nowozin 31 May '11

31 May '11

Hello, I am a regular user of the boost test library, having used CPPunit before. I miss the following macro: BOOST_CHECK_DOUBLES_EQUAL(first, second, absolute_tolerance); which would check whether "std::fabs(first-second) <= absolute_tolerance" is true. It seems the boost test library does not support it, and instead forces/encourages users to use BOOST_CHECK_CLOSE(first, second, percent_relative_tolerance); The above macro does not really make sense in my application, I really need to check for absolute tolerances, irrespectively of the magnitude of the numbers. CPPunit has this feature as DOUBLES_EQUAL. Would you consider adding this? Thanks, Sebastian

9 16

[shared_ptr] calling functions by reference
by Sid Sacek 31 May '11

31 May '11

This might be a unimportant question and may have already been answered many times before, but I was wondering about functions that take shared pointers as arguments. Is there ever a reason I would not want to use a shared_ptr reference as an argument? I can't think of any, but is there any? class XYZ; void foo( shared_ptr< XYZ > &xyz ) { }

5 12

boost.atomic and boost.lockfree backports
by Bryce Lelbach 30 May '11

30 May '11

Hartmut and I have been using modified versions of Boost.Lockfree and Boost.Atomic in our codebase at work. I've put git repositories of our versions of both libraries up on github, so that the lockfree/atomic authors can integrate our bug fixes and/or feature extensions if they wish. The code is under the BSL. In addition to a number of bug fixes/tweaks, our variants contain the following enhancements: * boost.atomic: 128bit lockfree atomics for MSVC 2008+ (using _InterlockedCompareExchange128 and SSE2 intrinsics) and GCC-compatible POSIX compilers (using 16 byte __sync intrinsics). This code is x86-64 specific, and disabled by default. Define BOOST_ATOMIC_HAVE_SSE2 to enable in x86-64 MSVC 2008+ environments. Define BOOST_ATOMIC_HAVE_SSE2, BOOST_ATOMIC_HAVE_GNU_SYNC_16 and BOOST_ATOMIC_HAVE_GNU_ALIGNED_16 to enable for GCC-compatible compilers. The following command line flags are also needed for GCC-compatible compilers: -mcx16 (enables 16byte sync intrinsics) and -msse2. * boost.lockfree: A growable lockfree deque, based on algorithms by M. M. Michael. Backed by 128bit atomics. This is the first lockfree data structure I've written, so take it with a grain of salt. There's one bug that I'm aware of, unfortunately, it occurs infrequently so I haven't had much luck tracking it down. Links: https://github.com/brycelelbach/boost.atomic https://github.com/brycelelbach/boost.lockfree P.S. I don't have a list of the specific bug fixes on hand, I'll have to go through the SVN logs for that. The only non-trivial one that I know of is the problem with intel-linux that I found and fixed (intel doesn't define *amd64* macros, and they were used for x86-64 bit detection). -- Bryce Lelbach aka wash boost-spirit.com px.cct.lsu.edu github.com/lll-project

4 7