[boost] Re: Re: Re: Smart pointers: One more implementation +question

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-02-05 15:53:26

On Wed, 05 Feb 2003 18:08:21 +0100, Dave Abrahams wrote:

> On Wednesday, February 05, 2003 10:55 AM [GMT+1=CET], Daniel Frey
> <daniel.frey_at_[hidden]> wrote:
> 
>> Dave Abrahams wrote:
>> >
>> > On Wednesday, February 05, 2003 9:32 AM [GMT+1=CET], Daniel Frey
>> > <daniel.frey_at_[hidden]> wrote:
>> >
>> > > "Premature flexibility is the root of all evil"
>> > >
>> > > Stone me, Andrei :o)
>> >
>> > I don't think it's premature.  There's certainly plenty of evidence
>> > by
> now
>> > that people want a variety of different smart pointers
>>
>> I know. And I agree. Sentences like the above are provoking by their
>> nature, but still hold some truth.
> 
> I don't dispute that, but particularly given the rocky history of
> Andrei's relationship with Boost, it'd probably be better to avoid
> statements that are provoking by their nature in this conversation.  I'd
> like to make sure Andrei feels welcome here and hope one day he'll make
> some library submissions.

I don't know much about this history, but I think Andrei knows that I
never meant to speak against PBSP by this sentence. While optimizations
are added to libraries, so is flexibility, and both for good reasons. My
statement was a (poor?) attempt of humor but it also makes it clear that I
consider Andrei a part of the boost community. Also, the "truth" part
involved is, that people may think of PBSP as "premature" flexibility -
and that is what keeps them from using it. This has nothing to do with the
technical part where it's IMHO not premature but valuable. (Still I am
using my own smart-pointer, but that's another story will I might tell
later :)

>> and I think it would be a
>> horror to create and even more to maintain a boostified version of
>> Andrei's PBSP. Boost is becoming a blackbox with lot's of magic inside,
> 
> I think that's also provoking by its very nature (it's subjective
> impression stated as fact).

Hm, I apologize for that. Of course it's only my personal and narrow view
to the parts of boost I looked at - and from these parts some are easy to
understand. I should be specific and point to the is_class question about
how it detects classes in the fallback-version.

> Which compiler?  How were you using intrusive counting?

I used some benchmark code which compared several smart-pointers (my own
and the boost version). I had a simple class

#define LOAD int dummy[2];

struct A0 { LOAD };
struct A1 : boost::counted_base { LOAD };

The size of A0 is 8 bytes, the size of A1 was 20 bytes for the Intel (6/7)
compiler and 44 bytes for the GCC (3.2.1). If you like, I can send the
complete code.

>> This was a
>> motivation to start my own little library where I can understand the
>> code. It helped me to understand the things I wasn't able to understand
>> from looking at the boost code. I haven't published it yet for several
>> reasons including missing documentation, missing tests for at least
>> some important platforms/compilers, and last but not least I'm not sure
>> if it would be fair to boost.
> 
> Why not?

Because it addresses the same problems. I don't want to insult anyone here
by taking away users or (even worse) developers. Although I am pretty sure
I can do that even if I intend to, but this impression is what I would
like to avoid. Of course credits are given whereever appropriate.

>> To sum it up: I believe boost is becoming a blackbox and that worries
>> me.
> 
> Please define "blackbox."
 
Blackbox means that if it's too hard for me to understand the code, I can
just hope it works. Whenever a problem comes up, I'm left on my own.
Support from the boosters is of course given, it's even better than what
you get from most companies where you have to pay for support, but it's
(at least to me) always the prefered way to understand the code yourself.

> Are you saying we need more implementation-level documentation?  Most
> projects concentrate on that at the expense of user-level docs, and it
> hurts usability.  Boost's focus goes the other way, which probably hurts
> transparency.  As you say "it's a trade-off."  What you could do that

Indeed, but all the knowledge inside the implementation of boost is
valuable. So many expert have put so much effort in it. Isn't it worth to
let others learn from it and help them to do so? I cannot imagine that I
would know as much as I do about C++ without boost, that is *you*.
Everyone here. Thank you! And I would just like to see more people to
learn from boost.

>> Andrei has done a lot of good things not just by creating them, but
>> also by writing a book about it.
> 
> Agreed, of course.  What I mean is that I'm not completely satisfied
> with the implications that his MI design has for smart pointer size on
> real-world compilers.

And size does matter - the smaller the better ;) Which reminds me to add
Andrei's PBSP to my benchmark and check some stuff. The problem for me is
that I know the importance of documentation, but I'm not good in writing
it :o)

Regards, Daniel