C++03 IDE+compiler for Windows / educational purposes

[Ioannis Vranos]

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

Any ideas would be welcome.

 

[Alf P. Steinbach]

* Ioannis Vranos:

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

Well, if g++ isn't good enough for long double, and considering that
Visual C++ long double is the same as double, i.e. no special long
double type, I guess your only option would be to try to combine e.g.
CodeBlocks or Eclipse IDE with Digital Mars compiler or the like.

However, is "long double" that important (and btw., what's the problem
with g++ and long double?)?

If it isn't all important, go for g++ with CodeBlocks, or Visual C++
with Visual Studio Express, both free. Also note that Microsoft is
giving away the Professional edition of Visual Studio to students, for
free. I guess the teacher must buy it... ;-)


Cheers, & hth.,

- Alf

 

[Ioannis Vranos]

* Ioannis Vranos:

Well, if g++ isn't good enough for long double, and considering that
Visual C++ long double is the same as double, i.e. no special long
double type, I guess your only option would be to try to combine e.g.
CodeBlocks or Eclipse IDE with Digital Mars compiler or the like.

However, is "long double" that important (and btw., what's the problem
with g++ and long double?)?

I am not talking about g++ having problem with long double, but the
MINGW port.

If it isn't all important, go for g++ with CodeBlocks, or Visual C++
with Visual Studio Express, both free. Also note that Microsoft is
giving away the Professional edition of Visual Studio to students, for
free. I guess the teacher must buy it... ;-)

CodeBlocks hasn't a stable version yet, it had nightly builds, but they
are stating they are going to have a stable version on their site
http://www.codeblocks.org soon.


I will check VC++ 2008 Express.

 

[jason.cipriani]

This is a big stretch, but another thing to try might be something
like CoLinux (http://www.colinux.org/) and use GCC on there. Of course
you won't be able to compile Windows binaries (unless you set it up to
cross compile), but it's like having a Linux machine right there. This
is assuming, of course, that using long double and just playing around
is more important than being able to compile binaries for Windows, use
a nice IDE, or play around with Windows-specific stuff. I have never
used CoLinux before though.

Why are long doubles important to you? Maybe, depending on your needs,
there is another solution for high-precision computations?

Jason

 

[dave_mikesell]

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

Any ideas would be welcome.

How about g++ + Vim + make?

 

[James Kanze]

* Ioannis Vranos:

Well, if g++ isn't good enough for long double, and
considering that Visual C++ long double is the same as double,
i.e. no special long double type, I guess your only option
would be to try to combine e.g. CodeBlocks or Eclipse IDE
with Digital Mars compiler or the like.

However, is "long double" that important (and btw., what's the
problem with g++ and long double?)?

If it isn't all important, go for g++ with CodeBlocks, or
Visual C++ with Visual Studio Express, both free. Also note
that Microsoft is giving away the Professional edition of
Visual Studio to students, for free. I guess the teacher must
buy it... ;-)

I wonder what he really meant be C++03. None of the compilers
mentionned so far truely implements C++03---all are missing
export, for example; more importantly for students, I suspect
that most of them have subtle variations in their treatment of
two phase lookup, and I think VC++ allows binding of a temporary
to a non-const reference, and, and, and... On the other hand,
all are perfectly fine for the sort of things I'd imagine
students would be doing.

If he really needs standards conformance, of course, Comeau is
about his only choice. Not free, but very reasonably priced.
(No IDE either, but there's always gvim/emacs and make.)

 

[Ioannis Vranos]

This is a big stretch, but another thing to try might be something
like CoLinux (http://www.colinux.org/) and use GCC on there. Of course
you won't be able to compile Windows binaries (unless you set it up to
cross compile), but it's like having a Linux machine right there. This
is assuming, of course, that using long double and just playing around
is more important than being able to compile binaries for Windows, use
a nice IDE, or play around with Windows-specific stuff. I have never
used CoLinux before though.

Why are long doubles important to you? Maybe, depending on your needs,
there is another solution for high-precision computations?

Imagine newcomer students learning C++ in a class, and not being able to
use long double, and having to instruct them to avoid the type.


This isn't good for the credibility of C++, caused by a bad compiler.

 

[jason.cipriani]

Imagine newcomer students learning C++ in a class, and not being able to
use long double, and having to instruct them to avoid the type.

I think that you are placing too much importance on a minor issue.
There are other, much trickier things about C++ than iffy support for
long doubles on certain compilers. Not being able to use long double
will not ruin a student's C++ experience -- I can promise you that.
You have a few options:

1) Do not tell them about "long double". It's not a critical type for
a beginner student to know about, an advanced student will understand
the real explanation, and in any case I can assure you nobody will be
missing out on all that much.

