Re: Increasing efficiency in C

From: Nick Landsberg (hukolau_at_NOSPAM.att.net)
Date: 03/05/04 

Date: Thu, 04 Mar 2004 23:42:38 GMT

jacob navia wrote:

[ much snippage ]

>
>>>The objective of this discussion is to see why the *language* doesn't
>>>support any other schema for implementing strings.
>>
>>No other scheme proved to by better in a GENERAL PURPOSE context.
>>As you admit yourself, the alternate libraries are designed for well
>>defined goals, rather than as universal replacements for the C strings.
>>
>
>
> Safety was one of the more widespread goals. I am trying to
> build checked strings into lcc-win32. I think that a more
> debuggable environment is easier to work with.
>
>
>>And the very existence of these libraries proves that the C language DOES
>>support alternate schemes. So, your point is moot.
>>
>
>
> The language doesn't support it.

At the risk of being in over my depth, the language
supports any string representation you may dream up.
The "standard libraries" support one particular
reprsentation. This implementation was, I guess,
chosen by the standards committee in order to
be backwards compatible with the large number
of C-programs which were in existence prior to 89.

One is free to re-create all of the standard routines using
a different convention for representing strings
(e.g. char-count in s[0], some "magic cookie" means
to flash the character on an IE browser, etc., etc.)
and put this into an implementation-specific library
using different names than the standard specifies for
the "standard" library functions. That is currently
supported by the language, is it not?

[ more snipped ]

>
> My whole point is that data structure development should
> be opened up to the C user that should be able to
> specify data types that follow special rules he/she defines.

It's already there. However, by convention, almost all people
use the routines in the standard. As Dan has said, there
have been attempts to do this in the past, but not
accepted by the vast majority of C programmers,
nor ported from one implementation to the next.

[ much snipped ]

>>
>
>
> That is the start. A better string library would be an achievement.
>
> Nothing spectacular, and very simple.
>
>

But would it be backward compatible with tons of
code already out there? This may be an
intractible problem. 

-- 
Ñ
"It is impossible to make anything foolproof because fools are so 
ingenious" - A. Bloch

Relevant Pages

  • Re: So what Standard are we working off?
    ... But C99 basically addresses none of these problems over C89. ... do support this with direct, ... libraries implementable completely in standard C, ... standard library as well. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)
  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)