On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
In C++, if you have
const vector<T*>& getStuff() const;
which returns a member variable, then as long as const isn't
cast away, you know that the container itself won't have any
elements added or removed from it, but you have _zero_
guarantees about the elements themselves.
Right.
In contrast, in D,
const ref Array!(T*) getStuff() const;
you would _know_ that not only is the container not altered,
but you know that the elements aren't altered either -
or anything which the elements point to.
I'm not so sure about that.
int yourGlobalCounter;
struct MyIntPtrArray
{
int*[] items;
MyIntPtrArray()
{
items = new int*[1];
items[0] = &yourGlobalField;
}
ref const(int*[]) getItems() const
{
++yourGlobalCounter;
return items;
}
}
And since casting away const and mutating a variable is
undefined behavior,
That is either vague, or contradicts what I was told above.
We all know casting away a const _object_ is undefined behavior
in both D and C++.
However, is casting away a const __reference__ undefined behavior
in D? (It's not in C++.)
> The compiler will guarantee you aren't changing data that is
> const.
Right, but it's the same with C++, right? Where's the
difference?
C++ makes no such guarantees, because you're free to cast away
const and modifiy objects
Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_
objects.
If the object happens to have been const _itself_, then that's
undefined behavior.
and because objects can have members marked with the mutable
keyword.
Right, it's the equivalent of static fields, see my example above.
> On the note of casting away const, I don't believe that is
> the operation which is undefined, however modifying const is
> undefined as it could be pointing to immutable data.
Oh, then that's not what I'd understood. Seems just like C++
then.
No. Casting away const and modifying an object is well-defined
in C++.
Only if the object was mutable to begin with. See above.
const is useful even without purity, because you _know_ that
nothing which is const can change unless you access it through
a non-const reference
Yeah, and as I just showed, aliasing messes this up just as badly
as in C++. See above.
Now, it _does_ get far better once purity is added into the mix
And of course, immutable offers even better guarantees
Yup, I agree about those; I'm just referring to const here.
