Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++03 IDE+compiler for Windows / educational purposes

Reply
Thread Tools

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

 
 
John Brawley
Guest
Posts: n/a
 
      02-21-2008

"Richard Herring" <junk@[127.0.0.1]> wrote in message
news:(E-Mail Removed)...
> In message <fpjlkm$ngu$(E-Mail Removed)>, Ioannis Vranos
> <(E-Mail Removed)> writes
> >(E-Mail Removed) wrote:
> >> 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.
> >

> 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.
>
> >
> >This isn't good for the credibility of C++, caused by a bad compiler.

> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
Web: http://tetrahedraverse.com


Now


 
Reply With Quote
 
 
 
 
Ioannis Vranos
Guest
Posts: n/a
 
      02-21-2008
(E-Mail Removed) wrote:
>
>> 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.



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".
 
Reply With Quote
 
 
 
 
Hendrik Sattler
Guest
Posts: n/a
 
      02-21-2008
Ioannis Vranos wrote:

> 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

 
Reply With Quote
 
jason.cipriani@gmail.com
Guest
Posts: n/a
 
      02-21-2008
On Feb 21, 2:35 pm, Ioannis Vranos <(E-Mail Removed)>
wrote:
> (E-Mail 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.

>
> 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".


 
Reply With Quote
 
jason.cipriani@gmail.com
Guest
Posts: n/a
 
      02-21-2008
On Feb 21, 3:43 pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> >[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.
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      02-21-2008
(E-Mail 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.



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
11897314953572317650212638530309702051690633222946 24200440323733891737005522970722616410290336528882 85354569780749557731442744315367028843419812557385 37436786735932007069732632019159182829615243655295 10646791086614311790632169778838896134786560600399 14875343321145491116008867984515486651285234014977 30376000091254793939662231513836224178385427439178 38138717805889487540575168226347659235576974805113 72564902088485522249479139937758502601177354918009 97962260268595085588836081598469002356451323465944 76384939859276456284579661772930407806609229102715 04608538808795932778162298682754783076808004015069 49423034117289577771003357140105597752421240573470 07386251660110828379119623008469277200965153500208 47447079244384854591288672300061908512647211195136 14675276335195629275979572502780029807959041931396 03021470997035276467445530922022679656280991498232 08332964124103850923918473478612192169721054348428 70483534081130425730022164213489173471742348007148 8075100206439051723424765600472176809648
61079949434157034763206435586242074435044243805661 36017608837478165389027809576975977286860071487028 28795556714140463261583262360276289631617397848425 44868606099482708679680480787025118589308385465842 23040908805996294594586201903766048446790926002225 41053077590106576067134720012584640695703025713896 09837579989269545530523685607586831792231136395194 68850880771872104705203957587480013143131444254943 91994017575316933939236688185618912993172910425292 12368351599223220509980016771027840353601408292963 98115122877768135706045789343535451696539561254048 84644716978689321167108722908808277835051822885764 60622187397028516550837209923494833344352289847512 32753726636066213902281264706234075352071724058665 07951821730346378263135339370677490195019784169044 18247380631628285868577414325811653640402184027249 13393320949219498422442730427019873044536620350262 38695780468200360144729199712309553005720614186697 48528468561865148327159744812031219467516863793430 9618961510733006555242148519520176285859
50910518394725028638716324941676138049963197914418 70254302706758495192008837915169401581740046711477 87720145964446117520405945350476472180797576111172 08462736392796003396704700376133745095531841500737 96412605047923251661354841291884211340823015473304 75406707281876350361733290800595189632520707167390 45477771296822652062256514399193768044002923809031 12437912614776255964694221981375146967079446870358 00439250765945161837981185939204954403611491531078 22510726914869798092409467721427270124043771874092 16756613634938900451232351668146089322400697993176 01780533819184998193300841098599393876029260139091 14145260037202848721324119554242821018312042161044 67404621635336900583664606591156298764745525068145 00393294140413149540067760295100596225302282300363 14738246810596484424413248645731374375950964161680 48024129351876204668135636877532814675538798871771 83651289394719533506188500326760735438867336800207 43878496570145760903498575712430451020387304948542 5670247933932280911052604153852899484920
39910919461299124916332899179980943803378795220931 31466946149705939664152375949285890960489916121944 98998638483702248667224914892467841020618336462741 69695763076324802355879752452537370354338829608627 53427740016333434055083537048507374544819754722228 97528108302089868263302028525992308416805453968791 14182976299889645764827652875045628549242651652177 50799516259669229114977788962356670956627138482018 19134832168799586365263762097828507009933729439678 46398790249145142227425270063639423279984839767399 87154418554201562244154926653014515504685489258620 27608576183712976335876121538256512963353814166394 95165560002641591865548500570526114319529199188079 54522394649627635630178580896692226406235382898535 86759599064700838568712381032959192649484625076899 22584193054807636202150890221492205280698420183508 40586938493815498909445461977893029113576516775406 23227829831403347327660395223160342282471752818181 88443048809213219335508698733958612760736708666523 7555567580317149010847732009642431878007
00087973460329062789435537435644488519071916164551 41155761939399690767415156402826543664026760095087 52394550734155613586793306603174472092444651353236 66476497354008519670407711036405381500734868917983 64049570606189535005089840913826869535090066783324 47257871219660441528492484004185093281190896363417 57398971665960007594878006191640948543387585206571 16541072260996288150123144377944008749301944744330 78438899570184271000480830501217712356062289507626 90428568000477188931580893585155938631766529480890 31267747029662545110861548958395087796755464137944 89596052797520987481383976257859210575628440175934 93241621483395653501891968113890918437957347032694 06342890087805846940352453479398080674273236297887 10086717580253156130235606487870925986528841635097 25295370911143172048877474055390540094253754241193 17944175137064689643861517718849867010341532542385 91108962471088538580868883777725864856414593426212 10866475884892600317623459607695088491496624441566 04419552086811989770240.000000

[john@localhost src]$



and under Visual C++ 2008 Express Edition:

1.79769e+308
17976931348623157000000000000000000000000000000000 000000000000000000000000000000
00000000000000000000000000000000000000000000000000 000000000000000000000000000000
00000000000000000000000000000000000000000000000000 000000000000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000.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.
 
Reply With Quote
 
jason.cipriani@gmail.com
Guest
Posts: n/a
 
      02-21-2008
"Ioannis Vranos" <(E-Mail Removed)> wrote in message
news:fpksqj$1i9c$(E-Mail Removed)...
> 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
 
Reply With Quote
 
InsainFreak101@gmail.com
Guest
Posts: n/a
 
      02-22-2008

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.
 
Reply With Quote
 
jason.cipriani@gmail.com
Guest
Posts: n/a
 
      02-22-2008
On Feb 21, 10:04 pm, (E-Mail Removed) wrote:
> 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.
 
Reply With Quote
 
jason.cipriani@gmail.com
Guest
Posts: n/a
 
      02-22-2008
On Feb 22, 12:04 am, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: C90 IDE+compiler for Windows / educational purposes Ioannis Vranos C Programming 57 02-22-2008 08:25 PM
[OT] C90 IDE+compiler for Windows / educational purposes Ioannis Vranos C Programming 35 02-07-2008 09:14 PM
NOTE: For educational purposes only Mhzjunkie Computer Support 1 07-07-2007 06:28 PM
[Q] Ruby for educational purposes and localization Laurent Julliard Ruby 7 05-23-2004 06:04 PM
Educational or Experience Requirements Roy MCSD 6 03-07-2004 11:15 PM



Advertisments