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:
1.
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.
2.
The only difference between the Fusion and STL pair concept is the 'first' member variable. The current name reflects these conceptual similarities.
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. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net