RE: [boost] Proposals: p2m offsets, prebuild<>, squad_ptr<> (of course)

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2002-07-23 07:32:17

ok, I admit it. I don't understand what testptr2.cpp is supposed to be
doing. apart from leaking, and if I'm honest I don't want to know what its
supposed to do:

node * s = new (new (new (buffer<node>()) int(8) + pos(& node::j))
double(2.6) - pos(& node::j)) node("My name is Bob.");

do?  I see three 'new's some node's and buffers, and all (if I understand
correctly) for the sake of delaying construction of the prebuild<> members.
How are these pos and offset constructs any help?  They definately don't
make reading any easier.  It reminds me of Item 47 from Scott Meyer's
excellent Effective STL, "avoid writing write-only code", have a look if you
have a copy.

Aside from the confusing use, prebuild to me, seems like a great way of
asking a classes user to create uninitalised data.  Sidestepping one of the
goals of C++.  It is already possible to create uninitialised data, but the
onus should be on you the class writer not the class user to make sure that
the data is initialised at the right time.

sorry, I know thats non-constructive, so for some constructive criticism,
have you considered the 80:20 rule? (80% of run time is spent running 20% of
the code, or something like that, apologies for misquoting)  Efficiency is
important, but it is something I think that should be thought about after
you have got the code working right. (although should be kept in mind
throughout)  Often with the help of a profiler to tell you which bits of the
code are your 80:20 bottleneck.

For myself, parsing, disk io, processing, or a poor choice of container have
always been the bottle necks, and only once was a copy ctor to blame, and a
simple replacement of using shared_ptr containers instead instantly removed
that problem, so that the disk io once more took the limelight.  Should
shared_ptr ever be a problem (I have not as yet had such a situation) then
from what I have heard intrusive_ptr would be a tool to look at.

Finally, for me at least, squad_ptr is just to obfuscated.

take the line:
squad_ptr<T> p = new (new (squad<T>()) T('Y')) squad_target<T>();

firstly, it took me a moment to find the actual constructor arguments,
admittedlt that is partly because as I spend much of my time using MSVC I at
first mistook the T('Y') for a _T macro.

which in shared_ptr speak would be
shared_ptr<T> p(new T('Y'));

and compared to the raw ptr usage, which is afterall what smart pointers are
trying to emulate

T* p(new T('Y');

I can see why shared_ptr is constructed as it is, it makes sense, I havn't
looked at intrusive_ptr yet, but from what I've seen its use is similar
also.  For similar (if not identical) performance gains.

I just don't see any real benefit of adding squad_ptr to boost.

sam

> Hi,
>
>     I know your priorities may be elsewhere right now but I made some
> derived utilities that may interest some of you besides squad_ptr<>.
>
> 1) I've included a little function and I would like your opinion if
> possible.  It consist of a pointer to non-function member to integer
> conversion.  I find it really helpfull for my complex instanciation
> demonstration (testptr2.cpp) which I know will never be needed in weird
> situation like this one but I'm just extrapolating the possibilities.
>
> 2) prebuild<> is an object that disables every initial constructions of a
> variable.  Construction will be reported to the next operator new (size_t,
> void *) call.  It is usefull when you want to disable class
> members initial
> constructions.  This will allow you to construct nested members directly
> without copying expensive temporaries.  It is effective when applied to
> every type of needed nodes pointed by smart pointers (or rewritten STL
> lists, vectors, etc. eventually).
>
> 3) squad_ptr<> finally.  I'm not asking to force this one to be used I'm
> just demanding some thoughts; library extensions, integration, etc. in the
> domain of the possible of course.  Let's not forget it is using unused but
> pure C++ syntax.  testptr1.cpp shows how clean testptr2.cpp can be when
> squad_target<> type is used.
>
> I'm open to nonconstructive and preferably constructive opinions.
>
>
>
> Thanks again,
>
> Philippe A. Bouchard
>
>
>
>