C++ programming migration from DOS to Windows

[Gregg]

I seem to recall that I installed VS7, it asked me what sort of
compatibility mode I wanted. Maybe we made different choices. If you
go to Help, Show Start Page, My Profile, it will show what you chose.
Mine is set to Custom Settings, but one of the keyboard choices is
Visual Studio 6.

It really does work that simply for me. I press Ctrl+N and it shows me
a dialog of different file types. The last one picked is the default.
If I press [enter], I get a blank file of that type, with syntax
highlighting appropriately set.

From experimenting, it is the Visual C++ Developer profile that gives the
simplified Ctrl+N behavior. If you have it set to Visual Studio Developer,
it brings up the new project dialog instead of the new file dialog.

Gregg

 

[Ioannis Vranos]

In VS6 if you want "RAD", you create an MFC application, and select
"CFormView" as the parent class for your view. You then plop down
buttons, edit controls, etc. Attaching code is virtually identical to
doing it in 7.1. For example, attaching code to a button in 7.1
requires double-clicking the button, where 6.0 requires a ctrl-double
click instead. If you're honestly suggesting that pressing or not
pressing the control key while double-clicking is the difference
between RAD and not, so be it, but if that's honestly what RAD means, I
have to admit it's even stupider than I always thought.

Perhaps I am missing something. May you tell how can I view such a RAD
view with drag 'n drop of components in an MFC application project, in
VC++ 7.x?

How in the world does this strike you as easier than MFC? For MFC, I
put the button on a form, do a control-double-click, and it creates a
skeleton handler for the button being pressed, and puts my cursor right
about where I'm likely to want to add some code to do something when
the button is pressed.

Yes double click creates an event handler for the button in .NET too, I
was talking about creating a Form with a Button with an initial text on
it, and not an event handler.

 

[Ioannis Vranos]

Yes double click creates an event handler for the button in .NET too, I
was talking about creating a Form with a Button with an initial text on
it
manually,

and not an event handler.

 

[Jerry Coffin]

Lionel B wrote:

[ ... ]

I think you're being a bit harsh on gcc here. I use the Cygwin port
of gcc for routine programming work in Windows. In particular, over
the last few releases it appears to have improved markedly in terms
of code speed/size optimisation and standards compliance. I can't
speak for VC7 (which is not available on my system) but compared
with VC6 my gcc executables are generally somewhat (but not
drastically) larger and significantly faster. [In fact I cannot
compile most of my code on VC6, mainly because of its horribly
broken template handling].

Well, let's be real here. Nobody (certainly not me) has said much good
about VC++ 6 (the compiler). For its time it wasn't particuarly bad,
but let's face reality: you're comparing "the last few releases" of gcc
to a compiler that's something like 7 or 8 years old. Of course it
doesn't do templates well -- nothing did at that time, and I'm pretty
sure the rules on template handling were changed fairly significantly
after it was published.

OTOH, for speed, as I said, gcc seems to be quite well for some code,
but for the _majority_ of code I've thrown at it, it does relatively
poorly.

Of course, I _probably_ haven't tested with whatever version is
absolutely the newest at this particular moment -- first because its
performance in the past has been so poor, and second, because every new
version of gcc seems to cause major problems.

Community support for gcc (and Cygwin) is IMO excellent - it doesn't
necessarily have to be "on Windows", since gcc is remarkably consistent
across platforms.

Yes, it's platform independent: it works poorly everywhere.

If you're doing GUI programming you'll probably be
using either the "raw" Windows API - which is not compiler-specific -
or perhaps another application framework which will presumably have
its own support (you won't - thankfully - be using the horrendous
MFC).

I'm pretty sure anybody who wants to compile MFC with gcc can probably
do so. In any case, I was thinking more in terms of getting the tools
to do their thing, not the code that gets written -- I rather took it
for granted that anybody here would realize without being told that a
call to CreateWindow (or whatever) isn't affected much by the compiler.
OTOH, gcc users seem to routinely end up in two week-long threads about
how to do things that are dead simple with almost anything else, and
the final conclusion usually seems to be that nobody can get it to do
what it's supposed to.

