Why do I get the errors below when I use the /ENTRY option for the linker in a C++ project?
Question
Answers
-
Oh, and just to cover all bases.
I would suggest you reread [basic.start]. It doesn't say that main has to be the first thing executed. To quote paragraph 1 without all of the references:
"Executing a program starts a main thread of execution in which the main function is invoked, and in which variables of static storage duration might be initialized and destroyed."
Notice how it only states that the main function has to be invoked. There is nothing stating how it gets there. This means that using a function that then calls main is permitted. If you look at the call stack for a Visual C++ application when it gets to main:
Notice how it does eventually invoke main? This conforms to the standard. What's more the rest of the code is used to initialise and destroy globals which is allowed by the standard.
*EDIT*
I just thought of something and it is something that I think is obvious but I just thought that it may not be obvious for everyone.
The /ENTRY doesn't refer to the entrypoint of a specific language. It is an operating system concept which basically defines at what address the executable image will start executing.
The operating system has to be language agnostic. This means that the operating system isn't what initialises things, it calls into the language runtime and this is what does the initialisation. It is this initialisation code that the executable's entrypoint points to. It has to be done this way since only a module is able to properly initialise itself.
This also allows any language to be used in Windows, all you have to do is provide a runtime layer and there you go.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
- Edited by Darran Rowe Wednesday, November 27, 2019 6:44 PM
- Marked as answer by Belloc Thursday, November 28, 2019 5:37 PM
-
Yes, but the entrypoint that you specify must do all the work.
One of the easiest ways is to just get your entrypoint to call the startup code explicitly.
#include <cstdio> #ifdef _DEBUG #pragma comment(lib, "msvcrtd.lib") #else #pragma comment(lib, "msvcrt.lib") #endif extern"C" int mainCRTStartup(); extern"C" int entrypoint() { //call the CRT startup code mainCRTStartup(); return 0; } //you need the function with this name //since the startup code will call it int main() { printf("Hello World!"); return 0; }If you set entrypoint as the entrypoint function using /ENTRY then it will initialise everything properly and call through to main.
However it is important to note that in this case everything will only be initialised in main, and you can't return from main because the C++ runtime will call exit as soon as it leaves main:
// // Initialization is complete; invoke main... // int const main_result = invoke_main(); // // main has returned; exit somehow... // if (!__scrt_is_managed_app()) exit(main_result);This is taken from the startup code. A managed app is defined as a .NET framework application, so anything not built with /CLR will exit with that exit statement.
The invoke_main function just calls the main function for the given settings:
static int __cdecl invoke_main() { return main(__argc, __argv, _get_initial_narrow_environment()); }As an example.
If you wanted to do a more complex setup, the startup code is available in the Visual C++ directory along side the compiler. But obviously this is unsupported and subject to change.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
- Marked as answer by Belloc Thursday, November 28, 2019 5:35 PM
All replies
-
Oh, and just to cover all bases.
I would suggest you reread [basic.start]. It doesn't say that main has to be the first thing executed. To quote paragraph 1 without all of the references:
"Executing a program starts a main thread of execution in which the main function is invoked, and in which variables of static storage duration might be initialized and destroyed."
Notice how it only states that the main function has to be invoked. There is nothing stating how it gets there. This means that using a function that then calls main is permitted. If you look at the call stack for a Visual C++ application when it gets to main:
Notice how it does eventually invoke main? This conforms to the standard. What's more the rest of the code is used to initialise and destroy globals which is allowed by the standard.
*EDIT*
I just thought of something and it is something that I think is obvious but I just thought that it may not be obvious for everyone.
The /ENTRY doesn't refer to the entrypoint of a specific language. It is an operating system concept which basically defines at what address the executable image will start executing.
The operating system has to be language agnostic. This means that the operating system isn't what initialises things, it calls into the language runtime and this is what does the initialisation. It is this initialisation code that the executable's entrypoint points to. It has to be done this way since only a module is able to properly initialise itself.
This also allows any language to be used in Windows, all you have to do is provide a runtime layer and there you go.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
- Edited by Darran Rowe Wednesday, November 27, 2019 6:44 PM
- Marked as answer by Belloc Thursday, November 28, 2019 5:37 PM
-
Yes, but the entrypoint that you specify must do all the work.
One of the easiest ways is to just get your entrypoint to call the startup code explicitly.
#include <cstdio> #ifdef _DEBUG #pragma comment(lib, "msvcrtd.lib") #else #pragma comment(lib, "msvcrt.lib") #endif extern"C" int mainCRTStartup(); extern"C" int entrypoint() { //call the CRT startup code mainCRTStartup(); return 0; } //you need the function with this name //since the startup code will call it int main() { printf("Hello World!"); return 0; }If you set entrypoint as the entrypoint function using /ENTRY then it will initialise everything properly and call through to main.
However it is important to note that in this case everything will only be initialised in main, and you can't return from main because the C++ runtime will call exit as soon as it leaves main:
// // Initialization is complete; invoke main... // int const main_result = invoke_main(); // // main has returned; exit somehow... // if (!__scrt_is_managed_app()) exit(main_result);This is taken from the startup code. A managed app is defined as a .NET framework application, so anything not built with /CLR will exit with that exit statement.
The invoke_main function just calls the main function for the given settings:
static int __cdecl invoke_main() { return main(__argc, __argv, _get_initial_narrow_environment()); }As an example.
If you wanted to do a more complex setup, the startup code is available in the Visual C++ directory along side the compiler. But obviously this is unsupported and subject to change.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
- Marked as answer by Belloc Thursday, November 28, 2019 5:35 PM
