C++ programming migration from DOS to Windows

[cat_dog_ass]

I am used to programming in DOS mode via Borland C++. I would now like
to create programs for the Windows envirinment. Is it absoultely
necessary to use Visual C++ to do this? Are there other tools that can
help me in doing Windows programming via C++? How am I going to create
drop-down menus and allow my programs to interact with the mouse?

Regards,
Icon

[EventHelix.com]

Visual C++ would still be your best bet for Windows application
programming.
It is a well developed platform with lots of support available on or
off the internet.

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Enter model in plain text;generate sequence diagram in PDF/Word

[SirMike]

EventHelix.com wrote:

Visual C++ would still be your best bet for Windows application
programming.
It is a well developed platform with lots of support available on or
off the internet.

But it's not free ;)

--
SirMike
the code is my strength
http://www.sirmike.grudziadz.com

[Thomas Matthews]

EventHelix.com wrote:

Visual C++ would still be your best bet for Windows application
programming.
It is a well developed platform with lots of support available on or
off the internet.

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Enter model in plain text;generate sequence diagram in PDF/Word

Borland C++ Builder would still be your best bet for Windows
application programming. It is a well developed platform with
lots of support available on and off the internet.

The GNU C++ compiler along with a windowing framework,
such as TK/TQ, and wxWidgets is a well developed and free
platform for windows application programming. There is
not as much support, but then it is free unlike Microsoft
and Borland, which require money for their support (depending
on the need or degree).

There are other compilers and platforms. The "best" for
Windows development is a decision that the OP must make
depending on the OP's needs and abilities.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[skeptical]

On 2 Mar 2005 03:30:11 -0800, "EventHelix.com" <ev********@gmail.com>
wrote:

Visual C++ would still be your best bet for Windows application
programming.
It is a well developed platform with lots of support available on or
off the internet.

The guy said he originally programmed with Borland. Borland has its
own version of visual C++, C# and Java.

The fact is M$ is overrated.

(But hopefully Borland has no visual basic. There ought to be a
law...)

[skeptical]

On Wed, 02 Mar 2005 13:22:58 GMT, Thomas Matthews
<Th*************************@sbcglobal.net> wrote:

EventHelix.com wrote:

Visual C++ would still be your best bet for Windows application
programming.
It is a well developed platform with lots of support available on or
off the internet.

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Enter model in plain text;generate sequence diagram in PDF/Word

Borland C++ Builder would still be your best bet for Windows
application programming. It is a well developed platform with
lots of support available on and off the internet.

The GNU C++ compiler along with a windowing framework,
such as TK/TQ, and wxWidgets is a well developed and free
platform for windows application programming.

Yeah I can just imagine building C++ foundation class dlls, ActiveX
and serialized MDI apps under that shitbox platform.

Umm, let's see. VC++ 6.0 or .NET is less than $100 for standard. Same
with Borland.

If you don't have that chump change go rob somebody...
There is
not as much support, but then it is free unlike Microsoft
and Borland, which require money for their support (depending
on the need or degree).

There are other compilers and platforms. The "best" for
Windows development is a decision that the OP must make
depending on the OP's needs and abilities.

[Tim Slattery]

"cat_dog_ass" <ic*************@hotmail.com> wrote:

I am used to programming in DOS mode via Borland C++. I would now like
to create programs for the Windows envirinment. Is it absoultely
necessary to use Visual C++ to do this? Are there other tools that can
help me in doing Windows programming via C++? How am I going to create
drop-down menus and allow my programs to interact with the mouse?

It's not absolutely necessary to use Visual C++ to write windows
programs, or even to write Windows programs in C++. It is necessary to
interact with the Windows API functions (which, among other things,
allow you to create menus and receive messages from the mouse). VC++,
being a Microsoft product and intended to be used for writing Windows
programs, provides lots of help in doing this. It also provides
Microsoft Foundation Classes (MFC), a C++ class library that wraps
many of the Windows API functions. Of course it also costs money.

