Global objects and exceptions

This is a discussion on Global objects and exceptions within the C++ Programming forums, part of the General Programming Boards category; From reading the other posts on global objects/variables here and elsewhere I don't see myself getting entirely helpful answers here ...

  1. #1
    Registered User
    Join Date
    Oct 2005
    Posts
    88

    Global objects and exceptions

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

    The main question, though, is just say for argument's sake that I had global variables and couldn't do anything about them. Ideally I wanted the constructors to work like they should and set up the class completely. 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.

    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?

    Sorry if this all seems a bit random/uninformed but I'm still pretty new to this. Any help would be appreciated.

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Quote 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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Exceptions that should terminate. Really.
    By Mario F. in forum C++ Programming
    Replies: 7
    Last Post: 06-26-2007, 10:56 AM
  2. Long-lasting objects that throw exceptions
    By drrngrvy in forum C++ Programming
    Replies: 7
    Last Post: 10-05-2006, 04:30 PM
  3. Collision detection algorithm
    By Hannwaas in forum Game Programming
    Replies: 5
    Last Post: 11-30-2001, 12:27 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21