Type alias in C#

[peter.tornqvist]

Maybe I'm stupid or maybe I am missing the obvious, but I can't find a way
to define a type alias in C# for primitive types (class and interfaces I can
inherit from, no problem). I.e I want to declare a type that is an alias
for, say, int. Conceptually, this is what I want to do:

public MyIntType = int; // won't compile

Anyone knows how to do this?

--
Regards, Peter

[Marc Gravell]

On a class-file -by- class-file basis you can use (at the top)

using MyIntType = System.Int32;

I.e I want to declare a type that is an alias for, say, int

Well, which do you want to declare: a type or an alias? They are mutually
exclusive. You can't subclass a struct, however.

Marc

[peter.tornqvist]

Well, which do you want to declare: a type or an alias? They are mutually

exclusive. You can't subclass a struct, however.

What is the difference in C#? In Delphi (where I have the most experience),
you create an alias by doing:

type
MyIntType = integer;

and a new type deriving from another type with:

type
MyIntType = type integer;

I'd be interested knowing the different options available in C#

--
Regards, Peter

[Marc Gravell]

Well, in the "class" case, the two syntax demos would be

using SomeAlias = Full.Namespace.To.BaseClass;

vs.

class SomeClass : BaseClass {}

A: The first (alias) is purely a compiler trick *within a single source
file*, to allow two things:
1: (more commonly) to avoid name conflicts within a file without having to
use fully qualified names, e.g. you have a custom class called (bizarrely)
XmlDocument, and you are using System.Xml, so you might alias one of the two
(or both), e.g.
using MyXmlDocument = My.Namespace.XmlDocument;

this now means that in your class file you can use
MyXmlDocument doc = new MyXmlDocument();
etc without the risk of conflicts, *but* the compiled IL only knows about
My.Namespace.XmlDocument.

2: (less common) to allow the programmer to change the backing type.
Sometimes generics can help, but note that generics do not respect
arithmetic (or other) operators. So if you weren't sure if you needed long
or int, you could use
using SomeAlias = System.Int32;
and then
SomeAlias value = 0;
value += 5;
etc
And if you change your mind later you can change just the alias to Int64.
*If* all the operations are still supported, then it will compile and work,
(but may break your interfaces).

B: the second (inheritance) defines a new type in your assembly inherited
from the old. This will allow automatic casting in one direction only, and
*possibly* won't change the behaviour significantly, but is not a good idea.
As well as being messy, it won't work with interface, static, sealed,
struct, etc.

Marc

[Christopher Ireland]

"Marc Gravell" <ma**********@gmail.comwrote in message
news:OT**************@TK2MSFTNGP04.phx.gbl...

B: the second (inheritance) defines a new type in your assembly inherited
from the old. This will allow automatic casting in one direction only, and
*possibly* won't change the behaviour significantly, but is not a good
idea. As well as being messy, it won't work with interface, static,
sealed, struct, etc.

It also won't work with value types (System.Double, System.Int, System.Array
etc.) as they cannot be inherited from. The OP was talking about the [very
nice] Delphi language feature called 'type identity' which means the ability
to create a completely new value type based on one of the existing value
types. AFAIK, this can't be done in C#; you're stuck with using only the
predefined value types.

Chris.

[Marc Gravell]

He asked what the options were; I thought I laid out the options, and yes:
you are right: none of them include what he wants to do. But I never implied
that they would.

Out of interest, what (in Delphi) does this give you? It's been quite a
while since my last object-pascal days... can you add methods etc? If so,
then (looking to the future) possibly the C# 3.0 extension functions may be
of interest. But no use today.

It also won't work with value types...

Hence "struct" in that list.

Perhaps the "other other" alternative is to declare a struct that
encapsulates the required type, and provide an implicit cast operator in
both directions, plus any other operators etc that are needed (oh for some
static inheritance ;-p). A bit more messing than the OP would no-doubt want
(coming from the Delphi route), but achievable. I've done it many times.

Oh, and System.Array is a reference type.

Marc

[Carl Daniel [VC++ MVP]]

Marc Gravell wrote:

He asked what the options were; I thought I laid out the options, and
yes: you are right: none of them include what he wants to do. But I
never implied that they would.

Out of interest, what (in Delphi) does this give you? It's been quite
a while since my last object-pascal days... can you add methods etc?
If so, then (looking to the future) possibly the C# 3.0 extension
functions may be of interest. But no use today.

In a nutshell, it gives you the same thing that having Enums be distinct
types gives you - better error detection at compile time since mixing values
and variables from different domains without coersion will cause errors.

-cd

[Peter Thornqvist]

Thanks, Marc and Cristopher.

It's funny how MS has gone from typedef'ing everything in sight in C/C++ to
creating a language that doesn't allow it at all. This isn't critical to me,
but it would have been nice to be able to define something like

public Hwnd = IntPtr;

to make it more obvious what is expected when declaring method parameters
and interop signatures.

--
Regards, Peter

[Marc Gravell]

Cheers - good explanation

[drifts back over projects past... ahh... now I remember ;-p]

Marc

[Christopher Ireland]

"Marc Gravell" <ma**********@gmail.comwrote in message
news:eu**************@TK2MSFTNGP04.phx.gbl...

He asked what the options were; I thought I laid out the options, and yes:
you are right: none of them include what he wants to do. But I never
implied that they would.

OK.

Out of interest, what (in Delphi) does this give you?

The ability to easily define your own value types.

>It's been quite a while since my last object-pascal days... can you add
methods etc?

Not using that particular syntax route, no.

