V
vvv
Hi All,
Do we have anything in .NET which is equivalent to C++'s Typedef .
Regards,
Vasanth
Do we have anything in .NET which is equivalent to C++'s Typedef .
Regards,
Vasanth
M
Mattias Sjögren
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
V
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
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
A
Armin Zingler
vvv said:
Out of interest: Why do you need it? Neither I needed typedefs nor operator
overloading so far.
H
Herfried K. Wagner [MVP]
* "Armin Zingler said:
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.
V
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
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
J
Jay B. Harlow [MVP - Outlook]
Vasanth,
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/permalink.aspx/5de5a161-9150-4237-a751-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
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/permalink.aspx/5de5a161-9150-4237-a751-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 said:
A
Armin Zingler
Vasanth said:
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.
J
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
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
H
Herfried K. Wagner [MVP]
* "Jay B. Harlow said:
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).
J
Jay B. Harlow [MVP - Outlook]
Herfried & Vasanth,
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
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
V
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.
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
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.
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 said:
J
Jay B. Harlow [MVP - Outlook]
Vasanth,
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
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 said: