On Friday, 17 August 2012 at 02:01:11 UTC, Mehrdad wrote:
...snip...
Are you sure?
I've already responded to something that is equivalent to what
you just posted. I'm not sure if you're intentionally being
obtuse (I'll give you the benefit of the doubt) or if your eyes
are glossing over when you get to the important parts of my
posts, but in either case I don't feel like repeating myself
again. For your benefit, I'm repeating myself as clearly as I can:
Const is basically a view of your data. If you have something
that's const, it's like looking through a filter that only allows
you to do certain things. It is _not_ a guarantee that it's the
only view of your data that exists in the universe. Your code,
again, shows that you have two views of your memory. x is a
mutable view of your data, and you're mutating it. y is your
const view of your data. No matter how hard you try (without
casts), you can't mutate y. You _can_ mutate x, which y is
viewing. The y view updates accordingly, but you didn't mutate y.
Maybe in a second you'll say "oh, but that's mutating y" and I'll
promptly ignore you completely this time because you've yet again
missed the point:2
You mutated x, not y, y is a view on the same data that x is so
mutating x would logically have y's view updated since const
isn't a guarantee that you only have one view of the data and
thus blah blah blah ... would be my ad infinitum response.
Let me point this out: It's there to give you guarantees and ways
to think about your code and to allow you to use the same code
for mutable and immutable data. That's it. There's no magic
behind it that you're not getting. The idea is that if you want
those particular features in your code and you know you can use
them effectively, then you use const. Generally, if you want the
same code to work on mutable data and immutable data, then you
have to use const. It's a bridge that allows the same code to
work with either type. You can use this so that you reduce code
duplication (and work for you) or/and reduce the amount of
instructions loaded in your CPU (potentially reducing the times
when your cache is reloaded) or I'm sure there's other good
reasons as well, but that's for you to figure out. It isn't a
catch all feature. Not everything needs to be bashed with the
const golden hammer of doom without any thought behind why you
might want it to be const. There's plenty of times where you
don't want to use const because it simply doesn't make sense and
it doesn't give any additional meaning to your code. But that's
okay, you just don't need to use const when it doesn't do
anything for you.
Your main problem seems to be that you're intentionally trying to
break const as hard as you can. Obviously, there's nonsensical
ways to use const, and I don't think anyone would argue that
_any_ feature is completely bulletproof to incompetence. Take
classes for instance. Do I really need to give you an example
that grossly misuses classes? Does that mean that classes have no
purpose? Should I always use structs or parallel arrays because
classes can be misused?
Instead of trying to misuse the feature, you ought to be spending
your energy trying to use the feature for your benefit.
(I'm going to make this the last post on the matter ... I'll
respond to Mr. Davis' concern on the bug in just a minute, but
I've made my full effort to explain const to you and I don't see
where additional conversation on my part can clarify this any
further.)
