simplistic misunderstanding about ; + "" in a print

[SMcNeill]

No.  The reason is just ease of translating.

It's actually a behavior difference Imagine instead of string literals you're printing the results of some functions:

Code: (Select All)

Print func1$(1); func2$(20)

Print func1$(1) + func2$(20)

Those two lines don't behave the same if func2$(20) produces an error - with the first one you'll see the result of func1$(1) on the screen, with the second you won't see anything.

The same logic applies if func2$(20) just doesn't return for an extended time (maybe it has a SLEEP or does a long computation). In the first case you'll see the partial output from func1$(1) on screen, in the other you won't see anything until func2$(20) finishes.

PRINT "abc"; "def"; "ghi"      <-- this will print in three separate statements like:
PRINT "abc";
PRINT "def";
PRINT "ghi"

Each one will test to see if they fit on the line, or if they need to word wrap, or if they need to perform a screen scroll.  (Or, as you point out, if they produce an error along the way.)

---

PRINT "abc" + "def" + "ghi"

The above will join all those fragments together to make "abcdefghi" and then only perform the word wrap once on that whole joined together line of text.  It'll only do the screen scrolling and such that one time as well.

---

If anyone was thinking that I was saying those two methods are identical, then I apologize.  They're not.   In many cases, however, one can fairly freely swap between the two styles and not see much difference -- though there are times when BOTH ways might bite you in the butt, if you're not careful.  Think about how long your possible strings are, and how they might word wrap, and then go from there.

PRINT CHR$(34); "test"; CHR$(34)   <-- as suggested by doppler, this MIGHT end up printing one of those three elements on the top line of text, and drop the others down to the next line.

PRINT CHR$(34) + "test" + CHR$(34)   <--- this would make certain that those three elements were combined.  Either all three will fit up on the top line, or else all three elements will be printed to the next line.

Now, if you're over on the left side of the line to start with, it's not going to matter as all three elements will fit on that single line to begin with.   BUT, if you're only a few characters from the right edge of the screen, the two are going to have much different word wrap actions happen with them.

They're not *exactly* the same, and it's not a case of "This is always better than that."   Always remember to use what works best in your own particular use case.  All we can really do here is just kind of draw attention to the behavior and hopefully make folks aware of what's going on so they can make informed decisions on what might work and perform best in their particular situations. 

[doppler]

Wow what an enlightenment.  What looks to be straight forward is nothing but.  Depending of where the text output is going.
It's one of those things that make me rack my brains trying to figure out "why it printed there" and "Not where I expected to go."

Thanks for delving deep, into what looked like simple print function.
Yes, I was following Steve on everything he said.  And only because I have done plenty O/S "core function" programming.
All of this is very inside information.  Sometimes it's not very pretty.

[TDarcos]

You have to remember, QB64 is a translator which turns BAS programs into C programs, and ... that's not always pretty. 

1. As it has been said, the process of turning a pig into bacon, pork chops, sausage, pig's feet, lard, etc. is not pretty. Butchering a hog usually isn't.
   
2. It has been said that if you have any respect for laws or sausage, you don't want to know the process of how either is made. Now I can probably change that to, "if you have any respect for laws, sausage, or how high-level programming languages are translated into C code, you don't want to know the process of how any of these are made."
   
3. I've seen various articles on programming languages or their compilation, and what I've heard, whether it's Free Basic's assembly language, or QB64/QB64PE's C code, "you really do not want to see what the code they generate looks like."
   

Just something to keep in mind, that most folks never consider.  It's behind the scene translation at work on your code.

Usually, for a high-level language programmer, you don't have to. It's been said that with most programming language compilers, it's not worth trying to improve your code by simplifying it, because the compiler already has improvement processes built into the compiler, like peephole optimization, loop unrolling, dead code elimination, expression simplification, etc., that there's not really that much you can do to provide a significant enough improvement to justify the time spent, and a better choice of thing to do for improvement is to see if there is a better algorithm for solving the problem your program is attempting to do than what you are using. Same for analyzing the assembly or machine code your program generates (or as in this case, C code), as most compiler writers either know the target instruction set (and operating system) very well, or they have people who do, and almost certainly better than you do.