www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is enum static?

reply "Borislav Kosharov" <boby_dsm abv.bg> writes:
If I have any enum in a class is it one for all instances or one 
per instance? Also are enums one per thread or only one?
Aug 08 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/08/2013 02:45 PM, Borislav Kosharov wrote:
 If I have any enum in a class is it one for all instances or one per
 instance? Also are enums one per thread or only one?
More than that. :) enums are manifest constants. Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code. Perhaps it is still that way... Ali
Aug 08 2013
next sibling parent reply "Borislav Kosharov" <boby_dsm abv.bg> writes:
On Thursday, 8 August 2013 at 21:49:31 UTC, Ali Çehreli wrote:
 On 08/08/2013 02:45 PM, Borislav Kosharov wrote:
 If I have any enum in a class is it one for all instances or 
 one per
 instance? Also are enums one per thread or only one?
More than that. :) enums are manifest constants. Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code. Perhaps it is still that way... Ali
What do you mean by AA? So enums are compile time constants that are like mini C macros?
Aug 08 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/08/2013 02:53 PM, Borislav Kosharov wrote:

 On Thursday, 8 August 2013 at 21:49:31 UTC, Ali Çehreli wrote:
 On 08/08/2013 02:45 PM, Borislav Kosharov wrote:
 If I have any enum in a class is it one for all instances or one per
 instance? Also are enums one per thread or only one?
More than that. :) enums are manifest constants. Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code. Perhaps it is still that way... Ali
What do you mean by AA? So enums are compile time constants that are like mini C macros?
Yes. For example: enum fileName = "abc.txt"; Here is the problem with AA manifest constants: import std.stdio; enum string[int] aa = [ 1 : "one", 10 : "ten" ]; void main() { writeln(1 in aa); writeln(1 in aa); } That program outputs different element addresses for the two 'in' operators because unfortunately the code is the equivalent of the following: writeln(1 in [ 1 : "one", 10 : "ten" ]); writeln(1 in [ 1 : "one", 10 : "ten" ]); Ali
Aug 08 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ali Çehreli:

 More than that. :) enums are manifest constants.

 Imagine that enum as being pasted into source code as is. This 
 used to have surprising effects for AAs, as an enum AA would be 
 instantiated from scratch everywhere that AA enum was used in 
 the code.
I think that some time ago Don has proposed to disallow the 'enum' tag for things like AAs, on the base that such behavour is not efficient, surprising, and maybe even not useful... I don't know where his proposal has gone later. Bye, bearophile
Aug 08 2013
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 8 August 2013 at 23:19:49 UTC, bearophile wrote:
 Ali Çehreli:

 More than that. :) enums are manifest constants.

 Imagine that enum as being pasted into source code as is. This 
 used to have surprising effects for AAs, as an enum AA would 
 be instantiated from scratch everywhere that AA enum was used 
 in the code.
I think that some time ago Don has proposed to disallow the 'enum' tag for things like AAs, on the base that such behavour is not efficient, surprising, and maybe even not useful... I don't know where his proposal has gone later. Bye, bearophile
Enum trick is useful to workaround bug with aggregate members of reference types being initialized - all instances share reference to same data and to enable default struct constructors.
Aug 08 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 09, 2013 at 01:19:44AM +0200, bearophile wrote:
 Ali Çehreli:
 
More than that. :) enums are manifest constants.

Imagine that enum as being pasted into source code as is. This
used to have surprising effects for AAs, as an enum AA would be
instantiated from scratch everywhere that AA enum was used in the
code.
I think that some time ago Don has proposed to disallow the 'enum' tag for things like AAs, on the base that such behavour is not efficient, surprising, and maybe even not useful... I don't know where his proposal has gone later.
[...] I think we should disallow it. It's surprising behaviour for someone who doesn't know how it's implemented. T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Aug 08 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 08, 2013 14:49:29 Ali Çehreli wrote:
 On 08/08/2013 02:45 PM, Borislav Kosharov wrote:
 If I have any enum in a class is it one for all instances or one per
 instance? Also are enums one per thread or only one?
