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

Vignesh,

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the OS.

Therefore I would choose for your problem probably direct C#

I hope this helps,

Cor

Mar 4 '06 #4

rmacias

If he needs to work w/ the registry he can use the Microsoft.Win32.Registry
and Microsoft.Win32.RegistryKey classes to do so. This can be done in either
VB.NET or C#. How does direct pointer manipulation give him an advantage?

"Cor Ligthert [MVP]" wrote:

Vignesh,

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the OS.

Therefore I would choose for your problem probably direct C#

I hope this helps,

Cor

Mar 4 '06 #5

rmacias,

In my opinion is the Registry one point, however to see if the registry is
correct you have to do investigations. That part seems for me the more
difficult part. Not the registry itself what is straight forward both in C#
and VB.Net

Just my thought,

Cor

"rmacias" <rm*****@newsgroup.nospam> schreef in bericht
news:78**********************************@microsof t.com...

If he needs to work w/ the registry he can use the
Microsoft.Win32.Registry
and Microsoft.Win32.RegistryKey classes to do so. This can be done in
either
VB.NET or C#. How does direct pointer manipulation give him an advantage?

"Cor Ligthert [MVP]" wrote:
Vignesh,

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the
OS.

Therefore I would choose for your problem probably direct C#

I hope this helps,

Cor

Mar 4 '06 #6

vighnesh

Thank You VeryMuch for your valuable suggestions

Regards
Vighneswar
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

rmacias,

In my opinion is the Registry one point, however to see if the registry is
correct you have to do investigations. That part seems for me the more
difficult part. Not the registry itself what is straight forward both in
C# and VB.Net

Just my thought,

Cor

"rmacias" <rm*****@newsgroup.nospam> schreef in bericht
news:78**********************************@microsof t.com...
If he needs to work w/ the registry he can use the
Microsoft.Win32.Registry
and Microsoft.Win32.RegistryKey classes to do so. This can be done in
either
VB.NET or C#. How does direct pointer manipulation give him an
advantage?

"Cor Ligthert [MVP]" wrote:
Vignesh,

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the
OS.

Therefore I would choose for your problem probably direct C#

I hope this helps,

Cor

Mar 4 '06 #7

m.posseth

Hmmm Cor are you moving to the dark side ? :-)

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the
OS.

Therefore I would choose for your problem probably direct C#

if this is actually needed i would say go for C++

regards

Michel Posseth [MCP]

"Cor Ligthert [MVP]" <no************@planet.nl> schreef in bericht
news:%2****************@TK2MSFTNGP09.phx.gbl... rmacias,

In my opinion is the Registry one point, however to see if the registry is
correct you have to do investigations. That part seems for me the more
difficult part. Not the registry itself what is straight forward both in
C# and VB.Net

Just my thought,

Cor

"rmacias" <rm*****@newsgroup.nospam> schreef in bericht
news:78**********************************@microsof t.com...
If he needs to work w/ the registry he can use the
Microsoft.Win32.Registry
and Microsoft.Win32.RegistryKey classes to do so. This can be done in
either
VB.NET or C#. How does direct pointer manipulation give him an
advantage?

"Cor Ligthert [MVP]" wrote:
Vignesh,

There is one part that is not in VBNet while it is in C#. That is unsafe
code which makes it you possible to do some more raw processes with the
OS.

Therefore I would choose for your problem probably direct C#

I hope this helps,

Cor

Mar 4 '06 #8

Brooke

I have used VB since it was released and I was actually a beta tester
when it was called Thunder back around 1990. I picked up VB.NET when it was
first released, and developed a few applications using it, but quickly made
the transition to C#. In the last 5 years I have came to the conclusion
that it is best to know the "Three C's". The "Three C's" are C, C++, and
C#.

My reasoning for this is that most embedded development is done in C,
the other OS's use C and C++ and their main development languages, there are
millions of lines of C and C++ code that can easily be converted to C#, Java
and C# are almost identical which makes learning Java easy, the source code
for .NET is in C#, as a contractor I definitely make more money on C#
contracts than VB.NET. You also cannot just jump from VB 6 to VB.NET as it
is completely different. Since you will have to learn a new language coming
from VB6 it makes sense to just move to C#.

