www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Immutable fields

reply bearophile <bearophileHUGS lycos.com> writes:
Is it correct for immutable struct fields to act like enum or static const
fields? (I don't think so, but I am wrong often):

struct Foo {
    immutable int x = 1;
}
static assert(Foo.sizeof == 4);
void main() {}


More info in the D.learn thread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540

Thank you,
bearophile
Nov 02 2010
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iaqbsb$1d30$1 digitalmars.com...
 Is it correct for immutable struct fields to act like enum or static const 
 fields? (I don't think so, but I am wrong often):

immutable struct fields can be changed inside the constructor, so they must be non-static. stuct S { immutable int a; this(int b) { a = b; } }
Nov 02 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Murphy:

 immutable struct fields can be changed inside the constructor, so they must 
 be non-static.

So do you think my code shows a compiler bug? Bye, bearophile
Nov 02 2010
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iaqgvl$1qbp$1 digitalmars.com...
 So do you think my code shows a compiler bug?

I'd like immutable to be implicitly static in some cases eg. void foo() { immutable int[20] table = [...]; } If this is possible, it does reduce the storage required and repeated init times. (Although it seems to be using enum, not static, which has its own set of problems) Removing the storage inside structs completely scews up the memory layout (which is meant to be C compatible) The fact that commenting out the constructor in struct C changes the size of the struct seems like a bug to me, or at least a horribly messy part of the spec. struct A { int x; } struct B { immutable int x; } struct C { immutable int x; this(int a) { x = a; } } Also, this seems to work for me. enum E { A, B }; struct Foo { immutable E x; this(int dummy) { x = E.A; } } struct Bar { immutable E x; this(int dummy) { x = E.B; } } void main() { auto f = Foo(0); assert((cast(Bar*)&f).x == E.A); } Also, What the hell?
Nov 02 2010
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
*What the hell?

struct Foo {
    immutable int x = 3;
 this(int dummy) { auto p = &x; }
}

void main() {

 auto f = Foo(0);

 auto p = &f.x; // Will compile with this commented out
}
Nov 02 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/11/2010 03:06, Daniel Murphy wrote:
 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...
 Is it correct for immutable struct fields to act like enum or static const
 fields? (I don't think so, but I am wrong often):

immutable struct fields can be changed inside the constructor, so they must be non-static.

Const/immutable struct members are an ugly mess, and a big hole in the const system. http://d.puremagic.com/issues/show_bug.cgi?id=2625 Stewart.
Nov 07 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/10 2:40 PM, Stewart Gordon wrote:
 On 03/11/2010 03:06, Daniel Murphy wrote:
 "bearophile"<bearophileHUGS lycos.com> wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...
 Is it correct for immutable struct fields to act like enum or static
 const
 fields? (I don't think so, but I am wrong often):

immutable struct fields can be changed inside the constructor, so they must be non-static.

Const/immutable struct members are an ugly mess, and a big hole in the const system. http://d.puremagic.com/issues/show_bug.cgi?id=2625 Stewart.

There are problems with the implementation, not the design. Fixing const and immutable will be #1 priority once the 64-bit dmd is off the gates. Andrei
Nov 07 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-11-08 02:13, Andrei Alexandrescu wrote:
 On 11/7/10 2:40 PM, Stewart Gordon wrote:
 On 03/11/2010 03:06, Daniel Murphy wrote:
 "bearophile"<bearophileHUGS lycos.com> wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...
 Is it correct for immutable struct fields to act like enum or static
 const
 fields? (I don't think so, but I am wrong often):

immutable struct fields can be changed inside the constructor, so they must be non-static.

Const/immutable struct members are an ugly mess, and a big hole in the const system. http://d.puremagic.com/issues/show_bug.cgi?id=2625 Stewart.

There are problems with the implementation, not the design. Fixing const and immutable will be #1 priority once the 64-bit dmd is off the gates. Andrei

Why can't we get an official roadmap for this? I thought dynamic libraries was next after 64bit. -- /Jacob Carlborg
Nov 08 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 07 November 2010 17:13:51 Andrei Alexandrescu wrote:
 There are problems with the implementation, not the design. Fixing const
 and immutable will be #1 priority once the 64-bit dmd is off the gates.

Now, _that_ is good news. The problems with const and immutable have long been some of the most annoying. - Jonathan M Davis
Nov 07 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 17:54:35 bearophile wrote:
 Is it correct for immutable struct fields to act like enum or static const
 fields? (I don't think so, but I am wrong often):
 
 struct Foo {
     immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}
 
 
 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.l
 earn&article_id=22540
 
 Thank you,
 bearophile

Assuming that it's the constructor which initializes the variable, then it's going to have to have storage, immutable or not. However, if it's not set by the constructor but directly initialized, then I don't see why the compiler can't treat it as not having storage. At that point, it's conceptually the same as using an enum. Why would it really matter though? If anything, I would have thought that the elimination of the storage would be a good thing, since it reduces the memory footprint of the object. - Jonathan M Davis
Nov 02 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Why would it really matter though?

I guess you have not followed my link with more explanations, right? :-) Bye, bearophile
Nov 02 2010
prev sibling next sibling parent reply Gareth Charnock <gareth.charnock gmail.com> writes:
On 03/11/10 00:54, bearophile wrote:
 Is it correct for immutable struct fields to act like enum or static const
fields? (I don't think so, but I am wrong often):

 struct Foo {
      immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}


 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540

 Thank you,
 bearophile

If it helps, the analogy I always use when explaining immutable is the stone tablet. A running program can chip out a message on a stone tablet (write to immutable memory) but once it's written once it's never going to change again. When your done with a stone tablet all you can do is throw it in the garbage but you can go and chip a new message on a new stone tablet. Don't worry, it took me a while before I realized that an immutable didn't have to be known at compile time as well.
Nov 02 2010
parent Gareth Charnock <gareth.charnock gmail.com> writes:
On 03/11/10 02:20, Gareth Charnock wrote:
 On 03/11/10 00:54, bearophile wrote:
 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):

 struct Foo {
 immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}


 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540


 Thank you,
 bearophile

If it helps, the analogy I always use when explaining immutable is the stone tablet. A running program can chip out a message on a stone tablet (write to immutable memory) but once it's written once it's never going to change again. When your done with a stone tablet all you can do is throw it in the garbage but you can go and chip a new message on a new stone tablet. Don't worry, it took me a while before I realized that an immutable didn't have to be known at compile time as well.

Ah, okay, I reread that. You meant is it correct for immutable to act like enum at any time, but I read all the time for some reason. Sorry.
Nov 02 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 19:24:29 bearophile wrote:
 Jonathan M Davis:
 Why would it really matter though?

I guess you have not followed my link with more explanations, right? :-) Bye, bearophile

I don't really get what you're doing there or what the problem is. You cast one struct to another struct and it retained the same value for x. That seems logical enough. You're just viewing that chunk of memory as a new type. You didn't actually change what's there. My first reaction to seeing that sort of cast though is that it's a bad idea anyway, though I guess that whether an immutable variable has storage could affect the result in such a case. Generally though, I would have argued that if you weren't going to set the variable with the constructor, it should probably be an enum anyway. - Jonathan M Davis
Nov 02 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Daniel Murphy, el  3 de noviembre a las 13:52 me escribiste:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:iaqgvl$1qbp$1 digitalmars.com...
 So do you think my code shows a compiler bug?

I'd like immutable to be implicitly static in some cases eg. void foo() { immutable int[20] table = [...]; }

I think immutable should NEVER, EVER be optimized-out from a struct, for the reasons I gave in the other post. I really hope this IS a bug, if D would like to stay being a system programming language. Struct are extremely important to represent memory layouts, and making that incompatible with immutable seems extremely silly. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de galaxias
Nov 02 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el  2 de noviembre a las 20:02 me escribiste:
 On Tuesday 02 November 2010 19:24:29 bearophile wrote:
 Jonathan M Davis:
 Why would it really matter though?

I guess you have not followed my link with more explanations, right? :-) Bye, bearophile

I don't really get what you're doing there or what the problem is. You cast one struct to another struct and it retained the same value for x. That seems logical enough. You're just viewing that chunk of memory as a new type. You didn't actually change what's there. My first reaction to seeing that sort of cast though is that it's a bad idea anyway, though I guess that whether an immutable variable has storage could affect the result in such a case. Generally though, I would have argued that if you weren't going to set the variable with the constructor, it should probably be an enum anyway.

I don't think it's a good idea to optimize out a struct member, as structs are often used to represent memory layouts when interacting with low level stuff (or not so low-level, like reading and writing a packet from the network). It seems pretty silly to have to avoid using immutable in those cases just to let the compiler "please, don't remove store from this struct". -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Y2K - what a disappointment... i had at least expected one nuclear plant to blow
Nov 02 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 21:00:00 Leandro Lucarella wrote:
 Jonathan M Davis, el  2 de noviembre a las 20:02 me escribiste:
 On Tuesday 02 November 2010 19:24:29 bearophile wrote:
 Jonathan M Davis:
 Why would it really matter though?

I guess you have not followed my link with more explanations, right? :-) Bye, bearophile

I don't really get what you're doing there or what the problem is. You cast one struct to another struct and it retained the same value for x. That seems logical enough. You're just viewing that chunk of memory as a new type. You didn't actually change what's there. My first reaction to seeing that sort of cast though is that it's a bad idea anyway, though I guess that whether an immutable variable has storage could affect the result in such a case. Generally though, I would have argued that if you weren't going to set the variable with the constructor, it should probably be an enum anyway.


Perhaps, but is it reasonable to be worrying about memory layouts like that when you're dealing with immutable? I would have thought that in cases where memory layouts like that mattered, you wouldn't be using immutable, since you're probably interfacing with C code or somesuch. It may be that we ultimately don't want to make immutable be optimized away (since you can just use an enum instead if you do want it to be optimized away), but it doesn't surprise me at all if the decision was made to optimize immutables away, since at first glance, at least, it seems like a good optimization and that there's no real need to keep it around if you can optimize it out. - Jonathan M Davis
Nov 02 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 02 Nov 2010 20:54:35 -0400, bearophile wrote:

 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):

This is bug 3449: http://d.puremagic.com/issues/show_bug.cgi?id=3449 -Lars
Nov 03 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 This is bug 3449:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=3449

Thank you to you and the others that have answered in this thread. That's an important bug, it changes how much I can use immutables. Bye, bearophile
Nov 03 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 03/11/2010 10:42, Lars T. Kyllingstad wrote:
 On Tue, 02 Nov 2010 20:54:35 -0400, bearophile wrote:

 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):

This is bug 3449: http://d.puremagic.com/issues/show_bug.cgi?id=3449 -Lars

Ouch, this is a very nasty bug indeed. :S -- Bruno Medeiros - Software Engineer
Nov 25 2010