Michiel Helvensteijn wrote:
Walter Bright wrote:
immutable - data that cannot change or be changed (imagine it is stored
in ROM)
const - read only view of data, you cannot change it but others can
enum - compile time constant, has no storage
The only place these overlap is in the declaration of symbolic
constants. C++ has all three, but in a way that is context dependent
that very few people are aware of.
Aren't immutable and enum the same thing? At least to the programmer?
Well you can build an immutable list.
* structs, classes
structs are value types, classes are reference types. That's a
fundamental distinction, not two ways to do the same thing. A lot of
confusing problems with C++ code stem from attempting to use a struct
(or class!) both ways, or trying to give it characteristics of both.
But in C++ you can put a class object on the stack with value semantics,
just as you can put a struct object on the heap. No problem, really. Stack
is default. For the heap, all you need is a pointer.
Personally I hate Java style reference semantics (a.k.a. heap without
pointers). Especially because they also offer a small set of value types,
to confuse matters. Now here's D doing the same thing.
So the solution in D would then be to always use struct? No, because value
semantics seems to come at the price of inheritance. Why? C++ seems to
handle inheritance in value types just fine.
I think C++ does not handle inheritance in value types all that well, in
fact the way it deals with the collision is pretty gruesome. It's all
dark corners and dangers and caveats and puzzling behavior. There's only
one place when anyone would seriously want something to be a value and a
reference simultaneously, and that's exception classes. And those are
tricky. I've never seen any correctly designed exception hierarchy in
C++, starting with the standard exceptions. The fact that D requires one
more allocation to throw an exception is IMHO a very small compromise.
Andrei
