www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Confused about const

reply Paul D. Anderson <paul.d.removethis comcast.andthis.net> writes:
I created a struct, call it "S", and some functions that operate on S. But I'm
confused about when const is useful.

Being an old Java programmer, I use 'const' the same as I used 'final' in Java.
So most of my functions look like this:

S for(const S a, const S b) {
    S x = a;
    S y = b;
    // do some stuff
    return a;
}

I declare the parameters const and then copy them to work on them.

I get error messages about not implicitly casting const S to S. So I can make
an explicit cast:

    S x = cast(S) a;
    S y = cast(S) b;

and the error messages go away.

But I think I must have gone off the rails somewhere -- all I want is for the
caller to be sure the function doesn't alter a and b. But I end up with lots of
casts to/from const. What am I missing??

Paul
Mar 19 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:

 I created a struct, call it "S", and some functions that operate on S. But I'm
confused about when const is useful.
 
 Being an old Java programmer, I use 'const' the same as I used 'final' in
Java. So most of my functions look like this:
 
 S for(const S a, const S b) {
     S x = a;
     S y = b;
     // do some stuff
     return a;
 }
 
 I declare the parameters const and then copy them to work on them.
 
 I get error messages about not implicitly casting const S to S.

This program compiles: struct S { int x; } S foo(const S a) { S other = a; return other; } void main() {} So, what's that you actually write? When possible show programs that run! It's one of the things I have learnt from the Python groups. Bye, bearophile
Mar 19 2010
parent reply Paul D. Anderson <paul.d.removethis comcast.andthis.net> writes:
bearophile Wrote:

 Paul D. Anderson:
 
 I created a struct, call it "S", and some functions that operate on S. But I'm
confused about when const is useful.
 
 Being an old Java programmer, I use 'const' the same as I used 'final' in
Java. So most of my functions look like this:
 
 S for(const S a, const S b) {
     S x = a;
     S y = b;
     // do some stuff
     return a;
 }
 
 I declare the parameters const and then copy them to work on them.
 
 I get error messages about not implicitly casting const S to S.

This program compiles: struct S { int x; } S foo(const S a) { S other = a; return other; } void main() {} So, what's that you actually write? When possible show programs that run! It's one of the things I have learnt from the Python groups. Bye, bearophile

My struct has a dynamic array as a member -- that seems to be the problem. This code doesn't compile: struct S { int x; int[] a; } S foo(const S b) { S other = b; return other; } void main() {} FYI, I'm using DMD version 2.30.
Mar 19 2010
next sibling parent reply biozic <dransic free.fr> writes:
My guess is that:

 struct S {
   int x;
   int[] a;
 }

 S foo(const S b) {

foo makes the promise that b's members won't change: so 'b.x' is implicitely const(int) and 'b.a' is implicitely const(int[]).
      S other = b;

Here you assign 'b.x', which is const(int), to 'other.x', which is int. You can assign an const(int) to an int: after the value is copied, changing 'other.x' won't change 'b.x'. But then you assign 'b.a', which is const(int[]), to 'other.a' which is int[]. This is forbidden: this would copy the reference to the array from 'b' to 'other', and after the copy, you would be able to change the content of 'b.a' by changing the content of 'other.a', thus going against const. I'm not sure if this is completely right nor if I'm completely clear, though... :) Nicolas
Mar 19 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
biozic:
 I'm not sure if this is completely right nor if I'm completely clear, 
 though... :)

I think you are right. In practice to copy something const to something that's not const you need a deep copy function, because inside the array there can be other arrays that are const, etc. Transitive const requires transitive copy, it's easy :-) Bye, bearophile
Mar 19 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
 Transitive const requires transitive copy, it's easy :-)

Or when possible, you don't copy it, just return it. Bye, bearophile
Mar 19 2010
parent bearophile <bearophileHUGS lycos.com> writes:
So the question here is: do you know if there are important use cases for a
shallow_const attribute?

Bye,
bearophile
Mar 19 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:
 My struct has a dynamic array as a member -- that seems to be the problem.
This code doesn't compile:
 
 struct S {
  int x;
  int[] a;
 }
 
 S foo(const S b) {
     S other = b;
     return other;
 }
 void main() {}

