using classes vs. modules

  • Thread starter Thread starter Andy B.
  • Start date Start date
I'm not sure I'm understanding you at all... stringA == null is
perefectly
valid in C#..
Click to expand...
Tom,

I see that you are Partially right and wrong (Like me)

private string a;
method()
{
if (a == null) MessageBox.Show(a);
}
Goes

But I tried it always like this
string a;
if (a == null) MessageBox.Show(a);

This wont work because it telss that a is not initialized.
That was were my message was about.

Sorry everybody, I should not have posted this in the VB language newsgroup.

Cor
 
That's perfectly valid. The return statement is optional in VB.NET.
Also,
because VB auto initializes local values (a very evil practice - and one
I've
always hated in VB), then Func will always return 0.
Click to expand...
You probably don't like to eat snails, oysters and more of that stuff, while
I like that.

In fact I like the French (or should I say Toscany kitchen) more than
English ones, However, I know that I can eat very well in the USA.

That is probably the difference, I can like more different things, while you
start direct with hating something as it does not directly fit in your
common use.

(Don't take it too serious Tom)

Cor
 
Hello Michael,
Did you actually try this? I tried that exact code before posting and
the errors returned were zero, zip, nil, nada, nothing. I tried it in
2005 also and again got no errors. Are you sure it isn't your
information that is flawed? :-)
Click to expand...

Please excuse the delay, I have been jumping around a bit today and have
not checked the group since this morning.

Michael my genuinue apologies. You are absolutely correct in this.

As I suggested to you, I should have checked my own facts. Again sorry.

I think I was confusing the integer example you gave with functions that
return reference types, in which VB.Net is kind enough to give such a warning.

I saw some of your previous statements as being very troll-like hence my
bridge comment.
I hope everone understands that this was meant in the sit-under sense rather
than the jump-off sense.

I still believe that you appear to have jumped into a vb.net group largely
with the purpose of annoyance.

However this is not an excuse for my own behaviour. Again Sorry

(It does appear that when I am wrong, I am extremely good at being wrong)
 
Tom,

I see that you are Partially right and wrong (Like me)

private string a;
method()
{
if (a == null) MessageBox.Show(a);
}
Goes

But I tried it always like this
string a;
if (a == null) MessageBox.Show(a);

This wont work because it telss that a is not initialized.
That was were my message was about.
Click to expand...

Which I believe I mentioned... You have to initialize local values - but, it
is perfectly valid to say:

string a = null;
if (a == null) MessageBox.Show(a);
 
string a = null;
if (a == null) MessageBox.Show(a);
Click to expand...
There was my message based on. C# does not initialize like VB.

But as I readed already, you hate that, while I like that.

Matter of taste probably

Cor
 
Hello Michael,
Actually VB6 defaulted to nothing (or was it empty) but not empty string.
Click to expand...
Dim s As String
Dim b As Boolean
b = (s = "")
MsgBox b

'In this scenario b is True.

Best regards,

Martin
 
You're barking up the wrong tree. C# warns about real errors that VB
will miss and only become a problem at run time. As an example, have
a look at this code:

Function ABC As Integer
Dim y as Integer
y = 5
End Function

There are 2 errors in this function that VB will miss. The more minor
one is that y is only ever set and never used. The more serious one
is that it doesn't warn that you have forgotten to return a value.
This could become quite a serious problem especially in a more
complex function when you forget to return a value from just one of
the branches. I'm sure there's plenty more that VB doesn't warn you
about.
Click to expand...

Meybe we first have to define what an "error" is? IMHO an "error" on
behalf of a compiler is code that won't compile and run.

You are speaking of "warnings" on logical mistakes.

But, if you want, there are a lot of warnings the VB compiler can show,
using code-analysis. There are approx. 200 and more Rules that might
help you. And some thirs party tools out there might provide you tons
of additional warnings.

Sometimes it seems to me that there is the need of just one little step
of evolution beyond these tools. After that you might let your cat pet
crossing your keyboard having only to use these tools afterwards for
getting pretty running code.
;-)

Sorry, but if a developer needs permanently to be told that a function
has to have to return a value, or somewhat else like that, I would not
like to know more about the other parts of the code he's writing.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de
 
