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 04:25:42 UTC, Chris Cain wrote:
> On Friday, 17 August 2012 at 04:17:33 UTC, Mehrdad wrote:
>> Okay so basically, the conclusion I'm drawing is that you have 
>> to combine it with pure/immutable in order to get much more 
>> out of it than compared with C++; otherwise, it's not really 
>> different.
>>
>> Thanks!
>
> You posted this before seeing the additional clarifications Mr. 
> Davis and I posted, and I understand that, but I just wanted to 
> say that factoring what we both said I think it's clear that it 
> is really different. Not bulletproof (I'd say const + pure 
> would be nearly bulletproof and immutable + pure would truly be 
> bulletproof if you started considering multi-threading), but 
> certainly better than C++.

Yup, I saw the difference after his post as well. :)
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
> On Friday, 17 August 2012 at 02:14:22 UTC, Jonathan M Davis 
> wrote:
>> What I meant is that you know that nothing was altered through 
>> the reference that the getter returned. You don't have any 
>> such guarantee in C++.

Please reread what Jonathan has written above and look at my 
example below:

struct MyStruct
{
   static int* x;
   int* y;
   int z;
   this(int* z) { x = z; }
   auto getValue() const { ++*x; return this.y; }
}

void main() {
   auto s = MyStruct();
   s.y = &s.z;
   auto r = MyStruct(s.y);
   r.y = r.x;
   r.getValue();  // const, but returns 1
   r.getValue();  // const, but returns 2
   r.getValue();  // const, but returns 3

   auto m = r.getValue();
   *m = 5; // test.d(21): Error: *m is not mutable
}
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On 8/16/2012 5:51 PM, Torarin wrote:
> The C++ standard, section 7.1.6.1:
>
> Except that any class member declared mutable (7.1.1) can be modified,
> any attempt to modify a const
>   object during its lifetime (3.8) results in undefined behavior.


That applies to a "const object", i.e. an object declared as const:

   const int x;

It does not apply to a non-const object. If you've got a pointer-to-const, and 
it points to a non-const object, you can legitimately cast away the const-ness, 
and modify it.

Such is not undefined behavior.

Check 5.2.11.

The crux of the matter is C++'s use of the word "const" to sometimes mean a 
storage class and sometimes a type constructor, and it takes some careful 
reading of the spec to pick apart the two.

In D, const is always a type constructor, and casting away const and then 
modifying the resulting object is undefined behavior, whether or not the 
original object was const or mutable.
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On 8/16/2012 6:43 PM, Mehrdad wrote:
> On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
>> Yeah. Again, you can't modify __the const view__.
>
> Isn't that kinda useless, if it tells you nothing about the object itself?

It means you can write code that can process both mutable and immutable objects.
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:
> If you did, then the code would be invalid, and the compiler 
> could simply format your C: drive instead of modifying the 
> object.

This is probably the worst discussion point when people talk of 
why undefined behavior is bad.

It is true in that you won't know what happens when in an 
undefined state, but it is false in that, if it formats your C 
drive then ~you'd have to be running Windows~, that would be 
defined behavior and the spec would have said "Implementation 
Defined"

Which actually brings another point "Implementation Defined" is 
then just as bad as Undefined because the compiler can do 
whatever it wants! (And yes I know it is bad too).

The reason it is left undefined is because either it would have 
to be prevented by the compiler, or some other change to the 
specification would have to be made in order to define the 
behavior (which would be an addition not desired).

In the case of D, we define casting, thus you can cast away 
const. But after that the compiler holds no record it was const, 
nor does it make any attempt to move the data into read only 
memory, and thus, if the variable is located in writable memory 
it can be changed.

The question you are asking I do not have an answer for. I will 
try repeating it here in case it clarifies for them.

Without the presence of immutable/pure, what can the compiler do 
with code that is marked as const that improves performance which 
is not done in C++. (Actually I'd like to know those which C++ 
preforms too).
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 21:25:31 UTC, Jesse Phillips wrote:
> On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
>> If you did, then the code would be invalid, and the compiler 
>> could simply format your C: drive instead of modifying the 
>> object.
>
> This is probably the worst discussion point when people talk of 
> why undefined behavior is bad.