>If so, then (looking to the future) possibly the C# 3.0 extension
functions may be of interest. But no use today.

Possibly.

>It also won't work with value types...

Hence "struct" in that list.

Not all value types are structures, for example, enum.

Perhaps the "other other" alternative is to declare a struct that
encapsulates the required type, and provide an implicit cast operator in
both directions, plus any other operators etc that are needed (oh for some
static inheritance ;-p). A bit more messing than the OP would no-doubt
want (coming from the Delphi route), but achievable. I've done it many
times.

Sure you can. Hey, we could all program in assembly and notepad ;-)

Oh, and System.Array is a reference type.

Yup, you're right. You can't inherit from it though.

Chris.

[Marc Gravell]

I never said it was a /fantastic/ option - indeed I only added it as an
afterthought.

But it can be made to work... if the desire is strong enough.

Happy coding ;-p

Marc

[Dustin Campbell]

Thanks, Marc and Cristopher.

>
It's funny how MS has gone from typedef'ing everything in sight in
C/C++ to creating a language that doesn't allow it at all. This isn't
critical to me, but it would have been nice to be able to define
something like

public Hwnd = IntPtr;

to make it more obvious what is expected when declaring method
parameters and interop signatures.

Peter,

Marc mentioned a trick that I've used successfully in the past. Create a
new struct called "Hwnd" that is implicitly-convertible to IntPtr by overloading
the implicit-conversion operators. This has been especially useful because
methods can be added to the Hwnd struct that hide underlying P/Invoke methods.
Here's a basic example:

public struct HWnd: IWin32Window
{
// private fields...
private IntPtr m_Handle;

// constructors...
public HWnd(IntPtr handle)
{
return m_Handle = handle;
}

// P/Invoke methods...
[DllImport("user32.dll")]
private static extern int GetClassName(IntPtr hWnd, [Out] StringBuilder
lpClassName, int nMaxCount);

// public methods...
public string GetClassName()
{
const int MAX_LENGTH = 256;
StringBuilder classNameBuilder = new StringBuilder(MAX_LENGTH);
int count = GetClassName(m_Handle, classNameBuilder, MAX_LENGTH);
return classNameBuilder.ToString(0, count);
}

// IWin32Window properties...
public IntPtr Handle { get { return m_Handle; } }

// operators...
public static implicit operator IntPtr(HWnd hwnd)
{
return hwnd.Handle;
}
public static implict operator HWnd(IntPtr ptr)
{
return new HWnd(ptr);
}
}

Admittedly, there's a bit of extra code but it is a workable solution.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Christopher Ireland]

"Marc Gravell" <ma**********@gmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

>I never said it was a /fantastic/ option - indeed I only added it as an
afterthought.

OK

But it can be made to work... if the desire is strong enough.

Yes indeed.

Happy coding ;-p

Thank you, you too!

Chris.

[Peter Thornqvist]

Marc mentioned a trick that I've used successfully in the past. Create a

new struct called "Hwnd" that is implicitly-convertible to IntPtr by
overloading the implicit-conversion operators. This has been especially
useful because methods can be added to the Hwnd struct that hide
underlying P/Invoke methods.

That is indeed very powerful. Will the HWnd struct be properly
wrapped/unwrapped if I used it as parameter in an interop call, i.e if I did
this in another class (not in the HWnd struct):
public struct HWnd: IWin32Window
{
....
}

public class Win32{

[DllImport("user32.dll")]
private static extern int GetClassName(HWnd hWnd, [Out] StringBuilder
lpClassName, int nMaxCount);
}

would the HWnd parameter be correctly interpreted? Is that what the implicit
operator declarations does or is there something else as play here?

--
Regards, Peter

[Dave Sexton]

Hi Christopher,

>>It also won't work with value types...

Hence "struct" in that list.

Not all value types are structures, for example, enum.

All value-types are structs. Enum is a struct as well.

Anything that derives from System.ValueType is a value-type. When you declare
a struct in C#, the compiler will ensure that it derives from
System.ValueType.

System.Enum derives from System.ValueType.

Certain classes may expose value-type semantics, such as System.String or
custom classes that override Equals, but they are certainly not true
value-types in terms of managed memory.

--
Dave Sexton

[Dustin Campbell]

>Marc mentioned a trick that I've used successfully in the past.

>Create a new struct called "Hwnd" that is implicitly-convertible to
IntPtr by overloading the implicit-conversion operators. This has
been especially useful because methods can be added to the Hwnd
struct that hide underlying P/Invoke methods.

That is indeed very powerful. Will the HWnd struct be properly
wrapped/unwrapped if I used it as parameter in an interop call, i.e if
I did
this in another class (not in the HWnd struct):
public struct HWnd: IWin32Window
{
...
}
public class Win32{

[DllImport("user32.dll")]
private static extern int GetClassName(HWnd hWnd, [Out]
StringBuilder
lpClassName, int nMaxCount);
}

would the HWnd parameter be correctly interpreted? Is that what the
implicit operator declarations does or is there something else as play
here?

Yes, the HWnd parameter would be interpreted correctly but I'd be careful
using it in P/Invoke calls because there is always the potential that you
could change the struct later in a way that breaks the call in odd ways (for
example, if you added another field to support other code in the struct).

Here's a test console app to try:

using System;
using System.ComponentModel;
using System.Windows.Forms;
using System.Runtime.InteropServices;
using System.Text;

