main is not the first function

Say I create a global object of a class. The constructor of this class does every thing.
Initializing. Performing operations. Everything needed. And then exit(0)s.

Is it okay? Recommended? or bad? very bad? or hardly matters!

For example:

Code:

---

#include <iostream>
#include <string>
#include <ctime>
#include <cstdlib>
using namespace std;

class foo
{
public:
        foo()
        {
                cout << "Your name please: ";
                string name;
                getline(cin, name);
       
                time_t now;
                time(&now);
                tm* tm = localtime(&now);
                string salute = "";
                if (tm->tm_hour < 12)
                {
                        salute = "Morning";
                }
                else if (tm->tm_hour < 15)
                {
                        salute = "Afternoon";
                }
                else
                {
                        salute = "Evening";
                }

                cout << endl << "Good " << salute << " " << name << " !" << endl;
                exit(0);
        }
};

foo foo;

int main()
{
        cout << "Eeek killed before entering me!" << endl;
        return 0;
}

---

Why do you want to do this, and what's the point of doing this?

VERY VERY BAD!

Why do you want to do things that way? main() is where your program starts, everything before that should be "irrellevant".

Global objects (or global variables) in themselves is not a "good" thing.

If you have global objects, the constructor should be kept to a minimum.

Note also that there's no guarantee about the order of execution of constructors if you create a second global object - so:

Code:

---

class A { A() { }; ... } ;
class B { B() {}; ... };

A a;
B b;

---

Logically, a.A() will be called first, but I beleive there is no guarantee that this is the case.

More importantly, if you put your

Code:

---

B b;

---

in a different source file, it's absolutely uncertain which constructor gets called first - for example, it may depend on the order that the object files are listed to the linker, or alphabetical order of filenames, or some other random order.

--
Mats

I remember my old C days. To figure out a program I would start from the main.
It was a definite start point. Everything would follow thereafter.
But in C++ it is not required at all. And if there are global objects here or there, then you may
not be starting from the start. If you start at main?

Don't put any code other than initialization (and keep that code to the specific object only!) in global object constructors.
Start from main and work your way from there.

Quote:

---

Originally Posted by manav

I remember my old C days. To figure out a program I would start from the main.
It was a definite start point. Everything would follow thereafter.
But in C++ it is not required at all. And if there are global objects here or there, then you may
not be starting from the start. If you start at main?

---

Yes, of course, there is, as you have shown, a technical possibility to create something where large amounts of code is executed before the first statement in main() [1]. There is of course, if you like to do things that way, also the possibility of re-writing the C runtime startup code so that it doesn't call main, but some other function first.

[1] At least in gcc, the construction of global objects is actually done as part of main - but it's done BEFORE the code you have supplied in main happens.

--
Mats

Quote:

---

Originally Posted by manav

Say I create a global object of a class. The constructor of this class does every thing.
Initializing. Performing operations. Everything needed. And then exit(0)s.

---

Interesting. I'm not sure if a call to exit() prior to invoking main() is a defined operation or not. I would expect that the standard library is already fully initialized by the time that global constructors begin running, but I'm not sure what the standard says about calling exit().

Quote:

---

Is it okay? Recommended? or bad? very bad? or hardly matters!

---

Global objects on the whole are "not recommended" but in some cases are unavoidable. I would suggest NOT performing complex operations in the constructors of global objects, though.

Quote:

---

Originally Posted by brewbuck

Interesting. I'm not sure if a call to exit() prior to invoking main() is a defined operation or not. I would expect that the standard library is already fully initialized by the time that global constructors begin running, but I'm not sure what the standard says about calling exit().

---

The only implementation I've looked into is g++'s constructor calls, and those are, for global objects, made by "main" itself, inserted between the entry of main itself and the "first code in main" [by calling ___main from _main in assembler].

I tried to prove this, but I wasn't able to call printf() from my constructor, so I couldn't get the dump of the stack working at all... Will look again tomorrow, perhaps.

--
Mats

Honestly, if you're doing globally accessible objects, I'd recommend you use the Singleton pattern and lazy instantiation. Then the constructor doesn't happen before main() at all.

Of course, this assumes there's a good reason to have this object globally accessible in the first place. Sometimes this makes a lot of sense, and that's what Singleton is for, but often it's a poor hack to make poorly designed code work.

Oh and if you're doing globally accessible objects but DON'T want the uniqueness imposed by Singleton (that is, you want multiple instances of the class, with one instance global) this is a very strong sign you're writing bad code.

Quote:

---

Originally Posted by matsp

Note also that there's no guarantee about the order of execution of constructors if you create a second global object - so:

---

Dynamic initializations in any given source file are executed in the order they appear. That's guaranteed. It's only inter-module order that isn't specified.

Bad enough, though.