Typedef Equivalent in .NET

[vvv]

Hi All,

Do we have anything in .NET which is equivalent to C++'s Typedef .

Regards,
Vasanth

[Mattias Sjögren]

Do we have anything in .NET which is equivalent to C++'s Typedef .

Not in VB.NET, no. The closest thing is that you can do

Imports SomeAlias = SomeType

and then use SomeAlias instead of SomeType. But that's pretty limited
compared to typedef.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[vvv]

Thanks. It works, but as you said it is restricted to the file where it is
declared.

If you have anyother round about way to achieve this, pls let me know.

I was trying to create wrapper classes for all the primitive datatypes, but
as vb.net doesn't support operator overloading, i was not able to use it.
Even if it supports i will have to use 'new' keyword for declaring any
variables. That is again a problem.

Vasanth

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:ua**************@TK2MSFTNGP12.phx.gbl...

Do we have anything in .NET which is equivalent to C++'s Typedef .

Not in VB.NET, no. The closest thing is that you can do

Imports SomeAlias = SomeType

and then use SomeAlias instead of SomeType. But that's pretty limited
compared to typedef.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Armin Zingler]

"vvv" <so*****@microsoft.com> schrieb

I was trying to create wrapper classes for all the primitive
datatypes, but as vb.net doesn't support operator overloading, i was
not able to use it. Even if it supports i will have to use 'new'
keyword for declaring any variables. That is again a problem.

Out of interest: Why do you need it? Neither I needed typedefs nor operator
overloading so far.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Herfried K. Wagner [MVP]]

* "Armin Zingler" <az*******@freenet.de> scripsit:

I was trying to create wrapper classes for all the primitive
datatypes, but as vb.net doesn't support operator overloading, i was
not able to use it. Even if it supports i will have to use 'new'
keyword for declaring any variables. That is again a problem.

Out of interest: Why do you need it? Neither I needed typedefs nor operator
overloading so far.

Maybe it would be usefup to "typedef" a "HWND" type for window handles,
etc., but I don't need it too. It would cause more confusion than it
increases readability.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Vasanth]

You would require this to achieve some kind of program dicipline and control
of data type usage.
In enterprise applications, some developers might use datatype 'Single' for
Price field while others use decimal, similarly Integer/Long for Quantity
field.

If you create typedefs for those primitive datatypes like the following (C++
syntax)
"Types.h"
Typedef Integer TQuantity;
Typedef Decimal TPrice;

"App.cpp"
# Include "Types.h"
TQuantity mQty;
TPrice mPrice;

we can force the developer to always use these typedefs through out our
application. And in future if you need to change the datatype for Quantity
field from Integer to Long, it would be easy changing it in one place
without touching other parts of our application.

Vasanth

"Armin Zingler" <az*******@freenet.de> wrote in message
news:eA*************@TK2MSFTNGP10.phx.gbl...

"vvv" <so*****@microsoft.com> schrieb

I was trying to create wrapper classes for all the primitive
datatypes, but as vb.net doesn't support operator overloading, i was
not able to use it. Even if it supports i will have to use 'new'
keyword for declaring any variables. That is again a problem.
Out of interest: Why do you need it? Neither I needed typedefs nor

operator overloading so far.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Vasanth,

I was trying to create wrapper classes for all the primitive datatypes, but
Remember that "the primitive datatypes" are structures, if you want to avoid
using "new" then consider defining your wrapper Classes as wrapper
Structures instead.

Of course be aware of the differences between a value type (Structure) and a
reference type (Class).

Note when Whidbey (VS.NET 2004) ships in the later half of 2004 we will have
operator overloading! Along with conversion operators, which allows you to
"hide" the new.

http://blogs.gotdotnet.com/cambecc/p...1-127195cceeab

Out of curiosity why are you wrapping the primitive datatypes? Or should I
ask why are you wanting a typedef?

In my experience using a typedef is different then creating a wrapper. IMHO
Creating a wrapper where I would have used a typedef seems to be more pain
then gain.

Hope this helps
Jay

"vvv" <so*****@microsoft.com> wrote in message
news:eY**************@tk2msftngp13.phx.gbl... Thanks. It works, but as you said it is restricted to the file where it is
declared.

If you have anyother round about way to achieve this, pls let me know.

I was trying to create wrapper classes for all the primitive datatypes, but as vb.net doesn't support operator overloading, i was not able to use it.
Even if it supports i will have to use 'new' keyword for declaring any
variables. That is again a problem.

Vasanth

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:ua**************@TK2MSFTNGP12.phx.gbl...

Do we have anything in .NET which is equivalent to C++'s Typedef .

Not in VB.NET, no. The closest thing is that you can do

Imports SomeAlias = SomeType

