- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Gah. Wrong. This stuff isn't that hard, people, which is why I can't fathom how so many of you can be so very wrong about it.
StringBuffer (and now StringBuilder) is the only sane way to do string concatenation in Java. So the question isn't "should you use StringBuilder" -- the answer to that is always "yes", because you are going to whether you like it or not. The question is "should you use an explicit StringBuilder as opposed to letting the compiler make one for you", and the answer to that is simple and obvious: only if it makes sense to reuse it.
In other words, String foo = ""; for (int i = 0; i < 100000; i++) foo += "foo"; is stupid, because you are letting the compiler create 100,000 different StringBuilders for you. It makes a lot more sense to create one and append to it a hundred thousand times. For big strings with tons of concatenations, the performance difference is astronomical. But again, it's not "using StringBuilder" versus "not using StringBuilder", it's "using one StringBuilder" versus "letting the compiler create a hundred thousand of them for you".
For the WTF function, it makes no practical difference whether he creates his own StringBuilder or lets the compiler do it for him, because there's only one concatenation sequence and therefore no value to manually creating the StringBuilder. That, of course, does not make this the right way to do things -- much better to manually create the StringBuilder outside of this function, so it can be used for the whole concatenation and not just this tiny piece of it. And obviously there is other stupidity here as well.
Admin
It does not "vitally need" them, but try writing a parser that can read everything that Excel writes when "save as CSV". Be sure to test
Compare this with a format where a backslash escapes the next char. You only have to remember the last character in the parser, while in the CSV-parser you have to remember multiple modes.
The CSV parser is a lot more complicated and this is why 99% of all CSV parsers([Citation needed]) cannot parse CSV files.
And it explains why todays WTF is a WTF:
CAPTCHA: illum (partially illuminated now?)
Admin
I was merely responding to the recurrent abuse VB gets for not supporting such an escape character. With the specific exceptions I noted previously, it simply has no use for one.
(The other part of the response, that I left out because it has been said before, is that VB doubles the string delimiter instead of backslashing it because of precedent from preceding BASICs, and some other languages of that time.)
Admin
This argument about string substition is far older than B,VB,(.NET), C or Pascal. It was the "One True Style" question of Fortran and machine code. It is the 50s/60s equivilant to the question "Should temp variables be declared inline?"
Admin
So combining the arguments of both you and VB Programmer:
it would be nice to have them; not having them leads to hackiness whenever string literals aren't well-behaved; the only reason VB doesn't have them is historical; the only thing to be said in favour of their absence is that VB wasn't designed with succinctness in mind.
Apparently it doesn't enable anything that can't be done in the same way in C except with even less syntax (i.e., one escape character for all purposes instead of different escape characters for escaping different characters, and char[] z = "foo" vbcrlf "bar"; would be legitimate if you did something like #define vbcrlf "\r\n" beforehand - note the lack of an '&' operator).
Thank you for your responses and stirring case for the defence. I'd drifted away from BASIC decades ago, and wondered if it would be worth brushing up on what it had become - most of my acquaintance with it came from decompiling CLR as both VB.NET and C# and comparing. So some time back I asked if there were any reasons why I ought to learn VB.NET, but nobody replied.
Admin
I've seen that idiom more than once before today.
Admin
Or they've just never used StringBuilder. I'm not sure which is more scary.
Although, afaik, string concatenation is better than StringBuilder for trivial amounts of concatenation. If it's less than 10, I tend to stick with concatenation, unless you're doing it in a loop, then StringBuilder is the way to go.
String.Format() uses a StringBuilder internally, iirc.
Admin
I'm tempted to say the guy who wrote this was Hispanic and confused "comillas" (quotes) with "comas" (commas).
Admin
The main complication VB strings run into is line-terminator characters. All other (non-delimiting) characters can be entered directly. If not for the unfortunate risks involved in making such a change, my personal recommendation would be to allow strings to include line-terminator characters.
The specification is otherwise quite clear, that strings are delimited by double-quote characters, and the only gains (syntactically) by disallowing the others are avoiding the "weirdness" of strings visually continuing on the next line, and avoiding the coincident "breaking" of indentation. (There is the potential added complexity to the parser, but I'm fairly sure VB already requires a context-sensitive grammar.)
(Now that I think about it, there may be precedent for this. Anyone remember for sure whether Commodore or Apple BASIC allowed line-end characters embedded in strings?)
I find it reasonable to say that succinctness wasn't a design goal (just consider how "wordy" VB is, compared to several other languages); but more importantly, its BASIC parentage (emphasizing simplicity, for "beginners" sake) likely had little need for embedding line-ends in strings. Most of the commonly-used output statements (PRINT, etc.) appended a line-end anyway, so most BASIC programs just output one line at a time instead of trying to build up one string with all the lines in it.
Admin
Check out the semantic of the +-operator for strings and you will see, that it results in an extra copy of the whole string. I think you do now understand the point.
Admin
thanks for info
Addendum 2024-08-19 01:55: As a busy college and university student, I often find it difficult to keep up with all of my writing assignments. That’s why I was so relieved when I found 99papers.com. This website cheap custom essay papers offers professional writing services that are perfect for students like me who need a little extra help. The writers are experienced in a wide range of subjects, so no matter what topic you need help with, they’ve got you covered. I’ve used 99papers for several of my essays and research papers, and I’ve been extremely satisfied with the results every time. If you’re looking for a reliable writing service.