Console.WriteLine(s) Is Missing Line Terminator?

[Fir5tSight]

Hi All,

I have a simple VB code:

Sub OutputLine(ByRef Level As String, ByRef InfoString As String)
Const gSTDOUT As Integer = -11
Dim hStdOut, BytesWritten As Integer
Dim s As String

s = Level & " " & InfoString
Console.WriteLine(s)

End Sub

This should write string s to a standard output with a line return each
time. However, I have two issues here:

1) Level is missing from the output - It only contains InfoString. For
instance: When Level = "INFO", and InforString = "Process started", The
output is "Process started" only;
2) No newline character at the end.

Any advice on what it going on and how to get this resolved? Thanks!
-Emily

[Mattias Sjögren]

>

>1) Level is missing from the output - It only contains InfoString. For
instance: When Level = "INFO", and InforString = "Process started", The
output is "Process started" only;
2) No newline character at the end.

Any advice on what it going on and how to get this resolved? Thanks!

Can you post a small complete application that will let us reproduce
the behaviour you're seeing? Console.WriteLine has always worked fine
here so I suspect your input is incorrect.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Gadget]

On Fri, 17 Nov 2006 21:46:44 +0100, Mattias Sjögren wrote:

>>
1) Level is missing from the output - It only contains InfoString. For
instance: When Level = "INFO", and InforString = "Process started", The
output is "Process started" only;
2) No newline character at the end.

Any advice on what it going on and how to get this resolved? Thanks!

Can you post a small complete application that will let us reproduce
the behaviour you're seeing? Console.WriteLine has always worked fine
here so I suspect your input is incorrect.
Mattias

Also as a rule of thumb, avoid using '&' to concatenate strings, as it has
a tendency to hide casting errors. It's only in there for VB6 style
compatibility, and should be burned at the stake along with Option Explicit
Off :)

Try placing a breakpoint on the Console.WriteLine statement and see what
the variable 's' contains. Perhaps you're passing control characters on the
end?

Cheers,
Gadget

[Mattias Sjögren]

>Also as a rule of thumb, avoid using '&' to concatenate strings, as it has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.

>It's only in there for VB6 style compatibility,

No it certainly isn't.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Gadget]

On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>>Also as a rule of thumb, avoid using '&' to concatenate strings, as it has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.

*Hopefully* not the + operator? I'm interested to know why you say that, so
please let me know if I'm missing something :)

The '&' concatenation performs runtime casting of objects to strings, so it
always calls the default ToString() method. It is better to perform this
cast implicitly at design time so you can also specify the format if needed
by calling an integer's ToString method.
Yes, in VB6 it was slower to join strings with '+', but in VB.Net all
strings are internally joined this way anyway.

>>It's only in there for VB6 style compatibility,

No it certainly isn't.

OK, fire away Mattias, I am genuinely interested.

Cheers,
Gadget

[RobinS]

I thought they recommend the & operator for concatenating
strings in VB over the + operator.

When outputting strings, you could try using FormatString
instead.

Console.WriteLine(String.Format("Level = {0}, InfoString = {1}", _
Level, InfoString))

Robin S.
-------------------------------
"Gadget" <ga****@sobell.netwrote in message
news:b9***************************@40tude.net...

On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>>>Also as a rule of thumb, avoid using '&' to concatenate strings, as it
has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.

*Hopefully* not the + operator? I'm interested to know why you say that,
so
please let me know if I'm missing something :)

The '&' concatenation performs runtime casting of objects to strings, so
it
always calls the default ToString() method. It is better to perform this
cast implicitly at design time so you can also specify the format if
needed
by calling an integer's ToString method.
Yes, in VB6 it was slower to join strings with '+', but in VB.Net all
strings are internally joined this way anyway.

>>>It's only in there for VB6 style compatibility,

No it certainly isn't.

OK, fire away Mattias, I am genuinely interested.

Cheers,
Gadget

[Tom Leylan]

When in doubt "simplify".

1) create a new project or make sure you turn off everything except the code
needed to test this method.
Get all other potential problems out of the way.

2) start with Console.WriteLine("test") and have that work without a hitch
If that didn't work it is pointless to go on right? Nothing we do to
complicate it will make it work correctly.

3) then have it display one of the variables
Again we want to see if it still works.

