Hi,

As I progress in my understanding of C++, I come closer to the 
inevitable conclusion that in order to make my code more efficient and 
easy to alter, I need to learn more about classes and structs. Simple 
concepts, but the problem comes with implementing said features.

A simple (tile based) level editor is my current project. Already, I 
have about two dozen global variables. It's getting messy, and I'm 
having to rewrite code to handle, say, foreground tile editing as 
opposed to background tile editing.

Does anyone have a link to some good tutorials to help me manage this 
ever-growing pile of data? I need to encapsulate everything. I'd like to 
rid myself of global variables entirely, if that's possible. Thanks~

Sam

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> A simple (tile based) level editor is my current project. Already, I 
> have about two dozen global variables. It's getting messy, and I'm 
> having to rewrite code to handle, say, foreground tile editing as 
> opposed to background tile editing.

  High-quality object-oriented design is far, far from trivial to do.
It requires years of OOD and OO programming experience, and even then
it usually requires several iterations of design-use-redesign.

  Making a good, encapsulated, abstract, flexible and reusable graphical
editor is a rather difficult tasks of OOD in general (regardless of the
programming language used) and C++ programming in particular. I know this
because I have been working on exactly such a thing as my payjob.

  You are on the right track, though: Global variables should and can
be avoided (there are very few exceptions to this rule, of which eg.
std::cout is a good example (I consider std::cout to be a "global" variable
even though it's inside a namespace), where practicality compensates
globality more than enough), and clean abstract designs should be preferred.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   You are on the right track, though: Global variables should and can
> be avoided (there are very few exceptions to this rule, of which eg.
> std::cout is a good example (I consider std::cout to be a "global" variable
> even though it's inside a namespace), where practicality compensates
> globality more than enough), and clean abstract designs should be preferred.

OOC, do you consider static members to be global? They're not tied to an 
instance of an object, but are generally available throughout the 
program (if made public)

Post a reply to this message

Warp wrote:
> stbenge <stb### [at] hotmailcom> wrote:
>> A simple (tile based) level editor is my current project. Already, I 
>> have about two dozen global variables. It's getting messy, and I'm 
>> having to rewrite code to handle, say, foreground tile editing as 
>> opposed to background tile editing.
> 
>   High-quality object-oriented design is far, far from trivial to do.
> It requires years of OOD and OO programming experience, and even then
> it usually requires several iterations of design-use-redesign.
> 
>   Making a good, encapsulated, abstract, flexible and reusable graphical
> editor is a rather difficult tasks of OOD in general (regardless of the
> programming language used) and C++ programming in particular. I know this
> because I have been working on exactly such a thing as my payjob.

Thanks, I feel both better and worse.

>   You are on the right track, though: Global variables should and can
> be avoided (there are very few exceptions to this rule, of which eg.
> std::cout is a good example (I consider std::cout to be a "global" variable
> even though it's inside a namespace), where practicality compensates
> globality more than enough), and clean abstract designs should be preferred.
> 

I'll just have to take baby steps and see what I learn. Thanks!

Sam

Post a reply to this message

Warp wrote:
>   You are on the right track, though: Global variables should and can
> be avoided 

While generally true, I find that if the *meaning* of a variable is 
truly global, it can be made a global harmlessly.

FILE * resourcefule;
   // The handle to the resource file if it's open, or NULL if not.

Stuff like that. If there's ever an instant where the definition of the 
variable doesn't match its content, then it isn't global, it's just a 
backdoor to pass parameters between functions.

Of course, with OO more than procedural code, you're more likely to pull 
a class into some other framework where it wasn't expected to be, so 
there's less good use for globally-visible variables. (Unless, of 
course, your language treats classes as globals, rather than as second 
class objects.)

But I've never regretted making a global that was truly global in that 
sense, so anyone could reference it.  "Bad" globals are ones that don't 
have a meaningful value for the entire duration of the program, from the 
first line to the last, methinks.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

stbenge wrote:
> Hi,
> 
> As I progress in my understanding of C++, I come closer to the 
> inevitable conclusion that in order to make my code more efficient and 
> easy to alter, I need to learn more about classes and structs. Simple 
> concepts, but the problem comes with implementing said features.
> 
> A simple (tile based) level editor is my current project. Already, I 
> have about two dozen global variables. It's getting messy, and I'm 
> having to rewrite code to handle, say, foreground tile editing as 
> opposed to background tile editing.
> 
> Does anyone have a link to some good tutorials to help me manage this 
> ever-growing pile of data? I need to encapsulate everything. I'd like to 
> rid myself of global variables entirely, if that's possible. Thanks~

The easiest way to get rid of the globals is to declare a class which 
has some static members in it:

appdata.h:

class AppData {
     static int AppDataInt;
};

appdata.cpp:

#include "appdata.h"
int AppData::AppDataInt=0; // or whatever

Everytime you want to use your formerly global data, you include 
appdata.h in the file and make sure you use the scope resolution to 
access it.

One benefit of this is that you can now borrow code from another project 
that uses globals without worrying about those globals conflicting with 
your ex-globals.

Additionally, you can make make the static members of AppData private 
members, and access them through member functions of AppData, to enforce 
sanity checks on the changes you make to the data.

I've been doing C++ since '02, and most of the hands-on involves my 
modeling application; it was originally written in C starting in 1999, 
and much of the code base remains a product of non-OOP C thinking.

Regards,
John

Post a reply to this message

Michael Raiford <mra### [at] hotmailcom> wrote:
> OOC, do you consider static members to be global? They're not tied to an 
> instance of an object, but are generally available throughout the 
> program (if made public)

  Not really because they don't garbage the global namespace and, most
importantly, they cannot be pulled out of the class, unlike things inside
namespaces can.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> While generally true, I find that if the *meaning* of a variable is 
> truly global, it can be made a global harmlessly.

  There are a few cases where a global instance may be more practical than
harmful. In C++ in particular, though, I still prefer putting those inside
a namespace.
  As I mentioned, I think std::cout is a good example.

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> The easiest way to get rid of the globals is to declare a class which 
> has some static members in it:

  IMO that only masks the problem, it doesn't solve it.

  If you find yourself using tons of global variables that's usually a
sign of an overall design flaw in your program. Moving the globals inside
a namespace or a class doesn't really solve the underlying design problem.

  As I have already mentioned, not all global variables are bad, and it's
not like you would have to avoid them like the plague. However, usually
the vast majority of global variables, especially if you find yourself
writing tons of them, are a sign of bad design.
  It's usually a sign that you are not using proper encapsulation and
proper abstraction, which are key concepts in creating high-quality reusable
and flexible code.

  Note that the problem with global variables is *not* exclusively that
the garbage the global namespace. That's actually the smallest of the
problems involved. That's why simply masking this one problem isn't really
the answer to the bigger design problems.

  With small projects good OOD doesn't really matter. However, the larger
the project, the more it becomes really useful.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   There are a few cases where a global instance may be more practical than
> harmful. 

Yeah. Kind of like "goto". :-)

> In C++ in particular, though, I still prefer putting those inside
> a namespace.

Certainly if you can give it a name that groups it appropriately, that's 
an improvement.  I just call anything whose lifetime and scope are both 
"the entire execution of the program" a global, regardless of how the 
name is qualified.  I don't think putting it inside a namespace prevents 
too many of the traditional problems associated with globals.

>   As I mentioned, I think std::cout is a good example.

Exactly. It means one thing, and it means that thing throughout the 
entire lifetime of the program. Unlike, say, "errno", whose semantics 
are poor due to not meaning anything obvious if the immediately 
preceding system call didn't fail - i.e., there are far too many caveats 
on when errno is "valid" for it to count as a good use of globals. It's 
more a kludge due to C not being able to return multiple values.

Of course, throw in threads and everything gets more confusing. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message