A free version of C++ on Win (7)??

R

Richard

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <[email protected]> spake the secret code
Well that's highly misleading.

MinGW g++ supports ordinary API level programming, which covers most of
the Windows API.

Based on the number of times I've seen people desperate for help in
getting MinGW working over the years, I don't see the point of trying
to use that and get it to work ("most" of the Windows API?), instead
of just using the free Visual C++ Express Edition and knowing its Just
Going To Work and you will have ALL of the Windows API guaranteed.
It's true that Visual C++ *enables* you to write standard code.

But sometimes you have to work really hard at it. Like, when it
presumably with the best of intentions try to help you by rewriting your
standard-compliant XHTML code [...]

This has nothing to do with C++.
[much whinging about _tmain, stdafx.h, etc.]

Like I said, all this stuff is documented.

The rest of your complaints are straw man arguments.

The question wasn't "what is the best way to TEACH STANDARD C++".
The question was: "Where can I get a free C++ compiler for Windows
programming?".

Visual C++ Express Edition is a perfectly usable answer to the
poster's question.
 
A

Alf P. Steinbach

[Please do not mail me a copy of your followup]

"Alf P. Steinbach"<[email protected]> spake the secret code
Well that's highly misleading.

MinGW g++ supports ordinary API level programming, which covers most of
the Windows API.

Based on the number of times I've seen people desperate for help in
getting MinGW working over the years, I don't see the point of trying
to use that and get it to work ("most" of the Windows API?), instead
of just using the free Visual C++ Express Edition and knowing its Just
Going To Work and you will have ALL of the Windows API guaranteed.
It's true that Visual C++ *enables* you to write standard code.

But sometimes you have to work really hard at it. Like, when it
presumably with the best of intentions try to help you by rewriting your
standard-compliant XHTML code [...]

This has nothing to do with C++.
[much whinging about _tmain, stdafx.h, etc.]

Like I said, all this stuff is documented.

The rest of your complaints are straw man arguments.

The question wasn't "what is the best way to TEACH STANDARD C++".
The question was: "Where can I get a free C++ compiler for Windows
programming?".

Visual C++ Express Edition is a perfectly usable answer to the
poster's question.

I replied to your incorrect assertion that "As for Visual C++ "tricking"
you into using Windows specific items, I'd say that's just disgruntled
*nix fanboy sentiment talking.".

You now chose to snip that from the quotes.

And to also add a false assertion about what I was replying to.

That may be unsmart (not understanding the discussion), or dishonest.

Given your classification of me as a "'nix fanboy" I'd say it's unsmart.


Cheers & hth.,

- Alf
 
R

Richard

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <[email protected]> spake the secret code
I replied to your incorrect assertion that "As for Visual C++ "tricking"
you into using Windows specific items, I'd say that's just disgruntled
*nix fanboy sentiment talking.".

I'd say that statement is still accurate.

You digressed into a complaint about HTML and how the Wizard makes it hard
to TEACH standard C++, neither of which is "tricking" you into using items
that are specific to Windows. As you yourself pointed out, simply say
generate empty project and type everything yourself. This is not as huge
an impediment as you're making it out to be. It's a couple mouse clicks.

Therefore I stand by my original statement.
 
R

Richard

[Please do not mail me a copy of your followup]

Oh, and _tmain and TCHAR generate perfectly compliant standard C++
code when you compile for ANSI and not UNICODE builds. That's the
whole POINT of TCHAR and the _txxx functions.
 
A

Alf P. Steinbach

[Please do not mail me a copy of your followup]

Oh, and _tmain and TCHAR generate perfectly compliant standard C++
code when you compile for ANSI and not UNICODE builds.
Right.

That's the
whole POINT of TCHAR and the _txxx functions.

Wrong.

Cheers & hth.,

- Alf
 
R

Richard

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <[email protected]> spake the secret code

*sigh*

The more you talk, the more you convince me you're just a *nix fanboy
with an axe to grind against MS.

The whole point of TCHAR and the _txxx macros/functions is to make
your code portable to either ANSI or UNICODE builds on Windows. In
the case of _tmain in an ANSI build, it expands to standard C++
signature for main.
 
I

Ian Collins

[Please do not mail me a copy of your followup]

"Alf P. Steinbach"<[email protected]> spake the secret code

*sigh*

The more you talk, the more you convince me you're just a *nix fanboy
with an axe to grind against MS.

The whole point of TCHAR and the _txxx macros/functions is to make
your code portable to either ANSI or UNICODE builds on Windows. In
the case of _tmain in an ANSI build, it expands to standard C++
signature for main.

