Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
January 07, 2008 New enum features | ||||
---|---|---|---|---|
| ||||
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 |
January 07, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sivo Schilling | 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
|
January 07, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sivo Schilling | 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);
}
---
|
January 07, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to torhu | 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
|
January 07, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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
|
January 07, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sivo Schilling | 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?
>> 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?
>
> 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
|
January 08, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sivo Schilling | Looks like a compiler bug to me. |
January 08, 2008 Re: New enum features | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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?
>>> 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?
>>
>> 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.
|
Copyright © 1999-2021 by the D Language Foundation