Expected? Parameters of type Int32 (and thus __value enum) implicitly converted to DateTime

[Christopher Crooker]

We had a function with the signature:

Function(Object *, DateTime, DateTime, EnumType)

and then changed the class some and there was a 4 parameter function with
the signature:

Function(Object *, DateTime, DateTime, DateTime)

The previous code had not been changed and to our surprise the function
compiled without error. I did a little testing and found any Int32 value
would be accepted as a DateTime parameter. Why is this not a compiler
error?

This definitely would have led to bugs would we have not known about the
functions that needed to be changed. There isn't even a constructor that
takes an Int32 specifically (though there is one for Int64), so the result
of this conversion is less than obvious. Is this documented somewhere or a
bug?

Christopher Crooker
Acquist Incorporated

[Hendrik Schober]

"Christopher Crooker" <ch***@AcquistIncorporated.com> wrote:

We had a function with the signature:

Function(Object *, DateTime, DateTime, EnumType)

and then changed the class some and there was a 4 parameter function with
the signature:

Function(Object *, DateTime, DateTime, DateTime)

The previous code had not been changed and to our surprise the function
compiled without error. I did a little testing and found any Int32 value
would be accepted as a DateTime parameter. Why is this not a compiler
error?
I don't know the definition of 'DateTime', but I
suspect it has a non-explicit constructor taking
and 'Int32'?
If so, the bug is in this class' design.
Christopher Crooker
Acquist Incorporated

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers org

"My hair style calls into immediate question all my judgements."
Scott Meyers
(http://www.google.de/groups?selm=MPG...ws.hevanet.com)

[Christopher Crooker]

Okay, that makes sense. I was overlooking the obvious here. However, does
anyone know if this type of automatic conversion between an Enum type and
something expecting an Int32 will always work? I read somewhere, a
knowledge base article maybe, that eventually there would be an
implemntation of Enums in Managed C++ that can have a different base type
(Short, Int64, etc.) but will this implemntation also make them seperate
types as far as the compiler is concerned or will Enum values always be
treated as equivalent to their base types native counterpart?

Thanks,
Chris

"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:OD**************@tk2msftngp13.phx.gbl...

Hi Christopher,

We had a function with the signature:

Function(Object *, DateTime, DateTime, EnumType)

and then changed the class some and there was a 4 parameter function with the signature:

Function(Object *, DateTime, DateTime, DateTime)

The previous code had not been changed and to our surprise the function
compiled without error. I did a little testing and found any Int32 value would be accepted as a DateTime parameter. Why is this not a compiler
error?

This definitely would have led to bugs would we have not known about the
functions that needed to be changed. There isn't even a constructor that takes an Int32 specifically (though there is one for Int64), so the result of this conversion is less than obvious. Is this documented somewhere

or a

bug?

Looking at the generated code is easy to see what is happening: The Int32
value is getting extended to an Int64 value, then the DateTime constructor
you're mentioning is getting invoked. Unintuive, for sure, but perfectly
valid according to C++ rules.

--
Tomas Restrepo
to****@mvps.org

[Tomas Restrepo \(MVP\)]

Hi Christopher,

Okay, that makes sense. I was overlooking the obvious here. However, does anyone know if this type of automatic conversion between an Enum type and
something expecting an Int32 will always work?
Compile, yes. Work? depends.
I read somewhere, a
knowledge base article maybe, that eventually there would be an
implemntation of Enums in Managed C++ that can have a different base type
(Short, Int64, etc.)
That's already implemented. For example:
public __value enum E : __int64
{
E1 = 1,
E2 = 2
};

but will this implemntation also make them seperate
types as far as the compiler is concerned or will Enum values always be
treated as equivalent to their base types native counterpart?

AFAIK, yes. Notice however that C++ usually allows silent narrowing
conversions on integral types, with possibly undefined results (well, not
undefined, but implementation defined anyway).

--
Tomas Restrepo
to****@mvps.org