If you plan on just writing code for Windows then either language will
work. But if you want to be a develop for other operating systems (UNIX,
LINUX, Embedded, Firmware, etc) then C# is the way to go.
"vighnesh" <vi******@nannacomputers.com> wrote in message
news:eq**************@tk2msftngp13.phx.gbl...

Hello Everyone

I am about to develop a project like Registry Mechanic using either VB.NET
or C#.NET.
But I dont know is it worth while in using these languages ? I mean is
there necessary support
provided in .NET to accomplish this task? If Provided please suggest me
the approach.

Regards
Vighneswar

Mar 4 '06 #9

"Brooke" <tb******@hotmail.com> schrieb:

I have used VB since it was released and I was actually a beta tester
when it was called Thunder back around 1990. I picked up VB.NET when it
was first released, and developed a few applications using it, but quickly
made the transition to C#. In the last 5 years I have came to the
conclusion that it is best to know the "Three C's". The "Three C's" are
C, C++, and C#.
I do not see many similarities between C/C++ and C#. So learning C# won't
make one more familiar with C/C++. While I think that C/C++ still have a
place in low-level development, I don't think that a legacy syntax which is
optimized for easy input through ancient devices should have its place in
modern, high-level application development (user mode applications).
If you plan on just writing code for Windows then either language will
work. But if you want to be a develop for other operating systems (UNIX,
LINUX, Embedded, Firmware, etc) then C# is the way to go.

I have to disagree. Both, the VB.NET and the C# compiler emit IL, so it
should not really matter which of the two programming languages one is using
for platform independent development.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 4 '06 #10

Homer J Simpson

"Brooke" <tb******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...

My reasoning for this is that most embedded development is done in C

This is true. It does not indicate that this is a good idea. Beware of the
'fashionable' - it changes often. My first computer language was Algol-68.

IMO, Pascal would be a better choice for embedded development. There would
be far less debugging and fixing that would have to be done if a P-Code
interpreter executed P-Code created by a robust compiler.

However, if you only have a hammer everything looks like a nail. If you only
know Java, guess which language you will prefer.

Mar 4 '06 #11

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

"Brooke" <tb******@hotmail.com> schrieb:
I have used VB since it was released and I was actually a beta tester
when it was called Thunder back around 1990. I picked up VB.NET when it
was first released, and developed a few applications using it, but quickly
made the transition to C#. In the last 5 years I have came to the
conclusion that it is best to know the "Three C's". The "Three C's" are
C, C++, and C#.
I do not see many similarities between C/C++ and C#.

Not even in syntax? I'm perfectly well aware that the majority of
differences between VB.NET and C# are just in syntactical - but coming
from a C/C++/Java background I was able to pretty much immediately read
a lot of C# code, whereas it takes me a lot longer to read VB.NET with
its fairly significantly different syntax. It's a case of familiarity,
that's all.
So learning C# won't make one more familiar with C/C++. While I think
that C/C++ still have a place in low-level development, I don't think
that a legacy syntax which is optimized for easy input through
ancient devices should have its place in modern, high-level
application development (user mode applications).

Some of us like terse syntax for reasons other than easy input.

If you plan on just writing code for Windows then either language will
work. But if you want to be a develop for other operating systems (UNIX,
LINUX, Embedded, Firmware, etc) then C# is the way to go.

I have to disagree. Both, the VB.NET and the C# compiler emit IL, so it
should not really matter which of the two programming languages one is using
for platform independent development.

I think Brooke's point here is that if you're going to work in Unix,
Linux etc, you may well end up writing non-.NET code - in which case,
C# is a better starting point as it's *closer* to C/C++/Java than
VB.NET is.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 5 '06 #12

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

> I have used VB since it was released and I was actually a beta
> tester
> when it was called Thunder back around 1990. I picked up VB.NET when
> it
> was first released, and developed a few applications using it, but
> quickly
> made the transition to C#. In the last 5 years I have came to the
> conclusion that it is best to know the "Three C's". The "Three C's"
> are
> C, C++, and C#.
I do not see many similarities between C/C++ and C#.