For Win32 API information, start here:
http://msdn.microsoft.com/library/de...start_page.asp

You might want to check the microsoft.public.vc.* newsgroup hierarchy
(if your ISP's server doesn't have them, check msnews.microsoft.com.
They will provide you with lots of information about Windows
programming. This newsgroup, which discusses standard C++, will not.

--
Tim Slattery
Sl********@bls.gov

[Jerry Coffin]

cat_dog_ass wrote:

I am used to programming in DOS mode via Borland C++. I would now
like to create programs for the Windows envirinment. Is it
absoultely necessary to use Visual C++ to do this? Are there other
tools that can help me in doing Windows programming via C++? How
am I going to create drop-down menus and allow my programs to
interact with the mouse?

First of all, you'd be much better off asking about this someplace like
comp.os.ms-windows.programmer.win32. There the question is topical, and
a much higher percentage of the participants actually have at least
some clue about the subject matter.

With that said, I hope I'll be forgiven a rather long post that's
mostly only marginally topical. Anybody who's only interested in
topical posts might as well move to the next post now...

No, Visual C++ isn't anywhere close to the only available option.
Depending on your situation, one of the alternatives might be better.

In the last few years, MS has worked very hard on upgrading their
compiler, so the current compiler is quite competitive WRT to
conforming with the C++ standard. OTOH, most of their competition has
been doing the same, the only obvious exception being Comeau, whose
conformance a few years ago was already better than anybody else is
really even trying to accomplish today. MS produces pretty decent
output code as a rule, seeming, in particular, to attempt to provide a
decent balance between size and speed of output.

Borland is still in the market to some extent. As has been the case
nearly forever, their compiler runs fast, but produces relatively poor
code. It has reasonable language conformance, but nothing to get
particular excited about (that's code for "the worst of a good crowd.")

There are a couple of ports of gcc to Windows (cygwin and mingw). IMO,
they're utterly worthless -- they run slowly and typically produce
ridiculously huge executables. Output speed varies over a wide range:
the fastest available for some input code, but other times in close
competition with Borland for the slowest code you can get. I've
frequently seen VC++ produce and executable that was one quarter the
size and 30% faster than gcc did for the same source code. Community
support for gcc on Windows is nearly nonexistent -- most gcc-oriented
newsgroups are oriented primarily toward Linux, and most
Windows-oriented newsgroups assume you use Microsoft. The few people
I've seen who attempt to give advice on using cygwin or mingw seem
mostly lost themselves.

Comeau is more or less unique: the best language conformance you can
get, superb error messages (a feature that's rarely mentioned but
_extremely_ useful, IMO) and no ability to produce machine code itself,
so you have to use it along with some other compiler. Code output
varies with the back-end compiler, but at least part of the time, the
combination does considerably better than the back-end compiler can on
its own.

Intel C++ is probably second only to Comeau for language conformance.
As you'd expect from Intel, its output is typically faster than
anything else available, at least on an Intel chip (its output also
runs on AMD chips, but rarely does so well on them). The penalty for
all this optimization is that the compiler runs quite slowly.

I haven't used Code Warrior recently enough to comment on it much. The
last time I used it, it seemed competitive with Intel for language
conformance, and about on a par with VC++ for compile speed and quality
of output code, but that was quite a while ago.

IDEs: Microsoft and Borland have both produced decent IDEs in the past,
but the current iterations of both are utterly unusable. Borland's IDE
is the least stable program I'd used in at least a decade. Microsoft's
is more dependable, but it's just dependably lousy. Based on the
current pre-release, the next iteration of MS's IDE is a _drastic_
improvement, though still (IMO) inferior to VS 6.0. Intel doesn't have
an IDE of their own, but their compiler can be used with recent MS
IDEs.

There are a couple of free IDEs available for gcc -- the best known is
probably Dev-C++ from bloodshed.net. At least the last time I tested
this, it failed what I consider the bare minimum of usability
requirements -- e.g. it doesn't support regular expressions for search
and replace. OTOH, there are a fair number of people who consider it
excellent, and you might easily like it a lot. It does strike me as
bearing a strong resemblence to Borland's IDEs.

TTBOMK, Comeau is currently usable only from the command line. Code
Warrior includes an IDE, but it's probably changed since I used it last
(though from what I recall, it struck me as reasonable).

Prices: contrary to popular belief, both Borland and VC++ can be
downloaded for free, minus the IDEs -- which are so worthless they're
no loss anyway. If you really want the VC++ IDE, you can get the
"Standard" version for <$100US. The compiler it includes is a
stripped-down version with no optimization, but you can then use it
with the freely-downloaded compiler (which _does_ have optimization) to
get nearly the equivalent of the full "Professional" version for a
fraction of the cost. The Windows version of Comeau (like most other
versions) is only $50 -- an outright bargain, given its quality. The
gcc ports manage the trick of being "free" yet simultaneously the most
expensive compilers you can get.

I won't try to go into how mouse handling and such is done under
Windows -- but I'd advise picking up a copy of _Programming Windows_,
which spends a few hundred pages explaining it quite well. For now,
suffice it to say that the basic orientation of the program is enough
different that it's probably going to take some serious adjustment to
get used to it.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ioannis Vranos]

Thomas Matthews wrote:

Borland C++ Builder would still be your best bet for Windows
application programming. It is a well developed platform with
lots of support available on and off the internet.

Actually as things are so far, it looks like it is discontinued
(unfortunately). Now they provide Delphi .NET and C#, all under one
package named "Delphi".

If you have enough bandwidth you can download the Delphi 2005 trial to
have a look.

You may also check this thread:

http://groups.google.com/groups?hl=e...ing.google.com
The GNU C++ compiler along with a windowing framework,
such as TK/TQ, and wxWidgets is a well developed and free
platform for windows application programming. There is
not as much support, but then it is free unlike Microsoft
and Borland, which require money for their support (depending
on the need or degree).

There are other compilers and platforms. The "best" for
Windows development is a decision that the OP must make
depending on the OP's needs and abilities.

Apart from portable GUIs, what makes sense to invest time for learning
Windows programming is .NET.
The only available IDE supporting .NET is VC++ 2003, however they
provide the compiler (visual studio 2003 toolkit) as a free download.
However since there is the upcoming C++/CLI (due to March) and VS 2005
(due to end of summer), the best approach for someone who is not in an
emergency to learn Windows programming today, is to wait for the 2005
release and invest his time learning some more ISO C++ until then.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Jerry Coffin wrote:

IDEs: Microsoft and Borland have both produced decent IDEs in the past,
but the current iterations of both are utterly unusable. Borland's IDE
is the least stable program I'd used in at least a decade. Microsoft's
is more dependable, but it's just dependably lousy.

Which VC++ version do you have in mind?

Based on the current pre-release, the next iteration of MS's IDE is a _drastic_
improvement, though still (IMO) inferior to VS 6.0.

?! VS 6 had no designer at all. What did you like in VS 6? The
maximize/minimize buttons look about the same with the current release. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Jerry Coffin]

