On Dec 7, 2012, at 12:01 PM, Jordan Rose <[email protected]> wrote:
> This broke the build for me; it's not const-correct. Moreover, it's really
> not const-correct. A const ImmutableMapRef is the same as a const
> ImmutableMap::Factory: it means you're not going to try to generate new maps
> from it.
It's const because the data structure itself does not change. That seems worth
capturing with 'const'. The underlying factory object mutates, but that seems
reasonable to me.
Suppose I had written...
ImmutableMapRef remove(key_type_ref K) const {
TreeTy *NewT = Factory->remove(Root, K);
return ImmutableMapRef(NewT, Factory);
}
as:
ImmutableMapRef remove(key_type_ref K, FactoryTy *Factory) const {
TreeTy *NewT = Factory->remove(Root, K);
return ImmutableMapRef(NewT, Factory);
}
That is essentially functionally the same thing. The factory is really an
implementation detail. 'const' does not mean that a method does not mutate
state anywhere. In this case, I'm saying that the data itself does not mutate,
which is true. This allows important optimizations. For example, it allows us
to bind a const & to an ImmutableMapRef and still use add and remove.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