A further point: if cross-platform portability is an issue (it is for
me), gcc is by far your best (if not only) option.

_Quite_ the contrary. My advice is to go to www.comeaucomputing.com,
and learn about a compiler that's not only cross-platform, but actually
makes a serious attempt at supporting the standard language.

 

[Ioannis Vranos]

OTOH, for speed, as I said, gcc seems to be quite well for some code,
but for the _majority_ of code I've thrown at it, it does relatively
poorly.

I think in Windows platform, MINGW and DJGPP (the last produces 32-bit
DOS executables) perform very well. Have you tried them? If yes, have
you used any optimisation switches?

http://www.mingw.org

http://www.delorie.com/djgpp


Dev-C++ uses MINGW, I suggest you download the latest Beta:

http://www.bloodshed.net

I'm pretty sure anybody who wants to compile MFC with gcc can probably
do so.

All Windows ports of GCC that I know compile only Win32 API, not MFC.

 

[Lionel B]

Lionel B wrote:

[ ... ]

I think you're being a bit harsh on gcc here. I use the Cygwin port
of gcc for routine programming work in Windows. In particular, over
the last few releases it appears to have improved markedly in terms
of code speed/size optimisation and standards compliance. I can't
speak for VC7 (which is not available on my system) but compared
with VC6 my gcc executables are generally somewhat (but not
drastically) larger and significantly faster. [In fact I cannot
compile most of my code on VC6, mainly because of its horribly
broken template handling].

Well, let's be real here. Nobody (certainly not me) has said much good
about VC++ 6 (the compiler). For its time it wasn't particuarly bad,
but let's face reality: you're comparing "the last few releases" of gcc
to a compiler that's something like 7 or 8 years old. Of course it
doesn't do templates well -- nothing did at that time, and I'm pretty
sure the rules on template handling were changed fairly significantly
after it was published.

Fair point.

OTOH, for speed, as I said, gcc seems to be quite well for some code,
but for the _majority_ of code I've thrown at it, it does relatively
poorly.

My experience is the opposite. Most of my code involves heavy
number-crunching rather than GUI stuff - maybe that's relevant.

Of course, I _probably_ haven't tested with whatever version is
absolutely the newest at this particular moment -- first because its
performance in the past has been so poor, and second, because every new
version of gcc seems to cause major problems.

Not for me, it hasn't...

Yes, it's platform independent: it works poorly everywhere.

Again: that's not my experience.

I'm pretty sure anybody who wants to compile MFC with gcc can probably
do so.