2) Tell them exactly what the issue is. Avoid "long doubles" because
currently, support is not widely available. That seems very
reasonable. It's part of C++, and so if you are going to teach C++,
you should teach that part as well.

3) Ask on comp.lang.c++ for a specific compiler on Windows that does
support long double. Do not mention the lack of common support to your
students. Instead, let them find out on their own later when code you
taught them about breaks on other current compilers. Alternatively,
explain to them that while they can use long double on the specific
compiler you are teaching them on, it won't necessarily work on other
compilers. That explanation is probably not as simple as "avoid it
because it's not widely supported". This is not a good option. This is
also the option you are proposing.

I think that you should go with #1, honestly. And then later on in the
course tell them "hey by the way, there is this long double type, but
it's not really widely supported right now so I'd avoid it". That's a
complete, brief explanation that anybody would understand.

If you are teaching students C++, you have far more on your plate than
teaching them about some obscure primitive data type...

In any case, you should brace yourself for the onslaught you are
likely about to receive from the less laid-back folks on this
newsgroup.

Jason

 

[jason.cipriani]

P.S.:

http://compilers.iecc.com/comparch/article/98-08-061

Also, now that I am armed with a shiny new copy of the C++03
standard...

You originally wrote this:

I know Dev-C++/MINGW but "long double" doesn't work
always correctly there.

Can you clarify what you meant by "correctly"? Section 3.9.1/8 reads:

"There are three floating point types: float, double,
and long double. The type double provides at least
as much precision as float, and the type long double
provides at least as much precision as double."

Which places no requirements on "long double" to be more precise than
"double". Float, double, and long double could all be the same
precision, from what I can see there. For it to be incorrect, "long
double" would have to be *less* precise than "double" -- but I don't
think you observed that.

Jason

 

[Richard Herring]

Imagine newcomer students learning C++ in a class, and not being able
to use long double, and having to instruct them to avoid the type.

My imagination won't stretch that far. What kind of student project uses
long double? Sure, there are some specialist fields where it's
essential, but generally if you're running out of precision so fast that
double isn't enough, it's more likely that you need a different
algorithm, not more bits in your fractions.

 

[John Brawley]

My imagination won't stretch that far. What kind of student project uses
long double? Sure, there are some specialist fields where it's
essential, but generally if you're running out of precision so fast that
double isn't enough, it's more likely that you need a different
algorithm, not more bits in your fractions.

Richard Herring

