[boost] Re: Extensible polymorphic pointer

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-07 15:45:54

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:airl42$qlr$1_at_main.gmane.org...
> [...]
> Is it faster?  I got the habit of not casting to reference types because
of
> implicit exceptions sometimes.

I believe that reinterpret_cast does not throw.  With dynamic_cast, you
could get a std::bad_cast when casting reference types improperly.

> Placement delete?  This is already handled by explicit destructor calls.

Technically, placement delete is a lot more subtle than that.  It is called
when placement new throws.  For instance, if T throws during construction,
but after the malloc() call, then the memory returned by malloc() will leak.
Therefore, you should define a placement delete to free() the memory in
such an event.

> [...]
> It will still work, you just live with redundant lookup tables.  But this
> problem is the main one with template usages.

What about having source file with the static data?  Also, can you explain
how get_type_id() works?  It seems to me that it could return a very large
value.  There also seems to be no discernable relationship between the
size of the space allocated by reserve() and the possible values returned
by get_type_id().

> [...]
> It is more extensible for speed & memory of large containers because
> the pointer is of sizeof(int), allocations & deallocations are not done
twice
> for each object pointed to, less overhead on memory maps

I don't see how these make it "extensible".  Perhaps we don't agree on
what the word means.  When I see "extensible", I think: "Can be made to
have different functionality".  The features you mention look like a set of
fixed functionality.

> and we all know the that the custom deleter can also be integrated
> eventually.

And the big question is: When it is, will we just end up with shared_ptr<>?

> I'm not a 100% familiar with the main policies this is why I haven't done
> it yet.

Well, not everyone is convinced that policy-based design is the way to
go, so don't worry about that.  Although, it would be worth your while to
do some reading and find out about it.

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:airm8o$u3k$1_at_main.gmane.org...
> >
> > Your code results in undefined behaviour, since it accesses vector
> > elements that have not been constructed.  Even though the data type
> > is POD, accessing vector[i] where i >= vector.size() is not legal C++.
>
> Why is it public then?  There's a flaw in their standards therefore.

No, there's not.  When you call reserve(), you are merely telling the
vector to make sure it has plenty of space, because you are about to
call push_*() or resize().  It does not actually change the size of the
vector.  Therefore, you should really be calling resize() or push_back().

> [...]
> The table is needed because it maps offsets associated with type T
> and all the object this type could point to.

I understand the intent, but for a given T, why would there be multiple
entries in the table, and show me an example with plausible values.

> [...]
> len<>() is usefull to implicitly generate offsets, but I'll look at
> ptrdiff_t.

I understand the purpose of len<>, but why not just use sizeof()
directly?  The comments appear to imply that your indirection is
faster than a raw sizeof() call.

Dave