4) and finally when that is working concatenate the strings
If it fails at this point you are assured it has to do with the
concatenation stage and not WriteLine()
I must point out gSTDOUT, BytesWritten, etc? They aren't used. Even the
variable "s" isn't really required: Console.WriteLine(Level + " " +
InfoString) will do it and suddenly that's the only thing in OutputLine().

My advice would be to assume that most of the basic .Net library code works
as advertised. If a routine isn't working, first check your assumptions and
then check your code. There may be a bug but if was in Console.WriteLine()
it would have been discovered by now.

The secret is "take small steps".

"Fir5tSight" <fi********@yahoo.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

Hi All,

I have a simple VB code:

Sub OutputLine(ByRef Level As String, ByRef InfoString As String)
Const gSTDOUT As Integer = -11
Dim hStdOut, BytesWritten As Integer
Dim s As String

s = Level & " " & InfoString
Console.WriteLine(s)

End Sub

This should write string s to a standard output with a line return each
time. However, I have two issues here:

1) Level is missing from the output - It only contains InfoString. For
instance: When Level = "INFO", and InforString = "Process started", The
output is "Process started" only;
2) No newline character at the end.

Any advice on what it going on and how to get this resolved? Thanks!
-Emily

[Gadget]

On Fri, 17 Nov 2006 22:14:28 -0800, RobinS wrote:

I thought they recommend the & operator for concatenating
strings in VB over the + operator.

When outputting strings, you could try using FormatString
instead.

Console.WriteLine(String.Format("Level = {0}, InfoString = {1}", _
Level, InfoString))

Yes, String.Format is the nicest and most flexible way to create complex
output, but concatenating two or more strings in a single statement doesn't
need that level of overhead. In this case all that was required was
Level + " " + InfoString
so I wouldn't bother using Format for this :)

Re the recommendation of using '&' over '+', well the ampersand was
introduced to remove the ambiguity of concatenation vs addition, which is
very important when you have the concept of variants, but becomes a more
awkward cast override when you have strongly typed datatypes, basically
saying "convert all the numbers in this list into strings".
I prefer to see this done as dblMyVar.ToString(), so I know exactly what is
happening, and so I *know* that the coder was intending the output in the
format he/she chose, such as dblMyVar.ToString("0.00").

Basically, when you turn Option Strict On you can't cast a double to a
string, so why does the '&' concatenation override this? Could this explain
why no other .NET language supports this string operator?

Cheers,
Gadget

[Gadget]

On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>>Also as a rule of thumb, avoid using '&' to concatenate strings, as it has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.

>>It's only in there for VB6 style compatibility,

No it certainly isn't.
Mattias

I'm still fascinated to hear your reasoning, Mattias. Don't let this thread
die... :)

Cheers,
Gadget

[RobinS]

Let me step in and support Mattias here.

According to Francesco Balena: "The + operator is supported
as a string concatenation operator only for historical
reasons. Using the & operator to concatenate strings
instead of the + operator makes your code more readable
and less ambiguous."

I completely agree. When I see this:

myData = firstData + secondData

If I don't know if those are strings or numerics,
I won't know if it's concatenating or adding.

And when Microsoft says something is included "for historical
reasons", to me it's like saying "Say Hasta La Vista to
this feature in the next version, baby."

Robin S.
-------------------------------------

"Gadget" <ga****@sobell.netwrote in message
news:4e*****************************@40tude.net...

On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>>>Also as a rule of thumb, avoid using '&' to concatenate strings, as it
has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.

>>>It's only in there for VB6 style compatibility,

No it certainly isn't.
Mattias

I'm still fascinated to hear your reasoning, Mattias. Don't let this
thread
die... :)

Cheers,
Gadget

[Mattias Sjögren]

>I'm still fascinated to hear your reasoning, Mattias. Don't let this thread

>die... :)

Well the others have pretty much stated what I was going to already.

If you don't like &, what do you suggest we use instead? There are
essentially three ways to concatenate strings in VB.

+ operator
& operator
BCL methods such as String.Concat

& has been recommended over + for as long as I've been using VB. The
reason being the risk of errors due to funny conversion rules or
ambiguity. Even Microsoft themselves recommend avoiding + for
concatenation here
http://msdn2.microsoft.com/en-us/library/9c5t70w2.aspx