Not even in syntax?

There are some similarities in syntax, but especially in terms of
object-orientiation C++ and C# differ significantly. Additionally C#'s
semantics are close to those of VB6 (references instead of pointers) too.
but coming from a C/C++/Java background I was able to pretty
much immediately read a lot of C# code

How long does it take to learn how 'for', 'do', etc. work in C# if you are
familiar with another programming language, be it VB(.NET) or C(++)? One
day? Two days? I have both a C/C++ and VB background, so I do not know,
but once I have understood how a certain thing works in one of the two
programming languages VB.NET and C# I can quickly find out how to archieve
the same in the other programming language.

>If you plan on just writing code for Windows then either language will
>work. But if you want to be a develop for other operating systems (UNIX,
>LINUX, Embedded, Firmware, etc) then C# is the way to go.

I have to disagree. Both, the VB.NET and the C# compiler emit IL, so it
should not really matter which of the two programming languages one is
using
for platform independent development.

I think Brooke's point here is that if you're going to work in Unix,
Linux etc, you may well end up writing non-.NET code - in which case,
C# is a better starting point as it's *closer* to C/C++/Java than
VB.NET is.

Again: Which knowledge of C# can be easily applied to C/C++? The syntax of
some loop types and a few keywords. There are /so many/ differences that
reusing this knowledge is really insignificant and IMO should not be a
reason for preferring C# over VB.NET.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 5 '06 #13

Jon/Herfried,

I think Brooke's point here is that if you're going to work in Unix,
Linux etc, you may well end up writing non-.NET code - in which case,
C# is a better starting point as it's *closer* to C/C++/Java than
VB.NET is.

What are your answers related to the question from the OP.

I am about to develop a project like Registry Mechanic using either VB.NET
or C#.NET.
I don't believe that this is asked for Linux or Unix.

:-)

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.com> schreef in bericht
news:MP************************@msnews.microsoft.c om... Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:
"Brooke" <tb******@hotmail.com> schrieb:
> I have used VB since it was released and I was actually a beta
> tester
> when it was called Thunder back around 1990. I picked up VB.NET when
> it
> was first released, and developed a few applications using it, but
> quickly
> made the transition to C#. In the last 5 years I have came to the
> conclusion that it is best to know the "Three C's". The "Three C's"
> are
> C, C++, and C#.

I do not see many similarities between C/C++ and C#.

Not even in syntax? I'm perfectly well aware that the majority of
differences between VB.NET and C# are just in syntactical - but coming
from a C/C++/Java background I was able to pretty much immediately read
a lot of C# code, whereas it takes me a lot longer to read VB.NET with
its fairly significantly different syntax. It's a case of familiarity,
that's all.
So learning C# won't make one more familiar with C/C++. While I think
that C/C++ still have a place in low-level development, I don't think
that a legacy syntax which is optimized for easy input through
ancient devices should have its place in modern, high-level
application development (user mode applications).

Some of us like terse syntax for reasons other than easy input.
>If you plan on just writing code for Windows then either language will
>work. But if you want to be a develop for other operating systems (UNIX,
>LINUX, Embedded, Firmware, etc) then C# is the way to go.

I have to disagree. Both, the VB.NET and the C# compiler emit IL, so it
should not really matter which of the two programming languages one is
using
for platform independent development.

I think Brooke's point here is that if you're going to work in Unix,
Linux etc, you may well end up writing non-.NET code - in which case,
C# is a better starting point as it's *closer* to C/C++/Java than
VB.NET is.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 5 '06 #14

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

I do not see many similarities between C/C++ and C#.

Not even in syntax?

There are some similarities in syntax, but especially in terms of
object-orientiation C++ and C# differ significantly. Additionally C#'s
semantics are close to those of VB6 (references instead of pointers) too.

Sure. All of that just says that it's not going to be a breeze going
from either C# or VB.NET to C/C++ though. The similarities in syntax,
case-sensitivity etc are going to *help* though.