and then use SomeAlias instead of SomeType. But that's pretty limited
compared to typedef.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Armin Zingler]

"Vasanth" <so*****@microsoft.com> schrieb

You would require this to achieve some kind of program dicipline and
control of data type usage.
In enterprise applications, some developers might use datatype
'Single' for Price field while others use decimal, similarly
Integer/Long for Quantity field.

If you create typedefs for those primitive datatypes like the
following (C++ syntax)
"Types.h"
Typedef Integer TQuantity;
Typedef Decimal TPrice;

"App.cpp"
# Include "Types.h"
TQuantity mQty;
TPrice mPrice;

we can force the developer to always use these typedefs through out
our application. And in future if you need to change the datatype for
Quantity field from Integer to Long, it would be easy changing it in
one place without touching other parts of our application.

I see the advantage, but it also drove me crazy when finding out what the
real data type of a variable is. Is a WORD 16 or 32 bits for example. In
addition some types are case sensitive or conditional compilation is used,
so it was often very confusing for me - but I am not a C specialist at all.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Jay B. Harlow [MVP - Outlook]]

Vasanth,
Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not
supported in .NET.

You could always use MSWish to submit a request that TypeDefs be supported
in .NET.

http://register.microsoft.com/mswish/suggestion.asp
I would only define "wrappers" for the primitive types if I truly needed to
define a new type. For example a Duration type that represents an Age.

Where Duration has a lot in common with Integer, however Duration has unique
constraints (>= 0) and unique behaviors. Integer would be an implementation
detail of Duration, Duration would not be a wrapper per se for Integer. I
generally consider wrappers to be proxy objects (Proxy Pattern), Duration is
not a Proxy pattern!

I would normally start Age as an integer, then using Refactoring
(http://www.refactoring.com) I would change it to the Duration type when a
Duration type was needed. Obviously when we get Operator Overloading in
Whidbey it would make implementing a Duration type easier.

Hope this helps
Jay

"Vasanth" <so*****@microsoft.com> wrote in message
news:OA**************@TK2MSFTNGP10.phx.gbl...

You would require this to achieve some kind of program dicipline and control of data type usage.
In enterprise applications, some developers might use datatype 'Single' for Price field while others use decimal, similarly Integer/Long for Quantity
field.

If you create typedefs for those primitive datatypes like the following (C++ syntax)
"Types.h"
Typedef Integer TQuantity;
Typedef Decimal TPrice;

"App.cpp"
# Include "Types.h"
TQuantity mQty;
TPrice mPrice;

we can force the developer to always use these typedefs through out our
application. And in future if you need to change the datatype for Quantity
field from Integer to Long, it would be easy changing it in one place
without touching other parts of our application.

Vasanth

"Armin Zingler" <az*******@freenet.de> wrote in message
news:eA*************@TK2MSFTNGP10.phx.gbl...

"vvv" <so*****@microsoft.com> schrieb

I was trying to create wrapper classes for all the primitive
datatypes, but as vb.net doesn't support operator overloading, i was
not able to use it. Even if it supports i will have to use 'new'
keyword for declaring any variables. That is again a problem.

Out of interest: Why do you need it? Neither I needed typedefs nor

operator

overloading so far.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Herfried K. Wagner [MVP]]

* "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:

Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not
supported in .NET.

If you have a look at C(++) code, it's easy to see why typedefs are not
a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case).

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Jay B. Harlow [MVP - Outlook]]

Herfried & Vasanth,

If you have a look at C(++) code, it's easy to see why typedefs are not
a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case). That's why I included fortunately!

I find they're a good idea (in C code) if properly managed, as you pointed
out they are rarely properly managed.

For the Win32 APIs I find them very handy! For most other cases I find them
more trouble then they are worth. However with System.Int16, Int32, Int64,
IntPtr the API reason largely goes away. Seeing as my APIs are in a single
Module I can do the Alias thing to make the API defs look "pretty" ;-)