Ioannis Vranos wrote:

Jerry Coffin wrote:

IDEs: Microsoft and Borland have both produced decent IDEs in the
past, but the current iterations of both are utterly unusable.
Borland's IDE is the least stable program I'd used in at least a
decade. Microsoft's is more dependable, but it's just dependably
lousy.
Which VC++ version do you have in mind?

7.x.
Based on the

current pre-release, the next iteration of MS's IDE is a _drastic_
improvement, though still (IMO) inferior to VS 6.0.

?! VS 6 had no designer at all.

I can't really comment until/unless I understand what you're talking
about. If the conversation is going to be very extended, we should
certainly move it elsewhere...
What did you like in VS 6?
The fact that it worked. You could do things quickly and efficiently.
Just to give an example, if I'm looking at a posting with some code in
it and want to compile it, in VS 6 I click on the "new file" button,
paste in the code, click on the "compile button", and it automatically
creates a project for me, prompts me to save the file, and then
compiles the code.

In VS 7, the equivalent of clicking the "new file" button is:
click on "File"
click on "New"
click on "File..."
click on "Visual C++" in the left column
click on "C++ file" in the right column
click on "Open"

All this just to create a blank file! As I recall, convincing the silly
thing to _compile_ the file afterwards is even more difficult (you
can't just click the compile button at all -- you have to do something
like saving the file yourself, then manually create an empty project,
then add that file back into it, or something on that order, but
frankly I'm too lazy to spend the next half-hour working on it just so
I can post what the 17 steps necessary to make it happen.
The
maximize/minimize buttons look about the same with the current
release. :-)