Wishing to contribute:
I have a need for high precision, and had considered long double, but found
that double was "good enough." (Maybe some day... and maybe some day
FORTRAN if it's all that important....)
Y'all seem right: long double's as much precision as most people, and
especially students, are likely to need.
I had friend once who was a stereo bug. He would spend oodle$ of buck$ on a
new system that gave him 0.0001 less total harmonic distortion, or upped his
root-mean-square power figure by 3 or 4 percent, and in all the time I knew
him and his ever-evolving stereo system, I couldn't *hear* the differences
from the first nice system he owned.
There's a time when precision becomes an obesssion instead of a tool.


--
Peace
JB
(e-mail address removed)
Web: http://tetrahedraverse.com


Now

 

[Ioannis Vranos]

Can you clarify what you meant by "correctly"? Section 3.9.1/8 reads:

"There are three floating point types: float, double,
and long double. The type double provides at least
as much precision as float, and the type long double
provides at least as much precision as double."

Which places no requirements on "long double" to be more precise than
"double". Float, double, and long double could all be the same
precision, from what I can see there. For it to be incorrect, "long
double" would have to be *less* precise than "double" -- but I don't
think you observed that.

Now that you are mentioning it, I think that long double actually works
with cout, but it is broken with printf("%Lf", ld); under MINGW, where
ld is long double, and the rest of C95 functions.


The course actually includes 2 lessons on C and one on C++ (a semester
each). Now we will actually begin with C, and I am actually looking for
C90/95 - C++03 IDEs+compilers, either combined or stand alone.

Visual C++ Express 2008 actually supports C95 and "C++98".

 

[Hendrik Sattler]

CodeBlocks hasn't a stable version yet, it had nightly builds, but they
are stating they are going to have a stable version on their site
http://www.codeblocks.org soon.

To make that "soon" more relative: the same statement was there a year ago
(and probably will be there in a year).

HS

 

[jason.cipriani]

(e-mail address removed) wrote:
Now that you are mentioning it, I think that long double actually works
with cout, but it is broken with printf("%Lf", ld); under MINGW, where
ld is long double, and the rest of C95 functions.

Yes, at least GCC 3.4.2 printf treats %Lf as a regular double, but
leaves "long double" as "long double" when passed through '...' (what
the C++ standard says about long doubles through '...', I don't know
-- but from what I can tell they should not be demoted to double, and
GCC is correct there, at least). So the following:

#include <cstdio>

using std:rintf;

int main (int, char **) {
double d = 1.0;
long double dd = 1.0L;
printf("%f %Lf ", d, d);
printf("%f %Lf ", dd, dd);
printf("%f %Lf ", (double)dd, (double)dd);
return 0;
}

Produces "1.0 1.0 0.0 0.0 1.0 1.0" with MinGW GCC 3.4.2.
Produces expectedly garbage results on Linux GCC 4.1.2 (since %Lf
works).
Produces "1.0 1.0 0.0 0.0 1.0 1.0" with BCC32 5.93
Produces "1.0 1.0 1.0 1.0 1.0 1.0" with MS CL 12.00 (VS6, since
they're all just "double")
Produces "1.0 1.0 1.0 1.0 1.0 1.0" with MS CL 14.00 (VS2005, same
deal).

So you are just talking about the *printing* of long doubles with
printf? That shouldn't prevent a student from using it. That just
prevents them from using printf to print it on some compilers.

Did you look at the link I sent you? Perhaps the Intel compiler printf
works.

However, if you are going to teach about long doubles, why do you not
want to tell your students about the actual situation? It's very
simple to explain (you could just show them this thread, for example),
and better than having them encounter a broken compiler or something
some day and it catches them by surprise. It's far more practical to
teach a student about a situation they may actually encounter, rather
than teaching theory and letting reality confuse them later. Also,
would you prefer "this doesn't work and Mr. Vranos said it would in my
course last year... what was that guy talking about?", or "Mr. Vranos
told me about this, he definitely knows what's up".

You could always eliminate the problem entirely by just not talking
about long doubles. It really shouldn't be a major issue. Again, I
think that you are concentrating too much on a language quirk that,
while interesting to talk about on a newsgroup, is very minor in
comparison to other aspects of C++ that you would be teaching.

 

[jason.cipriani]

[snip] Now we will actually begin with C [snip]

Typedef'ing structs and enums in C++ code is like scraping nails on a
chalkboard for me, I don't know why. If you are going to start with
C, make sure to take some valuable time out of the C++ semester to
explain the differences.

 

[Ioannis Vranos]

My above statement is incorrect (see below).

Yes, at least GCC 3.4.2 printf treats %Lf as a regular double, but
leaves "long double" as "long double" when passed through '...' (what
the C++ standard says about long doubles through '...', I don't know
-- but from what I can tell they should not be demoted to double, and
GCC is correct there, at least). So the following:

#include <cstdio>

using std:rintf;

int main (int, char **) {
double d = 1.0;
long double dd = 1.0L;
printf("%f %Lf ", d, d);
printf("%f %Lf ", dd, dd);
printf("%f %Lf ", (double)dd, (double)dd);
return 0;
}

Produces "1.0 1.0 0.0 0.0 1.0 1.0" with MinGW GCC 3.4.2.
Produces expectedly garbage results on Linux GCC 4.1.2 (since %Lf
works).
Produces "1.0 1.0 0.0 0.0 1.0 1.0" with BCC32 5.93
Produces "1.0 1.0 1.0 1.0 1.0 1.0" with MS CL 12.00 (VS6, since
they're all just "double")
Produces "1.0 1.0 1.0 1.0 1.0 1.0" with MS CL 14.00 (VS2005, same
deal).

So you are just talking about the *printing* of long doubles with
printf? That shouldn't prevent a student from using it. That just
prevents them from using printf to print it on some compilers.

AFAIK, MINGW's long double is broken with all the C subset standard I/O
functions.

Did you look at the link I sent you? Perhaps the Intel compiler printf
works.

Yes I checked it. It is a bit old thread. I am not sure what you mean.
The following code:


#include <cstdio>
#include <limits>
#include <iostream>

int main()
{
using namespace std;


cout<< numeric_limits<long double>::max()<< endl;

printf("%Lf\n", numeric_limits<long double>::max());

}

produces in my Linux box with "gcc version 4.1.2 20070626":


[john@localhost src]$ ./foobar-cpp
1.18973e+4932
118973149535723176502126385303097020516906332229462420044032373389173700552297072261641029033652888285354569780749557731442744315367028843419812557385374367867359320070697326320191591828296152436552951064679108661431179063216977883889613478656060039914875343321145491116008867984515486651285234014977303760000912547939396622315138362241783854274391783813871780588948754057516822634765923557697480511372564902088485522249479139937758502601177354918009979622602685950855888360815984690023564513234659447638493985927645628457966177293040780660922910271504608538808795932778162298682754783076808004015069494230341172895777710033571401055977524212405734700738625166011082837911962300846927720096515350020847447079244384854591288672300061908512647211195136146752763351956292759795725027800298079590419313960302147099703527646744553092202267965628099149823208332964124103850923918473478612192169721054348428704835340811304257300221642134891734717423480071488075100206439051723424765600472176809648
610799494341570347632064355862420744350442438056613601760883747816538902780957697597728686007148702828795556714140463261583262360276289631617397848425448686060994827086796804807870251185893083854658422304090880599629459458620190376604844679092600222541053077590106576067134720012584640695703025713896098375799892695455305236856075868317922311363951946885088077187210470520395758748001314313144425494391994017575316933939236688185618912993172910425292123683515992232205099800167710278403536014082929639811512287776813570604578934353545169653956125404884644716978689321167108722908808277835051822885764606221873970285165508372099234948333443522898475123275372663606621390228126470623407535207172405866507951821730346378263135339370677490195019784169044182473806316282858685774143258116536404021840272491339332094921949842244273042701987304453662035026238695780468200360144729199712309553005720614186697485284685618651483271597448120312194675168637934309618961510733006555242148519520176285859
509105183947250286387163249416761380499631979144187025430270675849519200883791516940158174004671147787720145964446117520405945350476472180797576111172084627363927960033967047003761337450955318415007379641260504792325166135484129188421134082301547330475406707281876350361733290800595189632520707167390454777712968226520622565143991937680440029238090311243791261477625596469422198137514696707944687035800439250765945161837981185939204954403611491531078225107269148697980924094677214272701240437718740921675661363493890045123235166814608932240069799317601780533819184998193300841098599393876029260139091141452600372028487213241195542428210183120421610446740462163533690058366460659115629876474552506814500393294140413149540067760295100596225302282300363147382468105964844244132486457313743759509641616804802412935187620466813563687753281467553879887177183651289394719533506188500326760735438867336800207438784965701457609034985757124304510203873049485425670247933932280911052604153852899484920
399109194612991249163328991799809438033787952209313146694614970593966415237594928589096048991612194498998638483702248667224914892467841020618336462741696957630763248023558797524525373703543388296086275342774001633343405508353704850737454481975472222897528108302089868263302028525992308416805453968791141829762998896457648276528750456285492426516521775079951625966922911497778896235667095662713848201819134832168799586365263762097828507009933729439678463987902491451422274252700636394232799848397673998715441855420156224415492665301451550468548925862027608576183712976335876121538256512963353814166394951655600026415918655485005705261143195291991880795452239464962763563017858089669222640623538289853586759599064700838568712381032959192649484625076899225841930548076362021508902214922052806984201835084058693849381549890944546197789302911357651677540623227829831403347327660395223160342282471752818181884430488092132193355086987339586127607367086665237555567580317149010847732009642431878007
0008797346032906278943553743564448851907191616455141155761939399690767415156402826543664026760095087523945507341556135867933066031744720924446513532366647649735400851967040771103640538150073486891798364049570606189535005089840913826869535090066783324472578712196604415284924840041850932811908963634175739897166596000759487800619164094854338758520657116541072260996288150123144377944008749301944744330784388995701842710004808305012177123560622895076269042856800047718893158089358515593863176652948089031267747029662545110861548958395087796755464137944895960527975209874813839762578592105756284401759349324162148339565350189196811389091843795734703269406342890087805846940352453479398080674273236297887100867175802531561302356064878709259865288416350972529537091114317204887747405539054009425375424119317944175137064689643861517718849867010341532542385911089624710885385808688837777258648564145934262121086647588489260031762345960769508849149662444156604419552086811989770240.000000

[john@localhost src]$



and under Visual C++ 2008 Express Edition:

1.79769e+308
17976931348623157000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000.000000
Press any key to continue . . .


and under Dev-C++ 4.9.9.2 Beta (which uses MINGW "gcc version 3.4.2
(mingw-special)"):

C:\c>temp
1.#INF
-1.#QNAN0

C:\c>


I have tried with a more recent MINGW version, with the same results, a
couple months ago or something like that.

However, if you are going to teach about long doubles, why do you not
want to tell your students about the actual situation? It's very
simple to explain (you could just show them this thread, for example),
and better than having them encounter a broken compiler or something
some day and it catches them by surprise. It's far more practical to
teach a student about a situation they may actually encounter, rather
than teaching theory and letting reality confuse them later.

I am not sure I am following you. long double is a standard C++ built in
type, and should work as it should. MINGW's long double is just broken
(or not appropriately implemented to deal with Windows if you prefer).

You could always eliminate the problem entirely by just not talking
about long doubles. It really shouldn't be a major issue. Again, I
think that you are concentrating too much on a language quirk that,
while interesting to talk about on a newsgroup, is very minor in
comparison to other aspects of C++ that you would be teaching.

Under C++03, when I want the largest built in integer type I am using
long, if I want the maximum precision floating point built in type, I
will use long double. Using double for most cases, doesn't imply we
shouldn't talk about long double.


Again the only compiler I know that is broken on this, is MINGW only.

 

[jason.cipriani]

I am not sure I am following you. long double is a standard C++ built in
type, and should work as it should. MINGW's long double is just broken
(or not appropriately implemented to deal with Windows if you prefer).

No, you are not following me. I'm sorry if I was unclear. Here: The
world is not perfect. Many compilers are broken. This is what
programming in C++ is like in reality, and reality is not ideal.
Students should be prepared to deal with reality (there is no need to
confuse students with every detail of reality, but for an issue as
minor as this, again, the explanation is very simple). You will not be
able to fix the brokenness of current compilers, nor will you be able
to force your students to always use compilers that treat it
correctly. Imperfections and broken things are as important an aspect
of C++ (and anything) as the standard itself. If you are teaching C++,
teach the entire thing, not just the ideal parts.

In other words: Yes, it's broken on many compilers. Yes it sucks. Yes,
there are some compilers that it works on. No, you can not change
this. You should consider not hiding that from your students. It's
just the way it is.

Again the only compiler I know that is broken on this, is MINGW only.

Then tell your students that. Is it really that much of a problem to
say "by the way guys, C I/O functions with long doubles are broken on
some current compilers, so watch out"?

You can always choose a non-free alternative, such as Comeau. You can
also use Visual C++, which is free (VS Express editions available for
free from Microsoft site) and I guess is suitable for what you are
doing (no broken printf with long double), or teach with GCC on Linux,
or use any other combination of platform and compiler that does not
have a broken printf(). That should answer your original question.

Jason

 

[InsainFreak101]

I use devc++, it is defiantly not the best ide in the world, but it
gets the job done. you should email bloodshed and tell them about
this flaw and hopefully they will fix it in the next version, if they
haven't already fixed it. but personally, I've never used a long
double.

 

[jason.cipriani]

I use devc++, it is defiantly not the best ide in the world, but it
gets the job done. you should email bloodshed and tell them about
this flaw and hopefully they will fix it in the next version, if they
haven't already fixed it. but personally, I've never used a long
double.

Dev-C++ uses MinGW GCC as it's compiler; Bloodshed isn't responsible
for it. You'd probably want to search for previously filed bug reports
here:

http://gcc.gnu.org/bugs.html

Or, possibly here instead:

http://www.gnu.org/software/libc/bugs.html

As it's a printf() issue not so much a compiler problem.

 

[jason.cipriani]

Dev-C++ uses MinGW GCC as it's compiler; Bloodshed isn't responsible
for it. You'd probably want to search for previously filed bug reports
here:

http://gcc.gnu.org/bugs.html

Or, possibly here instead:

http://www.gnu.org/software/libc/bugs.html

As it's a printf() issue not so much a compiler problem.

I'm sorry, this may not be correct. I should have thought about it
longer before posting. I do not know who is responsible for the
runtime libraries on MinGW -- although I can tell you for a fact it's
not Bloodshed.