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.

▲

mschuster91 6 hours ago | parent [-]

> 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.

▲

skydhash 5 hours ago | parent [-]

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.

▲

inejge 4 hours ago | parent | next [-]

> 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.

	▲	skydhash 4 hours ago \| parent [-]
		Full generality is not a practical target. You select your subset of the problem and you solve it. Supporting everything in a project is usually a fever dream.

▲

mschuster91 3 hours ago | parent | prev [-]

> 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.