but coming from a C/C++/Java background I was able to pretty
much immediately read a lot of C# code

How long does it take to learn how 'for', 'do', etc. work in C# if you are
familiar with another programming language, be it VB(.NET) or C(++)? One
day? Two days? I have both a C/C++ and VB background, so I do not know,
but once I have understood how a certain thing works in one of the two
programming languages VB.NET and C# I can quickly find out how to archieve
the same in the other programming language.

It's not a question of *learning* it though - it's a case of being
*comfortable* with a type of syntax. I know I find there's a certain
period when I go between Java and C# where I use the wrong naming
conventions and have to keep correcting myself. Can you really say
there wouldn't be the same kind of difficulty going from VB.NET to
C/C++ in terms of semi-colons, case-sensitivity, and just not be
familiar with the operators?

I think Brooke's point here is that if you're going to work in Unix,
Linux etc, you may well end up writing non-.NET code - in which case,
C# is a better starting point as it's *closer* to C/C++/Java than
VB.NET is.

Again: Which knowledge of C# can be easily applied to C/C++? The syntax of
some loop types and a few keywords. There are /so many/ differences that
reusing this knowledge is really insignificant and IMO should not be a
reason for preferring C# over VB.NET.

It's a comfort thing - and unless you can give me any advantage to
picking VB.NET over C# in terms of moving to C/C++, the small advantage
C# *does* offer for that transition is enough to make it a reason for
preferring C# over VB.NET - if, of course, the prospect of writing
C/C++ in the future is a significant one in the first place.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 5 '06 #15

Hi Brooke,

"Brooke" <tb******@hotmail.com> escribió en el mensaje
news:%2***************@TK2MSFTNGP12.phx.gbl...

I have came to the conclusion that it is best to know the "Three C's".
The "Three C's" are C, C++, and C#.
As developers, the more languages you know, the better. You don´t have to
stop at the three C's, and VB.NET, Java, etc. are also assets in your
career.
You also cannot just jump from VB 6 to VB.NET as it is completely
different.

This is not actually true, we could agree that VB6 is different than VB.NET
but not completely, the syntax is quite the same for the most part. Other
thing is that the underlying concepts of the .NET Framework are completely
different. Once you understand the .NET Framework concepts, choosing a
syntax or another is a matter of confort, IMHO.

Just my 2 cents.

--

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

Mar 6 '06 #16

Fabio

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio

How long does it take to learn how 'for', 'do', etc. work in C# if you are
familiar with another programming language, be it VB(.NET) or C(++)? One
day? Two days?

How much does a "standard" vb6 programmer take to understand that to get a
substring he should do string.Subtring() and not Mid(string,...)? And why
Form1.Show() does not works (unfortunately, not true with vs2005).

In this scenario passing directly to c# avoid him to "fall in tentation" :)
because it's true that both vb.net and c# produces IL, but what is the
quality of this IL if vb.net is used as vb7?
--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 6 '06 #17

Fabio

"Carlos J. Quintero [VB MVP]" <ca*****@NOSPAMsogecable.com> ha scritto nel
messaggio

This is not actually true, we could agree that VB6 is different than
VB.NET but not completely, the syntax is quite the same for the most part.
Other thing is that the underlying concepts of the .NET Framework are
completely different. Once you understand the .NET Framework concepts,
choosing a syntax or another is a matter of confort, IMHO.

You're right!
The problem is: will a vb6 programmer understand the difference from vb6-COM
and vb.net-.net framework?
I think that it was good if a vb6 programmer know that vb6 uses COM (note
I'm a vb6 programmer that see how people of my team write vb6 code).
--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 6 '06 #18

"Fabio" <zn*******@virgilio.it> schrieb:

How long does it take to learn how 'for', 'do', etc. work in C# if you
are familiar with another programming language, be it VB(.NET) or C(++)?
One day? Two days?

How much does a "standard" vb6 programmer take to understand that to get a
substring he should do string.Subtring() and not Mid(string,...)?

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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 6 '06 #19

Hi Fabio,

The problem is: will a vb6 programmer understand the difference from
vb6-COM and vb.net-.net framework?
I suppose so, otherwise he won´t go too far.... ;-)
I think that it was good if a vb6 programmer know that vb6 uses COM (note
I'm a vb6 programmer that see how people of my team write vb6 code).

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...
;-)