namespace ConsoleTest
{
class Program
{
[STAThread]
static void Main(string[] args)
{
Form form = new Form();
HWnd formHandle = form.Handle;
Console.WriteLine(GetClassName(formHandle));
}

// P/Invoke methods...
[DllImport("user32.dll")]
private static extern int GetClassName(HWnd hWnd, [Out] StringBuilder
lpClassName, int nMaxCount);

// public methods...
public static string GetClassName(HWnd hWnd)
{
const int MAX_LENGTH = 256;
StringBuilder classNameBuilder = new StringBuilder(MAX_LENGTH);
int count = GetClassName(hWnd, classNameBuilder, MAX_LENGTH);
if (count == 0)
throw new Win32Exception();

return classNameBuilder.ToString(0, count);
}
}

public struct HWnd: IWin32Window
{
// private fields...
private IntPtr m_Handle;
private bool m_Value;

// constructors...
public HWnd(IntPtr handle)
{
m_Handle = handle;
m_Value = true;
}

// IWin32Window properties...
public IntPtr Handle { get { return m_Handle; } }

// operators...
public static implicit operator IntPtr(HWnd hwnd)
{
return hwnd.Handle;
}
public static implicit operator HWnd(IntPtr ptr)
{
return new HWnd(ptr);
}
}
}

This will fail. However, if you remove the "m_Value" field from the HWnd
struct, it works fine.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uR**************@TK2MSFTNGP04.phx.gbl...

Hi Christopher,

>>>It also won't work with value types...
Hence "struct" in that list.

Not all value types are structures, for example, enum.

All value-types are structs. Enum is a struct as well.

I'm not so sure. Lutz Roeder's refector declares Enum as a 'public abstract
class' and the System.Type class has a specific 'IsEnum' property, the only
listed value type to have its own specific 'IsX' property. It may not a be a
'class' (IsClass returns false) as such, but I'm not convinced that it's a
struct either.

Anything that derives from System.ValueType is a value-type. When you
declare a struct in C#, the compiler will ensure that it derives from
System.ValueType.

True. All structures are value types.

>
System.Enum derives from System.ValueType.

Which does not necessarily make it a structure.

Certain classes may expose value-type semantics, such as System.String or
custom classes that override Equals, but they are certainly not true
value-types in terms of managed memory.

No, value types have to 'derive' from System.ValueType. This does not mean
that they inherit from it, however, as structures cannot inherit classes
(and System.ValueType is a class). Other value types, such as double, appear
as structures in Reflector and have 'ValueType' as a 'base type' without
seeming to make any other reference to ValueType in their members.
System.String makes no reference to ValueType in any of it's members either,
but derives directly from object; this class does share a number of
interfaces with value types (IComparable, IConvertible, IComparable<T>,
IEquatable<T>) which could lead to the 'value-type' semantics you refer to.

Chris.

[Dustin Campbell]

>>>>It also won't work with value types...

>>>>>
Hence "struct" in that list.

Not all value types are structures, for example, enum.

All value-types are structs. Enum is a struct as well.

I'm not so sure. Lutz Roeder's refector declares Enum as a 'public
abstract class' and the System.Type class has a specific 'IsEnum'
property, the only listed value type to have its own specific 'IsX'
property. It may not a be a 'class' (IsClass returns false) as such,
but I'm not convinced that it's a struct either.

Structs are not really a CLR notion -- value types are. Part of the confusion
here is that the term "struct" and "value type" are being passed around as
synonomous -- which they really aren't. All C# structs are value types but
not all value types are C# structs.

At the CLR level, there are only classes. In fact, interfaces are actually
classes too but have a specific bit set that denotes them as interfaces and
causes them to be treated differently. A value type is simply a class that
derives from System.ValueType. An enum is a class that derives from System.Enum
(which derives from System.ValueType). The CLR simply treats classes that
derive from System.ValueType in a special way -- passing them by value instead
of by reference and allocating them on the stack when declared in a method
body.

Lutz Roeder's reflector can be a bit misleading if you leave the language
set to C#. Setting it to IL will show the reality of how types are really
declared. Consider this declaration of System.Int32 in IL:

..class public sequential ansi serializable sealed beforefieldinit Int32
extends System.ValueType
implements System.IComparable, System.IFormattable, System.IConvertible,
System.IComparable`1<int32>, System.IEquatable`1<int32>

It is really a class that derives from System.ValueType and implements a
set of specific interfaces. There is nothing remarkably different about how
System.Int32 is declared versus, say, System.StringComparer:

..class public abstract auto ansi serializable beforefieldinit StringComparer
extends object
implements System.Collections.IComparer, System.Collections.IEqualityComparer,
System.Collections.Generic.IComparer`1<string>, System.Collections.Generic.IEqualityComparer`1<str ing>

The only difference is the base type that it derives from. Enums are no different
-- consider System.StringComparison:

..class public auto ansi serializable sealed StringComparison
extends System.Enum

Enums *are* classes at the CLR level. Reflection attempts to make distinctions
between different types to clarify them for the client. So, it is not a great
tool to use to try and understand how things are really put together at the
metadata-level.

>System.Enum derives from System.ValueType.

Which does not necessarily make it a structure.

You're correct, it makes it a value type. Clarification of terminology is
definitely needed here.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Chris,

>>>>It also won't work with value types...
Hence "struct" in that list.

Not all value types are structures, for example, enum.

All value-types are structs. Enum is a struct as well.

I'm not so sure. Lutz Roeder's refector declares Enum as a 'public abstract
class' and the System.Type class has a specific 'IsEnum' property, the only
listed value type to have its own specific 'IsX' property. It may not a be a
'class' (IsClass returns false) as such, but I'm not convinced that it's a
struct either.

