Re: shared_ptr from dinkumware ... comments??
Gennaro Prota wrote:
On 20 Oct 2006 21:22:13 -0400, "P.J. Plauger" <pjp@dinkumware.com>
wrote:
if you care about ease of installation
and compatibility with TR1 (and hence compatibility with the
next C++ Standard) see our detailed comparison of our stuff
against Boost and gcc (libstdc++) at:
http://www.dinkumware.com/tr1_compare.aspx
Well, while I've never thought that the boost code is anywhere near
production quality, I guess such comparisons mean almost nothing
without the actual code used for testing.
I don't think that the goal of Boost is to create a commercially
competitive production library. It's conceived (at least as I
understand it) to be more of a laboratory, so that we can get
some concrete experience before fixing the exact specifications
for a production library.
Having said that, of course, shared_ptr is one of the oldest
components in Boost, and I'm pretty sure that it is now stable
enough to be used in a production environment. As far as I
know, it is also pure template code, entirely contained in its
headers, and (at least for the non-threaded version) could be
installed just by copying the headers, without going through the
hassle of installing Boost (a real pain). And while there are
probably minor bugs in any version, like Pete, I doubt you'd
encounter problems in a typical application.
Unless, of course, you are trying to use a multi-threaded
version. Then, I'd be very sceptical. But IMHO, shared_ptr
isn't something you'd want to cross a thread boundary anyway.
(If the g++ version uses their atomic_add, there's a problem
with the Sparc 32 bit version, for example, which can cause the
process to pause unnecessarily in some cases; if the OS
implements real-time threads, the process can even block
completely due to priority inversion. And if it doesn't, it
means a pthread_mutex_lock per increment or decrement. 100%
correct, but likely to be a bit slow.)
One could easily come up with tests which revert the results.
A comparison made that way is just marketing hype which no
professional would take seriously as it is.
Yes and no. Obviously, tests by an independant testing
organisation would be preferable. But you use what you've got;
if you don't think that Plauger's tests, you're free to write
some of your own. (And I'm sure that the people at Boost, at
G++ and at Dinkumware would be happy to add them to their test
suites if you did.)
As for whether the tests are "faked" in any way, I think
Dinkumware's repuation pretty much speaks for itself. What is
possible (and even to a certain degree likely) is that there are
corner cases that the people at Dinkumware didn't see (in
general, not in shared_ptr in particular): in such cases, they
won't have thought to handle them in their own code, and they
won't have thought to test them. It's a general problem, and
probably affects most code for which there is no third party
test cases. (Of course, I would hope that when someone else
mentions a possible problem, Dinkumware incorporates a test for
it in their test suite, even if they hadn't thought of it
before.) And FWIW: in the past, in other cases (e.g. the
standard library), there has been a very high correlation
between Dinkumware's tests and independant tests like the
Perennial test suite. Dinkumware's tests may have shown their
library better than others, but so did all of the other test
suites. (Go back about five years, of course, and you didn't
need a test suite to realize that Dinkumware was the only
library that was both close to standard conforming and had
acceptable quality. Today, of course, we're lucky in that both
the Dinkumware standard library and that of G++ are of excellent
quality. Unless, of course, like me, you're stuck having to use
the native library of a compiler which uses neither.)
--
James Kanze Gabi Software email: kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]