With OOP (VB.NET, C++) I would define an actual type when I needed it,
rather then using TypeDef, as one of the reasons for OOP is introducing new
Types. (Don't remember specifically where I read that, but it makes sense).
This also allows giving that type custom behavior!

Note I will use typedefs in C++ when working with templates, simple because
its easier to remember the parameters to the template, ss the typedef
encapsulates the templates type parameters.

Also due to the stricter type checking (in C# & Option Strict On in VB.NET)
in .NET I suspect typedefs will not work as well as the original poster
wants.

Option Strict On

' fictitious VB.NET syntax
TypeDef TQuantity As Integer
TypeDef TPrice As Decimal

Public Sub Main
Dim i As Integer
Dim quantity As TQuantity
i = quantity
quantity = i
End Sub

If the above were allowed implicitly (as in C++) you will ultimately have
problems as changing TQuantity to Single will cause compile errors.

However if TypeDef types required explicit conversions, then changing
TQuantity to Single should not cause compile errors, as the type conversion
would deal with it.

i = CType(quantity, Integer)
quantity = CType(i, TQuantity )

In either case the TypeDef would have to be emitted as Meta Data, so
referencing the assembly allows using the TypeDef'd type. I suspect the JIT
may need to maintain Type info for the TypeDefs, however the executable code
could be (should be) shared with the underlying Type (which I understand the
JIT will do for Generics in Whidbey).

Also how does overloading on a TypeDef work?

Public Sub DoIt(amount As Integer)
Public Sub DoIt(amount As TQuantity)

Is the above allowed or are they considered different? How does the above
work if implicate conversions allowed? (does it follow the same logic that
causes 0 going to an Enum override rule?)

I'm curious, does Delphi allow TypeDefs? How does it handle conversions &
overloading?

That being said, I can see using TypeDef with Generics in Whidbey, to
simplify defining instances(?) of Generic Types. I could type def the
PersonCollection in the Person.vb file, then every place I need a collection
of People I could use PersonCollection, rather then trying to remember is
PersonCollection a Dictionary keyed by String or something else...

TypeDef PersonCollection As Dictionary<String, Person>

Dim people As PersonCollection

However I'm not sure how often I would need a 'stand alone'
PersonCollection, versus the collection simply being an attribute (field or
property) of some parent class...

Just a thought
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eH****************@TK2MSFTNGP12.phx.gbl... * "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:

Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not
supported in .NET.

If you have a look at C(++) code, it's easy to see why typedefs are not
a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case).

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Vasanth]

Thanks Jay, Herfried & Mattias for all the inputs.

Jay
As we know typedef is not a separate type, but only a synonym for another
type. Therefore, functions that differ by typedef types only may not have
the same name.

Public Sub DoIt(amount As Integer)
Public Sub DoIt(amount As TQuantity) So, in this case you will get an error if you use alias TQuantity for
Integer type otherwise it should be fine. This is how C++ works.

Delphi allows Typedefs and I guess the above must be true for delphi also.

Vasanth
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:#I*************@tk2msftngp13.phx.gbl... Herfried & Vasanth,

If you have a look at C(++) code, it's easy to see why typedefs are not
a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case). That's why I included fortunately!

I find they're a good idea (in C code) if properly managed, as you pointed
out they are rarely properly managed.

For the Win32 APIs I find them very handy! For most other cases I find

them more trouble then they are worth. However with System.Int16, Int32, Int64,
IntPtr the API reason largely goes away. Seeing as my APIs are in a single
Module I can do the Alias thing to make the API defs look "pretty" ;-)

With OOP (VB.NET, C++) I would define an actual type when I needed it,
rather then using TypeDef, as one of the reasons for OOP is introducing new Types. (Don't remember specifically where I read that, but it makes sense). This also allows giving that type custom behavior!

Note I will use typedefs in C++ when working with templates, simple because its easier to remember the parameters to the template, ss the typedef
encapsulates the templates type parameters.

Also due to the stricter type checking (in C# & Option Strict On in VB.NET) in .NET I suspect typedefs will not work as well as the original poster
wants.

Option Strict On

' fictitious VB.NET syntax
TypeDef TQuantity As Integer
TypeDef TPrice As Decimal

Public Sub Main
Dim i As Integer
Dim quantity As TQuantity
i = quantity
quantity = i
End Sub

If the above were allowed implicitly (as in C++) you will ultimately have
problems as changing TQuantity to Single will cause compile errors.

However if TypeDef types required explicit conversions, then changing
TQuantity to Single should not cause compile errors, as the type conversion would deal with it.

i = CType(quantity, Integer)
quantity = CType(i, TQuantity )

In either case the TypeDef would have to be emitted as Meta Data, so
referencing the assembly allows using the TypeDef'd type. I suspect the JIT may need to maintain Type info for the TypeDefs, however the executable code could be (should be) shared with the underlying Type (which I understand the JIT will do for Generics in Whidbey).

Also how does overloading on a TypeDef work?

Public Sub DoIt(amount As Integer)
Public Sub DoIt(amount As TQuantity)

Is the above allowed or are they considered different? How does the above
work if implicate conversions allowed? (does it follow the same logic that
causes 0 going to an Enum override rule?)

I'm curious, does Delphi allow TypeDefs? How does it handle conversions &
overloading?

That being said, I can see using TypeDef with Generics in Whidbey, to
simplify defining instances(?) of Generic Types. I could type def the
PersonCollection in the Person.vb file, then every place I need a collection of People I could use PersonCollection, rather then trying to remember is
PersonCollection a Dictionary keyed by String or something else...

TypeDef PersonCollection As Dictionary<String, Person>

Dim people As PersonCollection

However I'm not sure how often I would need a 'stand alone'
PersonCollection, versus the collection simply being an attribute (field or property) of some parent class...

Just a thought
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eH****************@TK2MSFTNGP12.phx.gbl...

* "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:

Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not supported in .NET.

If you have a look at C(++) code, it's easy to see why typedefs are not
a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case).

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Jay B. Harlow [MVP - Outlook]]

