[boost] Re: Proposals: faster pointers & postponed construction type

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-22 08:05:09

"David B. Held" <dheld_at_[hidden]> wrote in message
news:ahfhad$hoa$1_at_main.gmane.org...
> "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> news:ahf9c4$4h6$1_at_main.gmane.org...
> >
> > 1) I wanted to show you a benchmark showing shared pointer
> > differences between squad_ptr<> and shared_ptr<>.
>
> Again, you're comparing apples to oranges.

Well what can I say...  apple and oranges together make a good fruit salad.

> > shared_ptr<> is not derived from counted_base because I wanted to
> > point out that squad_ptr<> is easier to use with typenames like int,
> float,
> > ...  and keeps its rapidity.
>
> No, shared_ptr<> is not derived from counted_base because that's the
> way the library designers wrote it. ;)

Sorry, I wrote too fast here.  What I meant is that the object pointed to is
not derived from counted_base in my benchmark.

[...]

> > list shared_ptr<> took 3303000 nanoseconds to construct.
> > list shared_ptr<> took 2424000 nanoseconds to copy.
> > list shared_ptr<> took 2612000 nanoseconds to destroy.
> > [...]
> > list squad_ptr<> took 1251000 nanoseconds to construct.
> > list squad_ptr<> took 979000 nanoseconds to copy.
> > list squad_ptr<> took 1262000 nanoseconds to destroy.
>
> So your pointer is 2-3 times faster than shared_ptr<> on your platform.
> It doesn't support weak pointers, custom deleters, or a thread-safe
> count.  It also does not support array semantics.  Again, you're
> comparing apples to oranges.  Maybe some people do need a pointer
> that is just that fast.  Still, I would be suprised it managed to join
> the menagerie that is currently boost::smart_ptr.  The benefits just
> don't seem compelling, compared to the costs.

I know it is not portable, doesn't support thread safety and arrays
semantics yet.  I'm just showing basic functionnality so that it is easier
to understand & compare. IMO my oranges are easier to program with because
you don't need to write add_ref functions, derive your target from
counted_base, ...

On the other hand, let's not forget that C was a higher level, multiplatform
assembler programming languages.  C++ is an object oriented version of C but
still is a multiplatform assembler language.  Thus speed / memory benefits
will always outweigh user friendliness benefits in C++ so it is an important
cost for standartizations.

> The costs include peculiar usage (creating a squad pointer is surely
> bizarre to people used to raw pointers and most other smart pointers)
> and small functionality set.

operator new (size_t, void *) is pure C++ syntax.  If it's bizarre let's
discuss with AINSI.  I'm in the process of cleaning structure construction
with those operators and the macro will be gone.

[...]

Philippe A. Bouchard