Boost logo

Boost :

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

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

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

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