Thread: Global objects and exceptions

Originally Posted by drrngrvy

From reading the other posts on global objects/variables here and elsewhere I don't see myself getting entirely helpful answers here but I've considered the options and I think that in my case there is use for global objects.

There are always uses for conceptually global elements. cin and cout are simple globals. Other things in standard C++ are conceptually global, even if they're not implemented as such. An example is the global locale. It's sort of a hidden global: every default-constructed std::locale object is a copy of the global locale object, and you can replace the global locale by any other locale you have, but you cannot directly access the global locale itself.

There is one thing I don't understand the mechanics of: If an object is global, is it essentially initialized in main() and then passed around secretly by the compiler to every function that needs it or is there some sort of special place in memory that it's placed so it can be just linked in to any reference to it? Is it some other magic?

It's in a special place. Well, not special, but globals have their own space. Usually. Of course, with C++ you never know. However, they're NOT passed around. The compiler simply knows where they are and will reference them directly.

The problem is that if they throw an exception (which they do sometimes), I can't catch them. The only alternatives I can think of are to have global pointers (maybe auto_ptrs to keep them safe) and initialise them in a function which catches relevant exceptions; or to use normal objects, bypass the constructors and call an init() function somewhere.

You cannot bypass constructors. You can of course rewrite the objects to have two-phase initialization, but that's often bad design. The pointer solution (or a similar one, using perhaps boost::scoped_ptr as the most minimalistic pointer that fulfills the requirements, or boost:ptional to avoid the heap allocation - but it has a different problem, namely lack of in-place construction - or even a custom solution using some unmarked space and placement new) might be the best here. But there are a few others.

The thing is, if there are only a select few global objects (such as CGI, User and DBI objects in a single-user web app), surely that's more efficient and allows for cleaner code than passing objects around all over the place?

Yes, but in the specific case you're describing I'm not sure if these objects can justifiably be global.

Let's examine them.
First, there is no such thing as a single-user web app. Every app that tries to be is, in my opinion, conceptually flawed. By programming this way, you're taking a design decision that will eventually haunt you, because it will be so deeply entrenched in the code that you'll never be able to enhance the system without throwing away a lot of code.
So the user object is something that you pass around, or if not pass around, put it in thread-local storage when you enter the request. (That's pretty much what many Java web apps do.)

With CGI, I assume you mean an object that does all the CGI handling. That's not a global object: only a tiny part of your program needs it, namely the frontend, which gathers the data the user sent and finally writes a response. Everything else doesn't care about CGI. Thus, CGI is a member of your UI class. The UI class, in turn, is an object created in your main request handling loop and thus function-local.

With DBI, it's pretty much the same. Only your data layer cares about the database. Thus, the DAO objects all hold a reference to it, and it's created again in the request handling loop.

That's the thing about OOP: you have far fewer global objects than in procedural programming. Usually, you'll have member variables instead.