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" <mattias.dont.w ant.spam@mvps.o rg> wrote in message
news:uar7EDszDH A.2180@TK2MSFTN GP12.phx.gbl...[color=blue]
>[color=green]
> >Do we have anything in .NET which is equivalent to C++'s Typedef .[/color]
>
> 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.[/color]
"vvv" <someone@micros oft.com> schrieb[color=blue]
> 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.[/color]
Out of interest: Why do you need it? Neither I needed typedefs nor operator
overloading so far.
* "Armin Zingler" <az.nospam@free net.de> scripsit:[color=blue][color=green]
>> 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.[/color]
>
> Out of interest: Why do you need it? Neither I needed typedefs nor operator
> overloading so far.[/color]
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>
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.nospam@free net.de> wrote in message
news:eA9F45szDH A.484@TK2MSFTNG P10.phx.gbl...[color=blue]
> "vvv" <someone@micros oft.com> schrieb[color=green]
> > 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.[/color]
>
> Out of interest: Why do you need it? Neither I needed typedefs nor[/color]
operator[color=blue]
> overloading so far.
>
>
> --
> Armin
>
> http://www.plig.net/nnq/nquote.html
> http://www.netmeister.org/news/learn2quote.html
>[/color]
Vasanth,[color=blue]
> I was trying to create wrapper classes for all the primitive datatypes,[/color]
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.
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" <someone@micros oft.com> wrote in message
news:eY5dpZszDH A.2408@tk2msftn gp13.phx.gbl...[color=blue]
> 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,[/color]
but[color=blue]
> 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" <mattias.dont.w ant.spam@mvps.o rg> wrote in message
> news:uar7EDszDH A.2180@TK2MSFTN GP12.phx.gbl...[color=green]
> >[color=darkred]
> > >Do we have anything in .NET which is equivalent to C++'s Typedef .[/color]
> >
> > 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.[/color]
>
>[/color]
"Vasanth" <someone@micros oft.com> schrieb[color=blue]
> 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.[/color]
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.
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" <someone@micros oft.com> wrote in message
news:OAgmAxtzDH A.2240@TK2MSFTN GP10.phx.gbl...[color=blue]
> You would require this to achieve some kind of program dicipline and[/color]
control[color=blue]
> of data type usage.
> In enterprise applications, some developers might use datatype 'Single'[/color]
for[color=blue]
> Price field while others use decimal, similarly Integer/Long for Quantity
> field.
>
> If you create typedefs for those primitive datatypes like the following[/color]
(C++[color=blue]
> 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.nospam@free net.de> wrote in message
> news:eA9F45szDH A.484@TK2MSFTNG P10.phx.gbl...[color=green]
> > "vvv" <someone@micros oft.com> schrieb[color=darkred]
> > > 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.[/color]
> >
> > Out of interest: Why do you need it? Neither I needed typedefs nor[/color]
> operator[color=green]
> > overloading so far.
> >
> >
> > --
> > Armin
> >
> > http://www.plig.net/nnq/nquote.html
> > http://www.netmeister.org/news/learn2quote.html
> >[/color]
>
>[/color]
* "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> scripsit:[color=blue]
> Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not
> supported in .NET.[/color]
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>
Herfried & Vasanth,[color=blue]
> 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).[/color]
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
PersonCollectio n in the Person.vb file, then every place I need a collection
of People I could use PersonCollectio n, rather then trying to remember is
PersonCollectio n a Dictionary keyed by String or something else...
TypeDef PersonCollectio n As Dictionary<Stri ng, Person>
Dim people As PersonCollectio n
However I'm not sure how often I would need a 'stand alone'
PersonCollectio n, versus the collection simply being an attribute (field or
property) of some parent class...
Just a thought
Jay
"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:eH3E%23Awz DHA.1740@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> * "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> scripsit:[color=green]
> > Unfortunately (or is it fortunately? ;-)) that usage of a typedef is not
> > supported in .NET.[/color]
>
> 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>[/color]
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.[color=blue]
> Public Sub DoIt(amount As Integer)
> Public Sub DoIt(amount As TQuantity)[/color]
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]" <Jay_Harlow_MVP @msn.com> wrote in message
news:#IcnSowzDH A.604@tk2msftng p13.phx.gbl...[color=blue]
> Herfried & Vasanth,[color=green]
> > 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).[/color]
> 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[/color]
them[color=blue]
> 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[/color]
new[color=blue]
> Types. (Don't remember specifically where I read that, but it makes[/color]
sense).[color=blue]
> This also allows giving that type custom behavior!
>
> Note I will use typedefs in C++ when working with templates, simple[/color]
because[color=blue]
> 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[/color]
VB.NET)[color=blue]
> 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[/color]
conversion[color=blue]
> 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[/color]
JIT[color=blue]
> may need to maintain Type info for the TypeDefs, however the executable[/color]
code[color=blue]
> could be (should be) shared with the underlying Type (which I understand[/color]
the[color=blue]
> 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
> PersonCollectio n in the Person.vb file, then every place I need a[/color]
collection[color=blue]
> of People I could use PersonCollectio n, rather then trying to remember is
> PersonCollectio n a Dictionary keyed by String or something else...
>
> TypeDef PersonCollectio n As Dictionary<Stri ng, Person>
>
> Dim people As PersonCollectio n
>
> However I'm not sure how often I would need a 'stand alone'
> PersonCollectio n, versus the collection simply being an attribute (field[/color]
or[color=blue]
> property) of some parent class...
>
> Just a thought
> Jay
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:eH3E%23Awz DHA.1740@TK2MSF TNGP12.phx.gbl. ..[color=green]
> > * "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> scripsit:[color=darkred]
> > > Unfortunately (or is it fortunately? ;-)) that usage of a typedef is[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > supported in .NET.[/color]
> >
> > 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>[/color]
>
>[/color]
Vasanth,[color=blue]
> As we know typedef is not a separate type, but only a synonym for another
> type.[/color]
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" <someone@micros oft.com> wrote in message
news:OChI%23e3z DHA.2180@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> 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.[color=green]
> > Public Sub DoIt(amount As Integer)
> > Public Sub DoIt(amount As TQuantity)[/color]
> 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]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:#IcnSowzDH A.604@tk2msftng p13.phx.gbl...[color=green]
> > Herfried & Vasanth,[color=darkred]
> > > If you have a look at C(++) code, it's easy to see why typedefs are[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > 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).[/color]
> > That's why I included fortunately!
> >
> > I find they're a good idea (in C code) if properly managed, as you[/color][/color]
pointed[color=blue][color=green]
> > out they are rarely properly managed.
> >
> > For the Win32 APIs I find them very handy! For most other cases I find[/color]
> them[color=green]
> > more trouble then they are worth. However with System.Int16, Int32,[/color][/color]
Int64,[color=blue][color=green]
> > IntPtr the API reason largely goes away. Seeing as my APIs are in a[/color][/color]
single[color=blue][color=green]
> > 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[/color]
> new[color=green]
> > Types. (Don't remember specifically where I read that, but it makes[/color]
> sense).[color=green]
> > This also allows giving that type custom behavior!
> >
> > Note I will use typedefs in C++ when working with templates, simple[/color]
> because[color=green]
> > 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[/color]
> VB.NET)[color=green]
> > 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[/color][/color]
have[color=blue][color=green]
> > 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[/color]
> conversion[color=green]
> > 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[/color]
> JIT[color=green]
> > may need to maintain Type info for the TypeDefs, however the executable[/color]
> code[color=green]
> > could be (should be) shared with the underlying Type (which I understand[/color]
> the[color=green]
> > 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[/color][/color]
above[color=blue][color=green]
> > work if implicate conversions allowed? (does it follow the same logic[/color][/color]
that[color=blue][color=green]
> > causes 0 going to an Enum override rule?)
> >
> > I'm curious, does Delphi allow TypeDefs? How does it handle conversions[/color][/color]
&[color=blue][color=green]
> > 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
> > PersonCollectio n in the Person.vb file, then every place I need a[/color]
> collection[color=green]
> > of People I could use PersonCollectio n, rather then trying to remember[/color][/color]
is[color=blue][color=green]
> > PersonCollectio n a Dictionary keyed by String or something else...
> >
> > TypeDef PersonCollectio n As Dictionary<Stri ng, Person>
> >
> > Dim people As PersonCollectio n
> >
> > However I'm not sure how often I would need a 'stand alone'
> > PersonCollectio n, versus the collection simply being an attribute (field[/color]
> or[color=green]
> > property) of some parent class...
> >
> > Just a thought
> > Jay
> >
> > "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> > news:eH3E%23Awz DHA.1740@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > * "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> scripsit:
> > > > Unfortunately (or is it fortunately? ;-)) that usage of a typedef is[/color][/color]
> not[color=green][color=darkred]
> > > > supported in .NET.
> > >
> > > If you have a look at C(++) code, it's easy to see why typedefs are[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > 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>[/color]
> >
> >[/color]
>
>[/color]
Comment