|
Boost : |
Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-16 06:09:23
> Chris> there are major issues, to do with when, or how, assignment,
> construction and swapping move allocators around. There has been some
> serious discussion and research on this issue previously.
And I don't pretend to be an expert on all the issues. From wikipedia:
``Stepanov later commented that, while allocators "are not such a bad ideas
in theory (...) [u]nfortunately they cannot work in practice". He observed
that to make allocators really useful, a change to the core language with
regards to references<http://en.wikipedia.org/wiki/Reference_%28computer_science%29>was
necessary``
However, at the end of the day, this specific proposal works very well
without changing anything.
The key motivation for the proposal was to make fast and small nested
containers that can use the stack and/or heap for storage, and to make
deallocation a no-op. This has been accomplished with just one storage used
by a set of containers at or below a given stack frame, and also by having
multiple storage areas that the programmer is required to keep seperate.
This is not a huge burden, and is in fact a very simple thing to acheive in
the scheme of things. Can it be abused? Yes. But you can also dereference a
freed pointer.
> Not to say it can't be fixed, but it isn't just a case of "oh yes, just say
> they respect it".
I really didn't mean to trivialise the issue. I realise that the idea of
allocator equivalence has many issues, and it will be smarter people than I
whom decide on them. I'm just making the point that it doesn't adversely
affect the key aspects of this proposal.
All of my performances tests to date have used one storage with one or more
containers, have been completely safe (after adding correct alignment) and
standards-based, and have shown measurable and repeatable benefit. I very
clearly stand to be corrected on all results that I have posted.
> Chris
Cheers,
Christian.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk