473,320 Members | 2,193 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Binding a switch to an Enum at compile time?

Is it possible to bind a switch statement to an Enum such that a compile-time
error is raised if not all values within the Enum are handled in the switch
statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

....

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case
for MyVar.four
}

Thanks, Adam

Nov 16 '05 #1
13 3001
Adam Blair wrote:
Is it possible to bind a switch statement to an Enum such that a compile-time
error is raised if not all values within the Enum are handled in the switch
statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

....

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case
default:
System.Diagnostics.Debug.Assert(false, "unhandled enum value");
break;
for MyVar.four
}

Thanks, Adam


That compiler option does not exist (or I must be unaware of it).
I suggest calling Debug.Assert(false) in the default clause. This way
you are notified of any unhandled values, that is, in the debug version
of your application. The release version will silently ignore the
assert statement. You could also throw an exception in the default
case, but this would also happen in the release version, which might not
be very appealing.
BTW, I added some code inline.

Cheers,

Benoit.
Nov 16 '05 #2
Thanks for your response. Your idea is useful, but unfortunately it still
relies on traversing all code paths (and developers to be watching the Output
window).

Adam

"Benoit Vreuninckx" wrote:
Adam Blair wrote:
Is it possible to bind a switch statement to an Enum such that a compile-time
error is raised if not all values within the Enum are handled in the switch
statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

....

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case


default:
System.Diagnostics.Debug.Assert(false, "unhandled enum value");
break;
for MyVar.four
}

Thanks, Adam


That compiler option does not exist (or I must be unaware of it).
I suggest calling Debug.Assert(false) in the default clause. This way
you are notified of any unhandled values, that is, in the debug version
of your application. The release version will silently ignore the
assert statement. You could also throw an exception in the default
case, but this would also happen in the release version, which might not
be very appealing.
BTW, I added some code inline.

Cheers,

Benoit.

Nov 16 '05 #3
A compilation error doesn't make sense there since during compile time, the
value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good suggestion
there. Debug.Assert will not require the developers to look at the output
window.

You could always throw an exception for a little bit more intrusive alert.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
news:4A**********************************@microsof t.com...
Is it possible to bind a switch statement to an Enum such that a compile-time error is raised if not all values within the Enum are handled in the switch statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

...

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case
for MyVar.four
}

Thanks, Adam

Nov 16 '05 #4
What i was after is an indication - at compilation - if there *could ever be*
a value of myVar that is not handled.

"Sahil Malik" wrote:
A compilation error doesn't make sense there since during compile time, the
value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good suggestion
there. Debug.Assert will not require the developers to look at the output
window.

You could always throw an exception for a little bit more intrusive alert.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
news:4A**********************************@microsof t.com...
Is it possible to bind a switch statement to an Enum such that a

compile-time
error is raised if not all values within the Enum are handled in the

switch
statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

...

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case
for MyVar.four
}

Thanks, Adam


Nov 16 '05 #5
Right, and as I said .. the values are not populated at compile time, so the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
What i was after is an indication - at compilation - if there *could ever be* a value of myVar that is not handled.

"Sahil Malik" wrote:
A compilation error doesn't make sense there since during compile time, the value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good suggestion there. Debug.Assert will not require the developers to look at the output window.

You could always throw an exception for a little bit more intrusive alert.
- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
news:4A**********************************@microsof t.com...
Is it possible to bind a switch statement to an Enum such that a

compile-time
error is raised if not all values within the Enum are handled in the

switch
statement? I realise you can use default: to catch unhandled cases, but of course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

...

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case for MyVar.four
}

Thanks, Adam


Nov 16 '05 #6
My point is that the value myVar *must* be one of the 4 values in the Enum
MyEnum (so the compiler does in fact know what we might be sending down that
code path - it is either one, two, three or four; nothing else) but only 3 of
them are handled by the switch statement. I know that at compilation myVar
has no value, but it is logically possible to determine that the switch
statement does not handle all possible values.

regards, Adam

"Sahil Malik" wrote:
Right, and as I said .. the values are not populated at compile time, so the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
What i was after is an indication - at compilation - if there *could ever

be*
a value of myVar that is not handled.

"Sahil Malik" wrote:
A compilation error doesn't make sense there since during compile time, the value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good suggestion there. Debug.Assert will not require the developers to look at the output window.

You could always throw an exception for a little bit more intrusive alert.
- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
news:4A**********************************@microsof t.com...
> Is it possible to bind a switch statement to an Enum such that a
compile-time
> error is raised if not all values within the Enum are handled in the
switch
> statement? I realise you can use default: to catch unhandled cases, but of > course this is only at run-time.
>
> Example:
> public enum MyEnum
> {
> one, two, three, four
> }
>
> ...
>
> MyEnum myVar;
> switch (myVar)
> {
> case MyEnum.one:
> break;
> case MyEnum.two:
> break;
> case MyEnum.three:
> break;
> // I would like this to raise a compilation error as there is no case > for MyVar.four
> }
>
> Thanks, Adam
>


Nov 16 '05 #7
"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:CA**********************************@microsof t.com...
My point is that the value myVar *must* be one of the 4 values in the Enum
MyEnum (so the compiler does in fact know what we might be sending down
that
code path - it is either one, two, three or four; nothing else)
Unfortunately, that's not the case. myVar can be assigned any value from
the enum's underlying type (usually an integer).

but only 3 of
them are handled by the switch statement. I know that at compilation myVar
has no value, but it is logically possible to determine that the switch
statement does not handle all possible values.
Your best approach here might be a custom FxCop rule. In addition to
screening for all values from the enum, you might also want to consider
also enforcing using of a default clause to handle possible values that are
not defined by the enum.

regards, Adam

"Sahil Malik" wrote:
Right, and as I said .. the values are not populated at compile time, so
the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
> What i was after is an indication - at compilation - if there *could
> ever

be*
> a value of myVar that is not handled.
>
> "Sahil Malik" wrote:
>
> > A compilation error doesn't make sense there since during compile
> > time,

the
> > value of myVar is not populated.
> > You do want a runtime error though, and Debug.Assert is a good

suggestion
> > there. Debug.Assert will not require the developers to look at the

output
> > window.
> >
> > You could always throw an exception for a little bit more intrusive

alert.
> >
> > - Sahil Malik
> > http://dotnetjunkies.com/weblog/sahilmalik
> >
> >
> >
> > "Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
> > news:4A**********************************@microsof t.com...
> > > Is it possible to bind a switch statement to an Enum such that a
> > compile-time
> > > error is raised if not all values within the Enum are handled in
> > > the
> > switch
> > > statement? I realise you can use default: to catch unhandled cases,

but of
> > > course this is only at run-time.
> > >
> > > Example:
> > > public enum MyEnum
> > > {
> > > one, two, three, four
> > > }
> > >
> > > ...
> > >
> > > MyEnum myVar;
> > > switch (myVar)
> > > {
> > > case MyEnum.one:
> > > break;
> > > case MyEnum.two:
> > > break;
> > > case MyEnum.three:
> > > break;
> > > // I would like this to raise a compilation error as there is
> > > no

case
> > > for MyVar.four
> > > }
> > >
> > > Thanks, Adam
> > >
> >
> >
> >


Nov 16 '05 #8
> System.Diagnostics.Debug.Assert(false, "unhandled enum value");

For such things

System.Diagnostics.Debug.Fail("unhandled enum value");

is shorter :)

"Benoit Vreuninckx" <bv*****@nospam.skynet.be> schrieb im Newsbeitrag
news:41**********************@news.skynet.be...
Adam Blair wrote:
Is it possible to bind a switch statement to an Enum such that a compile-time error is raised if not all values within the Enum are handled in the switch statement? I realise you can use default: to catch unhandled cases, but of course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

....

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no
case
default:
System.Diagnostics.Debug.Assert(false, "unhandled enum value");
break;
for MyVar.four
}

Thanks, Adam


That compiler option does not exist (or I must be unaware of it).
I suggest calling Debug.Assert(false) in the default clause. This way
you are notified of any unhandled values, that is, in the debug version
of your application. The release version will silently ignore the
assert statement. You could also throw an exception in the default
case, but this would also happen in the release version, which might not
be very appealing.
BTW, I added some code inline.

Cheers,

Benoit.

Nov 16 '05 #9
Sahil Malik wrote:
Right, and as I said .. the values are not populated at compile time, so the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
What i was after is an indication - at compilation - if there *could ever


be*
a value of myVar that is not handled.

"Sahil Malik" wrote:

A compilation error doesn't make sense there since during compile time,
the
value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good
suggestion
there. Debug.Assert will not require the developers to look at the
output
window.

You could always throw an exception for a little bit more intrusive
alert.
- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
news:4A**********************************@micro soft.com...

Is it possible to bind a switch statement to an Enum such that a

compile-time

error is raised if not all values within the Enum are handled in the

switch

statement? I realise you can use default: to catch unhandled cases,
but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

...

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no
case
for MyVar.four
}

Thanks, Adam



Hi,

He just wanted to know if the compiler is able to check if all the
possible values of an enumeration have a corresponding case in the
switch statement. So if one adds a new value to the enumeration, the
compiler should throw a warning/error on all switch statements not
explicitly handling that new value.

Cheers,
Benoit.
Nov 16 '05 #10
I disagree. If i define an Enum as in my example and then attempt to assign
myVar to, say, 5 (myVar = 5) I recieve the build error "Cannot implicitly
convert type 'int' to 'MyEnum'". myVar *must* be one of the 4 values in the
Enum and so this scenario could be trapped at compile time.

I can accept that this is not possible (apart from the partial solutions
already posted) but maybe a syntax could be supported along the lines of

switch (myVar : MyEnum)
{
case one:
....
}
"Nicole Calinoiu" wrote:
"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:CA**********************************@microsof t.com...
My point is that the value myVar *must* be one of the 4 values in the Enum
MyEnum (so the compiler does in fact know what we might be sending down
that
code path - it is either one, two, three or four; nothing else)


Unfortunately, that's not the case. myVar can be assigned any value from
the enum's underlying type (usually an integer).

but only 3 of
them are handled by the switch statement. I know that at compilation myVar
has no value, but it is logically possible to determine that the switch
statement does not handle all possible values.


Your best approach here might be a custom FxCop rule. In addition to
screening for all values from the enum, you might also want to consider
also enforcing using of a default clause to handle possible values that are
not defined by the enum.

regards, Adam

"Sahil Malik" wrote:
Right, and as I said .. the values are not populated at compile time, so
the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
> What i was after is an indication - at compilation - if there *could
> ever
be*
> a value of myVar that is not handled.
>
> "Sahil Malik" wrote:
>
> > A compilation error doesn't make sense there since during compile
> > time,
the
> > value of myVar is not populated.
> > You do want a runtime error though, and Debug.Assert is a good
suggestion
> > there. Debug.Assert will not require the developers to look at the
output
> > window.
> >
> > You could always throw an exception for a little bit more intrusive
alert.
> >
> > - Sahil Malik
> > http://dotnetjunkies.com/weblog/sahilmalik
> >
> >
> >
> > "Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
> > news:4A**********************************@microsof t.com...
> > > Is it possible to bind a switch statement to an Enum such that a
> > compile-time
> > > error is raised if not all values within the Enum are handled in
> > > the
> > switch
> > > statement? I realise you can use default: to catch unhandled cases,
but of
> > > course this is only at run-time.
> > >
> > > Example:
> > > public enum MyEnum
> > > {
> > > one, two, three, four
> > > }
> > >
> > > ...
> > >
> > > MyEnum myVar;
> > > switch (myVar)
> > > {
> > > case MyEnum.one:
> > > break;
> > > case MyEnum.two:
> > > break;
> > > case MyEnum.three:
> > > break;
> > > // I would like this to raise a compilation error as there is
> > > no
case
> > > for MyVar.four
> > > }
> > >
> > > Thanks, Adam
> > >
> >
> >
> >


Nov 16 '05 #11
Hang on, you are right! I have succeeded in assigning myVar to 5 (myVar =
(MyEnum)5;) so I accept your point. Although I am slightly confused why it
should be possible to assign a Enum typed variable to a value outside of the
enum range.

Adam

"Nicole Calinoiu" wrote:
"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:CA**********************************@microsof t.com...
My point is that the value myVar *must* be one of the 4 values in the Enum
MyEnum (so the compiler does in fact know what we might be sending down
that
code path - it is either one, two, three or four; nothing else)


