Right. You can get around const with casts too.
But why would const or initonly be used on variables one wants to change
later?
I guess I missed the original point of the thread.
My point was just that initonly works as documented.
Mark

Signature
Mark Salsbery
Microsoft MVP - Visual C++
>>> Right. I see what you mean, but from the readonly (C#) docs:
>>>
[quoted text clipped - 27 lines]
> void doit() { /* b[0] = false; */ array<bool>^ bprime = b; bprime[0] =
> false; }
> Right. You can get around const with casts too.
> But why would const or initonly be used on variables one wants to change
> later?
What cast? There is no cast.
The reference marked as initonly is not being changed, it always holds the
address of the same object. The data within that object could change. This
could, for example, allow a gc optimization because the lifetime of the two
objects are equal and therefore the objects needn't be tracked separately.
> I guess I missed the original point of the thread.
> My point was just that initonly works as documented.
Perhaps, but it functions differently than native C++ const or C# readonly,
and the behavior makes no sense. If an initonly reference is supposed to
point to an immutable object, then it should carry the initonly attribute on
the referred-to type and not be lost without a const_cast. It then would
look like this:
array<initonly bool>^ b;
But that makes no sense, because it raises the question "Which constructor
is allowed to change the value?"
If you have
array<bool>^ initonly b;
then it is only natural to be able to
b[0] = false;
> Mark
>
[quoted text clipped - 30 lines]
>> void doit() { /* b[0] = false; */ array<bool>^ bprime = b; bprime[0] =
>> false; }
Mark Salsbery [MVP] - 28 Nov 2007 21:04 GMT
>> Right. You can get around const with casts too.
>> But why would const or initonly be used on variables one wants to change
[quoted text clipped - 13 lines]
> Perhaps, but it functions differently than native C++ const or C#
> readonly,
Right. My original point was that comparing two different keywords from two
different languages was irrelevant, no matter how many articles or other
people say they are the same..
> and the behavior makes no sense.
Now that I'm following the theme of the thread, I agree 100% :)
Thanks Ben!
Mark
>If an initonly reference is supposed to point to an immutable object, then
>it should carry the initonly attribute on the referred-to type and not be
[quoted text clipped - 14 lines]
>
>> Mark