So the new definition of portable code is "portable to either ANSI or
UNICODE builds on Windows"?
 
R

Richard

[Please do not mail me a copy of your followup]

Ian Collins <[email protected]> spake the secret code
So the new definition of portable code is "portable to either ANSI or
UNICODE builds on Windows"?

Jesus dude, wtf. If you just want to find things to harp on, there's
alt.flame.
 
R

ralph

On Windows perhaps that's true, but in any (free) Unix it's certainly
not -- unless you think anything which isn't one big IDE is a
DIY construction kit.

I intended to take exception to your comment - providing a enumeration
of the many efforts required and the dangers inherent in building a
robust development environment based on Open Source products. However,
the more I think about it - I agree with your opinion of my thoughts.
<g>

A single vendor IDE for any platform makes any collage of tools a
"construction kit", if only by definition.

-ralph
 
A

Alf P. Steinbach

[Please do not mail me a copy of your followup]

Ian Collins<[email protected]> spake the secret code
So the new definition of portable code is "portable to either ANSI or
UNICODE builds on Windows"?

Jesus dude, wtf. If you just want to find things to harp on, there's
alt.flame.


Richard, all you're doing is trying to drown my earlier reply to you --
in noise.

In my experience g++ does not in general support the latest Microsoft
"technologies", whether buzzword or useful. For example, there was a
time when g++ did not support GDI+, which is/was a very useful new
"technology" (essentially added graphics capabilities that had been
lacking for about ten years or so). I think but I'm not sure that GDI+
support has been added to g++ now. Anyway, creating a g++ binding was
quite laborious because Microsoft, unnecessarily, used Visual C++
compiler-specific features and really Bad Practices ,such as using min
and max macros instead of the functions from <algorithm>, in their GDI+
headers. There are two possibilities: unbelievable incompetence, or
intentional attempt to trap users in Microsoft land.

It's true that Visual C++ *enables* you to write standard code.

But sometimes you have to work really hard at it. Like, when it
presumably with the best of intentions try to help you by rewriting your
standard-compliant XHTML code to Microsoft-specific rubble. I remember
how ironic this was when MS released Internet Explorer 7, I think it
was, anyway the version after the long hiatus, the version with better
support for standards. The MS web page about this new version was
perfectly standard-conforming, which caused a lot of really impressed
and positive commentary -- for about 8 hours, when they updated it, and
the MS tools screwed it totally up forever...

When I wrote that novices should be aware of the (intentional or not)
Visual Studio attempts to trap the user in the Microsoft world, I did
not expect any discussion about that, because it is so well known and so
obvious to anyone experienced. So I did not give any examples. But OK,
now's the time.

Let's create a console project in Visual C++ Express 10.0.

We (you) are the teacher or lab assistant, providing instructions to a
novice. You want to /avoid/ that the novice ends up with Visual Studio's
automatically generated console program "starter code". Because that
starter code is not only Microsoft specific but teaches extreme wrongness.

<code>
// first_program_ever.cpp : Defines the entry point for the console
application.
//

#include "stdafx.h"


int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}

</code>

