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