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?

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

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
}

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?

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

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

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.

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

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.

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