As a newbie to c++, coming from python, I'm not sure why c++ doesn't allow statements outside of a function (in the global namespace?). It seems like this could be useful to do some initialization before main() is called or other functions are even declared. (I'm not trying to argue with the compiler, I'd just like to know the thought process behind implementing it this way.)
When you're running a python program, the interpreter runs through it from top to bottom executing as it goes. In C++, that doesn't happen. The compiler builds all your functions into little blobs of machine code and then the linker hooks them up. At runtime, the operating system calls your main function, and everything goes on from there. In that context, code outside of functions is meaningless - when would it run?
This can be thought of as a style difference between C++ and Python. However, there are pretty good reasons for it too. In C and C++, there is a very clear and specific place that the execution of your code starts from, and that's the beginning of the main() function (of course, this is only an approximation of the truth, but we can ignore that for now.) Actually, a C/C++ program starts and ends with the main() function which - in my opinion - helps quite a lot when you want to understand what a program actually does. The high-level flow of the program is clearer. Contrast this with the alternative; with code scattered all through the file and in between functions and whatnot.
Even in a well-organized and non-trivial Python program, you put your main body of code under an if __name__ == "__main__":, don't you?
Now for some stuff that are a little bit more advanced. There are ways for code to run before the main() function is called. Here's one of them:
#include <iostream>
using namespace std;
bool RunBeforeMain ()
{
cout << "Before main()!" << endl;
return true;
}
// This variable here causes the above function to be called
bool ignore_this_variable = RunBeforeMain ();
int main ()
{
cout << "Start of main()" << endl;
return 0;
}
Also, the constructors of all the global variables and all the static members of classes and some platform-dependent stuff are run before main(). Analogously, there are ways for code to run after the main() is finished. Those are usually the destructors for objects constructed before main() began, and functions registered with the atexit() function.
The main() is the access point to the program. So any code you wanna write would be needs to have an order of execution from that point.
Static variables are initiated before the main() is executed, so you can initiate whatever variables you need before that.
But if you want run code that initiates the state of the program, you should do it just in the beginning of the program, and abuse the static variables and do it some constructor.
Related
I wrote a program that uses a const global variable, and I wonder if it is ok to initialize it by calling a Windows API function on the global scope, outside of any other function, and outside of main() or WinMain(). It goes something like this:
#include "stdafx.h"
#include <iostream>
#include "windows.h"
const int i_HRes = GetSystemMetrics(SM_CXSCREEN);
int main()
{ std::cout << "Horizontal screen resolution: " << i_HRes << std::endl;
std::cin.ignore();
return 0;
}
It compiles and runs without errors, but I wonder if calling an API function on the global scope could cause a problem somewhere down the line in consumer software.
My recommendation is to make the variable accessible, but put the initialization within a function, and use something from the program environment's lifecycle to trigger and initialize when things could be changed. This could be at the beginning of the program, and when the screen resolution is changed. Because it could change, I don't recommend making it constant, either.
However as to making a Windows API call in the global scope, it should be OK from a technical perspective, just make sure you understand WHEN that function is going to be called - during initialization of the program in this case. If you were calling a function that depends on a screen context already being available, or a window being available, it will fail.
In the example you showed, it’s fine. The implicit, compiler-generated code which initialises i_hRes is called in a context where it’s fine to call winapi functions. In general, by the time your program is allowed to do anything, it’s safe to do winapi things.
However, as Raymond mentioned in a comment, that’s specific to the fact that you’re making an executable program. If you were writing a DLL instead, it might be a bad idea to call outside functions.
Intro
Hello! I recently started learning C++. I stopped learning python, because it didn't interest me that much as C++. I am a completely beginner in C++.
Context
My question is that do I need to make a main function for every thing I do?
For example, to print something
#include <iostream>
int main()
{
std::cout <<"Hello World!;
}
So I made it print "Hello World!".
Let's say for something similar do I need to make a new int main()? Or is everything going to be contained inside main()?
Sorry if I made this complicated, every answer is appreciated!
You don't need another main() function.
int main() is the entry point to your program. It is called immediately after initialization of any statically allocated variables.
You should write another function, let's name it add(), and call it from within main(). This lets you split your code up into smaller chunks that are more easily writeable, readable and maintainable.
For example:
We want a program that will print "Hello World!" to the console, then call another function that could print something else.
#include iostream
int main() {
std::cout << "Hello World" << endl; //endl designates the end of a line
printSomethingElse();
}
do i need to make a main function for every thing I do?
No, you do not need to have a main() for everything you do. You just need to have a main() to run your source code.
The main() function is your entry-point into your program in C++; unlike Python which is executed (or run/interpreted) top-down.
For modules like console applications, applications using windows or widgets, dynamic link libraries (Windows) or shared libraries (Linux), you need exactly one main-function. But not for static libraries. Static libraries are linked statically and don't need a main function. They are just collections of functions without a main entry point.
Regards
This question already has answers here:
Is main() really start of a C++ program?
(12 answers)
Closed 4 years ago.
Why main() function run first of all then other functions what if we want another function run first then main function in c or c++.
Can anyone explain logic behind it.thanks.
Because that's what the Standard defines the language to use (C++ quoted here):
[basic.start.main]
A program shall contain a global function called main. Executing a program starts a main thread of execution (...) in which the main function is invoked (...)
So the compiler has to produce the binary in a way that calls main when the program is started by the operating system, or, in case of freestanding environments, when it's loaded.
Technically speaking, it doesn't have to be the first call in the resulting assembly. The compiler can insert some additional startup code (like initializing variables etc.), which can itself be grouped into functions. This is out of concern of a C++ program developer, but becomes quite important on embedded systems, where you need/want to be aware of almost every instruction executed.
A program has to start somewhere... As far as the developer is concerned that's typically main() - referred to as the "entry point".
If you want to do certain things at the beginning of your program, then just move the content of your main() into another function (like run()), and place the startup code in main() before calling run().
#include <stdio.h>
void init(void) {
/* startup */
}
void run(void) {
/* application functionality */
}
int main(void) {
init();
run();
exit 0;
}
As far as the wider system is concerned there is an amount of setup that happens first:
The process needs to be created (e.g: fork())
The stack needs to be prepared
Global variables need to be initialized
etc...
This is because you can create any number of functions in a program. You can have 1 function, 10, 2340 functions, or whatever. The program needs to know where to start. This is the purpose of the main function, as that is always the first function called.
You need to have a place in the program where the execution starts. In C it is function main.
But the program starts executing before the call to the main. That before main code prepares the execution environment for your program and it is called
a startup code.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Does the program execution always start from main in C?
i want to start the execution of my program which contains 2 functions (excluding main)
void check(void)
void execute(void)
i want to start my execution from check(), is it possible in c/c++?
You can do this with a simple wrapper:
int main()
{
check();
}
You can't portably do it in any other way since the standard explicitly specifies main as the program entry point.
EDIT for comment: Don't ever do this. In C++ you could abuse static initialization to have check called before main during static init, but you still can't call main legally from check. You can just have check run first. As noted in a comment this doesn't work in C because it requires constant initializers.
// At file scope.
bool abuse_the_language = (check(), true);
int main()
{
// No op if desired.
}
Various linkers have various options to specify the entry point. Eg. Microsoft linker uses /ENTRY:function:
The /ENTRY option specifies an entry point function as the starting
address for an .exe file or DLL.
GNU's ld uses the -e or ENTRY() in the command file.
Needles to say, modifying the entry point is a very advanced feature which you must absolutely understand how it works. For one, it may cause skipping the loading the standard libraries initialization.
int main()
{
check();
return 0;
}
Calling check from main seems like the most logical solution, but you could still explore using /ENTRY to define another entry point for your application. See here for more info.
You cannot start in something other than main, although there are ways to have some code execute before main.
Putting code in a static initialization block will have the code run prior to main; however, it won't be 100% controllable. while you can be assured it runs prior to main, you cannot specify the order that two static initialization blocks will run prior to them both executing before main.
Linkers and loaders both have the concept of main held as a shared "understood" start of a C / C++ program; however, there is code that runs prior to main. This code is responsible for "setting up the environment" of the program (things like setting up stdin or cin). By putting code in a static initialization block, you effectively say, "hey you need to do this too to have the right environment". Generally, this should be something small, that can stand independently in execution order of other items.
If you need two or three things to execute in order before main, then make them into proper functions and call them at the beginning of main.
There is a contrived way to achieve that, but it is nothing more than a hack.
The idea is to create a static library containing the main function, and make it call your "check" function.
The linker will resolve the symbol when linking against your "program", and your "program" code will indeed not have a main by itself.
This is NOT recommended, unless you have very specific needs (an example that pops to mind is Windows Screensavers, as the helper library that comes with the Windows SDK has a main function that performs specific initialization like parsing the command line).
It may be supportted by the compiler. For example, gcc, you can use -nostartfiles and --entry=xxx to set the entry point of the program. The default entry point is _start, which will call the function main.
You can "intercept" the call to main by creating an object before the main starts. The constructor needs to execute your function.
#include <iostream>
void foo()
{
// do stuff
std::cout<<"exiting from foo" <<std::endl;
}
struct A
{
A(){ foo(); };
};
static A a;
int main()
{
// something
std::cout<<"starting main()" <<std::endl;
}
I have found solution to my own question.
we can simply use
#pragma startup function-name <priority>
#pragma exit function-name <priority>
These two pragmas allow the program to specify function(s) that should be called either upon program startup (before the main function is called), or program exit (just before the program terminates through _exit).
The specified function-name must be a previously declared function taking no arguments and returning void; in other words, it should be declared as:
void func(void);
The optional priority parameter should be an integer in the range 64 to 255. The highest priority is 0. Functions with higher priorities are called first at startup and last at exit. If you don't specify a priority, it defaults to 100.
thanks!
Is there any way a program can crash before main()?
With gcc, you can tag a function with the constructor attribute (which causes the function to be run before main). In the following function, premain will be called before main:
#include <stdio.h>
void premain() __attribute__ ((constructor));
void premain()
{
fputs("premain\n", stdout);
}
int main()
{
fputs("main\n", stdout);
return 0;
}
So, if there is a crashing bug in premain you will crash before main.
Yes, at least under Windows. If the program utilizes DLLs they can be loaded before main() starts. The DllMain functions of those DLLs will be executed before main(). If they encounter an error they could cause the entire process to halt or crash.
The simple answer is: Yes.
More specifically, we can differentiate between two causes for this. I'll call them implementation-dependent and implementation-independent.
The one case that doesn't depend on your environment at all is that of static objects in C++, which was mentioned here. The following code dies before main():
#include <iostream>
class Useless {
public:
Useless() { throw "You can't construct me!"; }
};
static Useless object;
int main() {
std::cout << "This will never be printed" << std::endl;
return 0;
}
More interesting are the platform-dependent causes. Some were mentioned here. One that was mentioned here a couple of times was the usage of dynamically linked libraries (DLLs in windows, SOs in Linux, etc.) - if your OS's loader loads them before main(), they might cause your application do die before main().
A more general version of this cause is talking about all the things your binary's entry point does before calling your entry point(main()). Usually when you build your binary there's a pretty serious block of code that's called when your operating system's loader starts to run your binary, and when it's done it calls your main(). One common thing this code does is initializing the C/C++ standard library. This code can fail for any number of reasons (shortage of any kind of system resource it tries to allocate for one).
One interesting way on for a binary to execute code before main() on windows is using TLS callbacks (google will tell you more about them). This technique is usually found in malware as a basic anti-debugging trick (this trick used to fool ollydbg back then, don't know if it still does).
The point is that your question is actually equivalent to "is there a way that loading a binary would cause user code to execute before the code in main()?", and the answer is hell, yeah!
If you have a C++ program it can initialize variables and objects through functions and constructors before main is entered. A bug in any of these could cause a program to crash.
certainly in c++; static objects with contructors will get called before main - they can die
not sure about c
here is sample
class X
{
public:
X()
{
char *x = 0;
*x = 1;
}
};
X x;
int main()
{
return 0;
}
this will crash before main
Any program that relies on shared objects (DLLs) being loaded before main can fail before main.
Under Linux code in the dynamic linker library (ld-*.so) is run to supply any library dependancies well before main. If any needed libraries are not able to be located, have permissions which don't allow you to access them, aren't normal files, or don't have some symbol that the dynamic linker that linked your program thought that it should have when it linked your program then this can cause failure.
In addition, each library gets to run some code when it is linked. This is mostly because the library may need to link more libraries or may need to run some constructors (even in a C program, the libraries could have some C++ or something else that uses constroctors).
In addition, standard C programs have already created the stdio FILEs stdin, stdout, and stderr. On many systems these can also be closed. This implies that they are also free()ed, which implies that they (and their buffers) were malloc()ed, which can fail. It also suggests that they may have done some other stuff to the file descriptors that those FILE structures represent, which could fail.
Other things that could possibly happen could be if the OS were to mess up setting up the enviromental variables and/or command line arguments that were passed to the program. Code before main is likely to have had to something with this data before calling main.
Lots of things happen before main. Any of them can concievably fail in a fatal way.
I'm not sure, but if you have a global variable like this :
static SomeClass object;
int main(){
return 0;
}
The 'SomeClass' constructor could possibly crash the program before the main being executed.
There are many possibilities.
First, we need to understand what actually goes on before main is executed:
Load of dynamic libraries
Initialization of globals
One some compilers, some functions can be executed explicitly
Now, any of this can cause a crash in several ways:
the usual undefined behavior (dereferencing null pointer, accessing memory you should not...)
an exception thrown > since there is no catch, terminate is called and the program end
It's really annoying of course and possibly hard to debug, and that is why you should refrain from executing code before main as much as possible, and prefer lazy initialization if you can, or explicit initialization within main.
Of course, when it's a DLL failing and you can't modify it, you're in for a world of pain.
Sort of:
http://blog.ksplice.com/2010/03/libc-free-world/
If you compile without standard library, like this:
gcc -nostdlib -o hello hello.c
it won't know how to run main() and will crash.
Global and static objects in a C++ program will have their constructors called before the first statement in main() is executed, so a bug in one of the constructors can cause a crash.
This can't happen in C programs, though.
It depends what you mean by "before main", but if you mean "before any of your code in main is actually executed" then I can think of one example: if you declare a large array as a local variable in main, and the size of this array exceeds the available stack space, then you may well get a stack overflow on entry to main, before the first line of code executes.
A somewhat contrived example would be:
int a = 1;
int b = 0;
int c = a / b;
int main()
{
return 0;
}
It's unlikely that you'd ever do something like this, but if you're doing a lot of macro-magic, it is entirely possible.
class Crash
{
public:
Crash( int* p )
{ *p = 0; }
};
static Crash static_crash( 0 );
void main()
{
}
I had faced the same issue. The root-cause found was.. Too many local variables(huge arrays) were initialized in the main process leading the local variables size exceeding 1.5 mb.
This results in a big jump as the stack pointer is quite large and the OS detects this jump as invalid and crashes the program as it could be malicious.
To debug this.
1. Fire up GDB
2. Add a breakpoint at main
3. disassemble main
4. Check for sub $0xGGGGGGG,%esp
If this GGGGGG value is too high then you will see the same issue as me.
So check the total size of all the local variables in the main.
Sure, if there's a bug in the operating system or the runtime code. C++ is particularly notorious for this behaviour, but it can still happen in C.
You haven't said which platform/libc. In the embedded world there are frequently many things which run before main() - largely to do with platform setup - which can go wrong. (Or indeed if you are using a funky linker script on a regular OS, all bets are off, but I guess that's pretty rare.)
some platform abstraction libraries override (i personally only know of C++ libraries like Qt or ACE, which do this, but maybe some C libraries do something like that aswell) "main", so that they specify a platform-specific main like a int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ); and setup some library stuff, convert the command line args to the normal int argc, char* argv[] and then call the normal int main(int argc, char* argv[])
Of course such libraries could lead to a crash when they did not implement this correctly (maybe cause of malformed command line args).
And for people who dont know about this, this may look like a crash before main
Best suited example to crash a program before main for stackoverflow:
int main() {
char volatile stackoverflow[1000000000] = {0};
return 0;
}