--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
Apropos of which, I now think that the Boost UserAllocator requirements
should be the default for components that parameterize how they use
memory, with the Standard Allocator requirements being used only for
components that need what they
--- David Abrahams [EMAIL PROTECTED] wrote:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period. Do
any implementations even use them? Allocators exist to
On Tuesday, Sep 2, 2003, at 05:42 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Conforming containers had better use them.
I'm sorry, but I think
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer, if
you include construct/destroy.
Or rather that some implementations have failed to use what they
offer, and our
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
...
Dave:
I think I would rather see a MPL lambda expression or metafunction
class interface for allocator type parameters. It makes little sense
for the allocator's user to be
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
Just how do you propose to prevent people from writing their own
construct/destroy functions? And if they write an allocator from
scratch, but *don't* provide construct/destroy manually, where will
they come from?
What I meant is that if
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
I think part of my point was that *nobody* needs what they offer,
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
I think the word static is not what you meant, and is what led me
to challenge the suggestion.
I used word 'static' because
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always assumed that
construct/destroy/pointer are a but someone might need to
On Tuesday, Sep 2, 2003, at 11:39 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams
wrote:
...
I think you're missing my point. There's no reason that a stateful
allocatorT should have access to the
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
You are assuming that there was no good reason to allow an allocator
to hook construct and destroy, for instance to do some bookkeeping.
I'm curious. Have you ever seen such an allocator? I've always
On Tuesday, Sep 2, 2003, at 13:00 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
On Tuesday, Sep 2, 2003, at 12:27 America/Denver, Peter Dimov wrote:
Then again, the Dinkumware implementation
dutifully calls construct and destroy, paying (and forcing me to pay)
the abstraction penalty
On Tuesday, Sep 2, 2003, at 12:51 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
On Tuesday, Sep 2, 2003, at 11:22 America/Denver, David Abrahams
wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
So you would rather use this than use construct?
template
On Tuesday, Sep 2, 2003, at 13:18 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Yep. I still think UserAllocator is a good default, and that where it
doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new
On Tuesday, Sep 2, 2003, at 15:00 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
Also, if shared_ptr only needs to allocate at construction time (I'm
not sure of this) we can avoid storing the allocator at all.
Then how to deallocate?
Using the custom deleter?
The deleter takes care of the pointee, but we
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
Why not just use std::allocator?
Because boost::memory::allocator will use UserAllocator under the covers.
So if you customized UserAllocator
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
T* _p;
Leading underscores are a no-no.
I didn't see it in boost naming convention docs.
Have I missed it?
Some STL implmentations use leading underscores for members.
Eugene
__
Do you Yahoo!?
Yahoo!
Gregory Colvin wrote:
[...]
Two small corrections:
shared_ptr currently uses std::allocator to allocate counts
regardless.
No, it uses plain new/delete by default. It is possible to get it to use
std::allocator via a #define.
[...]
versus standard Allocator
Allocator::pointer p =
On Sunday, Aug 31, 2003, at 13:13 America/Denver, David Abrahams wrote:
Gregory Colvin [EMAIL PROTECTED] writes:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period.
On Sunday, Aug 31, 2003, at 13:51 America/Denver, Peter Dimov wrote:
Gregory Colvin wrote:
[...]
Two small corrections:
shared_ptr currently uses std::allocator to allocate counts
regardless.
No, it uses plain new/delete by default. It is possible to get it to
use
std::allocator via a
21 matches
Mail list logo
