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

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   There are a few cases where a global instance may be more practical than
> > harmful. 

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

  I disagree. I have been writing C++ for hobby and professionally for
over 10 years, and the total amount of C++ I have written is probably
closer to 100k lines of code. I don't remember *ever* writing even a
single "goto".

  It's not like I avoid it. I just don't need it. (Usually good basic
encapsulation takes automatically care of anything that would be an
"acceptable use of goto" otherwise.)

  Global variables (inside namespaces or not) is not something I have used
a lot, but I have a few times. I believe I can rationally argue for the
rationality of each one.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I disagree. I have been writing C++ for hobby and professionally for
> over 10 years, and the total amount of C++ I have written is probably
> closer to 100k lines of code. I don't remember *ever* writing even a
> single "goto".

Note that calling "return" in the middle of a function is equivalent to 
"goto". :-)  Arguably "continue" and "break" and exceptions as well. 
Those are all non-structured constructs.

And, of course, depending on your language, "goto" may be more or less 
common.  Take break and continue out of your loops, take try/finally out 
of your exception handling, and suddenly there's places where "goto" is 
cleaner.

Admittedly, not a lot. Indeed, Tcl doesn't even have a goto. For a 
language where it's pretty trivial to implement your own control 
structures, I think I'd have a hard time implementing "goto" in Tcl.

>   It's not like I avoid it. I just don't need it. (Usually good basic
> encapsulation takes automatically care of anything that would be an
> "acceptable use of goto" otherwise.)

Agreed.  I was just trying to say that there are people who think "goto" 
is inherently evil, and that globals are inherently evil, because that's 
what they've been taught, but that's really just lies-to-children until 
they have enough experience to learn the few places where it really does 
make more sense.

And then as programming languages evolve, they incorporate the good 
places to use a goto into the syntax of the language and call it 
something else, like "try/catch" or "return".

Go back to Pascal with no break, no early return, no exceptions, and 
you'll realize where you miss your "return". :-)

>   Global variables (inside namespaces or not) is not something I have used
> a lot, but I have a few times. I believe I can rationally argue for the
> rationality of each one.

Yep.

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

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   I disagree. I have been writing C++ for hobby and professionally for
> > over 10 years, and the total amount of C++ I have written is probably
> > closer to 100k lines of code. I don't remember *ever* writing even a
> > single "goto".

> Note that calling "return" in the middle of a function is equivalent to 
> "goto". :-)  Arguably "continue" and "break" and exceptions as well. 
> Those are all non-structured constructs.

  I really think that when Dijkstra wrote "goto considered harmful" he
really meant "goto", as in "jump to a label", and not other control
structures (such as returns, loops and conditionals).

  The idea is that "goto" (ie "jump to a label") makes the code more
obfuscated than other control structures, and usually needlessly so.

> >   It's not like I avoid it. I just don't need it. (Usually good basic
> > encapsulation takes automatically care of anything that would be an
> > "acceptable use of goto" otherwise.)

> Agreed.  I was just trying to say that there are people who think "goto" 
> is inherently evil, and that globals are inherently evil, because that's 
> what they've been taught, but that's really just lies-to-children until 
> they have enough experience to learn the few places where it really does 
> make more sense.

  I don't think goto is inherently evil. I think it's inherently unnecessary,
and overusing it is a bad idea. In the vast majority of cases there are
better alternatives.

> And then as programming languages evolve, they incorporate the good 
> places to use a goto into the syntax of the language and call it 
> something else, like "try/catch" or "return".

  At least those state more clearly their intention and are not so easy
to misuse.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I really think that when Dijkstra wrote "goto considered harmful" he
> really meant "goto", as in "jump to a label", and not other control
> structures (such as returns, loops and conditionals).

I think when he wrote it, he was primarily addressing a generation of 
FORTRAN programmers. :-)  The people he was talking to generally didn't 
have things like "if/then/else" in the language they came from.

>   The idea is that "goto" (ie "jump to a label") makes the code more
> obfuscated than other control structures, and usually needlessly so.

Right. Structured programming is where each statement has an entrance 
and an exit. That's what (IIRC) Dijkstra was talking about.

Returning from the middle of a function also *can* make code more 
obfuscated. Certainly it isn't structured. Maintaining a function with 
internal returns when you need to put something at the end is as bad as 
making a function work that can throw exceptions when you have no 
"finally" type of functionality.

Take a look at something like Eiffel, where there's no goto, no return, 
no break or continue, and exceptions either abort your function or start 
over at the beginning of it, depending on whether you catch them or not. 
I can imagine situations where a goto might be handy in such a language.

"break" and "continue" and "return" and "catch" are all just limited 
versions of "goto" that give you the way to do the good stuff with 
"goto" without giving you the way of doing the "bad" stuff with goto.

>   I don't think goto is inherently evil. I think it's inherently unnecessary,
> and overusing it is a bad idea. In the vast majority of cases there are
> better alternatives.

Agreed. But again, it depends on the language. Something like the 
original version of Pascal? Not uncommonly the best way to get out of a 
nested loop, or to have several bits of code all clean up in a "finally" 
kind of way.  Something like the original BASIC?  Unquestionably 
necessary as it was the only way to build a while loop.

Much of the control structure research in "normal" languages 
(single-threaded etc) consists of better ways of expressing "goto". :-)