As far as I can see, the only button in the VS 7 IDE that matters at
all is the close button!

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alf P. Steinbach]

* Ioannis Vranos:

?! VS 6 had no designer at all. What did you like in VS 6? The
maximize/minimize buttons look about the same with the current release. :-)

<OT>
One big difference was that DevStudio 6 did not corrupt your source code or
your image resources or your project files, and in general, was not
designed by the Office Assistant "you need some help, obviously" team.
</OT>

Regarding the original question, that's a partial yes: AFAIK only Visual C++
supports GDI+, or put another way, the GDI+ C++ interface is made to
incompatible with C++ so you need the Visual C++ "language" :-).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

Jerry Coffin wrote:

?! VS 6 had no designer at all.

I can't really comment until/unless I understand what you're talking
about. If the conversation is going to be very extended, we should
certainly move it elsewhere...

VC++ 2003 has a RAD, you know, drag and drop components on a form...
The fact that it worked. You could do things quickly and efficiently.
Just to give an example, if I'm looking at a posting with some code in
it and want to compile it, in VS 6 I click on the "new file" button,
paste in the code, click on the "compile button", and it automatically
creates a project for me, prompts me to save the file, and then
compiles the code.

In VS 7, the equivalent of clicking the "new file" button is:
click on "File"
click on "New"
click on "File..."
click on "Visual C++" in the left column
click on "C++ file" in the right column
click on "Open"

Yes the IDE is not suitable for hello world programs (= to learn ISO C++
on it) as 6 was. But on the other hand, 6 is completely broken regarding
ISO C++ conformance since it is old.

All this just to create a blank file! As I recall, convincing the silly
thing to _compile_ the file afterwards is even more difficult (you
can't just click the compile button at all -- you have to do something
like saving the file yourself, then manually create an empty project,
then add that file back into it, or something on that order, but
frankly I'm too lazy to spend the next half-hour working on it just so
I can post what the 17 steps necessary to make it happen.

For this kind of stuff, you should probably use a text editor like
context and configure it to run the VC++ compiler.

The
maximize/minimize buttons look about the same with the current
release. :-)

As far as I can see, the only button in the VS 7 IDE that matters at
all is the close button!

7 was completely lame for .NET programming, since it lacked the
designer. 7.1 shares the same designer with VC# and VB producing C++
code automatically, as the current beta of 2005 (but in 2005 the
components are more nice, flashy or something - .NET 2 styles I suppose).


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Jerry Coffin]

Ioannis Vranos wrote:

Jerry Coffin wrote:

?! VS 6 had no designer at all.
I can't really comment until/unless I understand what you're
talking about. If the conversation is going to be very extended,
we should certainly move it elsewhere...

VC++ 2003 has a RAD, you know, drag and drop components on a form...

I see. And you believe VS 6 didn't do this?

[ ... ]
Yes the IDE is not suitable for hello world programs (= to learn ISO
C++ on it) as 6 was.
VC++ 7.x is _bad_ for small programs, but becomes even _worse_ on
larger ones.
But on the other hand, 6 is completely broken regarding
ISO C++ conformance since it is old.
This is true -- I'm pretty sure I pointed out that the compilers was
upgraded drastically. So far, the combination that gives reasonable
usability and decent conformance is VS 6 with the Intel compiler.
For this kind of stuff, you should probably use a text editor like
context and configure it to run the VC++ compiler.
I disagree -- what I should use is a decently designed IDE. There's
simply no excuse for turning something as simple as creating a file
into a 20-minute ordeal.
7 was completely lame for .NET programming, since it lacked the
designer. 7.1 shares the same designer with VC# and VB producing C++
code automatically, as the current beta of 2005 (but in 2005 the
components are more nice, flashy or something - .NET 2 styles I

suppose).

