Comment by sph
4 days ago
That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here.
And what is wrong with writing your own util library that fits your use case anyway? In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency. No one sane will add a third-party git submodule, wire it to the main Makefile, just to left-pad a string.
> That is true, but the hand-rolled StringUtil won't steal your credentials and infect your machine, which is the problem here.
Yeah, that's why I said that this is the other end of the pendulum.
> In C/C++ world, if it takes less than a couple hours to write, you might as well do it yourself rather than introduce a new dependency.
Oh I'm aware of that. My point still stands - that comes at a serious maintenance cost as well, and I'd also say a safety cost because you're probably not wrapping your homebrew StringUtils with a bunch of sanity checks and asserts, meaning there will be an opportunity for someone looking for a cheap source of exploits.
Wait what? That’s just fearmongering, how hard is it to add a few methods that split a string or pad it? It’s not rocket science.
> how hard is it to add a few methods that split a string or pad it?
In full generality, pretty hard. If you're just dealing with ASCII or Latin-1, no problem. Then add basic Unicode. Then combining characters. Then emojis. It won't be trivial anymore.
1 reply →
This kind of thing is precisely the stuff that needs to be in stdlib.
C++ is hardly a good example to follow here, but then again it does have Boost which is the de facto "extended standard library" in practice, and gets treated differently from other dependencies by many.
> how hard is it to add a few methods that split a string or pad it?
Well, if you're in C/C++, you always risk dealing with null pointers, buffer overruns, or you end up with use-after-free issues. Particularly everything working with strings is nasty and error-prone if one does not take care of proper testing - which many "homegrown" libraries don't.
And that's before taking the subtleties of character set encodings between platforms into account. Or locale. Or any other of the myriad ways that C/C++ and even Java offer you to shoot yourself in the foot with a shotgun.
And no, hoping for the best and saying "my users won't ever use Unicode" or similar falls apart on the first person copying something from Outlook into a multi-line paste box. Or someone typing in their non-Latin name. Oh, and right-to-left languages, don't forget about these. What does "pad from left" even mean there? Is the intent of the user still "at the beginning of the string itself?" Or does the user rather want "pad at the beginning of the word/sentence", which in turn means padding at the end of the string?
There's so much stuff that can go horribly horribly wrong when dealing with strings, and I've seen more than my fair share just reading e-mail templates from supposed "enterprise" software.