Is it worth while in developing VB.NET or C#.NET

[Fabio]

I am wondering where you got the perception that 'Mid' should not be used!

Oh, you can also use all the windows sdk programming via API, but this isn't
the best way to work with .net

 

[Fabio]

I think that most VB6 programmers know that it VB6 uses COM (ActiveX), but
I always get stunned when some VB6 developer asks me what regsvr32.exe
is... ;-)

I think you get the point
They will still try to do a regsrv32 my.net.dll when the .Net app won't
run...
I see that they already do this with system windows dll and they shout "Here
it is! The app doesn't work becouse the regsrv32 tell that gdi32.dll cannot
be registered! I got gdi32.dll corrupted!"

 

[Herfried K. Wagner [MVP]]

Oh, you can also use all the windows sdk programming via API, but this
isn't the best way to work with .net

'Mid' is actually .NET .

 

[Fabio]

'Mid' is actually .NET .

also

obj = Activator.CreateInstance(Type.GetTypeFromProgID(myComId, true))

....

Marshal.ReleaseComObject(obj)



is .NET... but we cannot lament about vb.net performances if we use old vb6
code (that produces trash IL).

 

[Herfried K. Wagner [MVP]]

also

obj = Activator.CreateInstance(Type.GetTypeFromProgID(myComId, true))

...

Marshal.ReleaseComObject(obj)

No, this is dealing with COM objects. 'Mid' is managed code, no COM or
other so-called "legacy" thingy.

is .NET... but we cannot lament about vb.net performances if we use old
vb6 code (that produces trash IL).

Could you give some samples where using 'Mid', 'Right', and 'Left' would
produce "trash IL"? It's even possible to write semantically incorrect code
using the low-level 'String.Substring' method.

 

[Fabio]

Could you give some samples where using 'Mid', 'Right', and 'Left' would
produce "trash IL"? It's even possible to write semantically incorrect
code using the low-level 'String.Substring' method.

this is the code of Mid()

Public Shared Function Mid(ByVal str As String, ByVal Start As Integer,
ByVal Length As Integer) As String
If (Start <= 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argument_GTZero1", New String()
{ "Start" }))
End If
If (Length < 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
{ "Length" }))
End If
If ((Length = 0) OrElse (str Is Nothing)) Then
Return ""
End If
Dim num1 As Integer = str.Length
If (Start > num1) Then
Return ""
End If
If ((Start + Length) > num1) Then
Return str.Substring((Start - 1))
End If
Return str.Substring((Start - 1), Length)
End Function



of Right

Public Shared Function Right(ByVal str As String, ByVal Length As Integer)
As String
If (Length < 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
{ "Length" }))
End If
If ((Length = 0) OrElse (str Is Nothing)) Then
Return ""
End If
Dim num1 As Integer = str.Length
If (Length >= num1) Then
Return str
End If
Return str.Substring((num1 - Length), Length)
End Function


of Left

Public Shared Function Left(ByVal str As String, ByVal Length As Integer) As
String
If (Length < 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argument_GEZero1", New String()
{ "Length" }))
End If
If ((Length = 0) OrElse (str Is Nothing)) Then
Return ""
End If
If (Length >= str.Length) Then
Return str
End If
Return str.Substring(0, Length)
End Function


It does not directly produce trash IL but produces an overload calling heavy
wrapper functions to standard .Net code (they at least always need to call
the string.Substring method, just processing some useless extra code).

 

[Guest]

You are partically correct. Left, Mid, Right, etc. are just wrappers for
String.Substring(). However, it does not product "trash IL", if you look at
the IL code, the only difference between Mid (etc.) and String.Substring() is
the actually call. Other than one line of code, the IL is identical. Take
the code:

Public Sub UsingMid()
Dim someString As String = "Hello World"

someString = Mid(someString, 0, 5)
End Sub

Public Sub UsingSubString()
Dim someString As String = "Hello World"

someString = someString.Substring(0, 5)
End Sub

Now look at the IL code for both functions:

