Re: entry point of application
On Nov 25, 7:00 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Nov 25, 4:33 pm, "Alf P. Steinbach" <al...@start.no> wrote:
The C++ standard requires a "main" startup function with "int"
The two signatures you show above must be supported.
With Microsoft tools you may indeed have to use the linker
option you referred to above, in order to correctly have the
standard "main" startup function called by the entry point
Are you sure of this. I've only used VC++ for small, test
programs, but I've all of them have a fully standard main(), and
I'm not aware of having used any special compiler options to
make them link. (I have needed special options to get them to
compile C++. Including the standard library headers. But as
far as I know, things like /GR /Ehs /vmg or whatever don't
affect the linker.)
Yes, I'm sure.
I think your experience is due to mostly writing server-like
Not on Windows. All I've written on Windows are small test
programs. No servers, no GUI's, no nothing significant.
When you specify GUI subsystem (no automatic console window) the
Microsoft tools default to a different entry point that doesn't call
"main" but "WinMain". GNU tools are smart enough to pick the startup
function you provide. Microsoft's tools are not.
When you write a GUI, you're often in another world. WxWidgets
takes over main as well, or does something similar, from what I
can see. (But again, I've not much experience with it, so I've
probably missed something.)
I don't know why this should be. It seems like poor design to
me. I suspect that it dates back from the days of single
threaded code, when the windowing code had to manage the main
loop in order to catch all of its events. There's no excuse for
it in a modern, threaded system. But it is.
Specifying the entry point in order to have "main" called is
not, however, necessary with e.g. the GNU toolchain.
But you still need -std=c++98 if you want a C++ compiler:-).
(Admittedly, the differences are several orders of magnitude
less than if you forget /GR /Ehs /vmg when compiling with
Well yes, sort of relevant. I didn't mention the
corresponding option for VC++ because with that option it
fails to compile Microsoft's own headers. Or at least used
to, I haven't checked lately. :-)
I've found just the opposite (with my small tests, using VC++
8). If you fail to specify /Ehs, for example, you'll get tons
of errors from Microsoft's own standard headers. From my
limited experience, if you want to compile without any options,
you can't use any of the standard C++ library---which for my
small tests programs means no I/O, no arrays (std::vector), and
no character strings.
It is unfortunate that a major compiler vendor still as of
late 2007 hasn't managed to correctly implement a feature from
1972 (going back to original C) so that you have to use linker
options, but then, that compiler defaults to non-standard
behavior also in many other respects: you have to use a load
of options to get standard-conforming mode (exceptions, RTTI,
for-loop scope, wchar_t).
Regretfully, that's the case for almost all compilers.
I think by "that" you're referring to the bunch of options I
listed in addition to specifying entry point.
I'm referring to a bunch of options, in general. If we're
talking about production code, no compiler works without some
options. In many ways, it couldn't: what you need for your
production code is likely different than what I need.
Well I have only limited experience with current C++
compilers, but at least with g++ you don't have to specify
that basic functionality such as "main", exceptions, RTTI,
for-loop scope and built-in wchar_t, should be supported.
It's one thing to have to up warning levels or say hey, I want
some extensions, it's quite another thing to have specify in
detail to a C++ compiler the various aspects of the standard
C++ language that you want supported.
Agreed. It's frustrating that "cl hello.cc" won't even compiler
the classical hello world program (which for C++ uses iostream,
and won't compile without /Ehs, and maybe some others). But the
problem is really limited to just those small test programs,
when you want to see how the compiler handles such and such a
construct. For your production code, one option more or less
doesn't matter (and of course, you'll have carefully gone
through the compiler documentation, and considered the relevance
of each option, regardless).
And for those unfortunate newbies using that compiler via its
associated IDE, to have to turn off features such as
Microsoft's precompiled headers that cause non-standard
There could be a problem with the IDE, and with newbies. Since
I don't use the IDE, I couldn't say, but from what I've heard,
the "defaults" aren't really appropriate for newbies (and of
course, it will only be newbies who use the defaults).
No options generally results in something that's barely usable.
Yes, no disagreement there!
And of course, you don't always want 100% standard-conformance.
(My professional code makes extensive use of sockets, threads
and a couple of other non-standard features.)
I have no experience with language extensions for sockets. Do
they really exist?
They're library extensions, of course, but they're certainly not
part of the C++ standard.
Anyways, having to add in language extensions, or turn them
off, is as mentioned quite different from having to specify in
detail the aspects of the C++ language that you want
I don't know the situation with regards to the IDE, since my use
of VC++ (to date) has been limited to trying to compile code
which already worked under Solaris or Linux, from the command
line of a Unix like shell (or from GNU make). I don't think I'm
a typical user, and while I am a newbie with regards to Windows,
I sort of doubt that I'm a typical newbie even there.
My point was only that I do write code which uses main(), that
compiles without any special options to tell the compiler that
main() is the entry point. Although I do need other options
(which for very simple things, such as testing answers to
questions here, I don't need with g++ or Sun CC).
James Kanze (GABI Software) email:firstname.lastname@example.org
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34