More than that. :) enums are manifest constants. Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code. Perhaps it is still that way...
I'm sure that it's still that way. When you use an enum, you're effectively copy-pasting its definition, so you end up with a separate copy of it every time you use it. That's not a big deal for value types or string literals, but for arrays or AAs, it can result in a lot of allocations that you may not have wanted. - Jonathan M Davis
Aug 08 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 08, 2013 at 06:38:18PM -0400, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 14:49:29 Ali Çehreli wrote:
 On 08/08/2013 02:45 PM, Borislav Kosharov wrote:
 If I have any enum in a class is it one for all instances or one
 per instance? Also are enums one per thread or only one?
More than that. :) enums are manifest constants. Imagine that enum as being pasted into source code as is. This used to have surprising effects for AAs, as an enum AA would be instantiated from scratch everywhere that AA enum was used in the code. Perhaps it is still that way...
I'm sure that it's still that way. When you use an enum, you're effectively copy-pasting its definition, so you end up with a separate copy of it every time you use it. That's not a big deal for value types or string literals, but for arrays or AAs, it can result in a lot of allocations that you may not have wanted.
[...] Are we going to fix this anytime soon (or at all)? If not, we'd better start documenting this, since currently enums are being sold as manifest constants, and most people would understand that as meaning it's only allocated once at compile-time/startup-time. It would leave a very bad impression if new users unknowingly end up with a lot of unwanted allocations just from using a language feature as-advertised. T -- There's light at the end of the tunnel. It's the oncoming train.
Aug 08 2013
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Thursday, 8 August 2013 at 21:46:02 UTC, Borislav Kosharov 
wrote:
 If I have any enum in a class is it one for all instances or 
 one per instance? Also are enums one per thread or only one?
Every field in a class is per-instance, unless it's marked with 'static', which makes it for all instances but thread-local, or marked with '__gshared', which again makes it for all instances but global (shared among all threads). I'm assuming you mean code like this: enum E { a, b, c } class C { E e1; // per-instance static E e2; // per-thread __gshared E e3; // shared among all threads }
Aug 08 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 08, 2013 15:40:25 H. S. Teoh wrote:
 Are we going to fix this anytime soon (or at all)? If not, we'd better
 start documenting this, since currently enums are being sold as manifest
 constants, and most people would understand that as meaning it's only
 allocated once at compile-time/startup-time. It would leave a very bad
 impression if new users unknowingly end up with a lot of unwanted
 allocations just from using a language feature as-advertised.
There's nothing to fix. It's by design. That _is_ what a manifest constant is as far as D is concerned. And if you search for manifest constants online, you end up running into stuff that talks about #define in C, which does the same thing. So, I don't think that we're doing anything abnormal here. We just have to make sure that it's clear in the documentation that that's how manifest constants work. I don't know what the documentation currently says though. - Jonathan M Davis
Aug 08 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 08, 2013 at 06:47:48PM -0400, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 15:40:25 H. S. Teoh wrote:
 Are we going to fix this anytime soon (or at all)? If not, we'd
 better start documenting this, since currently enums are being sold
 as manifest constants, and most people would understand that as
 meaning it's only allocated once at compile-time/startup-time. It
 would leave a very bad impression if new users unknowingly end up
 with a lot of unwanted allocations just from using a language
 feature as-advertised.
There's nothing to fix. It's by design. That _is_ what a manifest constant is as far as D is concerned. And if you search for manifest constants online, you end up running into stuff that talks about #define in C, which does the same thing. So, I don't think that we're doing anything abnormal here. We just have to make sure that it's clear in the documentation that that's how manifest constants work. I don't know what the documentation currently says though.
[...] Seriously, I think we should hire a tech writer. The way we manage our docs just ... leaves a lot to be desired. It's very unclear to newcomers, and even to someone who's been working with D for a while, like myself. In fact, I'm going to update http://wiki.dlang.org/Declaring_constants right now, to reflect this caveat. Maybe I'll submit a pull for the language docs. But honestly, I can totally understand why many people find D docs very frustrating. In fact, I found the online docs so unhelpful when I first found D, that it delayed my adopting D for at least half a year until one day I saw TDPL in a local bookstore and decided to buy it. A friend of mine has told me, in private, that after trying out D he liked the language, but one of the things he decidedly did NOT like was the docs. I think the only real solution to this is to hire a full-time tech writer to do the documentation, and do it *properly*. We're doing a great language a great disservice by documenting it so poorly. T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr
Aug 08 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 08, 2013 16:05:24 H. S. Teoh wrote:
 On Thu, Aug 08, 2013 at 06:47:48PM -0400, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 15:40:25 H. S. Teoh wrote:
 Are we going to fix this anytime soon (or at all)? If not, we'd
 better start documenting this, since currently enums are being sold
 as manifest constants, and most people would understand that as
 meaning it's only allocated once at compile-time/startup-time. It
 would leave a very bad impression if new users unknowingly end up
 with a lot of unwanted allocations just from using a language
 feature as-advertised.
There's nothing to fix. It's by design. That _is_ what a manifest constant is as far as D is concerned. And if you search for manifest constants online, you end up running into stuff that talks about #define in C, which does the same thing. So, I don't think that we're doing anything abnormal here. We just have to make sure that it's clear in the documentation that that's how manifest constants work. I don't know what the documentation currently says though.
[...] Seriously, I think we should hire a tech writer. The way we manage our docs just ... leaves a lot to be desired. It's very unclear to newcomers, and even to someone who's been working with D for a while, like myself. In fact, I'm going to update http://wiki.dlang.org/Declaring_constants right now, to reflect this caveat. Maybe I'll submit a pull for the language docs. But honestly, I can totally understand why many people find D docs very frustrating. In fact, I found the online docs so unhelpful when I first found D, that it delayed my adopting D for at least half a year until one day I saw TDPL in a local bookstore and decided to buy it. A friend of mine has told me, in private, that after trying out D he liked the language, but one of the things he decidedly did NOT like was the docs. I think the only real solution to this is to hire a full-time tech writer to do the documentation, and do it *properly*. We're doing a great language a great disservice by documenting it so poorly.
A lot of the problem stems from the fact that most of the devs don't do anything with the documenation. We tend to focus on the code and forget about the documentation. Maybe we need someone to champion the documentation and at least organize what needs to be done with it if not take the time themselves to fix it. The other big issue would probably be the fact that it's also treated as the spec for the language, and you don't write the same kind of documentation when you're writing a spec as when you're writing something to teach people (not that D's docs are quite what a spec requires either, as they don't tend to be precise enough, but they tend to lean heavily in that direction and aren't even vaguely meant as tutorials). - Jonathan M Davis
Aug 08 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 08, 2013 at 10:00:08PM -0400, Jonathan M Davis wrote:
 On Thursday, August 08, 2013 16:05:24 H. S. Teoh wrote:
