[boost] Re: Yet Another Pointer Policy Proposal... Fast One

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-28 16:57:27

"Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
news:ahum4e$c82$1_at_main.gmane.org...

[...]

> > contrary except for negligible small memory restrictions.  It is a pure
> and
> > simple speed _extension_...
> Couldn't you implement this "extension" in conventional way?

Yes but it would require to override the global operator new (size_t), then
it will allow us to use the simplest 'new type()' expression.  We do you
think about those different possibilities:
1) new type();
2) new (xmm) type();
3) make_rc(type());
4) make_rc(new (xmm) type());
5) new (new (xmm) type()) rc<type>;

The first one would require to overload the global operator new (size_t).
The problem is that we are not sure if the user had reimplemented the
function in specific classes.  The second (which I like) is more portable
but you'll have to know what you are doing because the smart pointer
handling it is assuming you are not using the simpler operator new (size_t).
It would be possible the deactivate it and force new (xmm) type() usage.
The 3rd one is a macro but the 4th one requires no redundancy without
macros.  The 5th one is redundant but is the most flexible besides the 4th.

It is possible to build a program using the 1st and 2nd statements.  It
doesn't look too bad and it would require to use the partly specialized
shared_ptr< rc<type> > pointer and would imply you know what you are doing
in order to start using those complex syntaxes.

> > I thought that Boost was all about this?!?
>
> I don't think that true. Boost libraries (almost) never consider
performance
> as first priority.

Too bad.  'Boost' sounded like a performance catalyst.

Philippe A. Bouchard