What guarantees does D 'const' provide, compared to C++?

Mehrdad wfunction at hotmail.com
Thu Aug 16 19:55:09 PDT 2012


On Friday, 17 August 2012 at 02:33:46 UTC, Chris Cain wrote:
> 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)

Thanks... I promise I'm not >__< I'm just having trouble seeing 
what guarantees anyone is getting.



> 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:

Ok thanks for trying again. :)


> 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.

Yup, just like in C++.


> 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.

Yup, so far so good.


> y is your const view of your data. No matter how hard you try 
> (without casts), you can't mutate y.

Yup.


> You _can_ mutate x, which y is viewing. The y view updates 
> accordingly, but you didn't mutate y.

Yup.


> 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

Nope, not what I said. :)


> 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.

Yes, I already understood this, and I'm pretty sure I still do.




What you're saying, I understand.

What is seems to be missing is the answer to my question:

What _guarantees_ can the compiler make about your code, /based/ 
on the fact that y is a const view, or that the entire struct is 
const?


You keep on telling me that y is a const view, which, obviously, 
it is.

But the question is: why is that useful, compared to C++?

e.g. What kind of a guarantee can a D compiler make about code 
that calls a const method, which a C++ compiler probably wouldn't 
be able to?



> 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.


"Hacking around", I guess you could put it. :-D
As well as trying to clarify things for other people who might 
have the same questions as well (which I'm sure they would).

> 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.


It's not a question about misuse, it's a question about 
guarantees. The compiler simply _isn't_ allowed to do something 
that works for 99% of code, while breaking that 1% that misuses 
it (but is legal).

i.e. It's a code generation issue, not a misuse issue.



> (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.)



Well ok, nice speaking with you then. :)


More information about the Digitalmars-d mailing list