N
noagbodjivictor
Hi, in the same group as Jacob's lcc-win32, there's also PellesC that
you want to check out.
Hi, in the same group as Jacob's lcc-win32, there's also PellesC that
you want to check out.
A
Army1987
It's not that fatal, but you've been told about it so many times, andjacob said:
editing the headers with a copy of the standard (or even of n1256) in
order to place those declarations in the #ifndef __ANSIC_ONLY__ would not
be a very hard task, so your unwillingness to do that is fatal.
I
Ioannis Vranos
Pelles C looks nice, but "unfortunately" it is a C99 compiler, and AFAIK
it doesn't come with any C90 mode. The "unfortunate" thing is that it's
help file is about C99 only, so if people start checking C99 they can be
out of C90 standard.
R
Randy Howard
It seems that the problem here is duct taping an "almost C99 compiler"
to the front of a "C90 plus funky extensions" library, and expecting it
to work properly in all cases. I never ran into this issue personally,
but I wont recommend either of the above when asked about windows
compilers anymore either.
K
Keith Thompson
Randy Howard said:
No, I don't believe this particular incompatibility has anything to do
with C90 vs. C99. It's a purely C90 issue.
A
Antoninus Twink
Ahh if gcc doesn't implement correctly long double... that
is just a minor thing that doesn't matter.
If lcc-win has some obscure name clashes with code written
specially for that purpose that is a FATAL flaw.
The regulars. Always so unbiased!
The regulars are a mix of boring old farts and nasty schoolyard bullies,
but what they all have in common is being complete and utter hypocrites.
We also know from Heathfield/Macintyre's anonymous sock puppets that
some of them have a pro-actively destructive agenda when it comes to
what they call "the Jacob problem" (i.e. the problem of someone being
independently minded and daring to contradict their ultra-narrow view of
clc).
F
Flash Gordon
Richard Heathfield wrote, On 04/02/08 00:13:
I consider it a big problem as well. At one point I was considering
using MinGW at work, but for me this is a show stopper. Also I suspect
the bug applies to the scanf family as well.
Personally I think the most sensible solution is for the MinGW people to
switch to the "normal" Windows conventions as to how long double is
implemented. This could trip people up interfacing to other Windows
libraries, not just the standard C library.
I agree with you Richard.
The OP should look at http://clc-wiki.net/wiki/C_resources:IDEs and
http://clc-wiki.net/wiki/C_resources:Compilers as well.
I consider it a big problem as well. At one point I was considering
using MinGW at work, but for me this is a show stopper. Also I suspect
the bug applies to the scanf family as well.
Personally I think the most sensible solution is for the MinGW people to
switch to the "normal" Windows conventions as to how long double is
implemented. This could trip people up interfacing to other Windows
libraries, not just the standard C library.
I agree with you Richard.
The OP should look at http://clc-wiki.net/wiki/C_resources:IDEs and
http://clc-wiki.net/wiki/C_resources:Compilers as well.
R
Richard
Mark McIntyre said:
Why are you such an prissy little busy body? Anyone with half a clue can
find that at this web page. Your declaring it here is no more than petty
nastiness. Grow up man.
R
Richard
Flash Gordon said:
And thousands of other get by.
Another one!
"indeed".
Yuck. It's almost embarrassing.
J
jacob navia
Ioannis said:
But C99 is the standard language. Why teaching an obsolete standard?
F
Flash Gordon
jacob navia wrote, On 04/02/08 21:12:
Probably because it is still the one the students are most likely to
encounter in real life.
Probably because it is still the one the students are most likely to
encounter in real life.
J
jacob navia
Flash said:
This is completely wrong.
The students of today will not start entering the job market until
3-4 years. In 2011 C99 will be widespread. Today, standard C is
supported by many compilers.
A
Army1987
Are you saying you think it didn't spread significantly in the past ninejacob said:
years but it will in the next three years?
(But, IMO, it's better to teach the intersection of C90 and C99. For
example, while implicit int could be mentioned to help students understand
old code, if it is it should also be said that using it in new code isn't
a very good idea.)
I am not 100% sure that C99 won't be widespread in 2011, but I think that
if it will, C1x will be implemented much more quickly than C99 was, as one
of its principles will be "no invention, without exception". But OK, I
don't have a crystal ball either, and the world will end by 21 Dec 2012
anyway...
R
Randy Howard
How do you know this? People having been making similar claims for a
decade, and it hasn't been true for any of them.
If you limit "many" to "a few" maybe.
R
Randy Howard
Are you saying you think it didn't spread significantly in the past nine
years but it will in the next three years?
(But, IMO, it's better to teach the intersection of C90 and C99. For
example, while implicit int could be mentioned to help students understand
old code, if it is it should also be said that using it in new code isn't
a very good idea.)
I am not 100% sure that C99 won't be widespread in 2011, but I think that
if it will, C1x will be implemented much more quickly than C99 was, as one
of its principles will be "no invention, without exception". But OK, I
don't have a crystal ball either, and the world will end by 21 Dec 2012
anyway...
You should also consider that if Chris Hills' predictions come to pass,
learning C99 and using it could be a big mistake, given that he has
implied that large chunks of C99 may get "rolled back". If that does
happen, teaching students to write C99 may be a big mistake.
IMO, although it's a nice idea, it's too late now, as people are
writing code using C99 in some places, so it's going to be yet another
rats nest, and represent yet another reason for people to look
elsewhere.
K
Kelsey Bjarnason
As opposed to 2008, when it isn't.
Really? Which ones? Not gcc. Not Microsoft's offering. Intel lists
the C99 bits they actually conform to; I'd have to check to see how far
off they are, but I suspect if they supported C99 in toto, they'd just
say so.
So just who, exactly, is producing these "standard C" - i.e. C99 -
compilers?