This compiles, oh joy: struct S { int x; int[] a; } S foo(const S b) { S other; other.x = b.x; other.a = b.a.dup; // the dup is necessary here return other; } void main() {} The idea now is to find a way to encapsulate that manual copying & dupping into some overloaded operator of S. But I have failed so far. Operator overloading in D2 is not an easy thing, it needs training. (That's why I have recently asked for the compiler to be strict to avoid wrong usages of the operator overloading.) Bye, bearophile
Mar 19 2010
parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Operator overloading in D2 is not an easy thing, it needs training. 
(That's why I have recently asked for the compiler to be strict to 

I think the problem is really that it's still very buggy. In particular, opAssign seems pretty defective. More importantly, struct constructors, post blit, and struct destructors are still quite badly broken.
Mar 20 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Don:
 I think the problem is really that it's still very buggy. In particular,
 opAssign seems pretty defective. More importantly, struct constructors, 
 post blit, and  struct destructors are still quite badly broken.

You are right, but in my opinion it's not just a matter of bugs. To solve real world problems (like bugs in code) you usually have to attack the problems from many sides at the same time. So once: - the op overloading design is not too much bug-prone; - such parts of D are debugged; - the compiler performs several sanity tests on the operators defined by the programmer (even if this means disallowing few legit corner cases) Then D2 op overloading can be safe enough to use :-) Bye, bearophile
Mar 20 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:
     S x = cast(S) a;
     S y = cast(S) b;

In Java (especially old Java) casts may be common, but in D they are something that has to be used with care, don't cast away things carelessly :-) Bye, bearophile
Mar 19 2010
parent Paul D. Anderson <paul.d.removethis comcast.andthis.net> writes:
bearophile Wrote:

 Paul D. Anderson:
     S x = cast(S) a;
     S y = cast(S) b;

In Java (especially old Java) casts may be common, but in D they are something that has to be used with care, don't cast away things carelessly :-) Bye, bearophile

I realize that casting is a last resort -- but it seemed to be the only thing that worked. That's what made me think I'm making some sort of fundamental mistake. Paul
Mar 19 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 19 Mar 2010 20:58:21 -0400, Paul D. Anderson  
<paul.d.removethis comcast.andthis.net> wrote:

 I created a struct, call it "S", and some functions that operate on S.  
 But I'm confused about when const is useful.

 Being an old Java programmer, I use 'const' the same as I used 'final'  
 in Java. So most of my functions look like this:

 S for(const S a, const S b) {
     S x = a;
     S y = b;
     // do some stuff
     return a;
 }

 I declare the parameters const and then copy them to work on them.

 I get error messages about not implicitly casting const S to S. So I can  
 make an explicit cast:

     S x = cast(S) a;
     S y = cast(S) b;

 and the error messages go away.

 But I think I must have gone off the rails somewhere -- all I want is  
 for the caller to be sure the function doesn't alter a and b. But I end  
 up with lots of casts to/from const. What am I missing??

I'll try to help, const is a very complex thing to understand. However, what it provides is so valuable for interface design that it is worth learning. One thing to remember that const is transitive. This means that if S contains a pointer to something, you have to treat that pointer as if it were const too. This is a difference from Java's final. If S has a pointer or reference, then a const S cannot be copied to a mutable S because you can then change the data through the mutable reference without any casts. I'll give you an example: struct S { int *a; } void foo(const(S) s) { S s2 = s; // this fails to compile because of the possibility for the next line. *s2.a = 5; // I now just changed the value pointed to by s, which is const data! } However, if S does not have a pointer or reference, then you can copy a const S to a mutable one because then changing the mutable S does not affect the const data in the original S. example: struct S { int a; } void foo(const(S) s) { S s2 = s; // this compiles s2.a = 5; // does not change s at all. } In answer to your question, what you are missing is what const is for. When declaring a function takes a const item, you are declaring that that function will not change the argument *or* anything it references. The compiler is trying to enforce that. Casting away const breaks the compiler guarantees, so you should not do that unless you know what you are doing. So what I think is if you want to change the elements of S, or return an S parameter that is not const, then you shouldn't declare them as const parameters. One final thing -- there is a brand new feature for D2 that allows you to forward the const attributes of parameters to return values. This is under the heading "inout functions" of the documentation. This feature is not implemented properly, even in the latest compiler. However, once it does work, you can use it to declare your function like this: inout(S) foo(inout(S) a, inout(S) b) { return a; } What this means is, during the foo function, it will not modify a or b, but once it returns, the return value has the same constancy as the parameters. It basically means "the const you put in is the const you get out." -Steve
Mar 19 2010
prev sibling parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 03/20/2010 01:58 AM, Paul D. Anderson wrote:
 I created a struct, call it "S", and some functions that operate on S. But I'm
confused about when const is useful.

 Being an old Java programmer, I use 'const' the same as I used 'final' in
Java. So most of my functions look like this:

 S for(const S a, const S b) {
      S x = a;
      S y = b;
      // do some stuff
      return a;
 }

 I declare the parameters const and then copy them to work on them.

 I get error messages about not implicitly casting const S to S. So I can make
an explicit cast:

      S x = cast(S) a;
      S y = cast(S) b;

 and the error messages go away.

 But I think I must have gone off the rails somewhere -- all I want is for the
caller to be sure the function doesn't alter a and b. But I end up with lots of
casts to/from const. What am I missing??

 Paul

I think you misunderstand const. If you flag an argument with const it means you're unable to ever change anything reachable from that argument, so if you have a const reference, you can not alter anything reachable from that reference. If you have this: struct S { int[] xs; } S foo(const S s) { return cast(S)s; } void main() { S s; s.xs = [1,4,5]; S fromconst = foo(s); fromconst.xs[0] = 4; //<-- there you alter something you // should not be able to alter. } The compiler protects you from this, unless you cast your constness away. If you want to copy, you'll need to implement the proper deep copying yourself. :)
Mar 20 2010