If you use & it's obvious that you mean string contatenation and not
addition or something else.

Using String.Concat can be appropriate in some cases but I wouldn't
use it all the time. I find a simple operator far more readable and
I'm no OOP zealot.
You also said in the other subthread that no other language supports
the & operator. I hope you realize that the + operator in C# works
pretty much the same way as & when it comes to string concatenation.
Specifically it implicitly calls ToString on an operand if it's not a
string. The difference is that it requires at least one operand to
actually be a string, whereas & in VB can implicily convert both
operands. If you don't like the result of the implcit ToString call,
just do something more appropriate yourself (such an explicit ToString
call with specific formating).
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Gadget]

On Mon, 20 Nov 2006 23:23:14 +0100, Mattias Sjögren wrote:

>>I'm still fascinated to hear your reasoning, Mattias. Don't let this thread
die... :)

Well the others have pretty much stated what I was going to already.

If you don't like &, what do you suggest we use instead? There are
essentially three ways to concatenate strings in VB.

+ operator
& operator
BCL methods such as String.Concat

& has been recommended over + for as long as I've been using VB. The
reason being the risk of errors due to funny conversion rules or
ambiguity. Even Microsoft themselves recommend avoiding + for
concatenation here
http://msdn2.microsoft.com/en-us/library/9c5t70w2.aspx

But aren't these "funny" compile time errors, not runtime?

If you use & it's obvious that you mean string contatenation and not
addition or something else.

Well, we moved on from variants a few years ago now, so I'm not quite sure
where this applies.

Using String.Concat can be appropriate in some cases but I wouldn't
use it all the time. I find a simple operator far more readable and
I'm no OOP zealot.

I don't think I've ever used String.Concat :)
It probably compiles to exactly the same code as A + B or A & B if both are
strings.

You also said in the other subthread that no other language supports
the & operator. I hope you realize that the + operator in C# works
pretty much the same way as & when it comes to string concatenation.
Specifically it implicitly calls ToString on an operand if it's not a
string. The difference is that it requires at least one operand to
actually be a string, whereas & in VB can implicily convert both
operands. If you don't like the result of the implcit ToString call,
just do something more appropriate yourself (such an explicit ToString
call with specific formating).

Er... yes, obviously it works the same way as '+' in C#... there is no
'special' string concatenation operator in any of the other .NET languages.
The point I made is that I don't like the implicit casting that goes on
with the '&' operator. It avoids any typecasting, which is good if you want
to ignore your datatypes, but as I said, if Option Strict On forces the
casting of datatypes to avoid confusion, why does the '&' operator override
this option?
I think it's a rather messy element to put into VB.NET. I understand why it
is in there, for backwards compatibility, but you believe that is not the
reason?
As I said, why does no other .NET language require or provide a separate
string concatenation operator? Are VB.Net developers the only ones who
require this?

Cheers,
Gadget

[Gadget]

On Mon, 20 Nov 2006 10:51:15 -0800, RobinS wrote:

Let me step in and support Mattias here.

According to Francesco Balena: "The + operator is supported
as a string concatenation operator only for historical
reasons. Using the & operator to concatenate strings
instead of the + operator makes your code more readable
and less ambiguous."

I guess it's historical in that it's always been the standard in every
languages except VB. It's a bit like saying '+' is only used as a string
concatenator in a fraction of languages; fractions like 50/3 and 17/2 :D

I completely agree. When I see this:

myData = firstData + secondData

If I don't know if those are strings or numerics,
I won't know if it's concatenating or adding.

Quite rightly too! MS also recommend using meaningful variable names. Can
you tell me what types those two variables types are?
For example, is
myData = strFirstName & " " & strLastName
any more readable than
myData = strFirstName + " " + strLastName
?
It's the ease with which it encourages lazy programming that puts me off
the '&' concatenator. How many times have you seen 'bodged' code using '&'
to avoid null errors instead of checking for null properly? I've frequently
seen code such as strX = DB["Name"] & "" because the coder didn't want to
bother checking if the Name was null? Is this really good coding practise,
and to follow up your example, is it 'readable and unambiguous'?