7 was completely lame (with no qualifications needed). 7.1 certainly
has a better compiler, but the IDE is virtually unchanged.

As far as designing forms goes, VS 6 worked perfectly well, and still
does for that matter. If you're doing something that doesn't fit so
well as a "form" VS 6 also works well, but VS 7.x becomes excruciating.

Just for one example of true stupidity in VS 7.1: you create a typical
MFC application. You want to override OnDraw to draw something in your
window. You have to start by rummaging through its lists of stuff until
you find that it considers OnDraw an Overridable. Then to override it,
you can't just double OnDraw in the list or something like that -- no,
you have to enter the name of the function you're going to overrid it
with. It knows ahead of time that this name _must_ be OnDraw, but you
still have to enter than into a text box anyway.

Then, let's assume that being slightly less than perfect, you override
a function you later find out you didn't really want to override
afterall. You go to try to remove your override. You start by going to
the box where you had to enter its name, and try to delete the name.
For your trouble, you get a message saying "The Message Handler Name
Cannot be Changed".

I'm not ever sure they provide a way to remove an override -- if there
is, I gave up and went back to VS 6 before I found it.

So, it has a text box, but you can only ever use it to enter one
specific piece of text. If you enter text in the wrong box, it not only
doesn't help you to fix your mistake, but does its best to prevent you
from doing so either.

I'd better stop, or the people who've never used it will start to
believe that I must just be making this all up -- that _nobody_ could
seriously have released such a user-hostile piece of garbage. Well, I'm
sorry to say it, but it really is all true.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Gregg]

"Jerry Coffin" <jc*****@taeus.com> wrote in news:1109798241.880578.255950
@z14g2000cwz.googlegroups.com:

The fact that it worked. You could do things quickly and efficiently.
Just to give an example, if I'm looking at a posting with some code in
it and want to compile it, in VS 6 I click on the "new file" button,
paste in the code, click on the "compile button", and it automatically
creates a project for me, prompts me to save the file, and then
compiles the code.

In VS 7, the equivalent of clicking the "new file" button is:
click on "File"
click on "New"
click on "File..."
click on "Visual C++" in the left column
click on "C++ file" in the right column
click on "Open"

All you have to do is Ctrl+N and ENTER. And unlike VC6, the editor knows at
this point that you are editing a .cpp or .h file, and does appropriate
syntax highlighting.

Gregg

[Ioannis Vranos]

Jerry Coffin wrote:

VC++ 2003 has a RAD, you know, drag and drop components on a form...

I see. And you believe VS 6 didn't do this?

VC++ 6 had not any RAD, only VB 6 had one.
I disagree -- what I should use is a decently designed IDE. There's
simply no excuse for turning something as simple as creating a file
into a 20-minute ordeal.

I can agree with that. :-)

7 was completely lame (with no qualifications needed). 7.1 certainly
has a better compiler, but the IDE is virtually unchanged.

In 7.1 the VC++ IDE got a RAD.

Just for one example of true stupidity in VS 7.1: you create a typical
MFC application. You want to override OnDraw to draw something in your
window. You have to start by rummaging through its lists of stuff until
you find that it considers OnDraw an Overridable. Then to override it,
you can't just double OnDraw in the list or something like that -- no,
you have to enter the name of the function you're going to overrid it
with. It knows ahead of time that this name _must_ be OnDraw, but you
still have to enter than into a text box anyway.