..method public instance void UsingMid() cil managed
{
// Code size 18 (0x12)
.maxstack 3
.locals init ([0] string someString)
IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: ldc.i4.0
IL_0009: ldc.i4.5
IL_000a: call string
[Microsoft.VisualBasic]Microsoft.VisualBasic.Strings::Mid(string,

int32,

int32)
IL_000f: stloc.0
IL_0010: nop
IL_0011: ret
} // end of method Form1::UsingMid

..method public instance void UsingSubString() cil managed
{
// Code size 18 (0x12)
.maxstack 3
.locals init ([0] string someString)
IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: ldc.i4.0
IL_0009: ldc.i4.5
IL_000a: callvirt instance string
[mscorlib]System.String::Substring(int32,

int32)
IL_000f: stloc.0
IL_0010: nop
IL_0011: ret
} // end of method Form1::UsingSubString

In general, I avoid the extra call to Microsoft.VisualBasic.dll and just use
String.Substring().

 

[Guest]

And it's always amuzing to see "VB6" code compiled with the VB.NET compiler.
Like making Win32 API calls for functions that are already in the .NET
Framework.

 

[Fabio]

Other than one line of code, the IL is identical.

Is not identical the IL to be executed since with vb.net the CLR has to run
lot of useless IL code to get the same result. Stop.

If I compile this into a separated dll

Public Class MyStrings
Public Shared Function Mid(ByVal s As String, ByVal index as Int32,
ByVal length As Int32) As String
System.Threading.Thread.Sleep(1000)
return s.Substring(index, length)
End Function
End Class

And do my call as in your example

Dim someString As String = "Hello World"

someString = MyStrings.Mid(someString, 0, 5)

This produces the same IL, just call MyStrings.Mid instead of
Microsoft.VisualBasic.Strings.Mid.

Following your logic the result is the same since the IL in your assamebly
is the same.

And don't talk about the difficulty of VBers in understanding c# code and
vice-versa just because VB people don't know how to write .Net app.
I am an estimator of VB6, but I begin to think that the folks that say "vb
programmers are lamers" was right.

 

[Herfried K. Wagner [MVP]]

Is not identical the IL to be executed since with vb.net the CLR has to
run lot of useless IL code to get the same result. Stop.

Did you ever think about the question, /why/ 'Mid' etc. contain some
additional checks?

And don't talk about the difficulty of VBers in understanding c# code and
vice-versa just because VB people don't know how to write .Net app.

Well, it's actually more often C# programmers not understanding VB's
function/class library than VBers not understanding the classes of the .NET
Framework. As said previously, 'Mid' etc. are perfectly .NET, they are
simply an other/simplified way to archieve things which are only implemented
in low-level form in the .NET Framework. Developing for .NET doesn't mean
producing the exact same IL in every programming language.

 

[Carlos J. Quintero [VB MVP]]

Well, that's another story, and there are two explanations for it, IMO:

- It can take a lot of time to know about all the classes and methods that
there are in the class libraries of the .NET Framework. It is a matter of
size, not a matter of not understanding the .NET concepts. The same happens
when you use .NET 2.0: it can be that there are now a managed way of doing
things that did not exist in .NET 1.x...

- Also, if you are migrating from VB6 to VB.NET, rather than writting a new
app from scratch, I suppose that the first priority of people is to get 0
build errors, the second is to make the app actually work as before without
bugs, then adjust the performance, etc. and the last one is to change the
code to fit better in the .NET way. That would explain also that you see
Win32 API calls when they are no longer required.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

 

[Guest]

Is not identical the IL to be executed since with vb.net the CLR has to run
lot of useless IL code to get the same result. Stop.

That is what I said. The IL code for both of my examples are identical,
except for one line (read the code). The difference is between the two is
that one for MID calls Microsoft.VisualBasic.dll. You stated earlier that
"trash IL" is produced. No "trash IL" is products. Extra IL is called
thourgh Microsoft.VisualBasic.dll. I was just merely stating extra code is
called, not "produced".

