Language standard: the least common denominator vs. utility

[websnarf]

So why don't you join the GNU gcc team and get it in shape?

Because I don't want or need the vast majority of C99 features? I have
my own solution to the stdint.h problem, and the gcc people have
already dealt with that in their compiler. Helping someone to
implement C99 would be serving *someone else's* adgenda, not mine.

[...] The
source is available, as is glibc. Once you have done that the
other compiler vendors will probably fall in line.

I rather doubt that. With no user demand at all, the fact the gcc
happens to support it would not suddenly create this demand. (For
example, gcc supports locally scoped functions, but nobody uses them.)

 

[CBFalconer]

.... snip ...

I rather doubt that. With no user demand at all, the fact the gcc
happens to support it would not suddenly create this demand. (For
example, gcc supports locally scoped functions, but nobody uses them.)

GPC does. Probably Ada too. There goes your 'nobody' claim.

 

[James Antill]

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.