Unfortunately I do not know MFC. In fact I had been waiting for .NET to
become available since 2000 (then code-named "Next Generation Windows
Services" - NGWS).
http://hosting.fast-trak.net/tutoria...definition.htm
Then, let's assume that being slightly less than perfect, you override
a function you later find out you didn't really want to override
afterall. You go to try to remove your override. You start by going to
the box where you had to enter its name, and try to delete the name.
For your trouble, you get a message saying "The Message Handler Name
Cannot be Changed".

Well it sounds like a headache. :-) The truth is that I think that the
pre-.NET C++ APIs were not resembling much to C++. I remember some COM
info that I came across, and it was using some strange interfaces with a
strange syntax. But then, C++ became a standard only relatively recently.
I'm not ever sure they provide a way to remove an override -- if there
is, I gave up and went back to VS 6 before I found it.

Well in VC++ 7 since it lacks a designer, you have to do GUI things
manually. But even so it sounds easier than MFC to me. You just do:
__gc class MyForm: public Form
{
Button *pOkButton;

// ...

public:

MyForm()
{
pOkButton= __gc new Button;

pOkButton->Text= "OK";

Controls->Add(pOkButton);
// ...
}
};

MyForm *pMainForm= __gc new MyForm;

Application::Run(pMainForm);
It is straightforward and it looks like C++. __gc means that you deal
with managed (garbage collected) types, so the use of it explicitly
makes things obvious.
The only pain was that you had to find and set the coordinates for the
various components on the form by yourself, as also to set the size of
the components, but I guess you still do it in MFC, and it is is very
high level.

So, it has a text box, but you can only ever use it to enter one
specific piece of text. If you enter text in the wrong box, it not only
doesn't help you to fix your mistake, but does its best to prevent you
from doing so either.

Well the only way I set text in a textbox is like this:
pTextBox->Text= "Some text";

I'd better stop, or the people who've never used it will start to
believe that I must just be making this all up -- that _nobody_ could
seriously have released such a user-hostile piece of garbage. Well, I'm
sorry to say it, but it really is all true.

Perhaps you are right about MFC, I had not that in mind.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Lionel B]

"Jerry Coffin" <jc*****@taeus.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

cat_dog_ass wrote:

I am used to programming in DOS mode via Borland C++. I would now
like to create programs for the Windows envirinment. Is it
absoultely necessary to use Visual C++ to do this? Are there other
tools that can help me in doing Windows programming via C++? How
am I going to create drop-down menus and allow my programs to
interact with the mouse?

/.../

There are a couple of ports of gcc to Windows (cygwin and mingw). IMO,
they're utterly worthless -- they run slowly and typically produce
ridiculously huge executables. Output speed varies over a wide range:
the fastest available for some input code, but other times in close
competition with Borland for the slowest code you can get. I've
frequently seen VC++ produce and executable that was one quarter the
size and 30% faster than gcc did for the same source code. Community
support for gcc on Windows is nearly nonexistent -- most gcc-oriented
newsgroups are oriented primarily toward Linux, and most
Windows-oriented newsgroups assume you use Microsoft. The few people
I've seen who attempt to give advice on using cygwin or mingw seem
mostly lost themselves.

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

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

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

--
Lionel B

[Jerry Coffin]

Ioannis Vranos wrote:

[ ... ]

I see. And you believe VS 6 didn't do this?
VC++ 6 had not any RAD, only VB 6 had one.

Perhaps you should learn what you're talking about before making such
definite statements.

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.

[ ... ]

7 was completely lame (with no qualifications needed). 7.1
certainly has a better compiler, but the IDE is virtually
unchanged.

In 7.1 the VC++ IDE got a RAD.

7.0 had the same sort of crap, just for VB, C# and such. In 7.1 they
added it for their corruption of C++, but the IDE itself doesn't strike
me as significantly different. OTOH, I have to admit that I found both
sufficiently bad that I quit using them fairly quickly, so there may be
differences in the details that I've never gotten around to finding.
Unfortunately I do not know MFC. In fact I had been waiting for .NET to become available since 2000 (then code-named "Next Generation Windows Services" - NGWS).
I'll refrain from an (even further off-topic) rant on the defects in
..NET.
Well in VC++ 7 since it lacks a designer, you have to do GUI things
manually. But even so it sounds easier than MFC to me. You just do:
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.