Interesting that Reflector shows "class" - probably because of Enum's abstract
nature, but it's definately a struct from which the CLR allows other structs
to derive.

I think this MSDN doc explains it best:

"Enum Structure"
http://msdn2.microsoft.com/en-us/lib...stem.enum.aspx

And here's some more interesting information on the subject:

"ValueType overrides the virtual methods from Object with more appropriate
implementations for value types. See also Enum, which inherits from ValueType.

Data types are separated into value types and reference types. Value types are
either stack-allocated or allocated inline in a structure. Reference types are
heap-allocated. Both reference and value types are derived from the ultimate
base class Object. In cases where it is necessary for a value type to behave
like an object, a wrapper that makes the value type look like a reference
object is allocated on the heap, and the value type's value is copied into it.
The wrapper is marked so the system knows that it contains a value type. This
process is known as boxing, and the reverse process is known as unboxing.
Boxing and unboxing allow any type to be treated as an object."

"ValueType Class"
http://msdn2.microsoft.com/en-us/lib...valuetype.aspx

<snip>

>Certain classes may expose value-type semantics, such as System.String or
custom classes that override Equals, but they are certainly not true
value-types in terms of managed memory.

No, value types have to 'derive' from System.ValueType. This does not mean
that they inherit from it, however, as structures cannot inherit classes
(and System.ValueType is a class).

I wasn't referring to polymorphism at all. But now that you mention it, how
is derivation different from inheritance? I always thought they were the same
:)

Other value types, such as double, appear as structures in Reflector and
have 'ValueType' as a 'base type' without seeming to make any other
reference to ValueType in their members. System.String makes no reference to
ValueType in any of it's members either, but derives directly from object;
this class does share a number of interfaces with value types (IComparable,
IConvertible, IComparable<T>, IEquatable<T>) which could lead to the
'value-type' semantics you refer to.

You wrote, "Not all value types are structures". I was simply explaining that
classes with value-type semantics are not actual value-types when managed by
the CLR.

So it seems that all value-types are structures.

BTW, Reflector is a nice tool to have (I use it myself) but how it displays
classes or structs in its GUI might not be such a good indication of how they
are actually being managed by the CLR. I'd prefer to stick with the docs on
this one.

--
Dave Sexton

[Christopher Ireland]

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

Enums *are* classes at the CLR level. Reflection attempts to make
distinctions between different types to clarify them for the client. So,
it is not a great tool to use to try and understand how things are really
put together at the metadata-level.

Many thanks for your detailed reply, Dustin!

You're right, looking at the issue using the IL setting of Reflector is
somewhat more enlightening here than using the C# setting.

I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated differently?

Thanks again,

Chris.

[Dave Sexton]

Hi Dustin,

Thanks for the input, but I don't think this is simply a debate on semantics.
But just to address that concern, I do think that all value-types can be
considered structs. The term "structure" was not coined in C#.

"Data types are separated into value types and reference types. Value types
are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]

System.Enum is also documented as a "structure" (see link in related post).

The CLR only "seeing" classes is irrelevant. The fact of the matter is, any
object that derives from ValueType can be considered a structure. Any object
that doesn't, can't.

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>>>>>It also won't work with value types...
>>
Hence "struct" in that list.
>
Not all value types are structures, for example, enum.

All value-types are structs. Enum is a struct as well.

I'm not so sure. Lutz Roeder's refector declares Enum as a 'public
abstract class' and the System.Type class has a specific 'IsEnum'
property, the only listed value type to have its own specific 'IsX'
property. It may not a be a 'class' (IsClass returns false) as such,
but I'm not convinced that it's a struct either.

Structs are not really a CLR notion -- value types are. Part of the
confusion here is that the term "struct" and "value type" are being passed
around as synonomous -- which they really aren't. All C# structs are value
types but not all value types are C# structs.

At the CLR level, there are only classes. In fact, interfaces are actually
classes too but have a specific bit set that denotes them as interfaces and
causes them to be treated differently. A value type is simply a class that
derives from System.ValueType. An enum is a class that derives from
System.Enum (which derives from System.ValueType). The CLR simply treats
classes that derive from System.ValueType in a special way -- passing them
by value instead of by reference and allocating them on the stack when
declared in a method body.

Lutz Roeder's reflector can be a bit misleading if you leave the language
set to C#. Setting it to IL will show the reality of how types are really
declared. Consider this declaration of System.Int32 in IL:

.class public sequential ansi serializable sealed beforefieldinit Int32
extends System.ValueType
implements System.IComparable, System.IFormattable,
System.IConvertible, System.IComparable`1<int32>, System.IEquatable`1<int32>

It is really a class that derives from System.ValueType and implements a set
of specific interfaces. There is nothing remarkably different about how
System.Int32 is declared versus, say, System.StringComparer:

.class public abstract auto ansi serializable beforefieldinit StringComparer
extends object
implements System.Collections.IComparer,
System.Collections.IEqualityComparer,
System.Collections.Generic.IComparer`1<string>,
System.Collections.Generic.IEqualityComparer`1<str ing>

The only difference is the base type that it derives from. Enums are no
different -- consider System.StringComparison:

.class public auto ansi serializable sealed StringComparison
extends System.Enum

Enums *are* classes at the CLR level. Reflection attempts to make
distinctions between different types to clarify them for the client. So, it
is not a great tool to use to try and understand how things are really put
together at the metadata-level.

>>System.Enum derives from System.ValueType.

Which does not necessarily make it a structure.

You're correct, it makes it a value type. Clarification of terminology is
definitely needed here.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Chris,

I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated differently?

