David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> 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