[...]
 But honestly, I can totally understand why many people find D docs
 very frustrating. In fact, I found the online docs so unhelpful when
 I first found D, that it delayed my adopting D for at least half a
 year until one day I saw TDPL in a local bookstore and decided to
 buy it. A friend of mine has told me, in private, that after trying
 out D he liked the language, but one of the things he decidedly did
 NOT like was the docs.  I think the only real solution to this is to
 hire a full-time tech writer to do the documentation, and do it
 *properly*. We're doing a great language a great disservice by
 documenting it so poorly.
A lot of the problem stems from the fact that most of the devs don't do anything with the documenation. We tend to focus on the code and forget about the documentation. Maybe we need someone to champion the documentation and at least organize what needs to be done with it if not take the time themselves to fix it.
Yeah, that's why I said we should hire a full-time tech writer. We coders are notoriously bad at writing docs. We're too familiar with the code, and unconsciously make unstated assumptions that others don't know about, so the little docs that we *do* write tend to be hard for newbies to understand. I don't see any other way to solve this problem... it's a common malady among opensource projects.
 The other big issue would probably be the fact that it's also treated
 as the spec for the language, and you don't write the same kind of
 documentation when you're writing a spec as when you're writing
 something to teach people (not that D's docs are quite what a spec
 requires either, as they don't tend to be precise enough, but they
 tend to lean heavily in that direction and aren't even vaguely meant
 as tutorials).
[...] When is the Akeron project coming to fruition? ;-) One of these days, we need to go back through the D-learn archives and collect frequently-encountered problems by newbies, and write suitable tutorials for them (say on the wiki or something). T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr
Aug 09 2013
parent reply "Borislav Kosharov" <boby_dsm abv.bg> writes:
So if I want to have a string constant it is a lot better to 
declare it as:

static immutable string MY_STRING = "Some string";

Because it won't be duplicated?
Aug 19 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want to have a 
string constant it is a lot better to declare it as:
 static immutable string MY_STRING = "Some string";

 Because it won't be duplicated?