And don't talk about the difficulty of VBers in understanding c# code and
vice-versa just because VB people don't know how to write .Net app.
I am an estimator of VB6, but I begin to think that the folks that say "vb
programmers are lamers" was right.

Under standing C# is not the issue. It's understanding how .NET works and
how to use the .NET Framework Base Classes. C# and VB.NET are just syntax,
with very few minor differences.

I have seen very well written VB6 code and well written .NET code (both in
C# and VB.NET). At the same time, I've also seen poorly written VB6 code,
and poorly written .NET code. Poor code can be written in any language.

Whether you write in VB.NET or C# does not matter, as long as you write it
well. I didn't mean to offend anybody, I was just mearly teasing those (some
I know) who refuse to learn. We are all busy and don't have time to learn
new things, but in this business, you need to make time. It's the nature of
the beast. In this field, you need to be able to adapt.

Sorry, I'm getting off the soap box now

 

[Guest]

I agree and that's understandable. I was clear in my last post. I was
talking about programmers who start from scratch writting a new program in
VB.NET, making WIN32 API calls. We contracted a 3rd party to write some
software we didn't have time to write. The code was to be written in VB.NET.
They were to follow our coding standards (using exception handling, no
direct calls to Win32, etc.). At the first code review, the code was written
poorly. Errors were being raised, instead of exception handling (per coding
standards) and there were many Win32API calls for methods that are native to
..NET. Now this was written from scratch.

As I said in a post above, we are all busy. And you are right, .NET is
massive and to this day, I'm still learning new things. But as developers we
need to make the time to learn. It is the nature of the business.

Sorry for the rant, just my two cents.

 

[Jon Skeet [C# MVP]]

Well, it's actually more often C# programmers not understanding VB's
function/class library than VBers not understanding the classes of the .NET
Framework.

Earlier you wrote:

<quote>
I am wondering where you got the perception that 'Mid' should not be
used!
</quote>

Isn't what you wrote above a good enough reason?

Yes, Mid is in .NET. It's in an assembly specifically created for VB
support, however - hence its name. For the maximum readability for all
..NET programmers, I'd suggest using the more commonly known string
manipulation libraries (ie System.String and the System.Text and
System.Text.RegularExpressions namespaces).

Put it this way - it's entirely possible to use the Java-support
redistributable and start using the Java API to manipulate strings too
- but I wouldn't recommend that, either.

 

[Homer J Simpson]

And don't talk about the difficulty of VBers in understanding c# code and
vice-versa just because VB people don't know how to write .Net app.
I am an estimator of VB6, but I begin to think that the folks that say "vb
programmers are lamers" was right.

C# programmers are pussies. Real programmers write machine code - in ink.

 

[Herfried K. Wagner [MVP]]

Jon --

Earlier you wrote:

<quote>
I am wondering where you got the perception that 'Mid' should not be
used!
</quote>

Isn't what you wrote above a good enough reason?

Yes, Mid is in .NET. It's in an assembly specifically created for VB
support, however - hence its name. For the maximum readability for all
.NET programmers, I'd suggest using the more commonly known string
manipulation libraries (ie System.String and the System.Text and
System.Text.RegularExpressions namespaces).

Note that I don't recommend to blindly use VB's string manipuliation
functions instead of those in the .NET Framework's class library. I simply
recommend to use them when using them makes sense (features missing in the
..NET Framework's class library) or if I consider them more high-level than
the equivalent methods in the .NET Framework.

Put it this way - it's entirely possible to use the Java-support
redistributable and start using the Java API to manipulate strings too
- but I wouldn't recommend that, either.

I would not recommend it either, but what if one of the methods provided
there is missing in the .NET Framework? In a J# application it would IMO be
the natural choice to use the Java API method. I am not sure where you
would draw the line between using language-specific features versus using
..NET Framework features.

Would you recommend to use '+' for string concatenation in VB.NET instead of
'&' only for the reason other programming languages use '+' too? Did you
refuse to use 'using' blocks in C# 1.* only because VB.NET didn't have an
equivalent syntactic construct? Personally I don't think it makes much
sense to refuse using constructs, be it syntactic constructs or library
features, only for the reason of not having an equivalent in another
programming language.

There is no programming language which can claim to be "the only programming
languge designed for the .NET Framework" except maybe ILASM. Different
programming languages have different historical backgrounds and cultures,
and serve different purposes, which means that they are optimized for
certain scenarios. Consequently they provide their own extensions to the
..NET Framework which make dealing with these scenarios easier.

 

[Jon Skeet [C# MVP]]

Note that I don't recommend to blindly use VB's string manipuliation
functions instead of those in the .NET Framework's class library. I simply
recommend to use them when using them makes sense (features missing in the
.NET Framework's class library) or if I consider them more high-level than
the equivalent methods in the .NET Framework.

However, you gave the impression that there's no reason not to use Mid.
Here are my reasons:

1) It's not as OO as using a method on the String class
2) There's a direct equivalent in String.Substring
3) Users of other languages are more likely to understand Substring
4) The Microsoft.VisualBasic assembly may not be entirely implemented
in other CLR implementations, whereas System.String certainly will
be
5) Due to being less widely used than System.String, it's more likely
to have bugs. This is a general point about the
Microsoft.VisualBasic assembly, which isn't as widely used as the
equivalents in the System.* assemblies. For instance, last time I
looked hard at Asc and Chr (IIRC) there was distinctly odd behaviour
in terms of which character encoding was actually used. (It depended
on the first use within the app, I believe.)
6) It's less efficient as it's performing all the checks that Substring
performs before calling Substring.

