Well I'm writing a module that does a few trivial manipulations on file
names. So I'll include your string library.
Oliver, my colleague, is outputting files in PDB format, and also wants a
few string manipulations. So he uses Fred's super string library.
Suddenly we've got all these string libraries sloshing about our code,
making it hard to read, and making it hard to call one module from another.
That's the problem with dependencies.
I don't understand your argument. With std. C-strings at least
allocation, deallocation[1], copying[2], concatenation[3], parsing[4] and
IO formatting[5] are all prone to being done in a variety of ways. Calling
conventions on who owns what when are totally up in the air (and if you
need to "share" a string between multiple places it's often so
complicated it's easier to just strdup() and assume it's not going to
change).
Using any decent string API has to unify the first 4 problems, and likely
at least helps with the others.
In fact, in my experience, to counter those and the general
security/usability problems of C-strings the better programmers tend to
implement some form of string API within their application. So the real
argument is "dep. on an external and well tested API" vs. "dep. on an
internal API".
I would be very surprised if lack of integration was a real problem for
using any of the worthwhile string libraries.
Also there just aren't that many worthwhile string libraries out there
(and there are even fewer designs behind them), so even if you did use
more than 1 it'd be very hard to get above 2 without their being major
overlap.
[1] Do you malloc(), or use fixed size buffers. To you grow the buffer, or
work out the length and allocate once. Where do you keep the meta data etc.
[2] strcpy(), strncpy(), memcpy(), memmove(), sprintf(), etc.
[3] Dito [2].
[4] Do you destroy the string via. strtok(), do you use sscanf(), do you
strspn/strcspn and memcpy the sub-strings out somewhere else.
[5] Do you split your IO to just have a pointer and length,
doing any formatting via. snprintf() (non-std. call) somewhere
else ... or use something that looks like fprintf() so you can easily
concatenate multiple strings into the output without having to do even
more allocations.