enum is fine with strings. It is a common space optimization of the compilers not to duplicate identical strings. The following program includes just one "hello world" in the compiled object file: import std.stdio; enum atModuleLevel = "hello world"; void foo() { writefln(atModuleLevel); } void main() { enum s = "hello world"; writeln(s); writeln(s); writeln(atModuleLevel); foo(); } Ali
Aug 19 2013
parent reply "JS" <js.mdnq gmail.com> writes:
On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
 On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want 
 to have a string constant it is a lot better to declare it as:
 static immutable string MY_STRING = "Some string";

 Because it won't be duplicated?
enum is fine with strings. It is a common space optimization of the compilers not to duplicate identical strings. The following program includes just one "hello world" in the compiled object file:
And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.
Aug 20 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 20, 2013 22:10:28 JS wrote:
 On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
 On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want
 
 to have a string constant it is a lot better to declare it as:
 static immutable string MY_STRING = "Some string";
 
 Because it won't be duplicated?
enum is fine with strings. It is a common space optimization of the compilers not to duplicate identical strings. The following program includes
 just one "hello world" in the compiled object file:
And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.
It only works with string literal because they're immutable, and the compiler optimizes for that by only creating them once (it even puts them in the read- only portion of the binary in Linux). The same doesn't hold true for stuff like AAs. - Jonathan M Davis
Aug 20 2013
parent "JS" <js.mdnq gmail.com> writes:
On Tuesday, 20 August 2013 at 21:01:43 UTC, Jonathan M Davis 
wrote:
 On Tuesday, August 20, 2013 22:10:28 JS wrote:
 On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
 On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I 
 want
 
 to have a string constant it is a lot better to declare it 
 as:
 static immutable string MY_STRING = "Some string";
 
 Because it won't be duplicated?
enum is fine with strings. It is a common space optimization of the compilers not to duplicate identical strings. The following program includes
 just one "hello world" in the compiled object file:
And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.
It only works with string literal because they're immutable, and the compiler optimizes for that by only creating them once (it even puts them in the read- only portion of the binary in Linux). The same doesn't hold true for stuff like AAs. - Jonathan M Davis
That wasn't the question, I didn't ask why D does what it does by why it can't do what it doesn't do.
Aug 20 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
 So if I want to have a string constant it is a lot better to
 declare it as:
 
 static immutable string MY_STRING = "Some string";
 
 Because it won't be duplicated?
Even if you copy-pasted "Some string" in your code thousands of times, only one string is allocated, which is one of the advantages of strings being immutable (the compiler can get away with allocating memory for string literals only once). But other array literals _do_ result in a new array allocated every time that they're in the code, and when you use an enum, its value is copy-pasted every place that it's used, resulting in a new allocation every time that it's used. So, using string enums is fine, but using other arrays as enums is usually a bad idea. - Jonathan M Davis
Aug 19 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 19 August 2013 at 23:14:12 UTC, Jonathan M Davis wrote:
 On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
 So if I want to have a string constant it is a lot better to
 declare it as:
 
 static immutable string MY_STRING = "Some string";
 
 Because it won't be duplicated?