Here the comment at the top is wrong, it's not the "entry point" but
rather the "startup function" (one of the most infamous Microsoft
documentation bugs, still there as far as I know, describes the WinMain
startup function signature as the signature of a program's entry point).

The "stdafx.h" header is not a standard header. It is a header used for
Visual C++ precompiled header technology. Which changes the semantics
such that *standard code* fails to compile, with baffling (to the
novice) "end of file" error messages. There is no advantage to
precompiled headers for a little console program, but lots of
disadvantages, including the non-standard semantics. I.e., when we
discount colossal incompetence as an explanation, it's an attempt to
trap the user in Microsoft-land.

"_tmain" is not a standard startup function name. The standard name is
"main". "_tmain" is in support of Windows 9x. Conceivably whoever
maintained this just forgot about stopping to use that thing after 2001,
when the Layer for Unicode was introduced to deal with the lack of
Unicode support in Windows 9x. But would anyone really believe that they
forgot about that for 10 years? I don't.

Similarly, "_TCHAR" in the argument list is non-standard, and is solely
in support of Windows 9x.

Finally, the "return 0;" is unnecessary, but it is the only thing here
that is not an attempt to unnecessarily trap the user in Microsoft land.

To avoid that entrapment, you have to provide step by step instructions
like those below, ordering the novice to do things in an apparently (to
the novice) needlessly and senselessly complicated way -- which as I see
it, of course is by design, an attempt to trap in Microsoft world.

Step 1.
Run Visual C++ Express by clicking its icon.

In Windows 7 one way I can do this is by typing "visual" in the Start
menu, and selecting the (on my machine) second choice.

Step 2.
Click "New Project", select Windows Console Project, fill in
details

This can look like <url: http://i.imgur.com/4V1bE.png>.

Step 3.
Click OK in "New Project" and ***DO NOT*** click "Next" in the
"Application Wizard" that pops up. Instead click "Application
Settings". This can look like <url: http://i.imgur.com/9ifsE.png>.

Step 4.
In the "Application Settings" page, **FIRST** remove the tick
mark in the "Precompiled Header" box. **THEN** place a tick mark
in the "Empty Project" box. Doing this the opposite order won't
work.

Now you might wonder, at version 10.0 of Visual Studio, as of 2011, is
it likely that there is still such an idiotic bug in one of the most
often used dialogs? Well yes, it is IMHO likely, that it is there *by
design*. That Microsoft rather heavy-handed steers the user towards
using "Precompiled header" at least, which changes the semantics of
ordinary C++ code so that it is no longer standard conforming (wrt.
header inclusion), but instead Microsoft specific, and for standard code
yields baffling error messages about encountering end-of-file.

Step 5.
Click Finish, right click the Source folder in the project, and add
an a new file (you can call it "main.cpp", or anything).

That's a pretty awkward procedure just to avoid the entrapments!

And so it goes, e.g. for COM programming where instead of associating
classes with UUIDs via standard C++ traits or even just a macro namer
thing, a non-standard language extension is used. This language
extension serves no purpose in C, where it would just as well be done
via macros, and in C++ it has no advantages compared to a traits class.
It is solely a device to trap the user in Microsoft land.

And so on.

All of this *can* in principle be avoided, and that's what I wrote.

But it is very much necessary to be aware of it.


Cheers & hth.,

- Alf
 
T

Tobias Müller

Richard said:
*sigh*

The more you talk, the more you convince me you're just a *nix fanboy
with an axe to grind against MS.

The whole point of TCHAR and the _txxx macros/functions is to make
your code portable to either ANSI or UNICODE builds on Windows. In
the case of _tmain in an ANSI build, it expands to standard C++
signature for main.

Exactly, and this means that the code won't compile on any other compiler
unless you
#define TCHAR char
#define _tmain main
which is essentially what VS is doing if you don't
#define UNICODE

It's not really portable but also no trap without escape, since it's really
easy to fix once you change your compiler.

Tobi
 
A

Asger Joergensen

Hi Leigh
Alf you are not just a troll; you are a spam troll as you have now posted the
same off-topic platform specific dross twice in two days. TAKE IT ELSEWHERE.

/Leigh

You are very much contributing Your self, when You don't delete all
those quotes.

Please!

Best regards
Asger-P
 
S

Squeamizh

Alf you are not just a troll; you are a spam troll as you have now
posted the same off-topic platform specific dross twice in two days.
TAKE IT ELSEWHERE.

/Leigh

I have a crazy idea, Leigh. If his posts offend you so much, maybe
you could ignore them?
 
N

Nick Keighley

Le 25/11/11 09:40, Nick Keighley a écrit :

This is the contrary to my experience and the experience of all the
people at work.

Which bit? I've used gcc on Linux it *is* fine. I've had problems in
the past with gcc on Windows. But this was a while ago so it may have
been fixed.
We have a huge C++ program (a database management system) written in
C++ and we run under linux and windows.

Nobody ever develops under linux, the problem is that there, the
only choice you have is the terrible gcc/gdb combination, what
makes any debugging and developing an incredible effort.

what's wrong with gcc? gdb can be wrapped in a GUI based debugger.
I've even used the cli version of gdb and its surprisingly usable.
Under windows we use the C++ IDE above all for the Go To Definition
feature, what saves us HOURS of grepping each week. As you (may)
know, with several dozens of overloaded functions of the same name
it is impossible to know which function will be called unless
you have an exact map of the class structure and template structure
of the application.

yes grep is a bit in adequate for C++. I've used other tools that can
do this and at least one of them runs under Linux. But it costs
money.
Problem is, the application is too big to fit in the head of a single
developer as a whole, nobody unerstand all the details since the
application has been debeloped by the team for over 6 years.

I'm quite familar with this
Many people have left and come, and it is today not possible to debug
a problem without having this feature.

When you develop, the IDE proposes you choices that avoid common
mistaks and allow you to think more into WHAT are you writing rather
than

"Was it SomeCompositeName, someCompositeName or some_composite_name"?

Yes, pedants will start with "Ahhh but you should have enforced
consistent naming conventions" and all that crap that is good in theory
but never found in real programs.

Another problem of gcc is that it generates slower executables than
MSVC, and specially slower than the Intel compiler, the best x86
compiler around.

Under linux, it is impossible to avoid the gcc/gdb combination but using
a windows machine we can still use the "Go to definition" feature
if we run in parallel the gdb debugger and the Visual C++ IDE.

And no, Eclipse is not usable. Written in Java, it chockes at the
hundred thousands of lines of the application.

I've not had a good experience with Eclipse. But this may be me.
 
N

Nick Keighley

[Please do not mail me a copy of your followup]

This is good advice in general.
"W. eWatson"<[email protected]>  spake the secret code
<[email protected]>  thusly:
Get Visual C++ Express Edition.  It's free and has no limitations on
the code that you produce with it (i.e. you can develop commercial
products with it).
Using gcc or other *nix-derived compilers is fine *if* you never intend
to write programs that use the Win32 API or anything other than POSIX
style system interfaces.  Otherwise, its just too much pain and I'd
recommend using the Visual C++ Express Edition instead.

Well that's highly misleading.

MinGW g++ supports ordinary API level programming, which covers most of
the Windows API.

But in my experience g++ does not in general support the latest
Microsoft "technologies", whether buzzword or useful. For example, there
was a time when g++ did not support GDI+, which is/was a very useful new
"technology" (essentially added graphics capabilities that had been
lacking for about ten years or so). I think but I'm not sure that GDI+
support has been added to g++ now. Anyway, creating a g++ binding was
quite laborious because Microsoft, unnecessarily, used Visual C++
compiler-specific features and really Bad Practices ,such as using min
and max macros instead of the functions from <algorithm>, in their GDI+
headers. There are two possibilities: unbelievable incompetence, or
intentional attempt to trap users in Microsoft land.
As for Visual C++ "tricking" you into using Windows specific items,
I'd say that's just disgruntled *nix fanboy sentiment talking.  It
isn't hard at all to write very portable code using Visual C++.  I
have done it for years.  If you don't know what's Windows or Visual
C++ specific in any project template, then read the docs on it.
Everything that is Windows/VC specific is documented as such.
As for the badness of "generated" code, Visual C++ simply recognizes
that each application type has some boilerplate that is the same from
project to project.  Writing a console application?  You're going to
need a main().  And so-on.  The project templates simply save you some
work by generating this boiler plate when you create the project.
There's nothing magic or evil about this code, you can edit it or
delete it to your heart's content.

It's true that Visual C++ *enables* you to write standard code.

But sometimes you have to work really hard at it. Like, when it
presumably with the best of intentions try to help you by rewriting your
standard-compliant XHTML code to Microsoft-specific rubble. I remember
how ironic this was when MS released Internet Explorer 7, I think it
was, anyway the version after the long hiatus, the version with better
support for standards. The MS web page about this new version was
perfectly standard-conforming, which caused a lot of really impressed
and positive commentary -- for about 8 hours, when they updated it, and
the MS tools screwed it totally up forever...

When I wrote that novices should be aware of the (intentional or not)
Visual Studio attempts to trap the user in the Microsoft world, I did
not expect any discussion about that, because it is so well known and so
obvious to anyone experienced. So I did not give any examples. But OK,
now's the time.

Let's create a console project in Visual C++ Express 10.0.

We (you) are the teacher or lab assistant, providing instructions to a
novice. You want to /avoid/ that the novice ends up with Visual Studio's
automatically generated console program "starter code". Because that
starter code is not only Microsoft specific but teaches extreme wrongness..

<code>
// first_program_ever.cpp : Defines the entry point for the console
application.
//

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
        return 0;

}

