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

From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-05 21:20:14

On Wednesday, February 05, 2003 3:53 PM [GMT+1=CET],
Daniel Frey <d.frey_at_[hidden]> wrote:

> > 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.

No need.  The size of A1 should be 16 bytes on most 32-bit architectures,
but there's nothing fancy going on here.  If compilers are making bigger
classes it's just

GCC-3.2.3 on x86 reports:

    sizeof(A0) = 8
    sizeof(sp_counted_base) = 16
    sizeof(A1) = 24

They didn't change the object layout, so I'm a little shocked at your figure
of 44 bytes.  With threading disabled, it's:

    sizeof(A0) = 8
    sizeof(sp_counted_base) = 12
    sizeof(A1) = 20

This is as small as you could expect it to be given the requirements.  In
any case, that method of making intrusive pointers has been deprecated, and
replaced with a new one which doesn't add more than the size of the count to
your object (of course, you pay for a separately allocated count object
which is 12/16 bytes depending on threading).

> > > 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.

I don't think anyone will be insulted.  Nobody around here is jealously
guarding development resources, AFAICT.

> Although I am pretty sure
> I can do that even if I intend to, but this impression is what I would
    ^^^ "can't?"
> like to avoid.

Don't worry about it.  The more discussion, the more better.

> 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)

No offense intended, but that's a bit of a cop-out.  If you're going to be
the one asking for better comprehensibility, it isn't really fair to plead
"I'm bad at documentation."

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com