Re: VB Conversion Keywords And .NET Conversion Routines

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Jay B. Harlow [MVP - Outlook] (Jay_Harlow_MVP_at_msn.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 17:07:58 -0600

Bob,
> The initial release of C# didn't have to cope with legacy issues since it
> was a brand-new language,
What do you consider "(int)" in C#?

I hope you realize that "(int)" in C# is the same as CInt in a number of
cases.

The "nice" thing about CInt is it is more powerful, then either "(int)" or
Convert.ToInt32, as it combines both, plus.

> I don't think anyone seriously recommends using, for example, PRINT#
The PRINT# keyword is not even available in VB.NET, so why would any one
even consider recommending it?

The Print# keyword has been replaced with the
Microsoft.VisualBasic.FileSystem.Print function in the VB.NET runtime. The
VB.NET runtime is an integral part of the VB.NET language.

> statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
CInt & CDbl are no where near obsolete, they are keywords which are an
integral part of the VB.NET language, just as are If, Sub, Property, and
every other keyword in VB.NET. Not to be confused with VB6 keywords that are
retained in VB.NET and not actually used, such as GOSUB.

If you have not yet read Paul Vick's article on CInt & such, I strongly
suggest you do:

http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx

Unfortunately I don't have access to my VS.NET 2005 partition right now, I
understand that CInt, CDbl, etc have expanded usage in VB.NET 2005! In that
they honor overloaded operators:

http://www.panopticoncentral.net/archive/2004/07/01/1338.aspx
http://msdn.microsoft.com/vbasic/whidbey/default.aspx?pull=/library/en-us/dnvs05/html/vboperatoroverloading.asp

Hope this helps
Jay

"Bob Grommes" <bob@bobgrommes.com> wrote in message
news:e3rUaLeHFHA.1500@TK2MSFTNGP09.phx.gbl...
> "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message
> news:uQyWQXbHFHA.2156@TK2MSFTNGP09.phx.gbl...
>> Bob,
>>
>>> Personally I use the generic .NET methods like Convert.ToInt32() instead
>>> of CInt(), etc. This makes your programs more congruent with other .NET
>>> languages, including C#.
>>
>> What is the advantage from this, in my idea can you than better write it
>> direct in C
>
> All I'm saying is that the CLR provides virtually all the classes and
> methods you need for conversions. .NET-hosted languages that have legacy
> syntax for doing the same things as the CLR methods will either implement
> compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
> they will provide a library that implements the legacy syntax / behaviors.
> VB.NET does primarily the latter, but with a little bit of syntax sugar --
> the namespace / library where the compatibility methods exist is always
> automatically referenced without the VB.NET developer having to do
> anything.
>
> In the best case, if you call the legacy VB function CInt(), it's just
> going to forward it to Convert.ToInt32() anyway. Why not avoid that extra
> call? In the worst case, CInt() is going to implement some legacy behavior
> that might be even more expensive. For example it might take Nothing as
> zero, which would involve another test or perhaps a try/catch. I don't
> recall offhand -- but I remember finding that some of the legacy
> conversion functions do jump through extra hoops to behave exactly like
> legacy VB.
>
> I'm not passing judgment on this as good, bad or indifferent -- it's just
> the way it is. I'm sure that some future version of C# will have similar
> issues. The initial release of C# didn't have to cope with legacy issues
> since it was a brand-new language, but over time, it will. I also assume
> that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
> code run somewhat as-is.
>
>> What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
>> and what ever from C derived languages have a lot of legacy C stuff.
>> (With what in my opinion is almost nothing wrong by the way)
>
> I'm not referring to language characteristics or conventions that descend
> from predecessor languages. I'm referring to keywords / functions /
> commands that are obsoleted by the provided .NET classes and which exist
> only so that code written for previous, non .NET versions of those
> languages will come as close as feasible to running unchanged.
>
> I don't think anyone seriously recommends using, for example, PRINT#
> statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
> People use them to ease the incorporation of legacy code into .NET apps,
> or out of habit; I'm simply advocating that they be treated like
> deprecated HTML tags, which is to say, they will probably not be supported
> someday and there are arguably better ways of doing the same things.
>
> The parallel to deprecated HTML tags also cuts the other way. <B> is
> deprecated, for example, but so many people continue to use it that it
> probably will continue to be supported just from sheer inertia. That
> probably means it's simple and abbreviated enough that it is useful and
> appealing despite the fact it's obsolete. One could argue that CInt() is
> more concise than Convert.ToInt32() and maybe on that basis plus the fact
> that probably most VB.NET developers started out with VB6, CInt() will
> remain enshrined in the language forever. Personally though I prefer to
> take the larger view that you want VB.NET to participate as an equal
> partner with other .NET languages and it should play in the sandbox the
> same way so that programmers can move between VB.NET and other .NET
> languages with a minimum of quirky exceptions to how things are done from
> one language to the next.
>
> --Bob
>
>

Relevant Pages

  • Re: VB Conversion Keywords And .NET Conversion Routines
    ... The PRINT# keyword is not even available in VB.NET, ... VB.NET runtime is an integral part of the VB.NET language. ... CInt & CDbl are no where near obsolete, they are keywords which are an ... .NET-hosted languages that have legacy ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why PHP?
    ... written business logic reduces development time in porting a legacy ... As far as using PHP - which is the topic goes - I guess it's just another ... >> efficient do it all in Pick (or OpenQM) instead - if you could? ... > 'interpreted once they get there' - most of the calls are C language ...
    (comp.databases.pick)
  • Re: Arent the fuddy-duddies in the group going to comment on Fortress
    ... In my personal opinion, there is nowadays to much material in the standard, with too many interactions among useful new features, because of this legacy support. ... Most of the code is in the optimization part anyway, and that is to a large degree indepedent of the fron-end language - except for such things as supporting arrays as first-calls citizens. ... compiler - but if explicit parallelization cannot be introduced into ...
    (comp.lang.fortran)
  • Re: Pythons simplicity philosophy
    ... >> personally argued that reduceshould be removed from the language, ... from legacy import * ... easy to get this functionality with a commandline switch, ... day-to-day python-dev traffic, but I don't think anything's been ...
    (comp.lang.python)
  • Re: VB Conversion Keywords And .NET Conversion Routines
    ... Don't you think that the compiler compiles Cint function to basically the ... .NET-hosted languages that have legacy ...
    (microsoft.public.dotnet.framework.performance)