good c compiler

[bernard]

howdy!

please recommend a good c compiler.

- should be small
- should be fast
- should come with a good ide
- should be inexpensive

i am using windows os.

awaiting replies.

[vippstar]

On Sep 30, 5:55 am, CBFalconer <[e-mail]:

[e-mail] wrote:

CBFalconer <[e-mail]:

jacob navia wrote:
James Kuyper wrote:

... snip ...

>>In the mode where it comes closest to conforming to C90, it
supports as extensions certain C99 features.

>For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform
to C90. The result is that the poor user is never told that his
code is not portable with those successive division symbols.

If accepting means to translate without emitting a diagnostic
error, you are correct. However, the standard seems to use the
word 'accept' to talk about the implementation processing the
file. In that sense, no, it's not horrible as a C90 compiler is
*required* to accept files containing // comments.

I don't think you meant what you wrote. A C90 compiler is required
to accept the '/' as indicating division. Two in a row are a
syntax error, not a comment, and require a diagnostic.

I did :-)

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

[jameskuyper]

[e-mail] wrote:
....

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made. As far as I can see,
a compiler which generates the message "Program accepted" counts as
having accepted the program, even if it does nothing else with the
program (not even translation phase 1). I don't think that this was
the committee's intent, which is why I believe the wording should be
changed to prevent that from being a valid interpretation.

[vippstar]

On Sep 30, 11:56 pm, [e-mail] wrote:

[e-mail] wrote:

...

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made. As far as I can see,
a compiler which generates the message "Program accepted" counts as
having accepted the program, even if it does nothing else with the
program (not even translation phase 1). I don't think that this was
the committee's intent, which is why I believe the wording should be
changed to prevent that from being a valid interpretation.

I agree the standard uses accept in critical sentences without
defining the meaning, but I don't think there's many interprentations
of what the standard means.

I was actually based on your own words when I mentioned TP 1 to 4.
Message-ID: <8ac6eb1c-3e61-404e-9bd7-
cf**********@34g2000hsh.googlegroups.com>
Message-ID: <5hJtk.966$UX.551@trnddc03>

You seem to contradict yourself...
Would you mind clarifying?

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 30 Sep 2008 13:56:29 -0700, jameskuyper wrote:

[e-mail] wrote:
...

>I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post. Accept seems to mean
apply TP 1 to 4 to it. So, a file with // comments must be accepted by
a C90 implementation.

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made.

Do you believe "accept" corresponds to more, or to less translation phases?

Personally, I dislike the idea of treating "A conforming hosted
implementation shall accept any strictly conforming program." as saying it
may refuse to link strictly conforming programs, just because linking
isn't part of "accept". I don't see how "accept" can be meant to refer to
anything less than all 8 phases.

[jameskuyper]

[e-mail] wrote:

On Sep 30, 11:56 pm, [e-mail] wrote:

[e-mail] wrote:

...

I mentioned the usage of 'accepting' by the standard (C99 though, not
C90), and it's different than yours in your post.
Accept seems to mean apply TP 1 to 4 to it.
So, a file with // comments must be accepted by a C90 implementation.

One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made. As far as I can see,
a compiler which generates the message "Program accepted" counts as
having accepted the program, even if it does nothing else with the
program (not even translation phase 1). I don't think that this was
the committee's intent, which is why I believe the wording should be
changed to prevent that from being a valid interpretation.

I agree the standard uses accept in critical sentences without
defining the meaning, but I don't think there's many interprentations
of what the standard means.

I've been monitoring comp.std.c since 1996, and in that time I've
heard quite a few mutually incompatible meanings for "accept" being
proposed as the only possible meaning.

I was actually based on your own words when I mentioned TP 1 to 4.
Message-ID: <8ac6eb1c-3e61-404e-9bd7-
cf**********@34g2000hsh.googlegroups.com>
Message-ID: <5hJtk.966$UX.551@trnddc03>

You seem to contradict yourself...
Would you mind clarifying?

That message described an absolutely minimally conforming
implementation of C99. My point was to show that there are far fewer
meaningful requirements on such an implementation than you might
think. One requirement is that code which contains a #error directive
which survives conditional compilation must be rejected, with a
suitable error message. That requires essentially full implementation
of translation phases 1-4. Another requirement is that all strictly
conforming programs must be accepted. In itself, that requirement can
be met by a compiler with accepts all programs, regardless of their
contents. In the message I posted today, I was only addressing the
acceptance requirement, not the rejection requirement.

[James Kuyper]

Harald van Dijk wrote:

On Tue, 30 Sep 2008 13:56:29 -0700, jameskuyper wrote:

....

>One key problem is that the standard uses the terms "accept" and
"reject" in important ways without defining them. I've heard arguments
that "accept" corresponds to translation phases 1-7; I don't think
that's plausible, but the argument has been made.

Do you believe "accept" corresponds to more, or to less translation phases?