I've never seen a working port of MFC to gcc - I guess nobody could be
bothered (who'd use MFC out of choice anyway?).

In any case, I was thinking more in terms of getting the tools
to do their thing, not the code that gets written -- I rather took it
for granted that anybody here would realize without being told that a
call to CreateWindow (or whatever) isn't affected much by the compiler.
OTOH, gcc users seem to routinely end up in two week-long threads about
how to do things that are dead simple with almost anything else, and
the final conclusion usually seems to be that nobody can get it to do
what it's supposed to.

Not my experience - OTOH I have found no particular problems using Win
SDK under gcc and therefore have not had much recourse to community
support.

_Quite_ the contrary. My advice is to go to www.comeaucomputing.com,
and learn about a compiler that's not only cross-platform, but actually
makes a serious attempt at supporting the standard language.

.... as does gcc these days. Still, I have heard good things about
Comeau.

Regards,

 

[Jerry Coffin]

Lionel B wrote:

[ ... ]

My experience is the opposite. Most of my code involves heavy
number-crunching rather than GUI stuff - maybe that's relevant.

Well, since you and Ioannis are so thoroughly conviced of how wonderful
it, is, I downloaded and installed the latest version of MinGW and did
some testing with it.

The good news is that as has been claimed, gcc clearly _is_ better than
the last time I tested it. The less good news is that at least in the
tests I ran, VC++ 7.1 still trounced it pretty thoroughly.

To be more specific: I used a mildly updated version of Joe Orost's
Bench++ 1.1 (mostly for the library being in std::, but I don't believe
I made any changes that should affect the tests themselves).
Unfortunately, gcc produced code that died after 73 of the tests (there
are over 100), and (at least so far) I haven't spent a lot of time
trying to figure out whether the problem is in the compiler or the
code.

In any case, averaging the results from the tests it did complete
showed VC++ 7.1 winning by about a 61% margin overall. For executable
sizes, the MinGW executable was approximately 2.7 times as large.
Depending on the options used, MinGW takes around two to three times as
long to built its slower, much larger executable. As far as heavy-duty
number crunching goes: among other things, the suite contains some NASA
orbit calculation code, which (as you'd probably guess) is about as
pure of heavy-duty number crunching as you can find -- and gcc lost on
this test by a margin of over 7:1.

Though I didn't try to filter the results, looking at the individual
results indicates (at least to me) that for real code VC++ will
typically win by an even wider margin. For example, the benchmark
includes 8 tests of the speed of throwing and catching exceptions, and
gcc won all but one of these, mostly by wide margins (up to 8 times as
fast). While this helps its score a lot, it'll rarely mean anything in
real use.

To address a few questions elsethread: yes, I've used various
optimization switches. In this case, '-O3 -msse' did better than the
others I tried. Given the nubmer of available options, there are
probably some I didn't try at all, and certainly a HUGE number of
combinations I couldn't hope to try in any reasonable length of time --
one run through the benchmarks takes well over an hour, during which I
can't use the machine anything else at all. As far as new versions
breaking compatibility: it's been mentioned in various other threads,
and looking at the gcc web page, they document having broken ABI
compatibility on MIPS, SPARC, ARM, Alpha and PowerPC. A quick test
seems to indicate that between 3.2 and 3.4 it was broken on the x86 as
well.

In case it should arise: yes, I'll be happy to email the sources I used
and the executables from both VC++ 7.1 and MinGW to anybody who wants
them. The executables were both built for Win32 using SSE instructions.
If somebody wants it, a non-SSE version would be pretty easy to do as
well.

[ ... ]

Again: that's not my experience.

Well, about all I can say is that I've virtually every competitor I've
seen is clearly better, but that's based on objective testing, so I
suppose it's no match for unsupported opinions.

[ ... ]

... as does gcc these days. Still, I have heard good things about
Comeau.

Hmm...I'd have _thought_ if they had finally made a serious attempt at
supporting the whole language (e.g. export), it would have been
mentioned on the web page, but perhaps they figure documenting what
they've done would make life too easy for us...

 

[Ioannis Vranos]

Well, since you and Ioannis are so thoroughly conviced of how wonderful
it, is, I downloaded and installed the latest version of MinGW and did
some testing with it.

The good news is that as has been claimed, gcc clearly _is_ better than
the last time I tested it. The less good news is that at least in the
tests I ran, VC++ 7.1 still trounced it pretty thoroughly.

Here are some benchmarks I did a couple of years ago (the last updated
date is a reference link that I added):

http://www23.brinkster.com/noicys/cppfaq.htm

Although I should have used /O2 with VC++ and not /Ox, the difference on
sorting isn't that much.

To be more specific: I used a mildly updated version of Joe Orost's
Bench++ 1.1 (mostly for the library being in std::, but I don't believe
I made any changes that should affect the tests themselves).
Unfortunately, gcc produced code that died after 73 of the tests (there
are over 100), and (at least so far) I haven't spent a lot of time
trying to figure out whether the problem is in the compiler or the
code.

In any case, averaging the results from the tests it did complete
showed VC++ 7.1 winning by about a 61% margin overall. For executable
sizes, the MinGW executable was approximately 2.7 times as large.
Depending on the options used, MinGW takes around two to three times as
long to built its slower, much larger executable. As far as heavy-duty
number crunching goes: among other things, the suite contains some NASA
orbit calculation code, which (as you'd probably guess) is about as
pure of heavy-duty number crunching as you can find -- and gcc lost on
this test by a margin of over 7:1.

I am not sure about these results, but certainly some compiler will
eventually prove better than another in a given time.

That said, GCC is good in standards conformance and efficiency.


Just quickly repeated that benchmark of mine with more recent versions
with the same command line options, and it can give us an idea:


MINGW 3.4.2:

vector<int>/sort() sorting time: 9444 translated in seconds: 9.444

valarray<int>/sort() sorting time: 8563 translated in seconds: 8.563

int */qsort() sorting time: 16854 translated in seconds: 16.854

int */sort() sorting time: 8452 translated in seconds: 8.452


VC++ 2003:

C:\c>temp

vector<int>/sort() sorting time: 9373 translated in seconds: 9.373

valarray<int>/sort() sorting time: 9213 translated in seconds: 9.213

int */qsort() sorting time: 14531 translated in seconds: 14.531

int */sort() sorting time: 9224 translated in seconds: 9.224



Intel C++ 8.1:

vector<int>/sort() sorting time: 13900 translated in seconds: 13.9

valarray<int>/sort() sorting time: 9184 translated in seconds: 9.184

int */qsort() sorting time: 14651 translated in seconds: 14.651

int */sort() sorting time: 9263 translated in seconds: 9.263




I do not see much difference in this among them.

 

[Ioannis Vranos]

Just quickly repeated that benchmark of mine with more recent versions
with the same command line options

and /O2 in VC++ this time,

 

[Rob Williscroft]

Jerry Coffin wrote in @g14g2000cwa.googlegroups.com in comp.lang.c++:

Well, since you and Ioannis are so thoroughly conviced of how wonderful
it, is, I downloaded and installed the latest version of MinGW and did
some testing with it.

I just checked and the current MinGW distro' is 3.4, 3.4 has a new C++
frontend (more conforming) but the same backend as 3.3, the next
version 4.0 will (maybe has on platforms where its available) a new
backend with an improved optimiser (something called tree-ssa IIRC).

You can find a windows (beta) version of 4.0 here:

http://www.thisiscool.com/gcc_mingw.htm#gcj34

AIUI "tree-ssa" is a framework which will allow GCC to catchup
with ms/intel etal, so I wouldn't expect to much of an improvment
yet.

Rob.

 

[Jerry Coffin]

Ioannis Vranos wrote:

[ ... ]

Here are some benchmarks I did a couple of years ago (the last
updated date is a reference link that I added):

http://www23.brinkster.com/noicys/cppfaq.htm

Although I should have used /O2 with VC++ and not /Ox, the difference
on sorting isn't that much.

First of all, I think it's worth noting that all the "work" being
measured in this benchmark is really being done by the standard
library, so the result probably depends at least as much on the
standard library as the compiler per se (e.g. the same compiler with
STLPort would probably produce at least slightly different results).

Second, I'd note that this really only tests sorting, which is common
enough to be worth testing, but provides little indication about how
the compiler will do for lots of other things.

[ ... ]

That said, GCC is good in standards conformance and efficiency.

Keep saying that -- you'll start to believe it eventually. Who knows --
by then it might even be true! Seriously though, "good" is open to
definition. From a practical viewpoint, its conformance is good enough
to compile most conforming code that most people write. OTOH, I don't
think it has a lot better conformance than most other compilers today.

Likewise for efficiency: compiling well-written code with gcc won't
(usually) render it unusuable, or anything like that. Nonetheless, if
you compile it with something else, the result will _probably_ be quite
a bit smaller and at least a little faster.

If gcc was substantially less expensive than the alternatives, using it
would often still make sense -- but at least on Windows, that's just
not the case. You can have legal copies of nearly every compiler for
Windows (gcc, MS, Borland, Digital Mars and Comeau) for a total
investment well under $100US ($50US if you don't count hard drive space
and download costs).

[ ... test results elided ]

I do not see much difference in this among them.

That's not surprising. For its original intent, the test makes sense,
but it really doesn't stress the compiler enough for a better compiler
to distinguish itself. It's a bit like saying an overweight, 50
year-old smoker and an olympic pentathlete to be in nearly the same
condition because they can both walk 50 feet (slowly) without getting
very out of breath.

Re-running your tests, I also get somewhat different results:

c:\c\source>g++ -msse2 -march=pentium4 -O3 bench1.cpp

c:\c\source>a

vector<int>/sort() sorting time: 2531 translated in seconds: 2.531

valarray<int>/sort() sorting time: 2407 translated in seconds: 2.407

int */qsort() sorting time: 5625 translated in seconds: 5.625

int */sort() sorting time: 2406 translated in seconds: 2.406

c:\c\source>cl -O2b2 -G7y -arch:SSE2 bench1.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for
80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

bench1.cpp
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation. All rights reserved.

/out:bench1.exe
bench1.obj

c:\c\source>bench1

vector<int>/sort() sorting time: 2375 translated in seconds: 2.375

valarray<int>/sort() sorting time: 2297 translated in seconds: 2.297

int */qsort() sorting time: 5063 translated in seconds: 5.063

int */sort() sorting time: 2297 translated in seconds: 2.297

Looking at executable sizes, here's what I get (standard library
statically linked in both cases):

MinGW: 480,213
VC++ 7.1: 98,304

Another point: you never seem to tell the compiler what processor to
optimize for, where I've been doing so consistently. Based on the
differences in our results, I'd tentatively guess that MS puts more
effort into processor-specific optimizations, where the gcc team works
more on processor-independent ones. In retrospect, both seem like
fairly obvious choices (for their respective markets), but it's
something I'd never really considered before.

I'd note, however, that at least in MS' case, the default made sense
when it was chosen, but probably doesn't anymore -- by default it
optimizes primarily for the original Pentium. At least IMO, MS should
really update this soon.

Oh -- I almost forgot -- I have the CL environment variable set to
"-GX", so even though it doesn't show up on the command line, exception
handling is enabled for VC++ in every case.

 

[Jerry Coffin]

Rob Williscroft wrote:

[ ... ]

I just checked and the current MinGW distro' is 3.4, 3.4 has a new C++
frontend (more conforming) but the same backend as 3.3, the next
version 4.0 will (maybe has on platforms where its available) a new
backend with an improved optimiser (something called tree-ssa IIRC).

You can find a windows (beta) version of 4.0 here:

http://www.thisiscool.com/gcc_mingw.htm#gcj34

This link doesn't seem to work for me, but did some looking at:

http://gcc.gnu.org/projects/tree-ssa/

AIUI "tree-ssa" is a framework which will allow GCC to catchup
with ms/intel etal, so I wouldn't expect to much of an improvment
yet.

Incremental, long-term improvements won't allow it to catch up --
everybody else is doing the same. Just for an obvious example, VC++
2005 is also in beta testing, and MS claims it frequently improves
generated code by 20% over 7.1.

 

[Rob Williscroft]

Jerry Coffin wrote in @z14g2000cwz.googlegroups.com in comp.lang.c++:

Rob Williscroft wrote:

[ ... ]

I just checked and the current MinGW distro' is 3.4, 3.4 has a new C++
frontend (more conforming) but the same backend as 3.3, the next
version 4.0 will (maybe has on platforms where its available) a new
backend with an improved optimiser (something called tree-ssa IIRC).

You can find a windows (beta) version of 4.0 here:

http://www.thisiscool.com/gcc_mingw.htm#gcj34

This link doesn't seem to work for me, but did some looking at:

http://gcc.gnu.org/projects/tree-ssa/

Just checked it myself and it worked fine.

Incremental, long-term improvements won't allow it to catch up --

That is what they were doing before tree-ssa and you're right they
wern't catching up, but AIUI the whole point of tree-ssa is so that
optimization's are easier (and presumably faster) to implement. IOW
tree-ssa isn't an incremental improvment but a seachange in how GCC
implement there optimiser.

Wether it will catch up or not, only time will tell.

everybody else is doing the same. Just for an obvious example, VC++
2005 is also in beta testing, and MS claims it frequently improves
generated code by 20% over 7.1.

Rob.