Probably because you can derive from them, which is uncommon for structs ;)

--
Dave Sexton

"Christopher Ireland" <ci******@gmail.comwrote in message
news:em**************@TK2MSFTNGP03.phx.gbl...

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>Enums *are* classes at the CLR level. Reflection attempts to make
distinctions between different types to clarify them for the client. So, it
is not a great tool to use to try and understand how things are really put
together at the metadata-level.

Many thanks for your detailed reply, Dustin!

You're right, looking at the issue using the IL setting of Reflector is
somewhat more enlightening here than using the C# setting.

I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated differently?

Thanks again,

Chris.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...
Hello Dave,

>>Certain classes may expose value-type semantics, such as System.String
or custom classes that override Equals, but they are certainly not true
value-types in terms of managed memory.

No, value types have to 'derive' from System.ValueType. This does not
mean that they inherit from it, however, as structures cannot inherit
classes (and System.ValueType is a class).

I wasn't referring to polymorphism at all. But now that you mention it,
how is derivation different from inheritance? I always thought they were
the same :)

Mmm, the docs do make that distinction. In the docs for 'Structs' is says:
"All value types in C# inherently derive from ValueType, which inherits from
Object."

As Dustin points out, I guess this is an artefact of C#'s implementation of
the CLI; if structs can't inherit from classes (as it says in the docs, "A
struct cannot inherit from another struct or class") then you can't go
around saying that structs "inherit" from ValueType without somehow
contradicting yourself.

So it seems that all value-types are structures.

Nope.

BTW, Reflector is a nice tool to have (I use it myself) but how it
displays classes or structs in its GUI might not be such a good indication
of how they are actually being managed by the CLR. I'd prefer to stick
with the docs on this one.

I think using the 'IL' setting is much more illustrative solution!

Chris.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:eT**************@TK2MSFTNGP03.phx.gbl...

Hi Chris,

>I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated
differently?

Probably because you can derive from them, which is uncommon for structs
;)

Maybe you mean that they can be derived from, in the sense of being able to
create an enum which derives from (inherits) a byte, short etc. Rather like
a class ;-)

Chris.

[Dustin Campbell]

Thanks for the input, but I don't think this is simply a debate on

semantics. But just to address that concern, I do think that all
value-types can be considered structs. The term "structure" was not
coined in C#.

"Data types are separated into value types and reference types. Value
types are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]
System.Enum is also documented as a "structure" (see link in related
post).

System.Enum is actually a bit different from the types that derive from it.
System.Enum is certainly a structure. And, in accordance with the features
of structures, it declares static methods and implements interfaces. However,
types that derive from System.Enum cannot declare methods or implement interfaces.
So, are enums still considered structures? They are value types, yes but
they seem to have a feature set that separates them from structures.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dustin Campbell]

Maybe you mean that they can be derived from, in the sense of being

able to create an enum which derives from (inherits) a byte, short
etc. Rather like a class ;-)

That's just the underlying type though -- not true derivation.

<rant>
And speaking of this feature of enums, why in the world do I have to explicitly
type-cast an enum to its base type. This seems a bit like overkill:

public enum Fruit: byte { Banana, Apple, Orange }
private byte GetFruitIndex(Fruit fruit) {
return (byte)fruit;
}

If I declared the type specifically, it would be useful to be able to get
rid of the type-cast and clean up the code a bit. :-)
</rant>

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Chris,

<snip>

>So it seems that all value-types are structures.

Nope.

Well, I'm going to have to continue to disagree with you on this point.

I think I've supplied ample documentation to prove otherwise. Even outside of
a C# context MSDN refers to value-types as structures. Consider the documents
that describe each of the primitive types, including System.Enum. The docs
all refer to each of them as "structure".

If you can produce evidence of a FCL ValueType that isn't referred to as a
structure in any MSDN documentation, then I might believe you.

I'll admit that calling all value-types "structs", not "structures", might be
misleading. But I do feel that they are semantically equivalent even though
"struct" really has special meaning to the C# compiler. Their equivalency is
in how they both refer to System.ValueType as the base class for an object.

--
Dave Sexton

[Dustin Campbell]

I think I've supplied ample documentation to prove otherwise. Even

outside of a C# context MSDN refers to value-types as structures.
Consider the documents that describe each of the primitive types,
including System.Enum. The docs all refer to each of them as
"structure".

If you can produce evidence of a FCL ValueType that isn't referred to
as a structure in any MSDN documentation, then I might believe you.

System.Enum is referred to as a "structure" in the documentation but any
type that derives is referred to as an "enumeration".

http://msdn2.microsoft.com/en-us/lib...omparison.aspx

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Dustin,

>Thanks for the input, but I don't think this is simply a debate on
semantics. But just to address that concern, I do think that all
value-types can be considered structs. The term "structure" was not
coined in C#.

"Data types are separated into value types and reference types. Value
types are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]
System.Enum is also documented as a "structure" (see link in related
post).

System.Enum is actually a bit different from the types that derive from it.
System.Enum is certainly a structure. And, in accordance with the features
of structures, it declares static methods and implements interfaces.
However, types that derive from System.Enum cannot declare methods or
implement interfaces. So, are enums still considered structures? They are
value types, yes but they seem to have a feature set that separates them
from structures.

So the question then is whether a structure is something that must be able to
implement interfaces and declare methods, or just something that derives from
System.ValueType.

Interesting question. Enums are special, however, because they are base
classes and structures, which is uncommon. Also, the C# compiler seems to
enforce certain rules about them.