Vasanth,

As we know typedef is not a separate type, but only a synonym for another
type. I was thinking that, however its been to long since I used them in C/C++.
:-)

Also I was questioning if a typedef should be only a synonym in .NET. As my
concern with it being a synonym or alias is you are introducing ambiguities
into your program that may compile fine today, however if you changed one of
the typedefs you will receive compile errors tomorrow. Seeing as the import
alias (available now) is per file, there is only a single file you are
impacting by changing that alias.

Just a thought
Jay

"Vasanth" <so*****@microsoft.com> wrote in message
news:OC****************@TK2MSFTNGP12.phx.gbl... Thanks Jay, Herfried & Mattias for all the inputs.

Jay
As we know typedef is not a separate type, but only a synonym for another
type. Therefore, functions that differ by typedef types only may not have
the same name.

Public Sub DoIt(amount As Integer)
Public Sub DoIt(amount As TQuantity)

So, in this case you will get an error if you use alias TQuantity for
Integer type otherwise it should be fine. This is how C++ works.

Delphi allows Typedefs and I guess the above must be true for delphi also.

Vasanth
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:#I*************@tk2msftngp13.phx.gbl...

Herfried & Vasanth,

If you have a look at C(++) code, it's easy to see why typedefs are not a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case).

That's why I included fortunately!

I find they're a good idea (in C code) if properly managed, as you pointed

out they are rarely properly managed.

For the Win32 APIs I find them very handy! For most other cases I find

them

more trouble then they are worth. However with System.Int16, Int32, Int64, IntPtr the API reason largely goes away. Seeing as my APIs are in a single Module I can do the Alias thing to make the API defs look "pretty" ;-)

With OOP (VB.NET, C++) I would define an actual type when I needed it,
rather then using TypeDef, as one of the reasons for OOP is introducing

new

Types. (Don't remember specifically where I read that, but it makes

sense).

This also allows giving that type custom behavior!

Note I will use typedefs in C++ when working with templates, simple

because

its easier to remember the parameters to the template, ss the typedef
encapsulates the templates type parameters.

Also due to the stricter type checking (in C# & Option Strict On in

VB.NET)

in .NET I suspect typedefs will not work as well as the original poster
wants.

Option Strict On

' fictitious VB.NET syntax
TypeDef TQuantity As Integer
TypeDef TPrice As Decimal

Public Sub Main
Dim i As Integer
Dim quantity As TQuantity
i = quantity
quantity = i
End Sub

If the above were allowed implicitly (as in C++) you will ultimately have problems as changing TQuantity to Single will cause compile errors.

However if TypeDef types required explicit conversions, then changing
TQuantity to Single should not cause compile errors, as the type

conversion

would deal with it.

i = CType(quantity, Integer)
quantity = CType(i, TQuantity )

In either case the TypeDef would have to be emitted as Meta Data, so
referencing the assembly allows using the TypeDef'd type. I suspect the

JIT

may need to maintain Type info for the TypeDefs, however the executable

code

could be (should be) shared with the underlying Type (which I understand

the

JIT will do for Generics in Whidbey).

Also how does overloading on a TypeDef work?

Public Sub DoIt(amount As Integer)
Public Sub DoIt(amount As TQuantity)

Is the above allowed or are they considered different? How does the above work if implicate conversions allowed? (does it follow the same logic that causes 0 going to an Enum override rule?)

I'm curious, does Delphi allow TypeDefs? How does it handle conversions & overloading?

That being said, I can see using TypeDef with Generics in Whidbey, to
simplify defining instances(?) of Generic Types. I could type def the
PersonCollection in the Person.vb file, then every place I need a

collection

of People I could use PersonCollection, rather then trying to remember is PersonCollection a Dictionary keyed by String or something else...

TypeDef PersonCollection As Dictionary<String, Person>

Dim people As PersonCollection

However I'm not sure how often I would need a 'stand alone'
PersonCollection, versus the collection simply being an attribute (field

or

property) of some parent class...

Just a thought
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eH****************@TK2MSFTNGP12.phx.gbl...

* "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:
> Unfortunately (or is it fortunately? ;-)) that usage of a typedef is

not > supported in .NET.

If you have a look at C(++) code, it's easy to see why typedefs are not a good idea. Every company defined a type with different name for the
same purpose, ending up in thousands of semantically equal types with
different names (including the company's name in the worst case).

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>