From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-16 06:40:03
Tobias Schwinger wrote:
> Douglas Gregor wrote:
>> pair: I tripped over the name of this entity a bit. It's a little
>> odd to have a "pair" with only one kind of data. I guess I'd feel
>> better if this were called "keyed_value" or "key_value", because
>> it's easier for me to copy with a typed key than it us for me to
>> have a pair that's very different from std::pair.
> I had a similar feeling about the "half runtime pair" when reading the
> documentation. After a deeper look and actually using the library, my
> scepticism vanished, however, because:
> When writing Fusion algorithms there are in fact two control paths to
> take care about: the template instantiations and the runtime behaviour.
> I experienced that it makes sense to work out the compile time path
> first, which is the point where the data structures are chosen.
> In the compile time world, Fusion pairs are just pairs ;-).
> Using "keyed_value" for e.g. the state with fusion::fold seems
> misleading to me, while using a "pair" makes a lot of sense.
> The only difference between the Fusion and STL pair concept is the
> 'first' member variable. The current name reflects these conceptual
Yet another frame thought that I've come to consider recently is
to altogether discard the notion of "half runtime pair" and simply
gravitate towards std::pair or any structure that conforms to the
STL concept. For typical uses of fusion::map, for example, one can
simply use boost::compressed_pair which automatically optimizes
away the key or the data part (typically the key). The disadvantages
of this approach are:
1) boost::compressed_pair is needlessly more expensive (at compile
time) than fusion::pair
2) The key type cannot be forward declared.
-- 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