Overall, using '&' vs '+' to document when you are want your variables to
be treated as strings, or as a lazy way to avoid null checking is pretty
poor programming technique, and assuming you code sensibly then your
variables will have meaningful names, and as shown above, the use of '+' vs
'&' becomes largely irrelevant.

Matius is arguing strongly that '+' should not be used to concatenate
strings, yet the only argument seems to be a single statement from a
strongly VB orientated author, and a rather dubious statement that it
clarifies what you are doing with appallingly named variables :)

I'm never stated that '&' is the spawn of the devil, I simply inferred that
it is better programming practise to use '+' to enforce explicit casting of
numbers to strings.

Cheers,
Gadget

And when Microsoft says something is included "for historical
reasons", to me it's like saying "Say Hasta La Vista to
this feature in the next version, baby."

Robin S.
-------------------------------------

"Gadget" <ga****@sobell.netwrote in message
news:4e*****************************@40tude.net...

>On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>>>>Also as a rule of thumb, avoid using '&' to concatenate strings, as it
has
a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.
It's only in there for VB6 style compatibility,

No it certainly isn't.
Mattias

I'm still fascinated to hear your reasoning, Mattias. Don't let this
thread
die... :)

Cheers,
Gadget

[RobinS]

Um, nobody uses Hungarian notation on their variables
any more.

At any rate, I'm not going to argue with you, we can
agree to disagree.

And by the way, Francesco Balena is not a strongly VB-oriented
author. His Standards & Practices book provides information on both
VB and C#. He has book on the languages out for both VB and C#.
And he programs primarily in C#.

Robin S.
---------------------------------------
"Gadget" <ga****@sobell.netwrote in message
news:1v*****************************@40tude.net...

On Mon, 20 Nov 2006 10:51:15 -0800, RobinS wrote:

>Let me step in and support Mattias here.

According to Francesco Balena: "The + operator is supported
as a string concatenation operator only for historical
reasons. Using the & operator to concatenate strings
instead of the + operator makes your code more readable
and less ambiguous."

I guess it's historical in that it's always been the standard in every
languages except VB. It's a bit like saying '+' is only used as a string
concatenator in a fraction of languages; fractions like 50/3 and 17/2 :D

>I completely agree. When I see this:

myData = firstData + secondData

If I don't know if those are strings or numerics,
I won't know if it's concatenating or adding.

Quite rightly too! MS also recommend using meaningful variable names. Can
you tell me what types those two variables types are?
For example, is
myData = strFirstName & " " & strLastName
any more readable than
myData = strFirstName + " " + strLastName
?
It's the ease with which it encourages lazy programming that puts me off
the '&' concatenator. How many times have you seen 'bodged' code using '&'
to avoid null errors instead of checking for null properly? I've
frequently
seen code such as strX = DB["Name"] & "" because the coder didn't want to
bother checking if the Name was null? Is this really good coding practise,
and to follow up your example, is it 'readable and unambiguous'?

Overall, using '&' vs '+' to document when you are want your variables to
be treated as strings, or as a lazy way to avoid null checking is pretty
poor programming technique, and assuming you code sensibly then your
variables will have meaningful names, and as shown above, the use of '+'
vs
'&' becomes largely irrelevant.

Matius is arguing strongly that '+' should not be used to concatenate
strings, yet the only argument seems to be a single statement from a
strongly VB orientated author, and a rather dubious statement that it
clarifies what you are doing with appallingly named variables :)

I'm never stated that '&' is the spawn of the devil, I simply inferred
that
it is better programming practise to use '+' to enforce explicit casting
of
numbers to strings.

Cheers,
Gadget

>And when Microsoft says something is included "for historical
reasons", to me it's like saying "Say Hasta La Vista to
this feature in the next version, baby."

Robin S.
-------------------------------------

"Gadget" <ga****@sobell.netwrote in message
news:4e*****************************@40tude.net.. .

>>On Sat, 18 Nov 2006 00:07:40 +0100, Mattias Sjögren wrote:

>Also as a rule of thumb, avoid using '&' to concatenate strings, as it
>has
>a tendency to hide casting errors.

Huh? Can you give an example of that? And what do you suggest we use
instead? Hopefully not the + operator.
>It's only in there for VB6 style compatibility,

No it certainly isn't.
Mattias

I'm still fascinated to hear your reasoning, Mattias. Don't let this
thread
die... :)

Cheers,
Gadget