Since I've been maintaining that the term structure refers to objects deriving
from System.ValueType, and because objects that derive from System.Enum
indirectly inherit from System.ValueType, I'm going to consider them to be
structures as well. I do believe that all value-types may be considered
structures because they can all be allocated on the stack, where as
reference-types can't.

I've been trying to stay away from C# here, and just discuss whether all
value-types are structures (although I have been referring to them as structs
from time to time, which as I said in a related post might have been a bit
misleading - but it's habit). I believe that you can derive from System.Enum
and add methods or implement interfaces in CIL, so your point doesn't hold
true on a framework level (as opposed to just C#). Please correct me if I'm
wrong.

--
Dave Sexton

[Dave Sexton]

Hi Chris,

>>I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated
differently?

Probably because you can derive from them, which is uncommon for structs ;)

Maybe you mean that they can be derived from, in the sense of being able to
create an enum which derives from (inherits) a byte, short etc. Rather like
a class ;-)

No, I mean "derive from System.Enum". Reflector will show you what I mean.
Just look for an enum type and view the "Base Class" folder.

--
Dave Sexton

[Dave Sexton]

Hi Dustin,

<snip>

And speaking of this feature of enums, why in the world do I have to
explicitly type-cast an enum to its base type. This seems a bit like
overkill:

public enum Fruit: byte { Banana, Apple, Orange }
private byte GetFruitIndex(Fruit fruit) {
return (byte)fruit;
}

If I declared the type specifically, it would be useful to be able to get
rid of the type-cast and clean up the code a bit. :-)

Yes, but some people (I'm still not sure if I'm one of them) believe that the
lack of type-safety in Enums is problematic, and to allow implicit coercion to
the underlying type would further break whatever type-safety exists now.

I assume that the authors figured that:

1. Enums represent an enumeration of values and an instance represents a
single selection. Implicit coercion from the underlying type is like
"selecting" a value because the enum actually does represent the value to
which it is assigned.
2. Implicit coercion to the underlying type is like saying that the enum
instance IS the underlying type, which is misleading.

Just a guess :)

--
Dave Sexton

[Dustin Campbell]

Just a guess :)

I'm aware of the reasoning but I'm not convinced that this isn't a case of
overkill.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Dustin,

System.Enum is referred to as a "structure" in the documentation but any
type that derives is referred to as an "enumeration".

That may be true, but in the same way that you would refer to any type that
derives from System.Exception as an "exception", but exceptions are still
objects, just like Enum-derived types are still ValueTypes, and therefore
structures. They can still be allocated on the stack.

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>I think I've supplied ample documentation to prove otherwise. Even
outside of a C# context MSDN refers to value-types as structures.
Consider the documents that describe each of the primitive types,
including System.Enum. The docs all refer to each of them as
"structure".

If you can produce evidence of a FCL ValueType that isn't referred to
as a structure in any MSDN documentation, then I might believe you.

System.Enum is referred to as a "structure" in the documentation but any
type that derives is referred to as an "enumeration".

http://msdn2.microsoft.com/en-us/lib...omparison.aspx

Best Regards,
Dustin Campbell
Developer Express Inc.

[Ben Voigt]

Since I've been maintaining that the term structure refers to objects

deriving from System.ValueType, and because objects that derive from
System.Enum indirectly inherit from System.ValueType, I'm going to
consider them to be structures as well. I do believe that all value-types
may be considered structures because they can all be allocated on the
stack, where as reference-types can't.

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

But that's somewhat redundant.

I don't see how this could get any clearer, than "structs" is a strict
subset of "value types". The MSDN article "Value Types (C#)" says:
The value types consist of two main categories:

a.. Structs

b.. Enumerations

Structs fall into these categories:

a.. Numeric types

a.. Integral types

b.. Floating-point types

c.. decimal

b.. bool

c.. User defined structs.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
Hi Dave,

If you can produce evidence of a FCL ValueType that isn't referred to as a
structure in any MSDN documentation, then I might believe you.

I'll admit that calling all value-types "structs", not "structures", might
be misleading. But I do feel that they are semantically equivalent even
though "struct" really has special meaning to the C# compiler. Their
equivalency is in how they both refer to System.ValueType as the base
class for an object.

I'm quite happy with the IL definition of value types being classes which
extend System.ValueType. The docs define 'structure' as a 'user defined
value type' seeming to stear away from the issue of whether all value types
are 'built in' as structures.

Chris.

[Christopher Ireland]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:OL**************@TK2MSFTNGP03.phx.gbl...

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

If we replace 'value-types' in the above with 'System.ValueType', wouldn't
that be even better?

Chris.

[Dustin Campbell]

I've been trying to stay away from C# here, and just discuss whether

all value-types are structures (although I have been referring to them
as structs from time to time, which as I said in a related post might
have been a bit misleading - but it's habit). I believe that you can
derive from System.Enum and add methods or implement interfaces in
CIL, so your point doesn't hold true on a framework level (as opposed
to just C#). Please correct me if I'm wrong.

That's incorrect. This will fail to assemble:

..assembly extern mscorlib { auto }
..assembly FruitTest { }
..module FruitTest.exe

..class public auto ansi sealed Fruit
extends [mscorlib]System.Enum
{
.field public specialname int32 __value
.field public static literal valuetype Fruit Banana = int32(1)
.field public static literal valuetype Fruit Apple = int32(2)
.field public static literal valuetype Fruit Orange = int32(3)

.method public int32 GetIndex() cil managed
{
ldfld int32 Fruit::__value
ret
}
}

The error is "error -- Method in enum".

So, clearly, enumerations are *not* structures because they lack all but
one of the features of a structure.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Ben,

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

But that's somewhat redundant.

Well, no. I was implying that the term "structure" refers to an object that
may be allocated on the stack, and that value-types are therefore structures.

I don't see how this could get any clearer, than "structs" is a strict
subset of "value types".

But "structure" isn't. System.Enum documentation on MSDN refers to it as a
"structure".

Again, my use of the term "struct" is out of habit - I meant "structure"
whenever it was used outside of the realm of C#, which was probably most, if
not all of the time here. Sorry for any confusion.

The fact that C# refers to an enumeration as an enum, not "struct" (the
keyword) is irrelevant to this discussion. Remember, the original statement
was, "Not all value types are structures". It wasn't, "Not all value types
are structs".

