S
santosh
Chris said:
No. This can be done any language like Java or Python, though presumably
the final implementation might be in C.
No. This can be done any language like Java or Python, though presumably
the final implementation might be in C.
C
Chris Thomasson
santosh said:
How do you create a GC in a language that requires a GC?
J
jfbode
The criticisms presented in that article are, for the most part,
valid. The only ones I'll quibble with are the lack of object-
oriented programming support; that's to be expected in a language that
wasn't designed to be object-oriented.
As others have pointed out, many of the weaknesses pointed out in the
article were results of deliberate design decisions. At the time, it
was more important that the language be small, fast, and easily ported
to other platforms rather than be fully featured.
All that means is that C is better suited to some tasks than others.
For example, text processing in C is a royal pain in the ass; C
doesn't define a native string type, for one thing, and the string
processing routines are rudimentary at best.
J
James Kuyper
Those characteristics continue to be important in many contexts, and it
is precisely in those contexts that C continues to flourish.
S
Szabolcs Nagy
[email protected] said:
not a good example
the fact that the standard does not contain certain functionality does
not mean one can not implement them simply and efficiently
for high level tasks obviously you'll need libraries, where you can
hide the complexity behind a well designed api (and you can do it in c
pretty well)
actually many string processing applications and libraries are written
in c
(eg applications: sed, awk, grep, perl; libraries: bstring, tre, ..)
C
Charlton Wilbur
PH> In other words I just want to make the language to be a whole
PH> hell of a lot better at doing what it already does today, and
PH> start making it less suck at what it sucks at today. Most of
PH> what I want can be solved with a better library alone.
PH> But people are just satisfied with C for some reason. In the
PH> years of posting here I have barely had any support for my
PH> point of view. It kind of disturbs me that nobody cares about
PH> any of these issues. So its not like any of this would ever
PH> make it into a proposal which would be considered by the ANSI
PH> C committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
I understand that you want a better language; why does it matter to
you that this better language is called C? What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else? There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.
The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts. C is good enough in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known. If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
In other words: people do care about the issues you care about, but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.
So why can't you and Jacob design your new perfect languages and call
them something other than C?
Charlton
PH> hell of a lot better at doing what it already does today, and
PH> start making it less suck at what it sucks at today. Most of
PH> what I want can be solved with a better library alone.
PH> But people are just satisfied with C for some reason. In the
PH> years of posting here I have barely had any support for my
PH> point of view. It kind of disturbs me that nobody cares about
PH> any of these issues. So its not like any of this would ever
PH> make it into a proposal which would be considered by the ANSI
PH> C committee.
The ANSI C committee has to consider millions of lines of existing
code, and backwards compatibility. It also has to contend with the
overwhelming yawn that came from the compiler-writing community in
response to C99.
I understand that you want a better language; why does it matter to
you that this better language is called C? What is it about the name
C and the ANSI imprimatur that is so valuable, that means you can't
create your own new language, with all the problems fixed, and call it
something else? There's precedent for this, you know: C++ and
Objective-C trod the same ground decades ago. Java started out as a
redesigned C++; Ruby started out as a redesigned Perl.
The reactions to your and Jacob's improvements to C has a very simple
explanation: they require tradeoffs that just don't make sense in a
lot of contexts. C is good enough in a lot of ways; more importantly,
the places where it's not good and the edge cases where it gets
pathological are well known. If you make major sweeping changes to
the language itself, suddenly that's not the case, and the only thing
New C has in common with Old C is the name.
In other words: people do care about the issues you care about, but
we're just addressing them by using other languages when the other
language is a better choice, not by altering C to suit.
So why can't you and Jacob design your new perfect languages and call
them something other than C?
Charlton
C
Charlton Wilbur
CT> How do you create a GC in a language that requires a GC?
The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.
Charlton
The same way you produce a compiler for a new language that requires a
compiler: you bootstrap it from lower levels.
Charlton
J
jacob navia
Charlton said:
I understand that you want a bad language. Why you want to call it C?
You say that any improvements to C should be in the official improvement
language for C: C++ isn't it?
All the time that anyone proposes an improvement the same lame
argument from the same people:
Why you want to improve something bad by design?
Just leave it like that. gets() is OK, needs no improvement.
Why it is so that if you want a bad language you create your own and
allow other people to improve C?
You can innovate. Call your language C--.
This has never been said before. I do not see what tradeoffs
you are talking about. The introduction of improved libraries
like a malloc where you can query the size of an object as proposed
by Paul would make sense and take no overhead.
for YOU
Yes. And please do not improve them. Just make your new
language C-- and leave us in peace ok?
Nobody is talking about your "sweeping changes", just you.
C must retain all its badly designed choices because you say so.
And people that propose improvements (that you do not even care
to say that are wrong!) are juust making a new language of course.
There is nothing worst than a new language that simplifies an old
one and makes it better. Yes.
I do not speak for Mr Hsieh but why should I?
C
Charlton Wilbur
JN> I understand that you want a bad language. Why you want to
JN> call it C? You say that any improvements to C should be in
JN> the official improvement language for C: C++ isn't it?
Because the language already exists, and has been called C for the
past three decades.
JN> All the time that anyone proposes an improvement the same lame
JN> argument from the same people:
JN> Why you want to improve something bad by design?
JN> Just leave it like that. gets() is OK, needs no improvement.
No: the question is, what will this improvement cost us? We know why
you want to improve it, because you harangue us at length; we may even
agree with your rationale. But there are millions, possibly billions
of lines of C code out there, and hundreds of C compilers, and if you
make a change that isn't backwards compatible, *someone* has to go and
deal with those millions of lines of code and hundreds of C compilers.
JN> Why it is so that if you want a bad language you create your
JN> own and allow other people to improve C?
The language C already exists, and is reasonably well-defined.
JN> This has never been said before. I do not see what tradeoffs
JN> you are talking about. The introduction of improved libraries
JN> like a malloc where you can query the size of an object as
JN> proposed by Paul would make sense and take no overhead.
In a new compiler, sure. In all new code, sure. What happens when
someone writes code with this new feature and tries to run it on an
old compiler?
JN> C must retain all its badly designed choices because you say
JN> so. And people that propose improvements (that you do not
JN> even care to say that are wrong!) are juust making a new
JN> language of course. There is nothing worst than a new
JN> language that simplifies an old one and makes it better. Yes.
No: C must retain all its badly designed choices because there are
millions of lines of code and hundreds of compilers that implement
them. I *don't* think your improvements are wrong, in the large; I
think that adding them to C is likely to break a lot of things, and
even if it doesn't, it will require updating a lot of compilers; thus
unless the cost of the change is less than the benefit of the change
is worth, the change should not be made.
If you're playing with even 100,000 lines of code and one compiler,
the tradeoffs are different.
JN> I do not speak for Mr Hsieh but why should I?
Because you'll get a lot farther that way. Because you might get your
new language into widespread use, instead of coming across as a crank.
You still haven't answered the basic question: why is the C name and
the ANSI imprimatur so important to you?
Charlton
JN> call it C? You say that any improvements to C should be in
JN> the official improvement language for C: C++ isn't it?
Because the language already exists, and has been called C for the
past three decades.
JN> All the time that anyone proposes an improvement the same lame
JN> argument from the same people:
JN> Why you want to improve something bad by design?
JN> Just leave it like that. gets() is OK, needs no improvement.
No: the question is, what will this improvement cost us? We know why
you want to improve it, because you harangue us at length; we may even
agree with your rationale. But there are millions, possibly billions
of lines of C code out there, and hundreds of C compilers, and if you
make a change that isn't backwards compatible, *someone* has to go and
deal with those millions of lines of code and hundreds of C compilers.
JN> Why it is so that if you want a bad language you create your
JN> own and allow other people to improve C?
The language C already exists, and is reasonably well-defined.
JN> This has never been said before. I do not see what tradeoffs
JN> you are talking about. The introduction of improved libraries
JN> like a malloc where you can query the size of an object as
JN> proposed by Paul would make sense and take no overhead.
In a new compiler, sure. In all new code, sure. What happens when
someone writes code with this new feature and tries to run it on an
old compiler?
JN> C must retain all its badly designed choices because you say
JN> so. And people that propose improvements (that you do not
JN> even care to say that are wrong!) are juust making a new
JN> language of course. There is nothing worst than a new
JN> language that simplifies an old one and makes it better. Yes.
No: C must retain all its badly designed choices because there are
millions of lines of code and hundreds of compilers that implement
them. I *don't* think your improvements are wrong, in the large; I
think that adding them to C is likely to break a lot of things, and
even if it doesn't, it will require updating a lot of compilers; thus
unless the cost of the change is less than the benefit of the change
is worth, the change should not be made.
If you're playing with even 100,000 lines of code and one compiler,
the tradeoffs are different.
JN> I do not speak for Mr Hsieh but why should I?
Because you'll get a lot farther that way. Because you might get your
new language into widespread use, instead of coming across as a crank.
You still haven't answered the basic question: why is the C name and
the ANSI imprimatur so important to you?
Charlton
J
jacob navia
Charlton said:
You still haven't proved that any change that I have proposed makes
some code go wrong. As far as I know the syntax
int operator[](Array tabv,int idx);
is not used in single line in those billions of C code lines.
Since we can do
#define operator __operator
we only use an already reserved word, and a new syntax. This
can't do any harm to any existing code.
And what happens if I try to use a compiler that still doesn't accept
prototypes?
It doesn't work. Great! Let's get rid of prototypes then!
Why you would try to use new code with an old compiler?
This is a data processing field, not an association for the
religious worship of old code!
OK. You agree that it will NOT break anything. Your arguments now
reduce to the price of retooling the compilers... I mean that
is a significant shift in your argumentation.
The cost of maintaining C code is staggering because of those
problems precisely. It require from the programmer a LOT of time
and attention to do all those allocations and freeings without a single
error.
The improvements to C would make it easier to use, the user base would
grow. Yes, there are zillions of old code but the people doing C
are less and less and everybody is associating the C language
with overflow bugs...
C applications could be rewritten using the new features slowly, and
they would improve.
Or, (and that is what you and many other people want) no improvements
would be done to either the language or the applications until they
disappear. C would disappear faster than Cobol and Fortran, since
even Cobol has improved, and Fortran accepts now operator overloading
and allows a modern style of programming.
But that would be in an horizon of 10 years from now, so nobody cares.
Let's freeze C until it dies away.
I am only "a crank" in this group. My compiler system is used by many
people, I have arrived at 500 000 downloads of this system. Users
from Chine, U.S., many universities, single people, etc. And they like
it because the language is simple, modern, and the whole download is
just 5MB. It is fast, and produces small executables.
Yes, there are still people that appreciate that, and like to use
simple things.
C has a future, and I am convinced of that and I will work for that
goal. ANd if I am considered "a crank" by people in this group
I do not care at all about their opinions!
P
Paul Hsieh
Ironically, the argument you make in what follows applies equally well
to C99 itself. In other words your argument is essentially moving
*backwards* in time, referring to things for which we already have
precedent. Compare this to my position in which I have observed the
ANSI C committee approve radical changes to the language (i.e., C99)
so I know that are *willing* to change the language and I am well
aware of the compiler vendor's reluctance to make the changes.
The problem is you take all that as a conclusion, instead of asking
the simple question of *WHY* those events happen. The compiler
vendors didn't bother because the programming community doesn't care
for any of C99's features. If programmers *demanded* certain
features, then compiler writes would implement them whether they
wanted to or not. (Not surprisingly, you will find the ANSI C commit
populated mostly by representatives of compiler writers -- thus
indicating a preference for the "not" in the previous sentence.)
Now, it turns out from the number of heap debugger utilities being
sold out there, that its plainly obvious that there is programmer
demand for heap debugging assistance. (On the other hand, I have yet
to encounter even a single usage of the complex number extensions in
C99 anywhere.) One can see from the efforts of Motorola (AltiVec),
Intel (MMX/SSE) and AMD (3DNow!) that SIMD math extensions are an
important concern for some applications. And of course "mulhi" or
double-output multiplies have been implemented in most processors for
ages. And how long has multi-threading been a standard paradigm in C
programming?
Its so obvious and easy to find features where people are interested,
and language standardization is a useful value add. And the point is
that with enough of these features the changes would be *compelling*
enough, that people would *want* to move to it, which would *force*
compiler vendors to implement them.
These features would also make C a truly better language, and call to
real question people who have moved away from C (and C++) in favor of
other languages like Java or C# or Python or Ruby.
Well I wonder why the people who designed STL for C++ didn't decide to
go off and make their own language. Same for the boost people.
Look, the ANSI committee has already demonstrated that they are
willing to break backward compatibility and put really esoteric
features into the language. People will pay attention of the
committee or some compiler vendors implement language features. Some
people *have* paid attention to various efforts of mine (the pstdint.h
file, and Bstrlib, both of which are used in real shipping commercial
and open source products) but obviously I alone don't wield the same
kind of influence as the standards committee.
Well maybe I am not a language designer? Maybe I don't have a few
years to dedicate to create my own IDE and debugger? It takes more
than just a desire for correctness to create a successful language.
Mr. Navia and I have different suggestions, and I will let him speak
for himself.
My proposals tend to be limited to the library. Perhaps you can
enlighten me with examples where my proposals would lead to actually
giving something up (to be a trade off you have to gain something in
balance with giving something up)? When people try to challenge me on
this, the best I get is the typical circular reasoning: "that's not in
the standard, therefore its not portable" or some crap like that, when
clearly I am trying to suggest something to be standardized.
You can't make a sentence like that and not have sympathy for the
position that the C standard needs some changes.
You mean like C99? My proposed changes would have *LESS*
compatibility impact than C99 (except for the vast increase in
compiler warnings from deprecation notices), but have a generally
profound functionality increase impact.
And they spend time and money dealing with them.
Which is the better language choice for mulhi? Which language is
better for heap debugging do you think?
I don't speak for Jacob, but as I understand it, he has lcc-win32 or
something very similarly named. So he's already done the leg work,
because he's found the time, energy, and believes that strongly in it.
My proposals generally speak of things I have already done, but I
obviously didn't write my own language to do so.
F
Flash Gordon
jacob navia wrote, On 15/11/07 17:56:
C is not a bad language. It has problems just as every language does.
Your characterisation is incorrect. It is also typical of your
misrepresentation of other peoples opinion when they disagree with you.
Many of the people you are complaining about have been arguing for
removing gets from the language and expressed their pleasure when it was
at last declared that it would be deprecated. So you are clearly
misrepresenting the opinion of a lot of the people you are complaining
about.
Well, it has been said in in this message
http://groups.google.com/group/comp.lang.c/msg/9664b1145f96216a?dmode=source
This thread talks about the tradeoffs as well
http://groups.google.com/group/comp...trade+off"+group:comp.lang.c#357639fa174f6db5
So does this one
http://groups.google.com/group/comp...trade+off"+group:comp.lang.c#116a74953aa83f84
I will put this down to you forgetting that people have discussed the
tradeoffs in language design with you.
Apart from the systems where the information is not easily available
which people have mentioned before.
For a LOT of people otherwise it would not be used as much as it is.
<snip>
A lot of people seem to think that a lot of things you suggest, such as
operator overloading and garbage collection *are* sweeping changes.
C is not a bad language. It has problems just as every language does.
Your characterisation is incorrect. It is also typical of your
misrepresentation of other peoples opinion when they disagree with you.
Many of the people you are complaining about have been arguing for
removing gets from the language and expressed their pleasure when it was
at last declared that it would be deprecated. So you are clearly
misrepresenting the opinion of a lot of the people you are complaining
about.
Well, it has been said in in this message
http://groups.google.com/group/comp.lang.c/msg/9664b1145f96216a?dmode=source
This thread talks about the tradeoffs as well
http://groups.google.com/group/comp...trade+off"+group:comp.lang.c#357639fa174f6db5
So does this one
http://groups.google.com/group/comp...trade+off"+group:comp.lang.c#116a74953aa83f84
I will put this down to you forgetting that people have discussed the
tradeoffs in language design with you.
Apart from the systems where the information is not easily available
which people have mentioned before.
For a LOT of people otherwise it would not be used as much as it is.
<snip>
A lot of people seem to think that a lot of things you suggest, such as
operator overloading and garbage collection *are* sweeping changes.
C
Chris Thomasson
Charlton Wilbur said:
Fair enough. Humm... Can you use Java to create a brand new GC
implementation for itself, thus totally replacing the one in the VM?
C
Charlton Wilbur
PH> The problem is you take all that as a conclusion, instead of
PH> asking the simple question of *WHY* those events happen. The
PH> compiler vendors didn't bother because the programming
PH> community doesn't care for any of C99's features. If
PH> programmers *demanded* certain features, then compiler writes
PH> would implement them whether they wanted to or not.
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
PH> Well I wonder why the people who designed STL for C++ didn't
PH> decide to go off and make their own language. Same for the
PH> boost people.
Those aren't different languages, though: those are libraries. They
don't require semantic changes in the language, and they don't require
the same stringency in the standardization process.
Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
PH> My proposals tend to be limited to the library. Perhaps you
PH> can enlighten me with examples where my proposals would lead
PH> to actually giving something up (to be a trade off you have to
PH> gain something in balance with giving something up)? When
PH> people try to challenge me on this, the best I get is the
PH> typical circular reasoning: "that's not in the standard,
PH> therefore its not portable" or some crap like that, when
PH> clearly I am trying to suggest something to be standardized.
So why not just create your new improved library? POSIX is not C99;
neither is BSD sockets, or X11. Why does it need to have the ANSI
imprimatur for you to be happy?
PH> You can't make a sentence like that and not have sympathy for
PH> the position that the C standard needs some changes.
I have sympathy for the position, but I see the costs, and I don't
understand why you consider the ANSI C imprimatur so important.
Charlton
PH> asking the simple question of *WHY* those events happen. The
PH> compiler vendors didn't bother because the programming
PH> community doesn't care for any of C99's features. If
PH> programmers *demanded* certain features, then compiler writes
PH> would implement them whether they wanted to or not.
But this brings me right back to the original question. Why is it so
important that this new improved language be called C, and why is it
so important that it have ANSI/ISO's imprimatur? We've seen, in the
case of things like C99, that the imprimatur is insufficient to get
people to use the thing, and we've seen, in the case of things like
BSD sockets, that usefulness does not require official imprimatur to
proliferate.
PH> Well I wonder why the people who designed STL for C++ didn't
PH> decide to go off and make their own language. Same for the
PH> boost people.
Those aren't different languages, though: those are libraries. They
don't require semantic changes in the language, and they don't require
the same stringency in the standardization process.
Things like garbage collecting and operator overloading *do* require
semantic changes in the language.
PH> My proposals tend to be limited to the library. Perhaps you
PH> can enlighten me with examples where my proposals would lead
PH> to actually giving something up (to be a trade off you have to
PH> gain something in balance with giving something up)? When
PH> people try to challenge me on this, the best I get is the
PH> typical circular reasoning: "that's not in the standard,
PH> therefore its not portable" or some crap like that, when
PH> clearly I am trying to suggest something to be standardized.
So why not just create your new improved library? POSIX is not C99;
neither is BSD sockets, or X11. Why does it need to have the ANSI
imprimatur for you to be happy?
PH> You can't make a sentence like that and not have sympathy for
PH> the position that the C standard needs some changes.
I have sympathy for the position, but I see the costs, and I don't
understand why you consider the ANSI C imprimatur so important.
Charlton
J
jacob navia
Charlton said:
And I did not wait for people in ANSI to build lcc-win.
So What?
Garbage collection is just a library. No changes at all to the
language are required!
M
Malcolm McLean
Generally object-orientation is more trouble than its worth. But onePaul Hsieh said:
exception is streams. Serialisation is so fundamental that it should be
built in. You might want to look at my serialisation pages.
gets() is something and nothing. Yes it is an easy way to make a broken
program, but it is only one function, not a methodology.
The other problem is the dependency feature. Time after time code which
could be reusable actually pulls in three of four headers, which pull in an
entire library, often for something totally trivial, such as a Point3d type.
Another one, which you will realise if you use Lisp, is that in C there are
too many ways to express the same thing - arrays of arrays of structures
with arrays, or lists of list of lists. Lisp handles it fine by simply
having one "list" structure. In C you are constantly checking - is it a
pointer or a nested array, where is the size member ?
K
Kenneth Brody
Kenny McCormack wrote:
[...]
Good thing I'm Jewish -- we have 58th century ideas!
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
[...]
Good thing I'm Jewish -- we have 58th century ideas!
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
K
Keith Thompson
jacob said:
So why do you insist on discussing lcc-win's non-ISO extensions here in
comp.lang.c?
(And why do you continue to refer to ANSI, the American National
Standards Institute, rather to ISO, the organization that issued the C
standard? I've asked you this before.)
Garbage collection breaks legal C programs. It can even break strictly
conforming C programs. Any program that stores a pointer value in a
place or format where the garbage collector can't recognize it as a
pointer will potentially be broken by GC.
Perhaps such programs are rare, but you persist in ignoring them, even
when the issue is repeatedly pointed out to you.
If GC were to be added to the language, the standard would have to
state that certain programs whose behavior is currently well defined
becomes undefined in the presence of GC.
I'm not stating an opinion on whether GC *should* be added to standard
C, just pointing out that it cannot be done with no changes at all to
the language.
P
Paul Hsieh
Still walking backwards in this argument. Go ask the ANSI C committee
why they continue to refer to the ANSI C 1999 standard as if it were
referring to the C language!
Right, and people are using various libraries that I have created, and
so on. But what you are missing is that people are also picking up
things from the various interim release of the C standard (like 1994
when they added vsnprintf()) without *too* much controversy (some
older compilers like Turbo C don't have a vsnprintf() because it
wasn't maintained; oh well, we live with it.)
If the standard endorses good ideas, *LOTS* of people will pick them
up. One of the things you are missing with BSD sockets, is the fact
that Microsoft went and implemented them with an interface that is
very different under Windows than it is under the Unixes (I wonder how
they implemented it under MacOS9). And various embedded systems don't
even bother with any kind of sockets. So there's no "standard
sockets" that anyone can assume -- its just a platform specific idea.
The capability of sockets is good -- the current state of
fragmentation is not so good. With effort you can reasonably write
wrappers that let you write socket code that is portable -- but
there's not single centralized standard for this.
I wonder if the C Standards Committee is aware of this new fangled
thing called the "intarweb". With a standardized interface they could
hide the fact that its implemented on top of tubes, instead of a big
truck. I've heard that sockets can help with that.
What is your problem? When you do a strcmp ("Paul Hsieh", "Jacob
Navia") do you get 0 for some reason? I think there's a bug in your
brain. Please go to the following link: http://en.wikipedia.org/wiki/Straw_man
In defense of Jacob, it appears as though he wants to *add* to the
functionality of the language by adding features that are almost
entirely neutral to existing code. Compare his extensions, for
example, to hijacking the word "restrict" and making it a keyword in
C99.
So who says I have not? The problem is that my various efforts are in
pieces, not well documented, sporadically tested, very context
dependent, not portable, not peer reviewed, etc (the main exception of
this being Bstrlib which, by now, is at compiler-level quality). And
I know there are thousands of different developers who have written
substantially the same thing with different degrees of quality
(probably at least some are better).
Because I want to write C. Not Microsoft C as opposed to Gnu C as
opposed to WATCOM C, etc. I mean -- what do I care? Why do I have to
learn sockets as many different times as compilers that I end up
using?
ANSI accomplished one thing -- and they did it back in 1989. They got
all the compiler vendors to agree to a common standard. This meant
that people could write common code. It meant that people did not
duplicate effort in redesigning and reimplementing common things like
FILE IO, some math, etc. If you don't see the value of this, then
this discussion is over.
If you do, then I would point out that the *reason* that we *needed*
the first ANSI standard is that everyone's C compiler was doing their
own random thing with their own extensions that rendered them
incompatible with every other C compiler out there. I.e., the purpose
of standardization was to *decrease* the disparities between platform
and compiler implementations, so that learning the language once was
immediately translatable to other platforms.
So take for example some of the things I am proposing: 1) Heap
extensions and heap debugging APIs. These things obviously exist in
various products and compiler extensions -- no two of which are
compatible, of course. 2) "mulhi" and "SIMD" instructions -- many
modern compiler come with assembly language extensions, and that's how
they are implemented; one by one, every one of them incompatible with
the next (actually Intel is somewhat compatible with MSVC, but that's
a weird special case.) 3) Some kind of fseek/ftell on intmax_t
instead of long: every modern compiler I know implements some sort 64
bit fseek and ftell (again, each incompatible with the other), because
"64 bits ought to be enough for everyone".
People clearly want and need those things. The way it happens today
is kind of pathetic. Why do I have to learn a different way to deal
with those things as a Solaris, or a VxWorks or a QNX or even a Linux
programmer?
J
jacob navia
Keith said:
Because I have the right to do that according to the charter
of this group published when this group was created.
Your arguments are typicall. Nothing will be discussed at a technical
level. All is about polemic, "Off topic", and similar non arguments.
int main(void)
{
FILE *f = fopen("foo","w");
disk_format("c:");
fprintf(f,"not reached
\n");fclose(f);
}
The function disk_format() breaks programs that were legal before...
How bad!