It sounds to me like you've used VS 6/MFC very little (if at all).

[ ... ]
It is straightforward and it looks like C++.
It's excessively complex, and bears only a superficial and misleading
resemblence to C++.
The only pain was that you had to find and set the coordinates for
the various components on the form by yourself, as also to set the
size of the components, but I guess you still do it in MFC, and it
is is very high level.
You guess wrong. You _can_ explicitly specify sizes and positions of
controls if you _want_ to with MFC, but if you're designing a form,
there's rarely much reason to do so. I'm pretty sure I don't remember
the last time I did such a thing anyway.

[ ... ]
Well the only way I set text in a textbox is like this:

pTextBox->Text= "Some text";

I'm not talking about in my code. I'm talking about in the IDE,
specifically in its "properties" window. It has all the "overridables"
for your form. If you want to override one, you have to put in the name
of the overriding function -- but this has to precisely match the name
of the function being overridden, so you can only ever enter one piece
of text there.

To their (minimal) credit, they do include a drop-down that lets you
select "add <function_name>" and it enters the text for you. While
better than nothing, this is still exceptionally poor GUI design --
first of all, what it holds isn't really a piece of data, but something
that acts like a button. Second, it's wasteful -- the space taken by
the drop-down list could easily hold the buttons directly. Third, it's
inefficient -- to add the item, you either type in its name (perfectly)
or else click the drop-down, then select the "add <whatever>" item (at
that point, the only item in the list) and finally get to start editing
your code.

Also looking more carefully, once you've added the handler, it turns
out there IS a way to remove it -- but you can't do it directly -- you
have to select the "delete" item from the drop-down list.

I'm reasonably certain the person who did this did NOT really think
about using it. Rather, s/he had this cool list that held actions
instead of data, and decide to use it, mostly just because it was new
where buttons were old and boring (and functional).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

Gregg wrote:

[ creating a file in VS 7.x ]

All you have to do is Ctrl+N and ENTER.
I just tried this. All I got for my trouble was a message box saying
"you must enter a valid file name".

I'm sure it's programmable enough that it did work this way (and there
may be a setting to make it work that way without programming) but it
doesn't seem to be at all certain that this is "all you have to do".
And unlike VC6, the editor knows at
this point that you are editing a .cpp or .h file, and does
appropriate syntax highlighting.

For me, at that point I'm back exactly where I started, with no
awareness of the file type, but there's no file of which it can be
aware.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Gregg]

"Jerry Coffin" <jc*****@taeus.com> wrote in news:1109903750.675666.36630
@f14g2000cwb.googlegroups.com:

I just tried this. All I got for my trouble was a message box saying
"you must enter a valid file name".

I'm sure it's programmable enough that it did work this way (and there
may be a setting to make it work that way without programming) but it
doesn't seem to be at all certain that this is "all you have to do".

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.

Gregg

[Gregg]

Gregg <gr***@invalid.invalid> wrote in
news:Xn*********************************@68.1.17.6 :

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]

Jerry Coffin wrote:

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

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ioannis Vranos]

Jerry Coffin wrote:

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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Lionel B]

"Jerry Coffin" <jc*****@taeus.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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

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.

Again: that's not my experience.

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.

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.

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.

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

Regards,

--
Lionel B

[Jerry Coffin]

Lionel B wrote:

[ ... ]

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.

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.

[ ... ]

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

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.

[ ... ]

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.

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ioannis Vranos]

Jerry Coffin wrote:

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

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

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

and /O2 in VC++ this time,
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

http://www23.brinkster.com/noicys

[Rob Williscroft]

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

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.

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.
--
http://www.victim-prime.dsl.pipex.com/

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Rob Williscroft]

Jerry Coffin wrote in news:1110133501.243785.77830
@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.

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

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.
--
http://www.victim-prime.dsl.pipex.com/