I recommend reading these (all three, not just the first one), if 
you haven't already:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html


> It is true in that you won't know what happens when in an
undefined state, but it is false in that, if it formats your C
drive then ~you'd have to be running Windows~, that would be
defined behavior and the spec would have said "Implementation
Defined"

No, you're completely missing the point.
"Implementation defined" and "undefined" are different terms, 
defined in the C++ standard. Go look them up. (I used to think 
like you as well, until I was corrected.)



> Which actually brings another point "Implementation Defined" is 
> then just as bad as Undefined because the compiler can do 
> whatever it wants! (And yes I know it is bad too).

I used to think like you too...

Implementation defined means "we don't tell you what it means, 
but the implementation will define it, and you can rely on 
getting sensible behavior out of it".

Undefined means "we don't tell you what it means, and we don't 
really expect the implementation to tell you, either, so unless 
the implementation tells you otherwise, if you run into it, your 
program will be meaningless".
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright wrote:
> On 8/16/2012 6:43 PM, Mehrdad wrote:
>> On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
>>> Yeah. Again, you can't modify __the const view__.
>>
>> Isn't that kinda useless, if it tells you nothing about the 
>> object itself?
>
> It means you can write code that can process both mutable and 
> immutable objects.

I meant from a C++/D comparison standpoint...
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On 8/17/2012 2:34 PM, Mehrdad wrote:
> On Friday, 17 August 2012 at 20:46:02 UTC, Walter Bright wrote:
>> On 8/16/2012 6:43 PM, Mehrdad wrote:
>>> On Friday, 17 August 2012 at 01:25:18 UTC, Chris Cain wrote:
>>>> Yeah. Again, you can't modify __the const view__.
>>>
>>> Isn't that kinda useless, if it tells you nothing about the object itself?
>>
>> It means you can write code that can process both mutable and immutable objects.
>
> I meant from a C++/D comparison standpoint...

I don't know what you're driving at.
August 17, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 22:05:56 UTC, Walter Bright wrote:
> I don't know what you're driving at.

Sorry... I tried to put it in the title. :\
August 18, 2012
Re: What guarantees does D 'const' provide, compared to C++?
On Friday, 17 August 2012 at 21:33:28 UTC, Mehrdad wrote:
> On Friday, 17 August 2012 at 21:25:31 UTC, Jesse Phillips wrote:
>> On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
>>> If you did, then the code would be invalid, and the compiler 
>>> could simply format your C: drive instead of modifying the 
>>> object.
>>
>> This is probably the worst discussion point when people talk 
>> of why undefined behavior is bad.
>
> I recommend reading these (all three, not just the first one), 
> if you haven't already:
>
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

He did not make his case on what of undefined behavior allows him 
to format your hard drive. Instead it just gives some good 
examples for what I am talking about.

void contains_null_check(int *P) {
  int dead = *P; // Compiler sees dereference
  if (P == 0) // Dereference indicates that you can't reach here 
if null
    return;
  *P = 4;
}

At no point does the compiler know you have enacted undefined 
behavior. Why? because does not have the information and is not 
permitted to insert extra information that when P is null do...

>> It is true in that you won't know what happens when in an
> undefined state, but it is false in that, if it formats your C
> drive then ~you'd have to be running Windows~, that would be
> defined behavior and the spec would have said "Implementation
> Defined"
>
> No, you're completely missing the point.
> "Implementation defined" and "undefined" are different terms, 
> defined in the C++ standard. Go look them up. (I used to think 
> like you as well, until I was corrected.)

I am not missing the point, though it seems there is also 
"Unspecified"

http://stackoverflow.com/a/4105123/34435

I am in agreement that the behavior of executing the code could 
be a formating of the hard drive. However I do not agree that it 
is the compiler which can cause this to happen an still conform 
to the specification. There are other aspects to the 
specification that would restrict the compilers ability to insert 
arbitrary code. Undefined behavior is usually identifiable at 
runtime, the compiler only has compile time information.
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home