</code>

Here the comment at the top is wrong, it's not the "entry point" but
rather the "startup function" (one of the most infamous Microsoft
documentation bugs, still there as far as I know, describes the WinMain
startup function signature as the signature of a program's entry point).

The "stdafx.h" header is not a standard header. It is a header used for
Visual C++ precompiled header technology. Which changes the semantics
such that *standard code* fails to compile, with baffling (to the
novice) "end of file" error messages. There is no advantage to
precompiled headers for a little console program, but lots of
disadvantages, including the non-standard semantics. I.e., when we
discount colossal incompetence as an explanation, it's an attempt to
trap the user in Microsoft-land.

"_tmain" is not a standard startup function name. The standard name is
"main". "_tmain" is in support of Windows 9x. Conceivably whoever
maintained this just forgot about stopping to use that thing after 2001,
when the Layer for Unicode was introduced to deal with the lack of
Unicode support in Windows 9x. But would anyone really believe that they
forgot about that for 10 years? I don't.

Similarly, "_TCHAR" in the argument list is non-standard, and is solely
in support of Windows 9x.

Finally, the "return 0;" is unnecessary, but it is the only thing here
that is not an attempt to unnecessarily trap the user in Microsoft land.

To avoid that entrapment, you have to provide step by step instructions
like those below, ordering the novice to do things in an apparently (to
the novice) needlessly and senselessly complicated way -- which as I see
it, of course is by design, an attempt to trap in Microsoft world.

   Step 1.
   Run Visual C++ Express by clicking its icon.

In Windows 7 one way I can do this is by typing "visual" in the Start
menu, and selecting the (on my machine) second choice.

   Step 2.
   Click "New Project", select Windows Console Project, fill in
   details

This can look like <url:http://i.imgur.com/4V1bE.png>.

   Step 3.
   Click OK in "New Project" and ***DO NOT*** click "Next" in the
   "Application Wizard" that pops up. Instead click "Application
   Settings". This can look like <url:http://i.imgur.com/9ifsE.png>.

   Step 4.
   In the "Application Settings" page, **FIRST** remove the tick
   mark in the "Precompiled Header" box. **THEN** place a tick mark
   in the "Empty Project" box. Doing this the opposite order won't
   work.

Now you might wonder, at version 10.0 of Visual Studio, as of 2011, is
it likely that there is still such an idiotic bug in one of the most
often used dialogs? Well yes, it is IMHO likely, that it is there *by
design*. That Microsoft rather heavy-handed steers the user towards
using "Precompiled header" at least, which changes the semantics of
ordinary C++ code so that it is no longer standard conforming (wrt.
header inclusion), but instead Microsoft specific, and for standard code
yields baffling error messages about encountering end-of-file.

   Step 5.
   Click Finish, right click the Source folder in the project, and add
   an a new file (you can call it "main.cpp", or anything).

That's a pretty awkward procedure just to avoid the entrapments!

I've also had to turn of unicode to get the standard libraries to be
supplied. You also have to do some magic to avoid the "security"
warnings for certain standard C functions like strcpy(). But of course
C++ programmers shouldn't be using strcpy()...
 
N

Nick Keighley

[Please do not mail me a copy of your followup]

Oh, and _tmain and TCHAR generate perfectly compliant standard C++
code when you compile for ANSI and not UNICODE builds.  That's the
whole POINT of TCHAR and the _txxx functions.

but your code is now not portable to non-Windows syztems.
 
G

Gert-Jan de Vos

I've also had to turn of unicode to get the standard libraries to be
supplied. You also have to do some magic to avoid the "security"
warnings for certain standard C functions like strcpy(). But of course
C++ programmers shouldn't be using strcpy()...

It shows this warning also when using std::copy().
 
T

Thomas Boell

Le 25/11/11 09:40, Nick Keighley a écrit :

This is the contrary to my experience and the experience of all the
people at work.

We have a huge C++ program (a database management system) written in
C++ and we run under linux and windows.

Nobody ever develops under linux

except lots.

, the problem is that there, the
only choice you have is the terrible gcc/gdb combination, what
makes any debugging and developing an incredible effort.

Under windows we use the C++ IDE above all for the Go To Definition
feature, what saves us HOURS of grepping each week. As you (may)
know, with several dozens of overloaded functions of the same name
it is impossible to know which function will be called unless
you have an exact map of the class structure and template structure
of the application.

CodeLite and Code::Blocks are examples of IDEs which have this feature
and run on Linux.

[...]
When you develop, the IDE proposes you choices that avoid common
mistaks and allow you to think more into WHAT are you writing rather
than

They do auto-completion too.
 
D

Dombo

Op 25-Nov-11 9:40, Nick Keighley schreef:
it just seemed a dumb naming convention. Visula C used to be (may
still be) a different language from C. I suspect Microsoft achieved
dominance of the Window's compiler market by means other than pure
technical excellence.

Technical incompetence of its competitors is one reason (if you have
every used Borland C++ Builder for a non-trival project you know what I
mean).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top