Re: Boost process and C

Keith Thompson a écrit :
jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
[...]

The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all
functions must be explicitely be given the length of the
strings/buffers/etc even if it is immediately obvious that the
programmer can't know in all cases what that dammed length is nor
should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;

is too much for the C standards comitee. This structure is split then
at each function call in a data and a length, and it is up to the
programmer to figure out the length without ever making an error.


Are you suggesting that the C standard should be changed so that
strings are no longer terminated by '\0'?

Yes. If we have the length as a size_t we do not need to start scanning memory at each access to get the length of the string, what is GREATLY inefficient and has been pointed out as inefficient since decades!!!!!

There are dozens of
standard library functions that use this representation, and it's
central to the semantics of string literals.


lcc-win32 proposed replacing
strcmp --> Strcmp
strcat --> Strcat

where the arguments are the same but in THOSE kind of strings.

Similarly, the compiler when it sees:

String s = "This is a string";

would make an array of characters and prepend the length instead of adding a terminating zero.

Conceivably you could add a new string representation *in addition to*
the existing one.

Yes.

You would then be permanently stuck with two
distinct and incompatible ways of representing strings. (Breaking
nearly all existing code is not an option.)


Yes, new code would use Strcmp, old would use strcmp.

I have tried porting code that uses heavily strings in the old representation to the new one and it is relatively easy to do.

Of course, it's easy enough to implement this kind of thing in a
library using purely standard C; perhaps that's why there isn't much
enthusiasm for adding it to the language.


No. The problem is that you want to keep:

String s;
....

s[23] = 'b';

and not forcing people to use:

strindex(s,23)

strindexassign(s,23,'c');

or similar nonsense.


I have proposed (and implemented) a demonstration how could that be
done. See the string library of lcc-win32.


If you'll provide a pointer to the documentation, I might take a look
at it. (If I can't read the documentation without installing
lcc-win32, I'm not going to bother.)


Basically it implements all functions of the C library using the new Strings. The syntax is almost the same:
Strcmp --> strcmp
Strcat --> Strcat

etc

Using operator overloading operators like

if (! s) {
}

have their usual meanings.


[...]

Of course, but they willl not agree with this, obviously. They are
still in C89 and the few points that C99 brought in the sense of a
better language are just denied. Each time I remind people about them,
they tell me that "not all compilers support C99" what is true but
doesn't make things advance at all.


Speaking only for myself, I routinely quote from the C99 standard.
Yes, I and others often point out that not all compilers support C99.
We do so because it happens to be true, and programmers in the real
world need to be aware of that fact.


Maybe. I would not say that it is wrong. But the insistence for using gcc with the -pedantic etc options that is getting recommended here goes with the attitude of negating C99 in this bgroup. I remember the discussion about the FAQ we had, where I was flamed because I insisted on upgrading the FAQ to C99.

[...]

Yes, but the problem is that in the C standards comitee most people
care much more about C++ than C. There is no compiler for C today. All
are C++ compilers that can do C as an after thought. Gcc has
implemented most of the standard but still never makes it to finish it.


<OT>
gcc is a suite of compilers with a common backend. The C and C++
frontends are separate. There are also frontends for a number of
other languages, including Fortran, Objective C, and Ada.

C is certainly not an "afterthought".
</OT>

Microsoft doesn't care at all, and pursues its own standards through
the windows platform, where it can dictate whatever it wishes.

Apple has got objective C, and sticks to it.


Which suggests a possible approach. If you want to use a C-like
language, but you don't think standard C has some feature you require,
*use a different language*. Changing the C standard itself, even if
there's general agreement that your change is a good idea, will take
many years; that's just the nature of the standardization process.
Any such change will be imposed on *all* conforming implementations.
There are numerous other C-like languages that you can use *today*.
One of them happens to be the C-like language implemented by
lcc-win32; I'm fairly sure you have access to it.

Nobody is preventing you from implementing and using whatever
extensions you like. The only thing you're having a problem with is
your inability to impose those extensions on the entire world.


I am not imposing anything to anyone. I have explained with a lot of arguments why I am doing this or that. Nobody is forced to use lcc-win32 but I think that arguing and convincing people still is possible, and is still the oenly way to publish your own ideas.

Nobody is behind me, there is no FSF nor Microsoft nor any other organization trying to promote the ideas exposed here. I have just confidence that good ideas speak for themselves and that they win at the end.

jacob
.

Relevant Pages

  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
  • Re: Is C99 the final C? (some suggestions)
    ... because the ANSI standard obsoleted them, and everyone picked up the ANSI ... There are far more pressing problems in the language that one would like to ... But a string has variable length. ... > are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: Why C is really a bad programming language
    ... competent in terms of a low standard, he realized that he had to write ... his own string handlers, and he did so. ... Why on EARTH would anyone EVER use a language for applications or even ... string handlers work with EBCDIC, but hasn't told me how he would test ...
    (comp.lang.c)
  • Re: Why is it dangerous?
    ... learn that C had such weak string handling, ... Exploiting getson an auto buffer ... that omitted any standard on what could or could not be input. ... the pedants, on whose code contains more *actual* bugs. ...
    (comp.lang.c)
  • Re: Anyone object to the following change in libc?
    ... sscanfinput string. ... ISO C standard" refers to "c89", which is the version of the C ... non-sensical format specifier entirely, since any characters that ... conformance test suite for ISO C complaining about the ...
    (freebsd-current)