Re: Confused about const
bearophile Wrote: > Paul D. Anderson: > > > After further review, I now realize that the right way (for me) to do this > > is to add a .dup property.< > > Steven Schveighoffer has given you quite good answers. > A dup is generally not enough, because what you dup can have other immutable > references nested inside. Dup is not a deep copy. > The summary of this topic is (until inout works) that if you can return a > const value, then don't copy things. This is the preferred option, because > one of the main purposes of const data is to not have to copy them. > If you can't return a const, then don't mark the input values as const. The > safety given by the not deep const of Java is only partial safety. > > Bye, > bearophile You're right that dup itself can have problems with pointers/references. My struct doesn't have 2nd-level references, so dup works fine for me. Paul
Re: Confused about const
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. :)
Re: Confused about const
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
Re: Confused about const
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 avoid wrong usages of the operator overloading.) 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.
Re: Confused about const
Paul D. Anderson: > After further review, I now realize that the right way (for me) to do this is > to add a .dup property.< Steven Schveighoffer has given you quite good answers. A dup is generally not enough, because what you dup can have other immutable references nested inside. Dup is not a deep copy. The summary of this topic is (until inout works) that if you can return a const value, then don't copy things. This is the preferred option, because one of the main purposes of const data is to not have to copy them. If you can't return a const, then don't mark the input values as const. The safety given by the not deep const of Java is only partial safety. Bye, bearophile
Re: Confused about const
After further review, I now realize that the right way (for me) to do this is
to add a .dup property. So instead of
S foo(const S s) {
S other;
other = s;
}
or
S foo(const S s) {
S other = S(s);
return other;
}
which didn't look right to me, I can write
S foo(const S s) {
S other = s.dup;
return other;
}
which is ultimately an equivalent operation.
Thanks again, everyone for taking the time to explain what was going on.
Paul
It just looks better to me.
Paul D. Anderson Wrote:
> bearophile Wrote:
>
> > 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
>
>
> So I understand better now, thanks, what is wrong. I'm a little disappointed
> that there is apparently no way to implement case 4 for any struct with a
> reference.
>
> Paul
Re: Confused about const
On Fri, 19 Mar 2010 20:58:21 -0400, 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??
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
Re: Confused about const
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
Re: Confused about const
bearophile Wrote:
> 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
Yes, thanks to you and biozic for finding the root of the problem. Here's a
piece of code that demonstrates the problem:
//-
struct S {
int x;
int[] a;
// including this postblit causes an error because the default
// constructor it applies to doesn't allow const argument.
/+this(this) {
a = a.dup;
}+/
// adding a const to the argument of this constructor allows case 2.
this(const S s) {
x = s.x;
a = s.a.dup;
}
// including or excluding this constructor doesn't change
// the compilability.
/+this( S s) {
x = s.x;
a = s.a.dup;
}+/
// an opAssign with a const argument allows case 3.
S opAssign(const S s) {
this.x = s.x;
this.a = s.a.dup;
return this;
}
// including this doesn't make a difference.
// I think this is the same as the default opAssign.
/+S opAssign(S s) {
this.x = s.x;
this.a = s.a.dup;
return this;
}+/
}
// case 1: no const. According to the spec this is
// a copy constructor in action.
S foo(S b) {
S other = b;
return other;
}
// case 2: const, but assignment requires the creation of a
// non-const S from before assignment.
S bar(const S b) {
S other = S(b);
return other;
}
// case 3: const, but creation and assignment are separate.
// this is a default construction and opAssign(const).
S foo(const S b) {
S other;
other = b;
return other;
}
// case 4:const. According to the spec this is
// a copy constructor in action, but it goes awry.
// does not compile.
S foo(const S b) {
S other = b;
return other;
}
void main() {}
/--
So I understand better now, thanks, what is wrong. I'm a little disappointed
that there is apparently no way to implement case 4 for any struct with a
reference.
Paul
p.s. Does it make any sense to send this over to the D forum to get more eyes
on the problem?
Re: Confused about const
So the question here is: do you know if there are important use cases for a shallow_const attribute? Bye, bearophile
Re: Confused about const
> Transitive const requires transitive copy, it's easy :-) Or when possible, you don't copy it, just return it. Bye, bearophile
Re: Confused about const
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
Re: Confused about const
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
Re: Confused about const
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
Re: Confused about const
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.
Re: Confused about const
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
Re: Confused about const
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
Confused about const
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