Even if you copy-pasted "Some string" in your code thousands of times, only one string is allocated, which is one of the advantages of strings being immutable (the compiler can get away with allocating memory for string literals only once). But other array literals _do_ result in a new array allocated every time that they're in the code, and when you use an enum, its value is copy-pasted every place that it's used, resulting in a new allocation every time that it's used. So, using string enums is fine, but using other arrays as enums is usually a bad idea. - Jonathan M Davis
I think one exception to this is when you index an enum. EG: enum vals=[1, 2, 3, 0]; auto a = vals[i]; Here, the compiler will not make an allocation (at least, it didn't last time I tested)
Aug 20 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 20 August 2013 at 09:38:35 UTC, monarch_dodra wrote:
 On Monday, 19 August 2013 at 23:14:12 UTC, Jonathan M Davis 
 wrote:
 On Monday, August 19, 2013 12:18:36 Borislav Kosharov wrote:
 So if I want to have a string constant it is a lot better to
 declare it as:
 
 static immutable string MY_STRING = "Some string";
 
 Because it won't be duplicated?
Even if you copy-pasted "Some string" in your code thousands of times, only one string is allocated, which is one of the advantages of strings being immutable (the compiler can get away with allocating memory for string literals only once). But other array literals _do_ result in a new array allocated every time that they're in the code, and when you use an enum, its value is copy-pasted every place that it's used, resulting in a new allocation every time that it's used. So, using string enums is fine, but using other arrays as enums is usually a bad idea. - Jonathan M Davis
I think one exception to this is when you index an enum. EG: enum vals=[1, 2, 3, 0]; auto a = vals[i]; Here, the compiler will not make an allocation (at least, it didn't last time I tested)
is there an allocation in this? enum vals=[1, 2, 3, 0]; int[4] a; a[] = vals[];
Aug 20 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
 is there an allocation in this?
 
 enum vals=[1, 2, 3, 0];
 
 int[4] a;
 a[] = vals[];
Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though. - Jonathan M Davis
Aug 20 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis 
wrote:
 On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
 is there an allocation in this?
 
 enum vals=[1, 2, 3, 0];
 
 int[4] a;
 a[] = vals[];
Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though. - Jonathan M Davis
So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...
Aug 20 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 20 August 2013 at 18:38:54 UTC, John Colvin wrote:
 So you're saying it will allocate a new dynamic array, 
 initialise it with 1,2,3,0 and then copy the elements from that 
 new array to the static one? That's not good...
Welcome to painful world of allocation-free D programming ;)
Aug 20 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
 On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
 
 wrote:
 On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
 is there an allocation in this?
 
 enum vals=[1, 2, 3, 0];
 
 int[4] a;
 a[] = vals[];
Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though. - Jonathan M Davis
So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...
Well, that's what you told it to do semantically. The compiler could theoretically optimize it (and hopefully will eventually), but it would be an optimization. At this point, if you initialize the static array with an array literal, then it will avoid the allocation (though it didn't used to), but AFAIK, it'll still allocate with your example. - Jonathan M Davis
Aug 20 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 20 August 2013 at 19:25:56 UTC, Jonathan M Davis 
wrote:
 On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
 On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
 
 wrote:
 On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
 is there an allocation in this?
 
 enum vals=[1, 2, 3, 0];
 
 int[4] a;
 a[] = vals[];
Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though. - Jonathan M Davis
So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...
Well, that's what you told it to do semantically. The compiler could theoretically optimize it (and hopefully will eventually), but it would be an optimization. At this point, if you initialize the static array with an array literal, then it will avoid the allocation (though it didn't used to), but AFAIK, it'll still allocate with your example. - Jonathan M Davis
I presume there's a good reason why we don't have: enum a = [1,2,3,4]; assert assert(is(typeof(a) == int[4])); this works after all: enum int[4] a = [1,2,3,4]; assert assert(is(typeof(a) == int[4]));
Aug 20 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 20, 2013 21:33:23 John Colvin wrote:
 I presume there's a good reason why we don't have:
 enum a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
 
 this works after all:
 enum int[4] a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
Array literals are always dynamic arrays, so [1, 2, 3, 4] is int[] by definition. - Jonathan M Davis
Aug 20 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 20 August 2013 at 19:38:34 UTC, Jonathan M Davis 
wrote:
 On Tuesday, August 20, 2013 21:33:23 John Colvin wrote:
 I presume there's a good reason why we don't have:
 enum a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
 
 this works after all:
 enum int[4] a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
Array literals are always dynamic arrays, so [1, 2, 3, 4] is int[] by definition. - Jonathan M Davis
What I was trying to say was: is there a good reason they are always dynamic arrays? What would break if they were made static by default but dynamic on direct assignment to a dynamic array?
Aug 20 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, August 21, 2013 00:23:09 John Colvin wrote:
 What I was trying to say was: is there a good reason they are
 always dynamic arrays?
 
 What would break if they were made static by default but dynamic
 on direct assignment to a dynamic array?
Static arrays are unsafe in many situations, especially if you end up slicing them by accident. The semantics of static arrays are also very different, since they're value types. Static by default would be a very bad idea IMHO. Obviously, static arrays can be desirable, but the programmer needs to be careful any time that they're used. Having the compiler avoid allocating a dynamic array in any situation where a static one is clearly warranted is certainly desirable, as it avoids unnecessary allocations, but that's very different from making static the default. - Jonathan M Davis
Aug 20 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 20 August 2013 at 22:48:26 UTC, Jonathan M Davis 
wrote:
 Static arrays are unsafe in many situations, especially if you 
 end up slicing
 them by accident.
