|
Boost : |
From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-30 13:13:35
> What I meant is that not all dynamically-allocated objects are placed in a
> ptr<>. Displacing the global new & delete forces the count to be
allocated
> 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 and it would help to
implement the basic_string<> class. Convertions to ptr<char const []> would
be easier to maintain also... It depends on the situation but I don't want
to reinvent the wheel also.
> Yes, but the underlying concept is that there are a few places where the
> Standard allows a restricted form of end-user program-level extensibility.
> In areas like these, IMO, libraries should not interfere. Examples:
> displacing global new/delete, registering functions with atexit,
> set_unexpected, set_terminate, etc.
Yeah good point here...
[...]
> 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 two
> pointers, similar to shared_ptr<>. Only instead of allocating the count
via
> "new int", allocate it from a pool.
Ok I'll go back to my previous proposal: what would be the difference to use
the overloaded operator new (size_t, xmm) then? The object is also
constructed thus easier syntax!
[...]
> For more information about pool allocators, check out the Boost.Pool
> documentation.
We could also consider operator new (size_t, xmm) as something similar to a
pool allocator.
Philippe A. Bouchard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk