www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - New enum features

reply Sivo Schilling <i-b-p gmx.net> writes:
I have made a small test to investigate the additional enum features
coming with DMD 2.009.

I'm using dmd to compile this test program:

import std.stdio;

// anonymous enum
enum
{
  ival = 1304,
  dval = 1965.0,
  chr1 = 'a',
  chrm = "This is a anonymous enum member string."
}

// manifest constants
enum ival_ = 1304;
enum dval_ = 1965.0;
enum chr1_ = 'b';
enum chrm_ = "This is a manifest constant string.";


void main()
{
  writefln("Test anonymous enum members.");
  writefln("----------------------------");
  writefln("ival = ", ival);
  writefln("dval = ", dval);
  writefln("chr1 = ", chr1);
  writefln("chrm = ", chrm, "\n");

  writefln("Test manifest constants.");
  writefln("------------------------");
  writefln("ival_ = ", ival_);
  writefln("dval_ = ", dval_);
  writefln("chr1_ = ", chr1_);
  writefln("chrm_ = ", chrm_, "\n");

}

and got these results:

Test anonymous enum members.
----------------------------
ival = 1304
dval = 1965
chr1 = a
chrm = This is a anonymous enum member string.

Test manifest constants.
------------------------
ival_ = 1304
dval_ = 1965
chr1_ = b
chrm_ = ¸B        €ÿ Ä… ´3B H­  1   ´3B


The last line of output looks wrong, but using a string as an
anonymous enum member gives the desired result.

Is there a difference between an anonymous enum member and a manifest
constant considering a string?

Regards
Jan 07 2008
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Sivo Schilling wrote:

 
 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



I wouldn't expect so.  In fact I wonder if it shouldn't be a compile 
error to pass a manifest constant string to a run-time function.  How 
can you take the address of something with no storage?


Sean
Jan 07 2008
parent reply Sivo Schilling <i-b-p gmx.net> writes:
Sean Kelly Wrote:


 Sivo Schilling wrote:

 
 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



 I wouldn't expect so.  In fact I wonder if it shouldn't be a compile 
 error to pass a manifest constant string to a run-time function.  How 
 can you take the address of something with no storage?
 
 
 Sean



Why should it a compile time error ? From the specs I guess
that the enhanced enum feature acts as "#define" in C/C++.
And it works as shown in my simple code example.
The question is bracketing or no bracketing!

With this small modification of the original code

// enum chrm_ = "This is a manifest constant string.";
enum { chrm_ = "This is a manifest constant string."}

the result is as expected.

In this light the specs considering manifest constants
should be verified for arrays of any kind.

Sivo
Jan 07 2008
parent reply Sean Kelly <sean f4.ca> writes:
Sivo Schilling wrote:

 Sean Kelly Wrote:
 

 Sivo Schilling wrote:

 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



 error to pass a manifest constant string to a run-time function.  How 
 can you take the address of something with no storage?



 Why should it a compile time error ? From the specs I guess
 that the enhanced enum feature acts as "#define" in C/C++.



Oh good point.  So storage is provided for manifest string constants 
which are actually used in the program, just like string literals.  That 
makes sense.  But I do still consider the brackets vs. no brackets issue 
to be a bug.  Both should print the string successfully then.


Sean
Jan 07 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:

 Sivo Schilling wrote:

 Sean Kelly Wrote:


 Sivo Schilling wrote:

 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



 error to pass a manifest constant string to a run-time function.  How 
 can you take the address of something with no storage?



 Why should it a compile time error ? From the specs I guess
 that the enhanced enum feature acts as "#define" in C/C++.



 Oh good point.  So storage is provided for manifest string constants 
 which are actually used in the program, just like string literals.  That 
 makes sense.  But I do still consider the brackets vs. no brackets issue 
 to be a bug.  Both should print the string successfully then.
 
 
 Sean



I hope this isn't intentional behavior... if so, it's WAY too confusing, 
and should be changed.
Jan 07 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Sivo Schilling wrote:

 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



I tried it with an int array, seems that's broken too.  I'm hoping for a 
bugfix release soon, so we can try out the features properly. :)

---
import std.stdio;

enum int[] array = [1, 2, 3];

void main()
{
    writefln(array); // ok, prints [1, 2, 3]

    foreach (x; array)  // access violation with 2.009
       writefln(x);
}
---
Jan 07 2008
parent Sivo Schilling <i-b-p gmx.net> writes:
torhu Wrote:


 Sivo Schilling wrote:

 Is there a difference between an anonymous enum member and a manifest
 constant considering a string?



 I tried it with an int array, seems that's broken too.  I'm hoping for a 
 bugfix release soon, so we can try out the features properly. :)
 
 ---
 import std.stdio;
 
 enum int[] array = [1, 2, 3];
 
 void main()
 {
     writefln(array); // ok, prints [1, 2, 3]
 
     foreach (x; array)  // access violation with 2.009
        writefln(x);
 }
 ---



I´ve got the same results with your code. But with a small
modification your code works without any error messages:

---
import std.stdio;

enum {int[] array = [1, 2, 3]}

void main()
{
    writefln(array); // ok, prints [1, 2, 3]

    foreach (x; array)  
       writefln(x);
    // ok, prints
    // 1
    // 2
    // 3 
}
---

So, I believe the reason could be bracketing or no bracketing? 
But trying the latter case is it a bug ?

Regards
Jan 07 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Looks like a compiler bug to me.
Jan 07 2008