--

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

Mar 6 '06 #20

Fabio

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio news:%

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 ;)

Mar 6 '06 #21

Fabio

"Carlos J. Quintero [VB MVP]" <ca*****@NOSPAMsogecable.com> ha scritto nel
messaggio

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!"
;)

--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 6 '06 #22

"Fabio" <zn*******@virgilio.it> schrieb:

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 ;)

'Mid' is actually .NET :-).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 6 '06 #23

Fabio

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio news:%23

'Mid' is actually .NET :-).

also

obj = Activator.CreateInstance(Type.GetTypeFromProgID(my ComId, true))

....

Marshal.ReleaseComObject(obj)

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

Mar 6 '06 #24

"Fabio" <zn*******@virgilio.it> schrieb:

'Mid' is actually .NET :-).

also

obj = Activator.CreateInstance(Type.GetTypeFromProgID(my ComId, 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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 6 '06 #25

Fabio

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio

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("Argumen t_GTZero1", New String()
{ "Start" }))
End If
If (Length < 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argumen t_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("Argumen t_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("Argumen t_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).

Mar 6 '06 #26

rmacias

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().

"Fabio" wrote:

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio
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("Argumen t_GTZero1", New String()
{ "Start" }))
End If
If (Length < 0) Then
Throw New
ArgumentException(Utils.GetResourceString("Argumen t_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("Argumen t_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("Argumen t_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).

Mar 6 '06 #27

rmacias

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" wrote:

"Carlos J. Quintero [VB MVP]" <ca*****@NOSPAMsogecable.com> ha scritto nel
messaggio
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!"
;)

--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 6 '06 #28

Fabio

"rmacias" <rm*****@newsgroup.nospam> ha scritto nel messaggio
news:AC8531D9-1E3A-48DC-BFCB-

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. :(

--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 7 '06 #29

"Fabio" <zn*******@virgilio.it> schrieb:

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.

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 7 '06 #30

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
"rmacias" <rm*****@newsgroup.nospam> escribió en el mensaje
news:9D**********************************@microsof t.com...

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. :)

Mar 7 '06 #31

rmacias

"Fabio" wrote:

"rmacias" <rm*****@newsgroup.nospam> ha scritto nel messaggio
news:AC8531D9-1E3A-48DC-BFCB-
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.

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 :)
--

Free .Net Reporting Tool - http://www.neodatatype.net

Mar 7 '06 #32

rmacias

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.

"Carlos J. Quintero [VB MVP]" wrote:

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
"rmacias" <rm*****@newsgroup.nospam> escribiÃ³ en el mensaje
news:9D**********************************@microsof t.com...
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. :)

Mar 7 '06 #33

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 7 '06 #34

Homer J Simpson

"Fabio" <zn*******@virgilio.it> wrote in message
news:44***********************@reader1.news.tin.it ...

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.

Mar 8 '06 #35

Jon --

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

> 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.

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 8 '06 #36

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

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.

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.

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 8 '06 #37

Ian Semmel

Homer J Simpson wrote:

"Fabio" <zn*******@virgilio.it> wrote in message
news:44***********************@reader1.news.tin.it ...

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.

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

Mar 8 '06 #38

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

> 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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 9 '06 #39

Cor Ligthert [MVP] <no************@planet.nl> wrote:

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 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.

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

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.)

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.

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

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.

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.

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.

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.

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 9 '06 #40

Jon,

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.
I would be the last to deny that, however as I see how often samples are
given in C# about datalayers which are made static, than I think that your
comment is as we say in Holland to be more catholic than the pope.

> 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.

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

In the Microsoft VB string methods are some things standard tested and
solved. By instance the check on the right lenght. That can lead to a better
performance than using the substring.

Cor

