Unofficial wish list status.(Jul 2008)

[Steven Schveighoffer]

"Don" wrote
> Steven Schveighoffer wrote:
>> With invariant functions, what you are defining is a contract for that 
>> member function.  The contract states that the object passed to the 
>> function as the 'this' pointer must be invariant.  Let's not forget that 
>> member functions are simply functions which require you to pass the 
>> object.  The only 'special' part of it is the way you write the function 
>> call.
>
> There's another difference. The person writing a member function is always 
> the same person who wrote the class. They've made a conscious design 
> decision that this class can be used as an invariant class (Not all 
> classes can be used in this way, in fact most cannot).

Any class that has const functions can be used as an invariant.

>> There is no reason you need to define multiple classes.  You are just 
>> defining more functions that take a different argument type as the 'this' 
>> pointer.  I don't see why it's so confusing to define those functions in 
>> the same class as the mutable functions.
>
> My gut feel is that mixing mutable and invariant functions in the one 
> class would be an indication of poor design. Which is why I'd be very 
> interested in use cases.

What about building an invariant lookup table dynamically?  First you use 
the mutable methods to build the table, then you mark it as invariant so you 
no longer have to synchronize.

I can see someone using such a table in another part of the code in a 
mutable state, so why repeat all the code for that lookup object?

You could put the common parts of code in unsynchronized const private 
functions, and then the synchronization in the public const API.

-Steve