[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