But we don't prohibit slicing static arrays. Does not seem consistent approach. If pointer safety would have been really important, `scope` definition and implementation would have been a priority.
 The semantics of static arrays are also very different, since
 they're value types.
But slices of static arrays are still slices. What does it change in practice?
 Static by default would be a very bad idea IMHO.
 Obviously, static arrays can be desirable, but the programmer 
 needs to be
 careful any time that they're used.
How do you expect to convince someone to use D instead of C in its domain if there no such thing as static array literal? It, khem, "literally" does not exist. What bothers me most here is that we have clear safe and system distinction in the language where former is expected to provide correctness guarantees and latter - C-like power. But in practice it is safe and no-really-safe-but-we-still-care distinction, with safe-flavored reasoning severely harming power of common (or even system) constructs. I have abandoned any hope to change this but it keeps frustrating.
Aug 20 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, August 21, 2013 01:21:22 Dicebot wrote:
 On Tuesday, 20 August 2013 at 22:48:26 UTC, Jonathan M Davis
 
 wrote:
 Static arrays are unsafe in many situations, especially if you
 end up slicing
 them by accident.
But we don't prohibit slicing static arrays. Does not seem consistent approach. If pointer safety would have been really important, `scope` definition and implementation would have been a priority.
 The semantics of static arrays are also very different, since
 they're value types.
But slices of static arrays are still slices. What does it change in practice?
Slicing a static array is the equivalent of taking the address of a local variable. It's a bug that it's not considered system. http://d.puremagic.com/issues/show_bug.cgi?id=8838 And IMHO, the fact that the language _ever_ implicitly slices static arrays is a major design flaw. It's the same as if passing a variable of type T to a function that accept T* implicitly took the address of that variable rather than giving an error, and I think that most people would agree that that's a dumb idea. Unfortunately though, I don't expect it to be fixed at this point, since it would break too much code to do so. - Jonathan M Davis
Aug 20 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 20 August 2013 at 23:42:48 UTC, Jonathan M Davis 
wrote:
 And IMHO, the fact that the language _ever_ implicitly slices 
 static arrays is
 a major design flaw.
Here you have my agreement, I tend to dislike any implicit slicing as well as any other implicit operation that is not 100% obvious.
 Slicing a static array is the equivalent of taking the address 
 of a local
 variable. It's a bug that it's not considered  system.
Sure. But array literals won't get static in system code. That is exactly what I am speaking about - pursuing correctness of safe severely harms system. It never was advertised that way. Was it meant to?
Aug 20 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 21, 2013 02:13:02 Dicebot wrote:
 Sure. But array literals won't get static in  system code. That
 is exactly what I am speaking about - pursuing correctness of
  safe severely harms  system. It never was advertised that way.
 Was it meant to?
Array literals wouldn't become static in safe code either. There only case I'm aware of where an array literal effectively becomes static is when directly initializing a static array. And even if there are more cases, none of them would have anything to do with safety. The only time that the compiler would do it would be if it was able to determine that avoiding the allocation wolud be semantically identical (aside from the lack of allocation). - Jonathan M Davis
Aug 20 2013
prev sibling parent reply "Borislav Kosharov" <boby_dsm abv.bg> writes:
On Tuesday, 20 August 2013 at 19:33:25 UTC, John Colvin wrote:
 On Tuesday, 20 August 2013 at 19:25:56 UTC, Jonathan M Davis 
 wrote:
 On Tuesday, August 20, 2013 20:38:52 John Colvin wrote:
 On Tuesday, 20 August 2013 at 17:02:07 UTC, Jonathan M Davis
 
 wrote:
 On Tuesday, August 20, 2013 12:54:29 John Colvin wrote:
 is there an allocation in this?
 
 enum vals=[1, 2, 3, 0];
 
 int[4] a;
 a[] = vals[];