--
Dave Sexton

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:OL**************@TK2MSFTNGP03.phx.gbl...

>Since I've been maintaining that the term structure refers to objects
deriving from System.ValueType, and because objects that derive from
System.Enum indirectly inherit from System.ValueType, I'm going to consider
them to be structures as well. I do believe that all value-types may be
considered structures because they can all be allocated on the stack, where
as reference-types can't.

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

But that's somewhat redundant.

I don't see how this could get any clearer, than "structs" is a strict
subset of "value types". The MSDN article "Value Types (C#)" says:
The value types consist of two main categories:

a.. Structs

b.. Enumerations

Structs fall into these categories:

a.. Numeric types

a.. Integral types

b.. Floating-point types

c.. decimal

b.. bool

c.. User defined structs.

[Dave Sexton]

Hi Chris,

If we replace 'value-types' in the above with 'System.ValueType', wouldn't
that be even better?

No, because replacing what I wrote (and meant) with your own terms wouldn't
make my point any clearer :)

--
Dave Sexton

"Christopher Ireland" <ci******@gmail.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:OL**************@TK2MSFTNGP03.phx.gbl...

>Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

If we replace 'value-types' in the above with 'System.ValueType', wouldn't
that be even better?

Chris.

[Dave Sexton]

Hi Chris,

<snip>

>The docs define 'structure' as a 'user defined value type' seeming to stear
away from the issue of whether all value types are 'built in' as structures.

I'd like to see that documentation (not saying I don't believe you, but it
will help to prove your point).

--
Dave Sexton

[Dave Sexton]

Hi Dustin,

Ok, so ILASM also prevents the declaration of methods on enums, but does that
change the definition of structure from being "any object that can be
allocated on the stack"?

Admittedly, I have no formal definition to cite. I've inferred the meaning of
the term "structure" from experience using .NET and its use in MSDN
documentation, which I've cited already.

I'm waiting on Chris to supply evidence to the contrary (within the scope of
managed programming, I might add).

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>I've been trying to stay away from C# here, and just discuss whether
all value-types are structures (although I have been referring to them
as structs from time to time, which as I said in a related post might
have been a bit misleading - but it's habit). I believe that you can
derive from System.Enum and add methods or implement interfaces in
CIL, so your point doesn't hold true on a framework level (as opposed
to just C#). Please correct me if I'm wrong.

That's incorrect. This will fail to assemble:

.assembly extern mscorlib { auto }
.assembly FruitTest { }
.module FruitTest.exe

.class public auto ansi sealed Fruit
extends [mscorlib]System.Enum
{
.field public specialname int32 __value
.field public static literal valuetype Fruit Banana = int32(1)
.field public static literal valuetype Fruit Apple = int32(2)
.field public static literal valuetype Fruit Orange = int32(3)
.method public int32 GetIndex() cil managed
{
ldfld int32 Fruit::__value
ret
}
}

The error is "error -- Method in enum".

So, clearly, enumerations are *not* structures because they lack all but one
of the features of a structure.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Ben Voigt]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...

Hi Dustin,

Ok, so ILASM also prevents the declaration of methods on enums, but does
that change the definition of structure from being "any object that can be
allocated on the stack"?

That could be used as a working definition of "value type", but not
"structure", as everyone else here has been explaining.

>
Admittedly, I have no formal definition to cite. I've inferred the
meaning of the term "structure" from experience using .NET and its use in
MSDN documentation, which I've cited already.

I'm waiting on Chris to supply evidence to the contrary (within the scope
of managed programming, I might add).

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>>I've been trying to stay away from C# here, and just discuss whether
all value-types are structures (although I have been referring to them
as structs from time to time, which as I said in a related post might
have been a bit misleading - but it's habit). I believe that you can
derive from System.Enum and add methods or implement interfaces in
CIL, so your point doesn't hold true on a framework level (as opposed
to just C#). Please correct me if I'm wrong.

That's incorrect. This will fail to assemble:

.assembly extern mscorlib { auto }
.assembly FruitTest { }
.module FruitTest.exe

.class public auto ansi sealed Fruit
extends [mscorlib]System.Enum
{
.field public specialname int32 __value
.field public static literal valuetype Fruit Banana = int32(1)
.field public static literal valuetype Fruit Apple = int32(2)
.field public static literal valuetype Fruit Orange = int32(3)
.method public int32 GetIndex() cil managed
{
ldfld int32 Fruit::__value
ret
}
}

The error is "error -- Method in enum".

So, clearly, enumerations are *not* structures because they lack all but
one of the features of a structure.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:O6**************@TK2MSFTNGP03.phx.gbl...

Hi Chris,

>If we replace 'value-types' in the above with 'System.ValueType',
wouldn't that be even better?

No, because replacing what I wrote (and meant) with your own terms
wouldn't make my point any clearer :)

So when you talk about 'structures' you are referring to the
System.ValueType class? If so, then we're there :-)

Chris.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...
Hi Dave,

I'm waiting on Chris to supply evidence to the contrary (within the scope
of managed programming, I might add).