Michael said:
When it is so simple to switch and C# is easier to use
and more powerful why continue with VB?
Click to expand...

There are no really good reasons. They are too close together - as you said
yourself. The few advantages it might offer are shot down by the
inacceptable drawbacks already mentioned.
C# is actually pretty good with DirectX, I did a whole lot of work
with DirectShow in C# and it worked quite well.
Click to expand...

I wrote "_native_ DirectX".

#include "direct3d9.h" does not work in C#


Armin
 
Hello Martin,
Dim s As String
Dim b As Boolean
b = (s = "")
MsgBox b

'In this scenario b is True.
Click to expand...

This is, because VB6 automatically assigns an empty string, when
accessing an unused string variable. The 'real' value of an unused
string variable is vbNullString.

See this:

Dim s As String
Debug.Print StrPtr(s)

s = vbNullString
Debug.Print StrPtr(s)

s = ""
Debug.Print StrPtr(s)


This behavior may be used in VB6 to determine if an user cancelled an
inputbox or if an optional string parameter is 'missing' (because
IsMissing only works with optional variant parameters).


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de
 
Cor Ligthert said:
Michael,

Funny that this is mentioned.

You see often confusion by solely C# users about the string.
Click to expand...

It's funny you should say C# developers get confused by string but you, a VB
developer, appears to be confused.
The string is an object which can have no reference (impossible in C#)

In that situation the object is nothing (sentence does not work in C#, not
a dialect, simple a language distinct)

The string can has well be empty (you can see that if you use indexof by
instance which gives back -1 when it is like that) then the reference =
nothing.

As you use if stringA = nothing, then a non referenced string will be
first set to its default value and then the test will be evealuated and
therefore is true.
Very handy because that is then the exact value you want in a string. This
is impossible to do in C#/
Click to expand...

That's just not true, a string in C# can be null, an empty string or a
string of length greater than 1. You can set each of these states easily and
test each of these states easily. I'm not sure why you think this is
impossible in C#.

Michael
 
Martin H. said:
Hello Michael,

Dim s As String
Dim b As Boolean
b = (s = "")
MsgBox b

'In this scenario b is True.
Click to expand...

Yes that is true but as I said the string s is still nothing. It's just the
test s = "" in VB will return true if the string is nothing. It will also
return true if the string is an empty string so your test is incorrect. You
need to compare it to vbNullString I think or maybe you need to use StrPtr
and compare that to 0. Give that a try and get back to me.

Michael
 
Rory Becker said:
Please excuse the delay, I have been jumping around a bit today and have
not checked the group since this morning.

Michael my genuinue apologies. You are absolutely correct in this.

As I suggested to you, I should have checked my own facts. Again sorry.

I think I was confusing the integer example you gave with functions that
return reference types, in which VB.Net is kind enough to give such a
warning.
Click to expand...

That is interesting, I didn't realise it worked with reference types. I
think because VB uses the function name like a local variable then it needs
to be initialised so it is like the return value has been set.
I saw some of your previous statements as being very troll-like hence my
bridge comment.
I hope everone understands that this was meant in the sit-under sense
rather than the jump-off sense.

I still believe that you appear to have jumped into a vb.net group largely
with the purpose of annoyance.
Click to expand...

Sometimes things just develop this way. I really just come here to learn a
few new things then find myself in religious discussions.
However this is not an excuse for my own behaviour. Again Sorry

(It does appear that when I am wrong, I am extremely good at being wrong)
Click to expand...

No worries. You really take all the fun out of the arguement when you do
that ;-)

Michael
 
Hello Michael,
Give that a try and get back to me.
Click to expand...

Yes, my master... :P
Yes that is true but as I said the string s is still nothing. It's just the
test s = "" in VB will return true if the string is nothing. It will also
return true if the string is an empty string so your test is incorrect. You
need to compare it to vbNullString I think or maybe you need to use StrPtr
and compare that to 0.
Click to expand...

If you compare with
b = (s Is Nothing)

You get a Type Mismatch Error.

The reason is that s is NOT an object, therefore it cannot be Nothing.

When comparing
b = (s = vbNullString), the result is True.
The help file says:
vbNullString:
String having value 0
Not the same as a zero-length string (""); used for calling external
procedures