Since, you're asking it to copy the elements of a dynamic array to a static one, I would fully expect it to result in an allocation, though a smart compiler might optimize it out. I wouldn't expect dmd to do that though. - Jonathan M Davis
So you're saying it will allocate a new dynamic array, initialise it with 1,2,3,0 and then copy the elements from that new array to the static one? That's not good...
Well, that's what you told it to do semantically. The compiler could theoretically optimize it (and hopefully will eventually), but it would be an optimization. At this point, if you initialize the static array with an array literal, then it will avoid the allocation (though it didn't used to), but AFAIK, it'll still allocate with your example. - Jonathan M Davis
I presume there's a good reason why we don't have: enum a = [1,2,3,4]; assert assert(is(typeof(a) == int[4])); this works after all: enum int[4] a = [1,2,3,4]; assert assert(is(typeof(a) == int[4]));
Did you mean static assert and not assert assert or am I missing something?
Aug 20 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/20/2013 12:58 PM, Borislav Kosharov wrote:
 On Tuesday, 20 August 2013 at 19:33:25 UTC, John Colvin wrote:
   assert assert(is(typeof(a) == int[4]));
Did you mean static assert and not assert assert or am I missing
something? Yes, he meant static assert. :) Ali
Aug 20 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 20, 2013 11:38:34 monarch_dodra wrote:
 I think one exception to this is when you index an enum. EG:
 enum vals=[1, 2, 3, 0];
 
 auto a = vals[i];
 
 Here, the compiler will not make an allocation (at least, it
 didn't last time I tested)
It probably does an optimtization based on constant folding or somesuch. And I'm sure that there are other cases where the compiler could theoretically optimize some array allocations, but in general, I wouldn't bet on dmd being that smart at this point. - Jonathan M Davis
Aug 20 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 20, 2013 at 03:38:18PM -0400, Jonathan M Davis wrote:
 On Tuesday, August 20, 2013 21:33:23 John Colvin wrote:
 I presume there's a good reason why we don't have:
 enum a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
 
 this works after all:
 enum int[4] a = [1,2,3,4];
 assert assert(is(typeof(a) == int[4]));
Array literals are always dynamic arrays, so [1, 2, 3, 4] is int[] by definition.
Wait, is that dynamic *by default*, or is it *always* dynamic? If the latter, I think we should fix the language. It should be possible to write things like: byte[] a = [1,2,3,4]; and *not* incur the overhead of allocating an int[] and then copying it over (with implicit casting) to the byte[]. On that note, I find it Very Evil that this doesn't work properly: char[] a = "abc"; const(char)[] b = "abc"; Instead, you have to do: char[] a = "abc".dup; const(char)[] b = "abc".dup; I can accept that having an explicit .dup or .idup is a good thing when the source string is a variable, but in this case, the compiler *should* be smart enough to know, hey, "abc" is a literal and is being immediately assigned to a char[], so the user must intend that it's used only to initialize the char[], so I don't need to actually allocate a *string* (as in, immutable(char)[]) for the literal and copy it, but instead, I should generate code to initialize each array element. tl;dr, I think D literals are assigned a type far too early in the compilation process. The intended meaning of a literal shouldn't be bound until the compiler is able to infer from context what type is actually required. On Tue, Aug 20, 2013 at 10:10:28PM +0200, JS wrote:
 On Monday, 19 August 2013 at 18:28:10 UTC, Ali Çehreli wrote:
On 08/19/2013 03:18 AM, Borislav Kosharov wrote:> So if I want to
have a string constant it is a lot better to declare it as:
 static immutable string MY_STRING = "Some string";

 Because it won't be duplicated?
enum is fine with strings. It is a common space optimization of the compilers not to duplicate identical strings. The following program includes just one "hello world" in the compiled object file:
And why can't this be done with any compile time objects? AA's that are identical be collated similar to strings.
The problem is that AA's are mutable at runtime. You wouldn't want something like this to happen: auto aa1 = ["a": 1, "b": 2]; auto aa2 = ["a": 1, "b": 2]; aa1.remove("a"); auto x = aa2["a"]; // oops, you get an error if the two AA // literals referred to the same thing You *could* collapse literals into the same object if they were immutable, though. I don't know if DMD does that (yet), but if not, it should! Honestly, the way literals are handled in D is one of the things I'm not very happy with. There's too many implicit allocations that may not be immediately obvious. Also, the fact that static immutable AA literals are currently not possible is a lamentable state of affairs. :-( The compiler *should* be able to generate the data for an AA literal at compile-time in such a way that it can be put into the executable and used directly at runtime without requiring runtime initialization. T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Aug 20 2013