Personally, I dislike the idea of treating "A conforming hosted
implementation shall accept any strictly conforming program." as saying it
may refuse to link strictly conforming programs, just because linking
isn't part of "accept". I don't see how "accept" can be meant to refer to
anything less than all 8 phases.

When you "accept" a gift, does that mean that you need to use it? Do you
even need to unwrap it? As I understand it, I've finished accepting the
gift when I take it into my hands, and say "thank you", even if I toss
it in the trash, still wrapped, as soon as I'm out of sight of the giver.

I don't see any justification for interpreting "accept" for compilers in
any stronger fashion than that. I believe that the committee intended
the term to mean more than that, but I think it's a defect in the
standard that they chose to use the word "accept" to convey that intent,
without giving it any C-specific definition.

[Kenny McCormack]

In article <gc************@jones.homeip.net>,
<la************@siemens.comwrote:

>jacob navia <ja***@nospam.comwrote:

>>
I have worked years implementing C99, and I have
now an implementation that is not missing any important feature.

According to your classification of which features are important and
which are not. Other people may well have different opinions. Your
compiler is an impressive piece of work, but I wish you'd stop
pretending that it's complete when you know darned well that it isn't
yet.

Nothing is ever complete. Nor is a painting ever finished.

[Richard Nixon]

On Tue, 7 Oct 2008 14:54:14 +0000 (UTC), Kenny McCormack wrote:

In article <gc************@jones.homeip.net>,
<la************@siemens.comwrote:

>>jacob navia <ja***@nospam.comwrote:

>>>
I have worked years implementing C99, and I have
now an implementation that is not missing any important feature.

According to your classification of which features are important and
which are not. Other people may well have different opinions. Your
compiler is an impressive piece of work, but I wish you'd stop
pretending that it's complete when you know darned well that it isn't
yet.

Nothing is ever complete. Nor is a painting ever finished.

Jacob's lcc was the most complete C compiler I had used when I was intent
on getting C99 features. I was decompressing off of Microsoft products,
but notwithstanding.

His compiler is complete in a way that standard thumpers don't value: you
can make a window without reinventing the wheel, which for those who target
the world's most popular OS, is the window.

All of the implementations with which I have experience are having trouble
with, say, double complex. YMMV.

What important C99 feature does lcc lack?
--
Richard Milhous Nixon

All kings is mostly rapscallions.
~~ Mark Twain

[Keith Thompson]

Richard Nixon <ri*****@example.invalidwrites:
[...]

>In article <gc************@jones.homeip.net>,
<la************@siemens.comwrote:

>>>jacob navia <ja***@nospam.comwrote:

I have worked years implementing C99, and I have
now an implementation that is not missing any important feature.

According to your classification of which features are important and
which are not. Other people may well have different opinions. Your
compiler is an impressive piece of work, but I wish you'd stop
pretending that it's complete when you know darned well that it isn't
yet.

[...]

>
Jacob's lcc was the most complete C compiler I had used when I was intent
on getting C99 features. I was decompressing off of Microsoft products,
but notwithstanding.

His compiler is complete in a way that standard thumpers don't value: you
can make a window without reinventing the wheel, which for those who target
the world's most popular OS, is the window.

Nobody said that's not valuable; I'm sure it is. There's nothing
wrong with making system-specific operations such as making a window
more convenient. The question we've discussed here is how well
lcc-win conforms to the C99 standard.

jacob frequently refers to his lcc-win as a C99 compiler, but he's
never claimed that it fully conforms to the C99 standard. As I
recall, it doesn't implement variadic macros, and there may be some
missing functionality in the C99 changes to initializers. I don't
have any details about the current status.

All of the implementations with which I have experience are having trouble
with, say, double complex. YMMV.

What important C99 feature does lcc lack?

An important note: lcc is a C90-only compiler. lcc-win (sometimes
also known as lcc-win32) is jacob navia's compiler, and is based on
lcc. lcc itself is still available.

Apparently it depends on what you mean by "important". jacob insists
that the only missing C99 features are unimportant ones, so his answer
would be "none". A question that might yield more meaningful results
would be: what important *or unimportant* features does lcc-win lack.
You can then decide for yourself which features are or are not
important to you.

Of course, if lcc-win suits your purposes, by all means use it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tim Rentsch]

la************@siemens.com writes:

ja*********@verizon.net wrote:

For some reason, jacob confusingly describes that situation by saying
that lcc doesn't implement "long double".

Because he's thinking as an implementor: "I've already implemented
32-bit floating-point arithmetic for float and 64-bit floating-point
arithmetic for double; I don't feel like implementing yet another kind
of floating-point arithmetic for long double, so I'll just use my 64-bit
implementation instead." In Jacob's mind, this lazy implementor has
just reused his double implementation instead of implementing long
double (correctly). While it's understandable in that context, you're
correct that it's very confusing to the rest of us.

I just want to offer some applause for a very nice
posting clarifying the two different mindsets here.