>> And then as programming languages evolve, they incorporate the good 
>> places to use a goto into the syntax of the language and call it 
>> something else, like "try/catch" or "return".
> 
>   At least those state more clearly their intention and are not so easy
> to misuse.

Exactly. And take them out of the language (like when Dijkstra was 
writing) and he's talking about using "goto" in good ways, namely in 
structured ways.

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

Darren New <dne### [at] sanrrcom> wrote:
> Right. Structured programming is where each statement has an entrance 
> and an exit. That's what (IIRC) Dijkstra was talking about.

  Dijkstra advocated structured programming as a replacement for the
heavily "goto-based" programming of the time. Structured programming
introduced concepts which are common in most current languages. The
more the reason to not to use goto...

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Right. Structured programming is where each statement has an entrance 
>> and an exit. That's what (IIRC) Dijkstra was talking about.
> 
>   Dijkstra advocated structured programming as a replacement for the
> heavily "goto-based" programming of the time. Structured programming
> introduced concepts which are common in most current languages. The
> more the reason to not to use goto...

Exactly. And the structured programming he introduced also eschewed 
early returns, break, continue, etc. That's all I'm trying to say. :-) 
If your language has *no* unstructured control-flow statements (such as 
early returns, break, continue, etc) then you probably wind up using 
goto about as much as you wind up using globals.

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

Warp wrote:
>   Dijkstra advocated structured programming as a replacement for the
> heavily "goto-based" programming of the time. 

Actually, this discussion lead to an interesting insight (for which I 
thank you).

The real problem with "goto" is not so much the "goto" as the "come 
from". I.e. you see a label, and anything in scope of that label might 
branch there. In something like COBOL or (dartmouth) BASIC, anywhere in 
the entire program might branch to any label in the entire program.

If you refactor a program to take some commonality out of a handful of 
functions, and that commonality doesn't really stand on its own, you 
haven't really structured it. You've just used a function as a goto.

I have a bit of program that takes an audio sample and tries to find a 
match. It does some stuff up front, and then depending where it looks 
for it, it makes different decisions to see if it "matches". It may or 
may not take timezones into account. It may or may not take time into 
account at all. It may or may not take the character set of the returned 
metadata into account, or the source of the metadata.  Depending what we 
match it again, there's four or five or six (depending on how you count) 
matching routines. I remember at one point wishing I had the FORTRAN 
"entry" declaration available. :-)

In any case, when I refactored the part that actually ran on *that* 
particular sort of computer, I actually wound up with a routine that's 
pretty much meaningless outside that matching mechanism, and which gets 
a whole bunch of variables that used to be local and don't make any 
sense as independent parameters (e.g., the logging information so far 
onto which I append more heuristic results so I can tell why it does or 
doesn't work after the fact, which of the fault-tolerance servers were 
queried and whether the first one worked or not, which column of the 
database to pull character set information out of, etc.) Stuff going in 
and out which you'd never have put in there had you not ripped the 
routine out of three copy-and-paste(*) functions and modularized it.

That's really not structured programming. That's three functions all 
using "goto" to go to the start of that function and passing any locals 
it uses in and out as parameters.  It's just another way of writing a 
goto, and it really doesn't clarify the code any as you might otherwise 
expect from "lifting common functionality into a subroutine."

Interesting.



(*) That's maybe the fourth or fifth time here I've changed 
"cut-and-paste" to "copy-and-paste" on this forum. I'm not sure whether 
to thank Warp for correcting me or be annoyed at him. ;-)

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

Darren New escribió:
> Agreed.  I was just trying to say that there are people who think "goto" 
> is inherently evil, and that globals are inherently evil, because that's 
> what they've been taught, but that's really just lies-to-children until 
> they have enough experience to learn the few places where it really does 
> make more sense.

C++ FAQ Lite:

One size does not fit all. Stop. Right now, take out a fine-point marker 
and write on the inside of your glasses: Software Development Is 
Decision Making. "Think" is not a four-letter word. There are very few 
if any "never..." and "always..." rules in software — rules that you can 
apply without thinking — rules that always work in all situations in all 
markets — one-size-fits-all rules.

[and from another FAQ:]

It really bothers me when people think they know what's best for your 
problem even though they've never seen your problem!! How can anybody 
possibly know that multiple inheritance won't help you accomplish your 
goals without knowing your goals?!?!?!?!!!

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> One size does not fit all. Stop. Right now, take out a fine-point marker 
> and write on the inside of your glasses: Software Development Is 
> Decision Making. "Think" is not a four-letter word. There are very few 
> if any "never..." and "always..." rules in software ??? rules that you can 
> apply without thinking ??? rules that always work in all situations in all 
> markets ??? one-size-fits-all rules.

  Maybe "never use goto" is wrong, but "in the over 10 years I have programmed
I have never needed goto" is right. I think it's rather telling.

> It really bothers me when people think they know what's best for your 
> problem even though they've never seen your problem!! How can anybody 
> possibly know that multiple inheritance won't help you accomplish your 
> goals without knowing your goals?!?!?!?!!!

  I completely disagree with anyone who says that multiple inheritance
is a bad thing.

  Sure, multiple inheritance can be misused. But so can regular inheritance.
So can variable and function naming. *Anything* can be misused.

-- 
                                                          - Warp

Post a reply to this message