If we don't have any clue about what you mean by "many" then your
statement is worthless. My experience suggests that there are not "many"
C99 implementations.
Well, that only shows that your experience is similar to Richard's:
you've only worked on weird places where things aren't ported to.
So how many of those implementations will build the following C99
program and execute it correctly:
#include <stdio.h>
#include <math.h>
int main(void)
{
printf("%f\n",atan2(1,1));
}
The nearest thing I have to a C99 implementation certainly does not.
To save you some trouble I'll let you know that it does not build on Linux.
I was able to build it in Linux with GCC:
$ cat atan2test.c
#include <stdio.h>
#include <math.h>
int main(void) { printf("%f\n", atan2(1, 1)); }
$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ gcc -std=c99 atan2test.c
$ ./a.out
0.785398
$
So what did you mean by "many" above? 1% of installed C implementations,
1% of available C99 implementations or what?
It would certainly be difficult to make a research to get an accurate
percent. From what I can see, though, there *are* "many"--or at least
many enough.
The evidence presented by James for a start.
Let's review the presumed evidence:
"A quick Google Groups search gives an estimated 880 uses of "C99
implementation" across all newsgroups. Among the first 100 hits, the
only ones that I could find using that term to refer to an
implementation which falls short of being fully conforming are by you
and jacob navia. A large fraction of those hits involve arguments
about that very issue, in this newsgroup."
We have established that the first sentence, despite the
misunderstanding about the quotation marks, is right. The second
sentence proves that he isn't able to find stuff since, among those
very first 100 hits, there *are* people other than me and Jacob Navia
who have used the mentioned term to refer to an implementation which
falls short of being fully conforming. Here is the counter-example:
http://groups.google.com/group/comp.lang.c/msg/3d764bc633d9b1db?
(Someone named E. Robert Tisdale starts a thread about transitioning
to C99, saying that at his workplace they have very good C99
compilers. Then someone named Mac responds to him asking whether he's
sure that those implementations he's referring to are actually C99
comforming. E. Robert Tisdale responds to this by saying: "I don't
even know of *any* implementation that actually claims C 89/90
compliance (conformance) let alone C 99 compliance.")
In that case all of the evidence for all current scientific theories is
completely irrelevant because the decent scientist who obtain it know it
does not actually prove anything just suggests that the theories are
correct.
The evidences for those theories you're referring to are probably more
believable and accurate than the presumed evidences you've claimed to
have. But I don't know what theories you're talking about, so that
hardly relates to this case.
Quote from the gcc info pages, "gnu89 GNU dialect of ISO C90..."
Quote from the gcc info pages, "c99... ISO C99. Note that this standard
is not yet fully supported...", so they explicitly state it is not full
support.
Yes, we've already agreed on that.
Quote from the gcc info pages, "gnu99... GNU dialect of ISO C99. When
C99 is fully implemented in GCC, this will become the default."
There you are, quotes supporting what gnu89 is, what gnu99 is, and the
reason that gnu99 is not the default.
Yes, well, like I said, I take my words back if they actually say
that.
They also say that various bits of it are broken as you well know, and
how can something be considered not-broken if part of it is broken?
If a tower has a broken brick, is that tower broken?
Then there is the simple program above which is C99 and fails to build
under gcc on Linux. How can it not be broken if a simple C99 fails to build?
Why did it fail for you? I already showed that it built fine on my
machine.
[...] You said
"Given that most people starting to write new apps don't actually have
a C99 implementation,"
Which is, let's admit it, gibberish.
No, it's simply true.
False.
Hmm. Microsoft Visual Studio is probably the most used C compiler on
Windows and it does not even *attempt* to come close to C99.
But it isn't the only C compiler on Windows.
No, just the most common by a very long way. So it is almost certainly
the compiler most commonly used when developing new C application on
Windows. So it not conforming to C99 is very strong evidence that you
are wrong.
First you say "No [it isn't the only C compiler on Windows], just the
most common by a very long way." And then you say that I'm wrong. Your
above paragraph contradicts itself.
I'll be clearer as you could not understand what I wrote. MS VCC is by
far the most used Windows C compiler, so whether it is the *only*
compiler is irrelevant to what most new C development is done in. MS VCC
has NO support for C99. Therefore most new C development on Windows is
NOT done in C99. This is a strong piece of evidence (but not the only
evidence) that most new C development is not done in C99.
You forgot the words "in Windows" in that last sentence.
No, I didn't. A piece of evidence on the state of one part of a field is
evidence of the state of all of the field. The more areas of the field
you have evidence from the more confident you can be about the state of
the entire field.
No, because most C new development in Windows doesn't constitute most
new C development in general.
It is a large area of the field. Another large area is embedded
development. So that is two large areas where C99 is definitely by far
in the minority.
In the first, perhaps, As for the second, it's hard to see how
embedded systems is a large area of the field, though I'll take your
word and others' for it.
It is a large sample. Add to that another large area, namely GNU, where
the GNU coding standards state:
"1989 Standard C is widespread enough now that it is ok to use its
features in new programs."
"1999 Standard C is not widespread yet, so please do not require its
features in programs."
I presume that only applies to GNU's own development, not to user
development under GNU tools.
Then there is embedded SW development.
We were talking about what C development is actually done in. The
availability of compilers which are not much used does not affect this.
It does affect it, since the availability of other compilers means
that some work, though not the majority of work, is done in those
other compilers.
You are using the presence of C99 compilers for Windows as evidence that
most development is done in C99.
No. We already established that, because of MSVC being the most widely
used compiler on Windows, and because of it not supporting C99, most C
development _under Windows_ was probably not done in C99. What most C
development _in general_ is done in is another matter.
As you have admitted that most Windows
development is done in a compiler that does NOT support C99 that part of
your refutation is clearly wrong. Other parts have been addressed
else-where in this thread.
My refutation to Richard's claim that most people don't have a C99
implementation has little to do with most Windows development being
done in a compiler that doesn't support C99, since that doesn't mean
they don't actually have one.
Your failure to understand the term is relevant because it has presented
you from recognising that some has been presented.
Let's--again--quote the dictionary:
"that which tends to prove or disprove something; ground for belief;
proof."
According to the dictionary, you haven't presented any evidence.
If the handle of a mug is broken then the mug is broken.
If a tower has a broken brick, is that tower broken? If the sea has a
broken oxygen atom, is the sea broken?
The status page
states parts of gcc are broken with respect to C99 so gcc is broken with
respect to C99. You have seen the page which states that parts are
broken, and it even uses that specific word.
The accurateness of the rest of that paragraph depends on which of our
analogies concerning the word "broken" is most accurate.
So says the person who knows what C implementations are used on the
bases of a massive sample of three?
Anyway, it is rather hard to escape knowledge of K&R as a C programmer.
Do a google search for "C Programming Language" without the quotes and
you hit it.
I've heard it's a good book, but it describes a past standard.
Some compilers come with a copy of the 2nd edition.
Ask in most places for recommendations of books and someone is likely to
point in that direction.
Ask any old-time C programmer (and new programmers do ask old-time
programmers) and the chances are you will be pointed in that direction.
Eye-witness evidence, I've met far more people who have heard of
Kernighan and Ritchie than have heard of the C standard.
Not very useful evidence, since someone that programs in a language
without even being aware of the existence of a standard for that
language isn't much of a programmer anyway.
I don't see a correlation because most of the good developers I have
come across outside this group had not heard of C99.
I don't see how a developer can be a good developer without being
aware of the current standard for the language he/she's programming in
(unless, of course, he/she is not a C developer)
Experience suggests that more people have heard of K&R than have heard
of C99.
Correction: /Your/ experience suggests that.
Where did I say that K&R was the *only* book they know?
Sorry for getting that wrong. I just assumed that, since they don't
know about the standard for the language they're programming in, they
had only limited knowledge about C.
Well, let me count the pieces of kit in this house with embedded SW...
Well, I can think of 20 pieces of kit in this house that definitely have
embedded SW, a lot of those pieces of kit (for example this PC) have
more than one processor and more than one piece of embedded SW (graphics
card has a processor and embedded SW, so does the sound card, the HW,
the DVD drive...).
Still, I think the Linux machine from where you posted this has a lot
of more C work in it.
It covers a wider range than your experience (I used more than three
different C implementations there) so is more relevant than your
experience. Remember that you have used your experience in argument with
Richard.
First, the experience of someone as a C programmer has nothing to do
with the number of implementations one has used. Second, it has
nothing to do with what most C development takes place on.
I've yet to find one that cannot be made to fully conform.
That's what I said: a C90 + extensions compiler (e.g., GCC) will
probably support C90 anyway.
I've yet to
find one that with all extensions enabled is not closer to fully
conforming the gcc ever comes to conforming to C99.
Then you haven't done much finding work yet.
So you claim that something vaguely close to conforming to C99 is a C99
implementation but something very close to conforming to C90 (which with
a simple switch becomes fully conforming) is not a C90 implementation?
No, I didn't claim that. Your claim was that by your presumed
definition of mine for a Cxx compiler is that C90 is used, which is
not only wrong but also unrelated to whether a C90 + extensions
compiler is a C90 compiler or not.
If gcc in *any* mode counts as being a C99 implementation by your rules,
then all implementations in their C90+extensions modes are C90
implementations.
If C90+extensions compilers don't count as C90 implementations (unless
full C90 conformance is enabled) then gcc can't be a C99 implementation
as it is even further away from conformance. Also remember that a lot of
extensions don't affect conformance.
Well, like I said, most C90 + extensions compilers will probably
support C90 anyway, so this isn't usually an issue.
It means that all those people using C90+extensions are not using C99.
Yes, people using X are not using Y.
The only other argumens you have given are that:
C99 is the current standard.
Your personal experience.
No, I have given many more even only in this post. You, on the other
hand, have
o evidences, many many evidences (where are those evidences?)
o James presented some evidence (but it was wrong, as shown above)
You have shown that your personal experience is limited (you have only
come across 3 implementations)
As explained before, someone's experience as a C programmer has
nothing to do with the number of implementations that person has used.
and C99 being the current standard proves
nothing about how much it is used.
I haven't said that it is used only because it is the current
standard.
Most of the rest of the compilers around are not C99 compilers.
But there are.
No, but it is the most common mode.
You yourself have said that most people use the -ansi option.
Well, the experienced people here recommend using the -ansi -pedentic
switches which put it in to fully C90 conforming mode. So we now have a
sample from beginner to experienced almost all using C90 or C90+extensions.
I've also seen experienced people here recommend -std=c99.
I was not talking about people who care about portability since, for
reasons already explained, the majority of them will *not* use C99
because most compilers do not conform to the C99 standard.
Yes, but I was saying that C99 is more portable than C90 + extensions.
It does when you remember the other bits earlier in the post about why
most people use C90+extensions.
...none of which was true.
You have been told a lot of things which are indicative and give an
outward sign, some of which you could verify independently. You have
been told a lot of things that would be helpful to most people in
forming a conclusion or judgement.
Were you really replying to that "Exactly" statement above?
A more complete quote which you have already been given is, "variable
length arrays broken". This being an extract from a table of
features. If the handle of a mug is broken then the mug is broken.
If the sea has a broken oxygen atom, is the sea broken? If the sky has
a broken cloud, is the sky broken?
Well, that shows you that there are far more C90 implementations than
C99 implementations. Therefore C90 is far more portable than C99.
Yes, though I wouldn't say "far."
Therefore people who really care about portability will have to stick to
C90.
IF they need more portability than C99 offers, which isn't normally
the case.
It does. I've now even provided some very simple code that demonstrates
that it is broken.
And I've provided a compilation process that shows that it isn't.
OK, so you need a hearing aid as well as new glasses.
Non sequitur.
All of which are more likely to lead you to having a C90 implementation
that a C99 implementation.
No, only the fourth.
It means that nothing else is available to those developers. That is
what management specifying something means.
In that sense, management specifying a compiler could even lead to
having a K&R C compiler and nothing else (i.e., it has nothing to do
with specific C standards.)
I explicitly did NOT say they were looking for a C90 compiler. The
ENTIRE POINT is that you DON'T need to be aware of ANY version of the C
standard to end up with a C90 implementation. Therefore most people WILL
end up with a C90 implementation.
No, because people don't just "end up" with compilers; they *choose*
they're compilers.
I talked about choosing a compiler for reasons other than wanting
conformance to a particular version of the standard. Unless you can show
some statistical correlation between conformance to versions of the
standard and another desirable attribute then it is effectively random
which standard will be supported with a distribution very skewed towards
C90 implementations due to simple numbers.
But that randomly selected compiler might not be free, though, which
was the point in the first place anyway.
I'm not. If they're not aware of free implementations, it has to with
whether they're using a C99 compiler, just as whether they're using a
C90 compiler, and so too whether they're using any other kind of
compiler.
You don't need to be aware of standards *or* free
compilers to use a compiler. You just need a compiler, and the odds are
it will be a C90 compiler.
Sure, if you're don't even care what you're programming in. I do.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^
You keep saying you never claimed that Richard's work IS for embedded
systems. I have never said you claimed Richard's work IS for embedded
systems. I have pointed out that you assumed the OPPOSITE, that
Richard's work is NOT for embedded systems. You just quoted both those
things above.
No, I claimed neither that I assumed that Richard's work IS for
embedded systems, nor that I assumed that Richard's work is NOT for
embedded systems. In fact, I never even mentioned the words "embedded
systems" when talking about this.
What Richard's customers use his code for is entirely relevant to what
will be acceptable.
Yes, and given that I didn't know what they used his code for I could
only speak _in general_.
I was pointing out that you are assuming things about his customer base
and that you can only make claims about C99 being acceptable by making
those assumptions.
But I didn't make those assumptions,.
your assumptions are wrong.If Richard has 10 customers and one of them
wants his code for embedded systems then your assumptions are wrong. If
one of his customers insists on using Microsoft Visual Studio (not
uncommon for Windows development) then your assumptions are wrong. If
Richard's code is doing Maths and he uses the C99 atan2 function and his
customers are using gcc on Linux then You assumed a *lot* about his
customers when you claimed that C99 was acceptable.
The first two cases are too specific. The third, regarding the atan2
function, was proven to work on Linux with gcc. And no, I did not
assume anything, I simply spoke in general.
<snip>
Since you are basing your argument on very limited experience and refuse
to accept anything contrary to your preconceived notions I don't see the
point in continuing this.
You don't know about my experience.
I've snipped a lot of the rubbish you were
talking. Feel free to have the last word.
I hope I did. I'm glad to see you've finally given up in holding this
absurd position.
Sebastian
