jacob said:
(e-mail address removed) a écrit :
I would like that such a group existed but... I have never found one.
Well, there is also no group for discussing the *practice* of C
programming, the implementation of C compilers/libraries, common C
compilers and their extensions, algorithms in C or C variants either.
It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:
"C++ is the future, we are just waiting that C programmers die out."
Yes, but there is an inherent contradiction in this. C++ people also
refuse to extend the C-like subset of their language. They do this,
precisely because they incorrectly assume that the C standards
committee will be responsible and improve their standard over time in
all the relevant ways they might need or desire. (I may overstate
this, as the C++ people are very much aware of what a debacle the C99
standard was; at least from their point of view.)
So there is a big opportunity for other languages to step in an simply
deliver greater functionality than both C and C++.
A classic example of this is how Python uses GMP to support long
integers in its language. The key portions of GMP are written in
assembly language that is not generatable by any C compiler and thus
cannot be approached in performance any better than 25%. So while
Python is generally a *much* slower language than C, on the one aspect
of long integer computation portable and standard compliant Python will
embarrass any comparable standard C code in terms of performance that
tries to do that same computation.
The obvious question, then, is why can't C programmer just use GMP?
Well they can, so long as they are not bothered by including lots of
handcrafted assembly in their projects. But there are also issues with
using GMP -- GMP is not thread safe, and does not include some
classical cryptographic functions such as Barret-reduction or
Montgomery-reduction. So there are alternatives, like LibTom and
others with various other kinds of trade offs, but all them achieving
speed through assembly language. I doubt that all of them have been
ported to AMD64, which is clearly going to be the dominant platform
going forward.
Python gets away with using GMP, because its multithreading
implementation is standardized, and is coroutine based (they call them
generators) and is *emulated* rather than relying on system features to
do this. (Python also does not have special support for crypto in its
operators.) So the use of GMP is merely an implementation detail
rather than being an exposed part of their standard.
The sad thing, of course, is that C needs to add one single polymorphic
function or operator (a widening multiply) to the specification to put
an end to all of this. I will make a prediction right now, that such
an operator or function with *NEVER* be added to the C standard. The
standards purveyors simply aren't at the level required, nor are they
focussed enough to realize why this and similar issues are so
important.
This precludes of course any attitude that would discuss the evolution
of the language
Well it ends up promoting really *BAD* evolution, actually. Take TR
24731 for example. This is an extension to C that is supposedly
supposed to make C safer for string manipulation and is likely to
appear in the next standard. It does no such thing, of course (every
failure mode in standard C is direcly mappable to a failure mode using
TR 24731) -- but the standards people, somehow *BELIEVES* that it does.
It seemed promising in the sense that they at least tried something --
but one cannot help but think this is nothing more than a reactionary
move against those decrying against C as a ridiculously unsafe
language. The guilt of knowing that the C standards committee members
are, in essence, coauthors of nearly every single virus and exploit is
probably what caused them to endorse this nonsense. Of course they are
just being tools of a PR maneuver by TR 24731's authors. Most people
in this newsgroup, or anywhere else, probably have no idea what TR
24731 is. That's because there is so little open discussion about the
evolution of C.
One thing we have to ask ourselves -- is it possible to extend C in a
way that general C programmers would have to say to themselves: "I
*need* the new standard, because it will make me a better programmer"?
Look at the C99 standard and as yourself whether it rose to this level.
It clearly did not, and the next standard won't rise to this level
either.
The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve. Or at least it
will not evolve from a process of open discussion. So people like
Microsoft have no trouble subverting the C standard for their own
purposes, and while system vendors just watch out for their own
self-interest.
Just compare how the proposed changes to the C standard (from C89, or
the new stuff from C99) to the proposals for the next C++ standard.
The next C++ standard is *clearly* going to be a much better language
than its predecessor -- the inclusion of "auto" is a brilliant maneuver
that really puts the question to the dynamic languages that have become
popular lately. I don't know if things are more open in the C++
universe, but clearly they have more activity amongst the creators of
Boost and STL; or maybe Stroustrup is just a brilliant guy. Whatever;
it really underscores how pathetic the C standard is.