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

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

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.

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.

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

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

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

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.

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

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.