I would not recommend it either, but what if one of the methods provided
there is missing in the .NET Framework? In a J# application it would IMO be
the natural choice to use the Java API method. I am not sure where you
would draw the line between using language-specific features versus using
.NET Framework features.

I would argue that if you're using J# you're in a world of pain to
start with, to be honest - but I see your point. I would argue that J#
isn't really a first class .NET language - it sits uncomfortably
between two worlds.

Would you recommend to use '+' for string concatenation in VB.NET instead of
'&' only for the reason other programming languages use '+' too? Did you
refuse to use 'using' blocks in C# 1.* only because VB.NET didn't have an
equivalent syntactic construct? Personally I don't think it makes much
sense to refuse using constructs, be it syntactic constructs or library
features, only for the reason of not having an equivalent in another
programming language.

I think it depends on whether you count the VB functions as part of the
language or not. The good thing about C# is that it's a relatively
small actual language, relying on the framework itself for most of the
functionality. As such, using all the features of the language doesn't
make it particularly hard to read C# code from the point of view of
users of other languages - there isn't that much to learn. If I'm
reading VB.NET code which uses the VB functions extensively, however, I
need to find out what each of them do.

There is no programming language which can claim to be "the only programming
languge designed for the .NET Framework" except maybe ILASM. Different
programming languages have different historical backgrounds and cultures,
and serve different purposes, which means that they are optimized for
certain scenarios. Consequently they provide their own extensions to the
.NET Framework which make dealing with these scenarios easier.

Sure. However, I would argue that if there are *lots* of those
extensions, such as is the case with VB functions, and if the
equivalent functionality is available in the "main" .NET framework
(even if at a slight extra cost in terms of source code - terse doesn't
mean readable), then use of those extensions should be actively
discouraged.

 

[Ian Semmel]

C# programmers are pussies. Real programmers write machine code - in ink.

Back in the '60s when I started work, we had to write our programs on coding
sheets - in ink.

 

[Cor Ligthert [MVP]]

Jon,

1) It's not as OO as using a method on the String class

Why this is really an answer Herfried does not deserve, he knows well as
probably you do that this is beside the truth a method has nothing to do
with OO.

2) There's a direct equivalent in String.Substring

It is not true because Mid is more efficient. But even as it was like that:
There is a direct equivalent for meat, which is flesh however it sligly
different used.

