Boost logo

Boost :

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

"David B. Held" <dheld_at_[hidden]> wrote in message
> "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> news:ahf9c4$4h6$
> >
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at