The point is in _used for calling external procedures_ : This is just
good for API calls (as they expect a \0 at the end of a string).
However, VB doesn't care for the \0, so it gives you the same result as
with "".

Best regards,

Martin
 
Martin H. said:
If you compare with
b = (s Is Nothing)

You get a Type Mismatch Error.

The reason is that s is NOT an object, therefore it cannot be Nothing.
Click to expand...

I did say "Actually VB6 defaulted to nothing (or was it empty) but not empty
string." I did state I was unsure if it was nothing or empty. Maybe it's one
of the other 10 forms of nothingness that vb6 had.
When comparing
b = (s = vbNullString), the result is True.
The help file says:
vbNullString:
String having value 0
Not the same as a zero-length string (""); used for calling external
procedures

The point is in _used for calling external procedures_ : This is just good
for API calls (as they expect a \0 at the end of a string). However, VB
doesn't care for the \0, so it gives you the same result as with "".
Click to expand...

Did you try the StrPtr (or is it VarPtr) thing. The point a string is not
initialised to empty string, it's initialised to a null pointer. I seem to
remember there was a native way to check this as you could check if a user
pushed cancel on an input box.

Michael
 
Harald M. Genauck said:
Sorry, but if a developer needs permanently to be told that a function has
to have to return a value, or somewhat else like that, I would not like to
know more about the other parts of the code he's writing.
Click to expand...

This is flawed logic. While I am a good developer I am not perfect. I've
received this warning many times and it's helped eliminate what could have
been a bug later. By your logic we should remove all such warnings and run
with option unstrict because real programmers don't need the compiler to
tell them what they're doing wrong.

Michael
 
Michael D. Ober said:
Turning on Option Strict On will fix the more serious error - no return
value.
Click to expand...

That is true only for reference types, for an integer it won't give you a
warning.
MS should have made Option Strict On the default, but you can do so via
the options.
Click to expand...

They should have not had option strict at all and made it always strict. If
there was a dot net language that did that I would be using it ;-)
The issue of setting the variable and not using it is indeed missed by the
VB compiler, but it should be optimized out by the JIT compiler as it's
the equivalent of a NOP.
Click to expand...

That's true, it's a minor issue but was just an example I came up with.

Michael
 
Hello Michael,
Did you try the StrPtr (or is it VarPtr) thing. The point a string is not
initialised to empty string, it's initialised to a null pointer. I seem to
remember there was a native way to check this as you could check if a user
pushed cancel on an input box.
Click to expand...

No, I haven't. But I am interested to find what you find out. Maybe you
can post an example you tried out.

Best regards,

Martin
 
Tom Shelton said:
Actually, Rory - I just tried it in 2008 and he's right on both accounts.
I
can explain to you why the return thing happens - it's a side effect of:

1) using the function name as a return value
2) defualt initialization of variables

See, it's possilbe in VB to return a value from a VB function by assigning
to
it's name:

Function Func() As Integer
Func = 5
End Function

That's perfectly valid. The return statement is optional in VB.NET.
Also,
because VB auto initializes local values (a very evil practice - and one
I've
always hated in VB), then Func will always return 0.
Click to expand...

Surely the compiler could still see that Func was never assigned to. It does
it for reference types so should be able to do it for value types.

Michael
 
Martin H. said:
No, I haven't. But I am interested to find what you find out. Maybe you
can post an example you tried out.
Click to expand...

I don't have VB6 any more but it will return a value of zero. If you
initialise the string to anything then it will return a value which is a
pointer to the string data.

Michael
 
Armin Zingler said:
There are no really good reasons. They are too close together - as you
said yourself. The few advantages it might offer are shot down by the
inacceptable drawbacks already mentioned.
Click to expand...

Anything "inacceptable" is just going to be something minor that only really
exists as an issue to you. For example, your dislike of {} is just a
preference of yours where less compiler warnings is something that is a real
issue.
I wrote "_native_ DirectX".

#include "direct3d9.h" does not work in C#
Click to expand...

No but that is just an include library for C, you can still work natively
with DirectX in C# you just have to convert what is in the include file into
C# code. The only difference is who wrote the include file. The alternative
is to download the C# include that someone has written, I believe most of
directshow has been done and probably all the other parts of DirectX. The
ability to use pointers in C# makes stuff like this possible.

Michael
 
Back
Top