Mar 9 '06 #41

Cor Ligthert [MVP] wrote:

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.

I would be the last to deny that, however as I see how often samples are
given in C# about datalayers which are made static, than I think that your
comment is as we say in Holland to be more catholic than the pope.

That would only be true if I were defending that kind of datalayer vs
one which was more OO.

> 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.

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

In the Microsoft VB string methods are some things standard tested and
solved. By instance the check on the right lenght. That can lead to a better
performance than using the substring.

String.Substring tests things too. If any of the parameters specified
are invalid, an exception is thrown, and if the specified length is 0,
string.Empty is returned. It could be that due to the order of some
checks, there are *some* very specific circumstances in which using Mid
performs better. (I'd be interested in seeing what those circumstances
are, however.)

In the vast majority, however - i.e. the calls where Mid ends up
calling String.Substring - Mid will perform worse because it's doing
other things before calling String.Substring.

Jon

Mar 9 '06 #42

Jon,

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

> 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.

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

That's not a criterion for me. I see OO as a valuable tool, but I cannot
see any advantages of object-orientation in this particular case over a
procedural approach.
2) There's a direct equivalent in String.Substring
It's not a direct equivalent. For example, I use 'Mid' if I want to make
use of its special 'Nothing' reference handling capability.
3) Users of other languages are more likely to understand Substring
Well, IIRC there are more developers on the world who are able to understand
'Mid' than 'String.Substring', I assume. Remember the popularity of VB6 --
all .NET languages together do not have such a huge number of users.
4) The Microsoft.VisualBasic assembly may not be entirely implemented
in other CLR implementations, whereas System.String certainly will
be
This may apply to any library. I agree with you that it's more likely that
'System.String' is implemented, but I'd consider a VB.NET implementation
without support of "Microsoft.VisualBasic.dll" as an imcomplete solution.
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.)
I didn't take a look at these particular functions. Bugs can be everywhere.
The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
It has been fixed in the current version. However, this operator could have
been widely used. I do not think that the overall quality of
"Microsoft.VisualBasic.dll" is lower than those of the .NET Framework class
library.
6) It's less efficient as it's performing all the checks that Substring
performs before calling Substring.

Well, sometimes I want this checks to be performed instead of putting them
into my code.

[Maybe I'll find time to reply on the rest later...]

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 9 '06 #43

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

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.

That's true, but I am not using OO for the sake of using OO. I use OO where
it increases overall productivity (reusability, maintainability, stability)
and I use other approaches in cases where I cannot see any advantages by
using OO.

Some months ago I have talked to a good friend of mine about the solution
taken for strings versus the solution taken for numeric types. The 'String'
class implements instance methods for certain operations which work on the
object they are called on, such as 'String.Substring'. Mathematical
operations however are implemented as shared methods of the 'Math' class.
Why not make 'Cos' an instance method of the 'Double' class? This would
certainly make the code more OO...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Mar 9 '06 #44

Some months ago I have talked to a good friend of mine about the solution
taken for strings versus the solution taken for numeric types. The
'String' class implements instance methods for certain operations which
work on the object they are called on, such as 'String.Substring'.
Mathematical operations however are implemented as shared methods of the
'Math' class. Why not make 'Cos' an instance method of the 'Double' class?
This would certainly make the code more OO...

:-)

Mar 9 '06 #45

Herfried K. Wagner [MVP] wrote:

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

That's not a criterion for me. I see OO as a valuable tool, but I cannot
see any advantages of object-orientation in this particular case over a
procedural approach.

It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.

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

It's not a direct equivalent. For example, I use 'Mid' if I want to make
use of its special 'Nothing' reference handling capability.

Whereas I'd deal with that explicitly in code, as I believe that's
clearer - I suspect that far from everyone knows that special case.

(It's also not directly equivalent in terms of its "basing" of 1 rather
than 0. Again, as the rest of the .NET framework is essentially
0-based, that seems like an inconsistency to me. Yes, it's consistent
with VB6, but I'd hope to move towards a more .NET-centric code base
and away from a VB6-centric code base.)

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

