- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
i don't understand. isn't it just another way to implement a speed-up loop?
Admin
"StringBuffer is faster if you need to append a lot" being cargo-culted into "always use StringBuffer, even if you just want to add a comma" is a nice touch.
I also presume this has a connection pool leak.
Admin
And we can't use something like sprintf() because it's old and stinky and it came from C, which is the worst kind of evil according to the Rust cult.
Admin
""StringBuffer is faster if you need to append a lot" - and even that is not nexcessarily true. Optimizations have been in place for many versions of the language to automatically use a StringBuilder" (not Buffer) under the covers when the tipping point is reached.
Admin
I think it's missing a StringBuffer, but every time I count its different. Clearly has quantum effects.
Admin
Weird... That looks like C# (OdbcCommand, ExecuteNonQuery, PascalCase methods and properties), but uses StringBuffer with a camelCase append method, which looks more like Java (C# has StringBuilder, not StringBuffer)
Admin
Perhaps the ODBC library for Java was coded using PascalCase inline with M$ preferred style? Or this is some kind of Java-.NET bridge situation where they're calling the .NET ODBC library from Java?
If neither of the above is true, then the only remaining possibility is that it's a made-up submission.
Admin
".append(bol.Bottles)" <-- I feel like opening a bottle right about now.
Admin
On the plus side, I'm sure the code-generating code is nice and compact!
Admin
Maybe they cargo-culted
StringBufferfrom Java over to C#? Which would be all sorts of deeply worrying.Admin
lmfao collecting paychecks
Admin
The way that they're using StringBuffer prevents any performance gain. StringBuffer is only faster if you repeatedly append to the same StringBuffer. If you repeatedly construct new StringBuffer objects, convert to string, then convert back to a new StringBuffer object, that will be slower than just appending to a string using the + operator.
Also, the compiler will convert + to StringBuffer operations, so none of this clever code was needed: https://stackoverflow.com/questions/1532461/stringbuilder-vs-string-concatenation-in-tostring-in-java
Admin
They are obviously using the wonders of class inheritance to make the new class so the Java code they found on StockOverflow can work in C#.
public class StringBuffer: Text.StringBuilder { }Admin
What's odd to me is it doesn't look like Visual Basic 3 which is the last time I ever saw ODBC being used.
Admin
This is Absolutely The Right Way to create inserts with provided data. There is Absolutely Nothing Wrong here. No chance of an SQL injection, each parameter is handled separately!
Admin
We have sprintf but cooler, now with 100% less buffer overflows: https://doc.rust-lang.org/std/macro.format.html
don't malign the Rust cult unless you actually know Rust :p
(on that note, given that the code is written in C#, I imagine you were referring to https://docs.microsoft.com/en-us/dotnet/api/system.string.format?view=net-5.0 which is closer to Rust's format! than to C's sprintf anyway)