Unfortunately, that's not the case. myVar can be assigned any value from
the enum's underlying type (usually an integer).

but only 3 of
them are handled by the switch statement. I know that at compilation myVar
has no value, but it is logically possible to determine that the switch
statement does not handle all possible values.


Your best approach here might be a custom FxCop rule. In addition to
screening for all values from the enum, you might also want to consider
also enforcing using of a default clause to handle possible values that are
not defined by the enum.

regards, Adam

"Sahil Malik" wrote:
Right, and as I said .. the values are not populated at compile time, so
the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik

"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:A2**********************************@microsof t.com...
> What i was after is an indication - at compilation - if there *could
> ever
be*
> a value of myVar that is not handled.
>
> "Sahil Malik" wrote:
>
> > A compilation error doesn't make sense there since during compile
> > time,
the
> > value of myVar is not populated.
> > You do want a runtime error though, and Debug.Assert is a good
suggestion
> > there. Debug.Assert will not require the developers to look at the
output
> > window.
> >
> > You could always throw an exception for a little bit more intrusive
alert.
> >
> > - Sahil Malik
> > http://dotnetjunkies.com/weblog/sahilmalik
> >
> >
> >
> > "Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in message
> > news:4A**********************************@microsof t.com...
> > > Is it possible to bind a switch statement to an Enum such that a
> > compile-time
> > > error is raised if not all values within the Enum are handled in
> > > the
> > switch
> > > statement? I realise you can use default: to catch unhandled cases,
but of
> > > course this is only at run-time.
> > >
> > > Example:
> > > public enum MyEnum
> > > {
> > > one, two, three, four
> > > }
> > >
> > > ...
> > >
> > > MyEnum myVar;
> > > switch (myVar)
> > > {
> > > case MyEnum.one:
> > > break;
> > > case MyEnum.two:
> > > break;
> > > case MyEnum.three:
> > > break;
> > > // I would like this to raise a compilation error as there is
> > > no
case
> > > for MyVar.four
> > > }
> > >
> > > Thanks, Adam
> > >
> >
> >
> >


Nov 16 '05 #12
"Sahil Malik" <co*****************@nospam.com> wrote in message
news:eT**************@TK2MSFTNGP15.phx.gbl...
In short - not possible to do.


Nonsense.

The compiler knows that myVar is of type MyEnum.
The compiler knows that MyEnum can legally have any of 4 values.
The compiler knows that only 3 of them are represented in switch
statement.

Hence the compiler knows enough to generate a warning.

Your argument that myVar could also hold illegal values is irrelevant.

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com

Nov 16 '05 #13
"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:26**********************************@microsof t.com...
Hang on, you are right! I have succeeded in assigning myVar to 5 (myVar =
(MyEnum)5;) so I accept your point. Although I am slightly confused why it
should be possible to assign a Enum typed variable to a value outside of
the
enum range.
At least two reasons:

1. Inter-version compatibility.
2. Combinations in flagged enums.

These are also reasons why it might be best to use FxCop to detect
deviations from full coverage in a switch. In some cases, it might be
desirable to omit particular values and/or a default clause, and FxCop
allows one to save reasons for exceptions to rule violations, so you
wouldn't need to re-visit each exception at each compilation.


Adam

"Nicole Calinoiu" wrote:
"Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
news:CA**********************************@microsof t.com...
> My point is that the value myVar *must* be one of the 4 values in the
> Enum
> MyEnum (so the compiler does in fact know what we might be sending down
> that
> code path - it is either one, two, three or four; nothing else)


Unfortunately, that's not the case. myVar can be assigned any value from
the enum's underlying type (usually an integer).

> but only 3 of
> them are handled by the switch statement. I know that at compilation
> myVar
> has no value, but it is logically possible to determine that the switch
> statement does not handle all possible values.


Your best approach here might be a custom FxCop rule. In addition to
screening for all values from the enum, you might also want to consider
also enforcing using of a default clause to handle possible values that
are
not defined by the enum.

