Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2002-07-30 14:44:10

> From: Philippe A. Bouchard [mailto:philippeb_at_[hidden]]
> > What I meant is that not all dynamically-allocated objects are placed in
> > ptr<>. Displacing the global new & delete forces the count to be
> > every time new is called; for example, every node allocated by every
> > std::list<..> would then take up more memory than necessary.
> On the other hand it would be faster knowing this...

All the std::list<..> implementations I'm aware of allocate list "nodes"
which are a previous pointer, next pointer, and a T, all done in the same
allocation. So I don't see how it would be faster.

> and it would help to
> implement the basic_string<> class.

You mean by prefixing a length? Perhaps if the array versions of new/delete
were similarly displaced...

> > The end-user syntax should be about the same as a shared_ptr<>.
> >
> > The most straightforward way to implement it is to have the ptr<> have
> > pointers, similar to shared_ptr<>. Only instead of allocating the count
> > "new int", allocate it from a pool.
> Ok I'll go back to my previous proposal: what would be the difference to
> the overloaded operator new (size_t, xmm) then? The object is also
> constructed thus easier syntax!

I think something got lost here. Here's the syntaxes as I see it:
  Current shared_ptr: shared_ptr<T> p(new T(..));
  Displaced new/delete: ptr<T> p(new T(..));
  Pool-based ptr: ptr<T> p(new T(..));
  Overloaded new: ptr<T> p(new (x) T(..));


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