|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-18 07:41:34
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> Peter Dimov wrote:
> > One problem with the "functional" push_back is that
> > programmers will be mislead by the analogy with the STL,
> > where push_back is more frequently supported than
> > push_front. In our case push_front is a primitive:
> >
> > (let's assume that the pair data structure A.B is called pair<A, B>)
> >
> > template<class List, class Value> struct push_front
> > {
> > typedef pair<Value, List> type;
> > };
> >
> > while push_back is (much) more taxing
>
> For this particular data structure. There are other compile-time
containers
> for which 'push_pack<C,T>' is O(1).
[...]
> Why? If I write 'push_back<C,T>::type', and it works, and satisfies its
> complexity specification (which IMO should be O(1)), I don't care how it's
> implemented.
>
> > and the false STL/meta analogy isn't going to help them.
> > push_back(L, V) is usually O(1) in STL, but O(|L|) in "meta."
>
> Not necessarily. For one, mpl::push_back<mpl::type_vector<>, T>::type is
> O(1).
Yes, yes, yes. There are other data structures for which push_back makes
perfect sense.
I'm addressing _specifically_ push_back on a slist. This is what the thread
was about.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk