[boost] Re: Proposal: boost::pool fast pointer

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-30 17:47:11

"David B. Held" <dheld_at_[hidden]> wrote in message
news:ai72jb$s2j$1_at_main.gmane.org...
> "Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> news:ai6uui$gn1$1_at_main.gmane.org...
> > [...]
> > Well we could restrict assignments from whom offsets differ only.  Here
> > is a clumsy compile-time assertion example (I'm sure someone else can
> > build one more cleanly):
> > [...]
>
> I have a name for your pointer: hack_ptr<>. ;)

Let's not forget those hacks will be integrated correctly eventually.  Those
are just to accelerate trials and errors for now.

> P.S.  Seriously, do you notice how you are constantly pressured into
> making hacks so that your pointer behaves like most smart pointers?
> Does that bother you at all?  Soon, your header will be a laundry list
> of reinterpret_cast<>s sprinkled with a few pointer operations. ;)  And
> notice that your "solution" doesn't restore missing functionality.  Rather
> it enforces the lack of functionality.  Many people might question the
> utility of a non-polymorphic pointer.

Well:
Y * pY = new Derived;
delete pY;

Won't work.  I don't see how shared_ptr<> is better in this situation.  My
'hacks' will prevent the user from implicitly doing an error: you'll have to
explicitly prove you know what you are doing.

'Hack' is also relative.  I could say the same thing about & foo expressions
when there are two overloaded version of the function.  You now need some
compiler hack: (void (*)(int)) & foo.  What about: istream & getline(istream
&, basic_string &) ?

Philippe A. Bouchard