Boost logo

Boost :

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:
> 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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at