Well, IIRC there are more developers on the world who are able to understand
'Mid' than 'String.Substring', I assume. Remember the popularity of VB6 --
all .NET languages together do not have such a huge number of users.

That will change, over time however. If you care more about readability
for VB6 developers than for other .NET developers, that's your choice
though. I think it's a reasonable objection for me to make at the same
time.

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

This may apply to any library. I agree with you that it's more likely that
'System.String' is implemented, but I'd consider a VB.NET implementation
without support of "Microsoft.VisualBasic.dll" as an imcomplete solution.

Well, it would still be a perfectly good ECMA library implementation.
There's a reason why it's *Microsoft*.VisualBasic...

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.)

I didn't take a look at these particular functions. Bugs can be everywhere.
The 'Like' operator of VB.NET has been flawed in VB.NET 7.*, for example.
It has been fixed in the current version. However, this operator could have
been widely used. I do not think that the overall quality of
"Microsoft.VisualBasic.dll" is lower than those of the .NET Framework class
library.

Maybe I happened to be unlucky then. It makes sense to me, however,
that the most used code tends to be the most reliable, because bugs are
more likely to get found in the wild and then fixed.

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

Well, sometimes I want this checks to be performed instead of putting them
into my code.

But they're already performed - in String.Substring! String.Substring
will check whether or not you've given it an invalid length, but if you
call Mid instead of Substring, the check gets made twice.

Jon

Mar 9 '06 #46

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> escribió en el mensaje
news:um**************@tk2msftngp13.phx.gbl...

Mathematical operations however are implemented as shared methods of the
'Math' class. Why not make 'Cos' an instance method of the 'Double' class?
This would certainly make the code more OO...

Hi Herfried,

While I see some of your point (and also Jon's one) notice that the Cos
mathematical function would be suitable for an Angle class, but not for a
Double class, since not every Double instance is intended to store an angle.
In fact the Double class is not the best type to store an angle in a OO
world, you would need an Angle class with input validation (0-360 degrees),
measurement system (radians, 360-degrees, 400-degrees, military-degrees),
special handling of "+" and "-" operators (350º + 20º = 10º) , etc.

--

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

Mar 9 '06 #47

"Jon Skeet [C# MVP]" <sk***@pobox.com> escribió en el mensaje
news:11**********************@u72g2000cwu.googlegr oups.com...

It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.

Hi Jon,

Notice that with current IDEs you can navigate to the definition of any
"magical" function, we no longer work with blind IDEs. And also, in a OOP
you can have classes with static (C#) / Shared (VB.NET) methods and at least
VB.NET (not sure about C#) allows you to add an "using" / "Imports"
statement for the class (not only for the namespace) and you use just the
name of the function in the code and you lose the same clarity, but I see
your point, and when using shared/static methods I always try to prefix them
with the class to gain clarity.

--

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

Mar 9 '06 #48

Carlos J. Quintero [VB MVP] wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> escribió en el mensaje
news:11**********************@u72g2000cwu.googlegr oups.com...
It's all about clarity as far as I'm concerned. When you use "Mid",
someone who doesn't know it's a "magical" VB function would be at a
loss to know what's going on. When you use String.Substring, it should
be obvious to anyone who knows *anything* about whatever language is
being used that you're calling a method on the string.
Notice that with current IDEs you can navigate to the definition of any
"magical" function, we no longer work with blind IDEs.

Sure - but you really don't want to have to keep doing that for
something as basic as taking a substring.
And also, in a OOP
you can have classes with static (C#) / Shared (VB.NET) methods and at least
VB.NET (not sure about C#) allows you to add an "using" / "Imports"
statement for the class (not only for the namespace) and you use just the
name of the function in the code and you lose the same clarity, but I see
your point, and when using shared/static methods I always try to prefix them
with the class to gain clarity.

There are times when static methods make sense. However, to use a
static method acting on a different type when there's a perfectly good
method which is already part of the class seems pretty pointless to me.
Part of an upgrade process? Fine. Part of new code? Preferrably not,
IMO.

Jon

Mar 9 '06 #49