entry point of application

[George2]

Hello everyone,


For entry point of a console application,

http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx

My understanding is it is important that the name of the function main
exists, and it does not matter the prototype of main function, for
example,

we can define main as int main () or int main (int argc, char** argv).

Is that understanding correct?


thanks in advance,
George

 

[Alf P. Steinbach]

* George2:

For entry point of a console application,

http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx

Well, judging from what you write below you have misunderstanding: a
program's /entry point/ is not the C or C++ function "main", it's code
that in turn, after doing various things, calls "main". Consider that
e.g. Pascal does not have a "main" function. How to use the Microsoft
linker to specify an entry point is largely off-topic in this group.

My understanding is it is important that the name of the function main
exists, and it does not matter the prototype of main function, for
example,

we can define main as int main () or int main (int argc, char** argv).

Is that understanding correct?

The C++ standard requires a "main" startup function with "int" result type.

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 code. Specifying the entry
point in order to have "main" called is not, however, necessary with
e.g. the GNU toolchain. 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).


Cheers, & hth.,

- Alf

 

[Mike Wahler]

Hello everyone,


For entry point of a console application,

http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx

My understanding is it is important that the name of the function main
exists,
Yes.

and it does not matter the prototype of main function, for
example,

Yes, it does, if you're concerned that the program
in standard-compliant.

we can define main as int main () or int main (int argc, char** argv).

Yes.

Also note that char *argv[] is another way to write the second argument,
preferred by some since its indicative of how argv is used (as an array
of pointers).

Is that understanding correct?

Yes.

-Mike

 

[Bo Persson]

Alf P. Steinbach wrote:
:: * George2:
:::
::: For entry point of a console application,
:::
::: http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx
::
:: Well, judging from what you write below you have misunderstanding:
:: a program's /entry point/ is not the C or C++ function "main",
:: it's code that in turn, after doing various things, calls "main".
:: Consider that e.g. Pascal does not have a "main" function. How to
:: use the Microsoft linker to specify an entry point is largely
:: off-topic in this group.
::
::
::: My understanding is it is important that the name of the function
::: main exists, and it does not matter the prototype of main
::: function, for example,
:::
::: we can define main as int main () or int main (int argc, char**
::: argv).
:::
::: Is that understanding correct?
::
:: The C++ standard requires a "main" startup function with "int"
:: result type.
::
:: 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 code. Specifying the
:: entry point in order to have "main" called is not, however,
:: necessary with
:: e.g. the GNU toolchain. 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).

That's just not the case. If you have a main() function in your code,
it will be called (eventually).

The linker option is used only when you don't want the standard CRT
initialization code called first. It is of course VERY rare that you
do not.



Bo Persson

 

[Alf P. Steinbach]

* Bo Persson:

Alf P. Steinbach wrote:
:: * George2:
:::
::: For entry point of a console application,
:::
::: http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx
::
:: Well, judging from what you write below you have misunderstanding:
:: a program's /entry point/ is not the C or C++ function "main",
:: it's code that in turn, after doing various things, calls "main".
:: Consider that e.g. Pascal does not have a "main" function. How to
:: use the Microsoft linker to specify an entry point is largely
:: off-topic in this group.
::
::
::: My understanding is it is important that the name of the function
::: main exists, and it does not matter the prototype of main
::: function, for example,
:::
::: we can define main as int main () or int main (int argc, char**
::: argv).
:::
::: Is that understanding correct?
::
:: The C++ standard requires a "main" startup function with "int"
:: result type.
::
:: 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 code. Specifying the
:: entry point in order to have "main" called is not, however,
:: necessary with
:: e.g. the GNU toolchain. 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).

That's just not the case. If you have a main() function in your code,
it will be called (eventually).

I'm sorry, but it seems you don't know what you're talking about.

It is possible that Microsoft has fixed the defaults in VC 8, but I
highly doubt it.

The linker option is used only when you don't want the standard CRT
initialization code called first. It is of course VERY rare that you
do not.

No, it's quite common, for all GUI subsystem programs -- but the
details are off-topic in comp.lang.c++, so I'm setting follow-ups.

Cheers, & hth.,

- Alf


Follow-ups set to [comp.os.ms-windows.programmer.win32].

 

[James Kanze]

[...]

The C++ standard requires a "main" startup function with "int"
result type.

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

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

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

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. No
options generally results in something that's barely usable.

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

 

[Alf P. Steinbach]

* James Kanze:

[...]

The C++ standard requires a "main" startup function with "int"
result type.

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

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

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.

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

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.

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

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

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


Cheers,

- Alf

 

[David Harmon]

On Sun, 25 Nov 2007 19:00:44 +0100 in comp.lang.c++, "Alf P.

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

That's different; you are deliberately specifying non-default,
non-standard-complying options.

 

[Alf P. Steinbach]

* David Harmon:

On Sun, 25 Nov 2007 19:00:44 +0100 in comp.lang.c++, "Alf P.


That's different; you are deliberately specifying non-default,
non-standard-complying options.

I'm sorry but that is, as was once remarked, so meaningless that it's
not even wrong.

Windows executable's subsystems have nothing to do with the C++
language, except for the connection Microsoft's tools establish.


Cheers, & hth.,

- Alf

 

[David Harmon]

On Sun, 25 Nov 2007 18:00:18 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* Bo Persson:

I'm sorry, but it seems you don't know what you're talking about.

It is possible that Microsoft has fixed the defaults in VC 8, but I
highly doubt it.

Well, I sure don't know what you are talking about. I routinely get
the standard C++ startup then main() from MSVC without any special
options. Using MSVC 2003, my typical compile for quickies is
cl /EHsc foo.cpp

[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]

 

[David Harmon]

On Sun, 25 Nov 2007 19:21:04 +0100 in comp.lang.c++, "Alf P.

I'm sorry but that is, as was once remarked, so meaningless that it's
not even wrong.

Windows executable's subsystems have nothing to do with the C++
language, except for the connection Microsoft's tools establish.

The thread begins with "For entry point of a console application".
There is no need of any of the nonsense you are talking about for
the entry point of a console application.

If Windows executable's subsystems have nothing to do with the C++
language, then why are you injecting them here? Your reply to the
initial post says nothing about subsystems; it is solely in context
of a console application with a main(), and what you say about MSVC
options therein is wrong. Your later digression into GUI apps is
irrelevant, mostly off-topic, and a feeble attempt to retroactively
cover up your wrong argument. The posted question was entirely
about console applications.

 

[Alf P. Steinbach]

* David Harmon:

On Sun, 25 Nov 2007 18:00:18 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* Bo Persson:
I'm sorry, but it seems you don't know what you're talking about.

It is possible that Microsoft has fixed the defaults in VC 8, but I
highly doubt it.

Well, I sure don't know what you are talking about. I routinely get
the standard C++ startup then main() from MSVC without any special
options. Using MSVC 2003, my typical compile for quickies is
cl /EHsc foo.cpp

[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]

Please see my reply in that "evil" group.


Cheers, & hth.,

- Alf


Follow-ups set again, to [comp.os.ms-windows.programmer.win32].

 

[Alf P. Steinbach]

* David Harmon:

On Sun, 25 Nov 2007 19:21:04 +0100 in comp.lang.c++, "Alf P.


The thread begins with "For entry point of a console application".
There is no need of any of the nonsense you are talking about for
the entry point of a console application.

If Windows executable's subsystems have nothing to do with the C++
language, then why are you injecting them here? Your reply to the
initial post says nothing about subsystems; it is solely in context
of a console application with a main(), and what you say about MSVC
options therein is wrong. Your later digression into GUI apps is
irrelevant, mostly off-topic, and a feeble attempt to retroactively
cover up your wrong argument. The posted question was entirely
about console applications.

I'm sorry but the above is bullshit.

Cheers, & hth.,

- Alf


Follow-ups set to [comp.os.ms-windows.programmer.win32], discussion of
usage of particular platform-specific tools is off-topic in clc++.

 

[David Harmon]

On Sun, 25 Nov 2007 19:45:19 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:

[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]

Please see my reply in that "evil" group.

Nope, not going there. Keep it here.

 

[David Harmon]

On Sun, 25 Nov 2007 19:47:33 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:

I'm sorry but the above is bullshit.

It is not. The thread begins with "For entry point of a console
application". There is no room for you to deny it.

cl /EHsc foo.cpp

It works.

 

[Alf P. Steinbach]

* David Harmon:

On Sun, 25 Nov 2007 19:45:19 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:

[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]

Please see my reply in that "evil" group.

Nope, not going there. Keep it here.

You can get answers in the "evil" group. I've answered these newbie
Win32 questions so many times that eventually I wrote it up, with some
other stuff, as a PDF document for that other "evil" group. See you there.

Cheers, & hth.,

- Alf


Follow-ups set to [comp.os.ms-windows.programmer.win32].

 

[David Harmon]

On Sun, 25 Nov 2007 19:59:10 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:

On Sun, 25 Nov 2007 19:45:19 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:
[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]
Please see my reply in that "evil" group.

Nope, not going there. Keep it here.

You can get answers in the "evil" group. I've answered these newbie
Win32 questions so many times that eventually I wrote it up, with some
other stuff, as a PDF document for that other "evil" group. See you there.

There is no win32 question in this thread, newbie or otherwise. Your
document is probably great for what is, but it's irrelevant here.

The evil isn't about the other group; it's about you trying so
desperately to hijack the thread into an irrelevant digression and
redirect it to a distant newsgroup in order to cover up your
misinformation about compiling a console application.

 

[Alf P. Steinbach]

* David Harmon:

On Sun, 25 Nov 2007 19:59:10 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"

* David Harmon:

On Sun, 25 Nov 2007 19:45:19 +0100 in
comp.os.ms-windows.programmer.win32, "Alf P. Steinbach"
* David Harmon:
[Reposted, after fixing Alf's evil setting of followups to an
irrelevant newsgroup.]
Please see my reply in that "evil" group.
Nope, not going there. Keep it here.

You can get answers in the "evil" group. I've answered these newbie
Win32 questions so many times that eventually I wrote it up, with some
other stuff, as a PDF document for that other "evil" group. See you there.

There is no win32 question in this thread, newbie or otherwise. Your
document is probably great for what is, but it's irrelevant here.

The evil isn't about the other group; it's about you trying so
desperately to hijack the thread into an irrelevant digression and
redirect it to a distant newsgroup in order to cover up your
misinformation about compiling a console application.

It seems you're trolling.

Plink.

- Alf

 

[Chris Thomasson]

Hello everyone,


For entry point of a console application,

http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx

My understanding is it is important that the name of the function main
exists, and it does not matter the prototype of main function, for
example,

we can define main as int main () or int main (int argc, char** argv).

Is that understanding correct?

Yes. However, there are other platform-specific entry functions as well;
Microsoft has _tmain and WinMain, ect...

 

[bob_blaine]

Hello everyone,

For entry point of a console application,

http://msdn2.microsoft.com/en-us/library/f9t8842e(VS.71).aspx

My understanding is it is important that the name of the function main
exists, and it does not matter the prototype of main function, for
example,

we can define main as int main () or int main (int argc, char** argv).

Is that understanding correct?

thanks in advance,
George

George2:

I'm not sure that your original question was answered. I read your
link and it looks like you can redirect the microsoft linker to call a
function different than the main() function prototypes (I didn't
follow the links to the signature definition, but it looked like it
was restricted). Keep in mind that main is not the real entry point as
Alf pointed out -- before the application hits your main it does a lot
of processing, both for OS/GUI stuff and also for pre-main C++ work
like initializing static variables and such, but I'm sure you were not
asking about that.


Cheers and good luck,
Madhacker1000