On 09/02/2012 03:45 PM, monarch_dodra wrote:
> On Saturday, 1 September 2012 at 09:16:30 UTC, Jonathan M Davis
> wrote:
>> [SNIP]
>> so it looks like not only do all instances of the same string enum use
>> the
>> same memory, but another enum with the same string literal shares it
>> as well.
>> So, only one is allocated. And on Linux at least, as I understand it, the
>> string literals go in ROM. But it may be that the above code functions
>> differently in Windows, since it _doesn't_ put string literals in ROM.
>> [SNIP]
>
> FYI: I get the exact same behavior in Windows. Not that it
> matters, but it sounded like you were asking.
>
> I'm a bit confused now though: Why would someone want to use an
> enum when they could use a static immutable instead?
>
> If I understood correctly, the enum will *always* be inlined
> (doesn't create any actual symbols). But if you use a static
> immutable, then the compiler will create an actual symbol, but
> probably inline it away if it judges that is a better choice
> anyways...
>
> Is there *any* scenario where one would choose the enum over the
> static immutable...?

- If there is no need to access it at run time.
- Type deduction.

On Sunday, 2 September 2012 at 16:20:16 UTC, Timon Gehr wrote:
> On 09/02/2012 03:45 PM, monarch_dodra wrote:
>>
>> FYI: I get the exact same behavior in Windows. Not that it
>> matters, but it sounded like you were asking.
>>
>> I'm a bit confused now though: Why would someone want to use an
>> enum when they could use a static immutable instead?
>>
>> If I understood correctly, the enum will *always* be inlined
>> (doesn't create any actual symbols). But if you use a static
>> immutable, then the compiler will create an actual symbol, but
>> probably inline it away if it judges that is a better choice
>> anyways...
>>
>> Is there *any* scenario where one would choose the enum over the
>> static immutable...?
>
> - If there is no need to access it at run time.
> - Type deduction.

-Type deduction: Not really, I can just declare it as "immutable auto".
-no need to access it at run time. I guess.

On 09/02/2012 06:26 PM, monarch_dodra wrote:
> On Sunday, 2 September 2012 at 16:20:16 UTC, Timon Gehr wrote:
>> On 09/02/2012 03:45 PM, monarch_dodra wrote:
>>>
>>> FYI: I get the exact same behavior in Windows. Not that it
>>> matters, but it sounded like you were asking.
>>>
>>> I'm a bit confused now though: Why would someone want to use an
>>> enum when they could use a static immutable instead?
>>>
>>> If I understood correctly, the enum will *always* be inlined
>>> (doesn't create any actual symbols). But if you use a static
>>> immutable, then the compiler will create an actual symbol, but
>>> probably inline it away if it judges that is a better choice
>>> anyways...
>>>
>>> Is there *any* scenario where one would choose the enum over the
>>> static immutable...?
>>
>> - If there is no need to access it at run time.
>> - Type deduction.
>
> -Type deduction: Not really, I can just declare it as "immutable auto".

enum x = 2;

void main(){
    auto y = x;
    y = 3;
}


> -no need to access it at run time. I guess.

On 09/02/2012 06:45 AM, monarch_dodra wrote:

> Is there *any* scenario where one would choose the enum over the
> static immutable...?

That's a good question. If Timon Gehr's example is the only difference, I wonder whether the guidelines that I had come up with are still valuable? I would appreciate if someone could review the guidelines under the "How to use" section here:

  http://ddili.org/ders/d.en/const_and_immutable.html

Ali

On Sun, Sep 2, 2012 at 8:50 PM, Ali Çehreli <acehreli@yahoo.com> wrote:
> On 09/02/2012 06:45 AM, monarch_dodra wrote:
>
>> Is there *any* scenario where one would choose the enum over the static immutable...?

Due to Jonathan advice, I converted a part of my code (enum => static
this). At runtime, I got a 40% decrease in runtime, a *very* good
news. But then CTFE does not work anymore: some functions tell me the
static AA I use is not initialized (or whatever).
I tried to use if(__ctfe) but then I lose most of the speedup.

All in all, for my Pegged parser generator project, I ended up generating code specifically for compile-time (for CT parsing) and some other function for runtime. So yes, enums are useful for CT computation sometimes.

On 09/02/2012 12:24 PM, Philippe Sigaud wrote:
> On Sun, Sep 2, 2012 at 8:50 PM, Ali Çehreli<acehreli@yahoo.com>  wrote:
>> On 09/02/2012 06:45 AM, monarch_dodra wrote:
>>
>>> Is there *any* scenario where one would choose the enum over the
>>> static immutable...?
>
> Due to Jonathan advice, I converted a part of my code (enum =>  static
> this). At runtime, I got a 40% decrease in runtime, a *very* good
> news. But then CTFE does not work anymore: some functions tell me the
> static AA I use is not initialized (or whatever).
> I tried to use if(__ctfe) but then I lose most of the speedup.
>
> All in all, for my Pegged parser generator project, I ended up
> generating code specifically for compile-time (for CT parsing) and
> some other function for runtime. So yes, enums are useful for CT
> computation sometimes.

Thank you. Then I am sticking with the guidelines under the "How to use" section here:

  http://ddili.org/ders/d.en/const_and_immutable.html

There is some warning there against making arrays and associative arrays enums:

<quote>
enum constants bring a hidden cost when they are used for arrays or associative arrays [...] For that reason, it may make more sense to define arrays and associative arrays as immutable variables if they are going to be used more than once in the program.
</quote>

<quote>Consider the hidden cost of enum arrays and enum associative arrays. Define them as immutable variables if the arrays are large and they are used more than once in the program.</quote>

Ali