3) Users of other languages are more likely to understand Substring

Why only those who have used one of those that larch bunch of languages who
are derived from C or those who have used languages, where it was
remembering me that start just a kind of added method. It is not in PL
languages, not in Cobol, not in Algol, not in Fortran, not in Macro
Assemblers etc etc.

4) The Microsoft.VisualBasic assembly may not be entirely implemented
in other CLR implementations, whereas System.String certainly will
be

Than it is not Net. I know that the Reliant has/had 3 wheels, however it was
only popular in Brittain where it was called a Car, there were it was
slightly used in Holland and Germany it was more a shielded motorbike.

5) Due to being less widely used than System.String, it's more likely
to have bugs. This is a general point about the
Microsoft.VisualBasic assembly, which isn't as widely used as the
equivalents in the System.* assemblies. For instance, last time I
looked hard at Asc and Chr (IIRC) there was distinctly odd behaviour
in terms of which character encoding was actually used. (It depended
on the first use within the app, I believe.)

Yes that is mostly as programs have more posibilities, if this is an
argument, than use only some base Intel assembler code. Those don't have
that problem.

6) It's less efficient as it's performing all the checks that Substring
performs before calling Substring.

That is only important as there is performance need, although 1 as showed
that it takes more are problably gained by the more efficient way as it is.

And here I stop. I never use Mid anymore by the way as I don't use any
String function from the Microsoft Visual Basic. I do have to admit that I
don't know why, however probably mostly because they use the one indexer
instead of the zero indexer, by what I become often confused.

Cor

 

[Jon Skeet [C# MVP]]

Why this is really an answer Herfried does not deserve

He made a statement which implied that there's no reason not to use
Mid. I'm giving reasons.

he knows well as probably you do that this is beside the truth a
method has nothing to do with OO.

Um, yes it does. Having an instance method which acts on an instance of
a class is more OO than having a static method in a separate class to
operate on an instance of the first class.

It is not true because Mid is more efficient.

More efficient? Doing the same work twice is more efficient?

But even as it was like that: There is a direct equivalent for meat,
which is flesh however it sligly different used.

I suspect that most users of Mid aren't aware of the differences
between Mid and Substring other than the starting index, and those
differences could easily be exposed in code anyway if they really
wanted them. (Do you often want to take a substring of a null string,
or start from a higher index than the length of the string? Those both
sound like situations which are likely to arise from bugs, at which
point I'd rather have an exception.)

Why only those who have used one of those that larch bunch of languages who
are derived from C or those who have used languages, where it was
remembering me that start just a kind of added method. It is not in PL
languages, not in Cobol, not in Algol, not in Fortran, not in Macro
Assemblers etc etc.

No, I'm talking about other users of the .NET framework (or other CLI
implementations).

Than it is not Net.

No. Indeed it couldn't be .NET if it's not Microsoft. It could still be
a full implementation of the CLR/CLI and its ECMA-specified system
libraries, however. You need to make a very clear distinction between
Microsoft's implementation (which includes extra libraries) and what is
specified.

I know that the Reliant has/had 3 wheels, however it was
only popular in Brittain where it was called a Car, there were it was
slightly used in Holland and Germany it was more a shielded motorbike.

In this case, the standard libraries are clearly specified by ECMA.

Yes that is mostly as programs have more posibilities, if this is an
argument, than use only some base Intel assembler code. Those don't have
that problem.

I would rather use a more tested implementation than a less tested
implementation when the functionality is broadly equivalent. I don't
see what's wrong with that as a reason.

That is only important as there is performance need, although 1 as showed
that it takes more are problably gained by the more efficient way as it is.

That sentence doesn't make sense. Could you try it again?

And here I stop. I never use Mid anymore by the way as I don't use any
String function from the Microsoft Visual Basic. I do have to admit that I
don't know why, however probably mostly because they use the one indexer
instead of the zero indexer, by what I become often confused.

Ah, another reason not to use it. Thanks.