On 07/10/2012 01:57 AM, Geoffrey Biggs wrote:
On 10 July 2012 01:02, Timon Gehr<timon.g...@gmx.ch> wrote:
...
2.
- hash table
- opApply compacts the table if it is occupied too sparsely, in order
to speed up further iteration.
- toString iterates over all key/value pairs by the means of opApply.
Clearly, toString cannot be const in this setup.
...
I am not talking about code quality. I am talking about code
maintainability, extensibility and performance.
Although I don't know what D's goals with const are, in C++,
const-correctness is often considered from the perspective of outside
the interface. A const member function guarantees that, from the point
of view of an entity using the object, its state will not change. This
does not guarantee that data stored in the object is not changing.
This allows for things like storing cached values. Unfortunately,
implementing this is more difficult than it might sound, e.g. in cases
such as #2 above, particularly if you also want the compiler checking
that the const keyword can allow (which you should).
See here for more information:
http://www.parashift.com/c++-faq-lite/mutable-data-members.html
Geoff
Exactly! I don't think that the term 'const correctness' actually
has a meaning in D. It is a C++ term.
