Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-02-15 10:25:06

Joel de Guzman <joel_at_[hidden]> writes:

> Larry Evans wrote:
>> On 02/15/2005 08:08 AM, Larry Evans wrote:
>> [snip]
>>>> Yes, it is a non-member function. No, it does not mutate s.
>>>> It does return another set. It is purely functional (no side-
>>>> effects).
>> Then it's different from tuple<T1,...,Tn> since any mutating
>> operation Ti::op on an instance of Ti can be performed on the
>> corresponding member variable in an instance of tuple<T1,...,Tn>?
> I don't understand what you are saying.
>> See
>> /field_sets.hpp for an example of what I had thought you were
>> talking about here:
>> > fusion::vector, fusion::list, fusion::set and fusion::map
>> > all have data. These are different incarnations of the
>> > tuple with different characteristics.
>> when you said fusion::set had data. Having data implies, at least
>> to me, that the data can be modified.
> I do not understand why we are having an impedance mismatch here.
> It seems to me that we're in different universes. I do not even
> understand why this matters at all. Having data *does not* imply
> that the data is mutable. It can be const, for example. Or, in
> purely functional terms, you do not wish to have side-effects.
> Still, the data is there, in real bits and bytes.

And in fact it can be mutated, at least in most fusion structures.
It's the _structure_ that can't be mutated. Just like boost::tuple.
You can change the elements, but you can't change their number and
type (in-place).

Dave Abrahams
Boost Consulting

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