Here it is (for what it's worth):
http://msdn2.microsoft.com/en-us/lib...wf(VS.80).aspx
(scroll down to 'structure')

"structure
A user-defined value type. Like a class, structures can contain
constructors, constants, fields, methods, properties, indexers, operators,
and nested types. Unlike classes, however, structures do not support
inheritance. See also: class, field, indexer, nested type, property, value
type."

The key here is 'user-defined', stated explicity to distance the meaning
from 'built in', possibly.

Chris.

[Dave Sexton]

Hi Chris,

Interesting, thanks. However, that means either that definition is wrong or
the docs that state System.Enum and all the FCL primitives are structures is
wrong :)

Also, I've heard many people refer to structure as I've defined it. I guess
you haven't.

Because of that definition there is some ambiguity in the term now, however
I'm still not sure that one small paragraph should invalidate the use of the
term throughout the FCL documentation. Do you?

--
Dave Sexton

"Christopher Ireland" <ci******@gmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...
Hi Dave,

>I'm waiting on Chris to supply evidence to the contrary (within the scope
of managed programming, I might add).

Here it is (for what it's worth):
http://msdn2.microsoft.com/en-us/lib...wf(VS.80).aspx
(scroll down to 'structure')

"structure
A user-defined value type. Like a class, structures can contain
constructors, constants, fields, methods, properties, indexers, operators,
and nested types. Unlike classes, however, structures do not support
inheritance. See also: class, field, indexer, nested type, property, value
type."

The key here is 'user-defined', stated explicity to distance the meaning
from 'built in', possibly.

Chris.

[Dave Sexton]

Hi Ben,

>Ok, so ILASM also prevents the declaration of methods on enums, but does
that change the definition of structure from being "any object that can be
allocated on the stack"?

That could be used as a working definition of "value type", but not
"structure", as everyone else here has been explaining.

No, you were trying to explain how that's true for the C# keyword, "struct",
which is different than the term "structure". But even the keyword, "struct"
is used to represent types that derive from System.ValueType for the C#
compiler, so they share common ground. "enum" is purely a compiler term used
to make declaring Enums easier and has no bearing on this discussion.

I've determined that the term "structure" represents value-types based on how
the term is used in MSDN docs and other managed information that I've read,
and from experience working with other professionals that use the term the
same. I've supplied evidence of this. Chris has supplied evidence to the
contrary, however I don't think it's enough yet to entirely invalidate the use
of the term throughout MSDN, at the very least.

Value-types (types that derive from System.ValueType), allow for memory
allocation in-line, which may very well be on the stack.

Therefore, if the term "structure" may be used to refer to types that derive
from ValueType [MSDN docs], and all ValueTypes may be allocated on the stack,
then the definition I supplied appears to be one in the same:

Structures are value-types; any object that can be allocated on the stack.

C# "structs" are structures.

C# "enums" are Enums, which are structures as well, but certainly aren't
"structs". However, nobody meant that they were.

Chris wrote:

Not all value types are structures, for example, enum.

I think I've proven otherwise if you consider MSDNs use of the term.

--
Dave Sexton

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Hello Dave,

Because of that definition there is some ambiguity in the term now,
however I'm still not sure that one small paragraph should invalidate the
use of the term throughout the FCL documentation. Do you?

I've no idea. I guess the major advantage of computational languages over
natural languages are that they are less ambiguous. As far as the code goes,
we both know that the c# struct and c# enum are value types but only one of
them is a struct. Referring to value types as structures could lead to
confusion when others refer to c# struct(s) as structures, as I did.

Chris.

[Christopher Ireland]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:en**************@TK2MSFTNGP03.phx.gbl...
Hello Dave,

Chris wrote:

>Not all value types are structures, for example, enum.

I think I've proven otherwise if you consider MSDNs use of the term.

For the record, in my phrase above when I said 'structures' I was referring
to 'c# struct'(s). Sorry for any confusion this may have caused.

Chris.

[Dave Sexton]

Hi Chris,

Understood - I believe that I inappropriately used the term "struct" when
referring to "structure" in some cases.

And BTW, I believe that the definition of "structure" that you cited should
really be the definition of the C# keyword "struct". Don't you agree?

--
Dave Sexton

"Christopher Ireland" <ci******@gmail.comwrote in message
news:eP**************@TK2MSFTNGP03.phx.gbl...

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:en**************@TK2MSFTNGP03.phx.gbl...
Hello Dave,

>Chris wrote:

>>Not all value types are structures, for example, enum.

I think I've proven otherwise if you consider MSDNs use of the term.

For the record, in my phrase above when I said 'structures' I was referring
to 'c# struct'(s). Sorry for any confusion this may have caused.

Chris.

[Dave Sexton]

Hi Chris,

Agreed.

--
Dave Sexton

"Christopher Ireland" <ci******@gmail.comwrote in message
news:em**************@TK2MSFTNGP04.phx.gbl...

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Hello Dave,

>Because of that definition there is some ambiguity in the term now, however
I'm still not sure that one small paragraph should invalidate the use of
the term throughout the FCL documentation. Do you?

I've no idea. I guess the major advantage of computational languages over
natural languages are that they are less ambiguous. As far as the code goes,
we both know that the c# struct and c# enum are value types but only one of
them is a struct. Referring to value types as structures could lead to
confusion when others refer to c# struct(s) as structures, as I did.

Chris.