Bizarre: string.split() method

  • Thread starter Thread starter JV
  • Start date Start date
J

JV

This is too weird. You're going to love this one.

I just ran across the most bizarre DotNet "feature" with the String.Split()
method. You are supposed to pass it an array of characters to tell it what
separators to split the string on. if it finds any of those characters, it
treats that as a separator.

Well, in VB.NET you can turn off option strict if you want to write
non-typesafe code (*bleh!*). This allows you to specify a string of
characters instead of a character array, and it treats the entire string as
a separator. Kind of handy, but I can find no way to do that in a typesafe
language (you'd have to write your own function to split the string).
 
Well, in VB.NET you can turn off option strict if you want to write
non-typesafe code (*bleh!*). This allows you to specify a string of
characters instead of a character array, and it treats the entire string as
a separator. Kind of handy, but I can find no way to do that in a typesafe
language (you'd have to write your own function to split the string).
Click to expand...

Can't you use String.ToCharArray() ?




Mattias
 
well, vb doesn't use the String.Split, it has it own which you can call from
the language of your choice.

c#

string[] r =
Microsoft.VisualBasic.String.Split("string1**string2**string3","**");

-- bruce (sqlwork.com)
 
But the origional poster says "it treats the entire string as a separator".
Split a string using "as" as seperator will certainly not behave the same as
using 'a' and 's'...
 
uh?
what about (in 2.0 doc, I am not sure about 1.x)
public string[] Split(
string[] separator,
StringSplitOptions options
);
 
That is good to know. However, I think that requires loading that whole vb
dll and any supportive dlls. That is probabably is a pretty big cost for
one split function. Don't know the mem or perf cost as have not looked into
it, but something to think about. Naturally, the same can be done pretty
easy with a static regex method put in your utils library.

--
William Stacey [MVP]

Bruce Barker said:
well, vb doesn't use the String.Split, it has it own which you can call
from the language of your choice.

c#

string[] r =
Microsoft.VisualBasic.String.Split("string1**string2**string3","**");

-- bruce (sqlwork.com)


JV said:
This is too weird. You're going to love this one.

I just ran across the most bizarre DotNet "feature" with the
String.Split() method. You are supposed to pass it an array of
characters to tell it what separators to split the string on. if it
finds any of those characters, it treats that as a separator.

Well, in VB.NET you can turn off option strict if you want to write
non-typesafe code (*bleh!*). This allows you to specify a string of
characters instead of a character array, and it treats the entire string
as a separator. Kind of handy, but I can find no way to do that in a
typesafe language (you'd have to write your own function to split the
string).
Click to expand...
Click to expand...
 
JV said:
This is too weird. You're going to love this one.

I just ran across the most bizarre DotNet "feature" with the String.Split()
method. You are supposed to pass it an array of characters to tell it what
separators to split the string on. if it finds any of those characters, it
treats that as a separator.

Well, in VB.NET you can turn off option strict if you want to write
non-typesafe code (*bleh!*). This allows you to specify a string of
characters instead of a character array, and it treats the entire string as
a separator. Kind of handy, but I can find no way to do that in a typesafe
language (you'd have to write your own function to split the string).
Click to expand...

Time for you to learn c#
 
Indeed this overload is new in 2.0... the 1.x Framework only has
splitting on characters, not strings.

uh?
what about (in 2.0 doc, I am not sure about 1.x)
public string[] Split(
string[] separator,
StringSplitOptions options
);
Click to expand...
 
William,
That is good to know. However, I think that requires loading that whole
vb dll and any supportive dlls. That is probabably is a pretty big cost
for one split function. Don't know the mem or perf cost as have not
looked into it, but something to think about. Naturally, the same can be
done pretty easy with a static regex method put in your utils library.
Click to expand...

That DLL is part of the standard Net framework, there is nothing needed to
load, it is just another namespace as System.net is another standard one.

Cor
 
JV,

You can do in VBNet any system.net safe code method as in C# in the same
way.

Why would you set option Strict Of, it sounds for me the same as that you
say that you want to use in C# only unsafe code.

Probably because of the fact that there are millions of VB classic
programmers who are converting to VBNet option strict it is when you start
standard of. (For a programmer who is than more used to VBNet it is just
setting one option in the IDE to let it work forever with Option Strict On)

If there would have been so many people converting from VB classic in one
stroke to C# than that would have had probably a feature like VBNet to make
it easier for a VB classic programmer to convert to C#.

Your message sounds for me as a kind of weird thinking.

Only my opinion.

Cor
 
that is not true. not all of the BCL come in one giant dll. aside from
everything that's in mscorlib, every extra dll you include in your project is
a seperate dll you have to load into the appdomain. and the string split
happens to be in a seperate Microsoft.VisualBasic.dll
 
Than why is than the Exe from the same VBNet program sometimes more than 2
times smaller than from the same C# program?

Cor
 
My friend, I have been coding in C# since the 2nd Beta of Visual Studio.
And I have about 10 years of C++ before that. The problem I have is with a
conversion of an application originally written in VB.NET. It does not make
sense to me that strings would behave differently in two DotNet languages as
the string class is supposed to be a framework class, not a
language-specific class.
 
Sorry, Cor, but I think you missed the point.

It so happens that I came across this while trying to convert some VB.NET
code (written by inexperienced programmers) to C#. They did not use Option
Strict in their coding (yech!). But that is not the point. It is not my
intention to write code that is non-typesafe.

The point is that we are led to believe that both VB and C# use the same
framework classes, but here we find that string class behavior in VB is not
necessarily equal to string class behavior in C#. This seems very
inappropriate at best. I am fine with VB having additional library
functions available to handle strings, but both languages should be using
the identical framework string class.
 
This turns out to be one of the best workarounds. But, again, that's not
the point. The point is that both languages are supposed to use the same
string class (that's why they called it "common runtime library" I
thought?), and yet they don't behave identically.
 
Back
Top