Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-09-29 20:55:14


David Abrahams wrote:
> Joel de Guzman <joel_at_[hidden]> writes:
>
>> All that being said, I don't care too much either way. It's not
>> a concern of Fusion, AFAICT. Unless, you are asking for std::pair
>> to be removed from the list of supported Fusion sequences?
>
> Nope. Just raising the point for discussion.

Glad to hear :)

Anyway... just one more before I go. I think I agree with you with
there's no "wrong" here. But I'll add that there is definitely
"better". And, I say, that the range definition of pair<T*,T*>
is definitely *not* better.

I'm not caring too much because we are all too accustomed to using
a general representation for "something". We use int to specify
all sorts of things and act on the data depending on the context.
We supply ints as length arguments, as width, as age, etc. The
same is happening with pair. It is used to specify different sorts
of data. It so happens that in the case of Boost.Range, it is
used to specify iterator_ranges. That's fine. But, we all know
that that is error prone. We have come a long way. We've designed
libraries like Quan to help in avoiding mis-representations of
general types like int. Your "Dimensional Analysis" article discusses
the very reasons why "numbers being manipulated don't stand alone".
I'd say that the very essence of your article also applies to generic
data types like pair. While this works:

     typedef pair<int, int> point;

This is definitely better:

     struct point { /*...*/ pair<int, int> coords; };

The latter prevents you from shooting yourself in the foot by
making sure that you are really dealing with points and not
some other pair of ints that structurally looks like a point
(i.e. has 2 ints). Having a pair of 2 ints alone does not
constitute a point. Well, it can, but I can't say that a design,
using such an approach, is good.

IOTW, pair<T*,T*> used as an iterator_range loses one important
aspect inherent in good design: type checking.

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk