[OT] C90 IDE+compiler for Windows / educational purposes

[Ioannis Vranos]

Hi,

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't work
correctly there.

Any ideas would be welcome.

 

[jacob navia]

Hi,

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't work
correctly there.

Any ideas would be welcome.

lcc-win is a C compiler used a lot in universities and educational
settings.

It features
o IDE with windowed debugger

o Compiler assembler, linker, make utility

o Advanced IDE with spelling checker, tooltips, goto definition,
software metrics, grep/search/diff, and many other utilities.

o Small package installs in approx 1 minute.

o Types:
True long double precision
long long type (64 bit integer)
Optional 352 bits float (104 digits)
128 bit integers
All normal types (int,double,float,short, etc)

o Optional extensions like operator overloading/try-catch/ etc.

o Educational licenses available.

If interested contact me below.

 

[Keith Thompson]

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't
work correctly there.

Any ideas would be welcome.

As I recall from discussions here, the problem is an inconsistency
between the compiler and the runtime library regarding the
representation of long double. Either choice would be valid by
itself, but the inconsistency is a bug.

How much of a problem is that really? What if you just avoid the use
of long double in the class?

 

[Richard Heathfield]

Ioannis Vranos said:

Hi,

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't work
correctly there.

Turbo C is fine, and is available for free download from the Borland museum
site.

BTW welcome back to clc

 

[vippstar]

Hi,

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't work
correctly there.

There is no 'long double' in C90.
'long double' was standarised in C99 AFAIK.
Is long double that importand?

 

[Flash Gordon]

Ioannis Vranos wrote, On 03/02/08 21:30:

Hi,

Do you know of any decent free simple C90 IDE+compiler for Windows for
use in a classroom? I know Dev-C++/MINGW but "long double" doesn't work
correctly there.

Any ideas would be welcome.

Check out the licensing terms on the free versions of MS Visual Studio.

Also, whatever you go for, *please* find out how to put it in to
ISO-conforming mode and start off by teaching standard portable C before
you go on to any non-standard stuff, and when you do the non-standard
stuff let the students know it is non-standard and not portable.

 

[Richard Heathfield]

(e-mail address removed) said:

There is no 'long double' in C90.

Rubbish. See (the C90 equivalent of) 3.1.2.5 of C89.

 

[Mark McIntyre]

lcc-win is a C compiler used a lot in universities and educational
settings.

Jacob meant to declare an interest at this point as he is the maintainer
of lcc-win32, and the beneficiary of any commercial license.

For the non-Brits amongst you, "declaring an interest" is what our
elected representatives are supposed to do when a law is under
discussion from which they might financially benefit.

(jacob, two things; 1) this is not an attack on you, its a simple
clarification - so take your paranoid hat off; 2) your new email is in
my killfile so no need to respond).

 

[jacob navia]

Jacob meant to declare an interest at this point as he is the maintainer
of lcc-win32, and the beneficiary of any commercial license.

Yes. I have been working since 1995 in providing this
compiler to many people and to the C community in
general. This compiler is not supported by any big
institution but by its users: universities,
private people, several companies, and many
other people that contributed to this project.

 

[jacob navia]

Mark McIntyre wrote:
[snip]


2) your new email is in my killfile ...

Your killfile has a bug apparently. If not, how could
you read my answers to posts here?



But obviously you can't write anything without a bug,
not even a killfile!

 

[Richard Heathfield]

Mark McIntyre said:

Jacob meant to declare an interest at this point as he is the maintainer
of lcc-win32, and the beneficiary of any commercial license.

He also forgot to mention that lcc-win32 has C90 conformance issues which
generally seem to come as a complete surprise to him when they come to
light here in comp.lang.c; apparently this is because he didn't bother to
read the Standard all that closely when "improving" the software - after
all, it's just boring techie stuff, right? Who wants to spend time reading
that stuff, when they could be adding FEATURES?

 

[Keith Thompson]

There is no 'long double' in C90.
'long double' was standarised in C99 AFAIK.
Is long double that importand?

Incorrect; long double is in C90. (I've seen compilers produce error
messages that imply otherwise; those messages are incorrect.)

 

[jacob navia]

As I recall from discussions here, the problem is an inconsistency
between the compiler and the runtime library regarding the
representation of long double. Either choice would be valid by
itself, but the inconsistency is a bug.

How much of a problem is that really? What if you just avoid the use
of long double in the class?

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!

 

[Ioannis Vranos]

There is no 'long double' in C90.
'long double' was standarised in C99 AFAIK.
Is long double that importand?

It is a C90 built in type:

long double ld= 0.1L;

printf("%Lf", ld);

 

[Keith Thompson]

Ahh if gcc doesn't implement correctly long double... that
is just a minor thing that doesn't matter.

I didn't say it doesn't matter. It's certainly a bug; I merely
suggested that it might not be a show-stopping problem in a particular
context.

(If I recall correctly, it's not a bug in gcc; it's a bug in
Dev-C++/MINGW's integration of gcc with the Microsoft runtime library.
It should certainly be corrected somehow; I've never suggested
otherwise.)

If lcc-win has some obscure name clashes with code written
specially for that purpose that is a FATAL flaw.

No, it's not a fatal flaw. It's a bug, and it's a failure to conform
to the standard. You should fix it.

The regulars. Always so unbiased!

Recently, when somebody's program failed to compile because of a bug
in lcc-win, I suggested a possible workaround, namely avoiding the
particular identifier that lcc-win incorrectly declared in a standard
header. Now when someone mentions a conformance failure in
Dev-C++/MINGW, I suggest a possible workaround, namely avoiding the
use of type long double. So what bias are you talking about?

Since you've jumped into this discussion (which wasn't about you or
your compiler in the first place), I'll ask you whether you have any
plans to fix this particular bug in lcc-win. (I don't ask the same
thing about Dev-C++/MINGW simply because its maintainers don't post
here, as far as I know.)

 

[Richard Heathfield]

Keith Thompson said:

As I recall from discussions here, the problem is an inconsistency
between the compiler and the runtime library regarding the
representation of long double. Either choice would be valid by
itself, but the inconsistency is a bug.
Right.

How much of a problem is that really?

I'd have thought that the failure to implement a fundamental type correctly
is a serious conformance issue. That's a big problem, surely?

What if you just avoid the use
of long double in the class?

I see your point, but wouldn't it be simpler to use an implementation that
conforms to C90? It's not as if there is any shortage of conforming
implementations for the Windows platform - and many of them are free. Why
use a broken implementation when working implementations are available?

 

[jacob navia]

Since you've jumped into this discussion (which wasn't about you or
your compiler in the first place), I'll ask you whether you have any
plans to fix this particular bug in lcc-win. (I don't ask the same
thing about Dev-C++/MINGW simply because its maintainers don't post
here, as far as I know.)

It is fixed already. And it is fixedf also the one
about RAND_MAX. Will be there tomorrow.

 

[Keith Thompson]

It is a C90 built in type:

long double ld= 0.1L;

printf("%Lf", ld);

Of course. I was merely suggesting that, in a classroom context, it
might be acceptable to work around this bug by avoiding the use of
long double, or at least to avoid passing it to the *printf()
functions. Implementing a function to create a string representation
of a long double value (which printf *should* do) could even be a good
exercise.

It's your call, of course.

 

[Keith Thompson]

Keith Thompson said:

I'd have thought that the failure to implement a fundamental type correctly
is a serious conformance issue. That's a big problem, surely?

As I recall, the type itself is implemented correctly; the bug is that
the runtime library's implementation of printf doesn't handle it.

It's a failure to conform to the standard, which is a serious problem.
For an application that deons't use long double, it might not be a
show-stopper.

I see your point, but wouldn't it be simpler to use an implementation that
conforms to C90? It's not as if there is any shortage of conforming
implementations for the Windows platform - and many of them are free. Why
use a broken implementation when working implementations are available?

I don't know enough about C implementations under Windows to judge how
good they are. It's possible that Dev-C++/MINGW had advantages that
might, in some contexts, outweigh this one bug. It's also possible
that it doesn't. I was merely pointing out a possiblity.

 

[Keith Thompson]

It is fixed already. And it is fixedf also the one
about RAND_MAX. Will be there tomorrow.

Glad to hear it, especially after your previous attitude.

Have you check for other non-standard identifiers in your standard
headers?