|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-01-23 13:09:19
Douglas Paul Gregor <gregod_at_[hidden]> writes:
> On Thu, 23 Jan 2003, David Abrahams wrote:
>
>> Douglas Paul Gregor <gregod_at_[hidden]> writes:
>>
>> > On Thu, 23 Jan 2003, David Abrahams wrote:
>> >> AFAICT it
>> >> doesn't solve the problem that Andrei was pointing at.
>> >
>> > You mean the front/pop_front issue?
>>
>> No, I mean the complexity-of-expression issue.
>
> Hmmm, I don't see how that issue applies.
I don't know what you mean by that. Are you saying that Andrei was
making an invalid argument? I wouldn't agree with that.
> STL users know how to write function objects. It's not a gigantic
> leap to write function objects with a templated function call
> operator (at least, it isn't if you've already decided to play with
> template metaprogramming). The rest of the syntax is inherited from
> STL. I don't see any extra complexity here. Granted, it means
> pulling in a lot more code than Andrei's version,
And writing a lot more code.
> but as one who has written that same bit of code approximately a
> billion times I'm ready for a simple, familiar abstraction.
Yeah, as I said I'm more comfortable with it too.
>> > Just stick your third-party iterators into sequence<> and you're all set;
>> > I'd expect that mpl::list, mpl::vector, etc. would just derive from
>> > mpl::sequence to reduce the amount of typing in the common case.
>>
>> Maybe it would be better to define namespace-scope begin(), end(),
>> et. al which can operate on STL and MPL sequences.
>
> I have two concerns with that:
> 1) begin and end are already class templates in MPL
> 2) There isn't much precedent for begin(container) and end(container);
> there is for container.begin() and container.end()
OK. I think it would be best to start by making an experimental layer
on top of MPL in the sandbox.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk