View mode: basic / threaded / horizontal-split · Log in · Help
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
> Also, if the only view of the data you have is that const view, 
> it's effectively the same as immutable (it couldn't be changed 
> by any valid code).


So you're saying casting away a const _pointer_ is undefined, 
even if the target was originally created as mutable. (Otherwise, 
the code would certainly be "valid", just like in C++.)


Which means you can effectively _never_ cast away constness of a 
pointer/reference, no matter how certain you are about the target 
object, right?

If you did, then the code would be invalid, and the compiler 
could simply format your C: drive instead of modifying the object.

If so, then why is such an undefined cast allowed in the first 
place?
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
> He was clearly _not_ talking about modifying the pointer.
> He said you cannot alter the "elements pointed TO".
>
>
> Given that, I have no idea how that is supposed to be saying 
> "you can't modify the const _view_". He's clearly talking about 
> the target of the pointer, not the pointer itself.

I'll let Mr. Davis confirm which he was talking about. The only 
thing that's clear is that our understandings of his point differ.
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
> So you're saying casting away a const _pointer_ is undefined, 
> even if the target was originally created as mutable. 
> (Otherwise, the code would certainly be "valid", just like in 
> C++.)
>
>
> Which means you can effectively _never_ cast away constness of 
> a pointer/reference, no matter how certain you are about the 
> target object, right?
>
> If you did, then the code would be invalid, and the compiler 
> could simply format your C: drive instead of modifying the 
> object.
>
> If so, then why is such an undefined cast allowed in the first 
> place?

If you're absolutely 100% completely totally certain that the 
data is mutable (i.e., you have confirmed either through good, 
sound reasoning OR you have some method of seeing exactly where 
it is stored in your RAM and you've checked that the place it is 
stored is writable memory), then __technically__, yes you can 
cast away and modify away. Apparently, according to some, it's 
necessary for low level programming. I'd highly discourage this 
type of behavior because if you're doing something like that I'm 
nearly certain you could come up with a better design, not to 
mention you're missing the point of having something const in the 
first place.

Let's just say I wouldn't use const in a place where I'm itching 
to cast it away. If you're not going to use it to your advantage, 
there's no point.
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 01:50:02 UTC, Chris Cain wrote:
> On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
>> Isn't that kinda useless, if it tells you nothing about the 
>> object itself?
>
> Not sure what your point is. It tells you enough about how you 
> work with that "object itself"


Are you sure?



struct MyStruct
{
	static int* x;
	int y;

	this() { }
	this(int* z) { x = z; }

	auto getValue() const
	{
		++*x;
		return this.y;
	}
}

auto s = MyStruct();
s = MyStruct(&s.y);

s.getValue();  // const, but returns 1
s.getValue();  // const, but returns 2
s.getValue();  // const, but returns 3



So, effectively, the mere const-ness (and even its transitivity) 
is useless to the compiler.



> I'll let Mr. Davis confirm which he was talking about. The only 
> thing that's clear is that our understandings of his point 
> differ.

Okay sure, thanks for trying to explain it anyway!
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, August 17, 2012 03:52:38 Chris Cain wrote:
> On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
> > He was clearly _not_ talking about modifying the pointer.
> > He said you cannot alter the "elements pointed TO".
> > 
> > 
> > Given that, I have no idea how that is supposed to be saying
> > "you can't modify the const _view_". He's clearly talking about
> > the target of the pointer, not the pointer itself.
> 
> I'll let Mr. Davis confirm which he was talking about. The only
> thing that's clear is that our understandings of his point differ.

If you have a const object, then you have the guarantee that none of what it 
contains or refers to either directly or indirectly can be altered through 
that reference or pointer. It's possible to alter it via other references, and 
without pure, const functions called on that object may still be able to alter 
by using global variables, but you do have the guarantee that that object and 
anything and everything that it refers to won't be directly mutated by that 
reference.

- Jonathan M Davis
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, August 17, 2012 03:51:36 Mehrdad wrote:
> On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
> > Also, if the only view of the data you have is that const view,
> > it's effectively the same as immutable (it couldn't be changed
> > by any valid code).
> 
> So you're saying casting away a const _pointer_ is undefined,
> even if the target was originally created as mutable. (Otherwise,
> the code would certainly be "valid", just like in C++.)
> 
> 
> Which means you can effectively _never_ cast away constness of a
> pointer/reference, no matter how certain you are about the target
> object, right?
> 
> If you did, then the code would be invalid, and the compiler
> could simply format your C: drive instead of modifying the object.
> 
> If so, then why is such an undefined cast allowed in the first
> place?

Because there are plenty of functions which take mutable objects but don't 
actually alter them - particularly when interacting with C code. It's the sort 
of thing that you really shouldn't be doing normally but on rare occasions is 
useful - in this case when dealing with code that isn't const correct but 
still won't actually alter the object.

- Jonathan M Davis
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, August 17, 2012 03:00:34 Chris Cain wrote:
> On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
> > Also, D's const is _not_ a guarantee that there are no mutable
> > references to something. That'd be immutable.
> 
> And, by the way, I'd call this a bug (not sure if reported yet):
> 
> 
> 
> int yourGlobalCounter;
> 
> struct S
> {
> int*[] items;
> 
> this(int i)
> {
> items = new int*[1];
> items[0] = &yourGlobalCounter;
> yourGlobalCounter = i;
> }
> 
> ref const(int*[]) getItems() const
> {
> ++yourGlobalCounter;
> return items;
> }
> }
> 
> import std.stdio;
> 
> void main() {
> immutable(S) s = immutable(S)(0);
> auto it = s.getItems();
> writeln(*it[0]);
> s.getItems();
> writeln(*it[0]);
> }

How is it a bug? The variable that you're altering is not part of the object. 
That's part of why having pure with const in so valuable. It prevents stuff 
like what you're doing here.

- Jonathan M Davis
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 01:59:03 UTC, Chris Cain wrote:
> On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
>> So you're saying casting away a const _pointer_ is undefined, 
>> even if the target was originally created as mutable. 
>> (Otherwise, the code would certainly be "valid", just like in 
>> C++.)
>>
>>
>> Which means you can effectively _never_ cast away constness of 
>> a pointer/reference, no matter how certain you are about the 
>> target object, right?
>>
>> If you did, then the code would be invalid, and the compiler 
>> could simply format your C: drive instead of modifying the 
>> object.
>>
>> If so, then why is such an undefined cast allowed in the first 
>> place?
>
> If you're absolutely 100% completely totally certain that the 
> data is mutable (i.e., you have confirmed either through good, 
> sound reasoning OR you have some method of seeing exactly where 
> it is stored in your RAM and you've checked that the place it 
> is stored is writable memory), then __technically__, yes you 
> can cast away and modify away.





If doing so is "invalid" (i.e. undefined?) like you mentioned, 
no, you can't, because the compiler can't guarantee it can 
respect your assumptions and generate otherwise-correct code.

If it IS valid, then it seems to me like the situation is the 
exact same with C++.
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
> How is it a bug? The variable that you're altering is not part 
> of the object.


It doesn't need to be.


What you said was:



> If you have a const object, then you have the guarantee that 
> none of what it contains or refers to ____either directly or 
> indirectly_____ can be altered through that reference or 
> pointer.


But as I just showed, it can, so... yeah.



> That's part of why having pure with const in so valuable.

Right, but purity is another topic. :)
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
> Because there are plenty of functions which take mutable 
> objects but don't actually alter them - particularly when 
> interacting with C code.



Ah, so that explains that, thanks.

So to clarify, modifying a mutable object through casting away a 
const reference is undefined in D, but valid in C++.

Now the only question is what guarantees that actually gives you 
that the compiler can use for optimization (aliasing issue 
above^).
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home