> regards, Adam
>
> "Sahil Malik" wrote:
>
>> Right, and as I said .. the values are not populated at compile time,
>> so
>> the
>> compiler has no way of knowing what you might be sending down that
>> code
>> path. Which is why the default keyword.
>>
>> In short - not possible to do.
>>
>> - Sahil Malik
>> http://dotnetjunkies.com/weblog/sahilmalik
>>
>>
>>
>> "Adam Blair" <Ad*******@discussions.microsoft.com> wrote in message
>> news:A2**********************************@microsof t.com...
>> > What i was after is an indication - at compilation - if there *could
>> > ever
>> be*
>> > a value of myVar that is not handled.
>> >
>> > "Sahil Malik" wrote:
>> >
>> > > A compilation error doesn't make sense there since during compile
>> > > time,
>> the
>> > > value of myVar is not populated.
>> > > You do want a runtime error though, and Debug.Assert is a good
>> suggestion
>> > > there. Debug.Assert will not require the developers to look at the
>> output
>> > > window.
>> > >
>> > > You could always throw an exception for a little bit more
>> > > intrusive
>> alert.
>> > >
>> > > - Sahil Malik
>> > > http://dotnetjunkies.com/weblog/sahilmalik
>> > >
>> > >
>> > >
>> > > "Adam Blair" <Adam Bl***@discussions.microsoft.com> wrote in
>> > > message
>> > > news:4A**********************************@microsof t.com...
>> > > > Is it possible to bind a switch statement to an Enum such that a
>> > > compile-time
>> > > > error is raised if not all values within the Enum are handled in
>> > > > the
>> > > switch
>> > > > statement? I realise you can use default: to catch unhandled
>> > > > cases,
>> but of
>> > > > course this is only at run-time.
>> > > >
>> > > > Example:
>> > > > public enum MyEnum
>> > > > {
>> > > > one, two, three, four
>> > > > }
>> > > >
>> > > > ...
>> > > >
>> > > > MyEnum myVar;
>> > > > switch (myVar)
>> > > > {
>> > > > case MyEnum.one:
>> > > > break;
>> > > > case MyEnum.two:
>> > > > break;
>> > > > case MyEnum.three:
>> > > > break;
>> > > > // I would like this to raise a compilation error as there
>> > > > is
>> > > > no
>> case
>> > > > for MyVar.four
>> > > > }
>> > > >
>> > > > Thanks, Adam
>> > > >
>> > >
>> > >
>> > >
>>
>>
>>


Nov 16 '05 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

20
by: Glenn Venzke | last post by:
I'm writing a class with a method that will accept 1 of 3 items listed in an enum. Is it possible to pass the item name without the enum name in your calling statement? EXAMPLE: public enum...
27
by: Yuriy Solodkyy | last post by:
Hi VS 2005 beta 2 successfully compiles the following: using System; using System.Collections.Generic; using System.Text; namespace ConsoleApplication1 { class Program {
11
by: ME | last post by:
In C# the following code generates a compiler error ("A constant value is expected"): public void Test(string value) { switch (value) { case SimpleEnum.One.ToString(): MessageBox.Show("Test...
13
by: Fei Liu | last post by:
Hi Group, I've got a problem I couldn't find a good solution. I am working with scientific data files in netCDF format. One of the properties of netCDF data is that the actual type of data is only...
34
by: Steven Nagy | last post by:
So I was needing some extra power from my enums and implemented the typesafe enum pattern. And it got me to thinking... why should I EVER use standard enums? There's now a nice little code...
3
by: MariuszC | last post by:
Hello, I have used some library where is defined enum like: typedef enum Enum1 { ENUM1_1, ENUM1_2, ENUM1_3, ENUM1_4, ENUM1_5 }; In my code I have defined: typedef enum Enum2 { ENUM2_1,...
11
by: Peter Kirk | last post by:
Hi i have a string variable which can take one of a set of many values. Depending on the value I need to take different (but related) actions. So I have a big if/else-if construct - but what is...
7
by: Kurt | last post by:
Hi. I have a c++ project that is basically a set of implementation hiding classes, so that we can convert a static lib with a lot of dependancies into a dynamic lib with less dependancies, so that...
10
by: koolj96825 | last post by:
{ const int state_black = 1 ; const int state_white = 2 ; int state ; state = state_black ; switch(state) {
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.