Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11671 > unrolled thread

Can I avoid using a global?!

Back to article view | Back to comp.lang.c++

Contents

  Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-21 16:07 -0800
    Re: Can I avoid using a global?! Ian Collins <ian-news@hotmail.com> - 2011-11-22 13:39 +1300
      Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-21 20:08 -0800
        Re: Can I avoid using a global?! Ian Collins <ian-news@hotmail.com> - 2011-11-22 17:15 +1300
          Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-21 23:18 -0800
        Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-21 23:36 -0800
          Re: Can I avoid using a global?! "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-11-22 09:09 +0100
          Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 02:02 -0800
            Re: Can I avoid using a global?! Stuart Redmann <DerTopper@web.de> - 2011-11-22 05:02 -0800
              Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 12:43 -0800
                Re: Can I avoid using a global?! Stuart Redmann <DerTopper@web.de> - 2011-11-22 23:04 -0800
                  Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-23 13:27 -0800
                    Re: Can I avoid using a global?! Stuart Redmann <DerTopper@web.de> - 2011-11-23 22:40 -0800
            Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-22 06:08 -0800
              Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 12:32 -0800
                Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-22 23:50 -0800
              Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 12:46 -0800
                Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-23 00:02 -0800
                  Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-23 13:25 -0800
                    Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-24 05:45 -0800
                      Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-24 19:44 -0800
        Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-22 01:36 -0800
          Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 02:09 -0800
            Re: Can I avoid using a global?! Goran <goran.pusic@gmail.com> - 2011-11-22 03:03 -0800
              Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 12:48 -0800
      Re: Can I avoid using a global?! ralph <nt_consulting64@yahoo.net> - 2011-11-21 22:59 -0600
    Re: Can I avoid using a global?! Juha Nieminen <nospam@thanks.invalid> - 2011-11-22 07:53 +0000
      Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 02:05 -0800
    Re: Can I avoid using a global?! Mielke <smielke@webpartner.com.br> - 2011-11-22 07:35 -0800
      Re: Can I avoid using a global?! mike3 <mike4ty4@yahoo.com> - 2011-11-22 12:34 -0800
    Re: Can I avoid using a global?! Krice <paulkp@mbnet.fi> - 2011-11-23 00:42 -0800

Page 1 of 2  [1] 2  Next page →

#11671 — Can I avoid using a global?!

Hi.

I've got this problem. I was building a game in C++, and ran into
this, which is causing me some trouble. I was wondering if I could
avoid using a global here since I've heard that globals are "bad".
I've also heard global _functions_ are bad too. If that's the case,
then this seems impossible to do without using one: how can we draw to
the screen, which seems to require a set of screen drawing functions
that you can call from anywhere, or a "singleton" screen object (bad
too!), etc. etc. etc.?

[toc] | [next] | [standalone]

#11672

On 11/22/11 01:07 PM, mike3 wrote:
> Hi.
>
> I've got this problem. I was building a game in C++, and ran into
> this, which is causing me some trouble. I was wondering if I could
> avoid using a global here since I've heard that globals are "bad".

Global variables are best avoided.

> I've also heard global _functions_ are bad too. If that's the case,

It isn't, it's nonsense!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#11674

On Nov 21, 5:39 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 11/22/11 01:07 PM, mike3 wrote:
>
> > Hi.
>
> > I've got this problem. I was building a game in C++, and ran into
> > this, which is causing me some trouble. I was wondering if I could
> > avoid using a global here since I've heard that globals are "bad".
>
> Global variables are best avoided.
>
> > I've also heard global _functions_ are bad too. If that's the case,
>
> It isn't, it's nonsense!
>
> --
> Ian Collins

Hmm. Now I've got another question. In this program, I have a number
of
objects that represent various parts of the screen to draw in
("windows").
These are "global" to the source code file that handles the display,
but
are not accessed anywhere outside that -- or at least not visibly,
since
there are functions that can be called from outside that use them. Is
this
global bad? If so, what can be done to replace it?

Namely, I've got some stuff like:

--- Code ---
DisplayWindow *msgWnd, *gameWnd, *statsWnd;
("globals" within the source file UH OH)

...
(Functions that use them -- this is all you see from "outside")
void InitializeGameDisplay()
{
...
}
...
--- End code ---

What to do? I suppose one could wrap the whole display as an
object, but that'd be a "singleton", no, and SINGLETONS ARE
BAD just like globals, no?

???

[toc] | [prev] | [next] | [standalone]

#11675

On 11/22/11 05:08 PM, mike3 wrote:
> On Nov 21, 5:39 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 11/22/11 01:07 PM, mike3 wrote:
>>
>>> Hi.
>>
>>> I've got this problem. I was building a game in C++, and ran into
>>> this, which is causing me some trouble. I was wondering if I could
>>> avoid using a global here since I've heard that globals are "bad".
>>
>> Global variables are best avoided.
>>
>>> I've also heard global _functions_ are bad too. If that's the case,
>>
>> It isn't, it's nonsense!
>
> Hmm. Now I've got another question. In this program, I have a number
> of
> objects that represent various parts of the screen to draw in
> ("windows").
> These are "global" to the source code file that handles the display,
> but
> are not accessed anywhere outside that -- or at least not visibly,
> since
> there are functions that can be called from outside that use them. Is
> this
> global bad? If so, what can be done to replace it?

It would be tidier to put them in the unnamed namespace.  That way they 
really will only be visible in the source file where they are defined.

> Namely, I've got some stuff like:
>
> --- Code ---

namespace {
> DisplayWindow *msgWnd, *gameWnd, *statsWnd;
}

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#11681

On Nov 21, 9:15 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 11/22/11 05:08 PM, mike3 wrote:
>
>
>
> > On Nov 21, 5:39 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
> >> On 11/22/11 01:07 PM, mike3 wrote:
>
> >>> Hi.
>
> >>> I've got this problem. I was building a game in C++, and ran into
> >>> this, which is causing me some trouble. I was wondering if I could
> >>> avoid using a global here since I've heard that globals are "bad".
>
> >> Global variables are best avoided.
>
> >>> I've also heard global _functions_ are bad too. If that's the case,
>
> >> It isn't, it's nonsense!
>
> > Hmm. Now I've got another question. In this program, I have a number
> > of
> > objects that represent various parts of the screen to draw in
> > ("windows").
> > These are "global" to the source code file that handles the display,
> > but
> > are not accessed anywhere outside that -- or at least not visibly,
> > since
> > there are functions that can be called from outside that use them. Is
> > this
> > global bad? If so, what can be done to replace it?
>
> It would be tidier to put them in the unnamed namespace.  That way they
> really will only be visible in the source file where they are defined.
>
> > Namely, I've got some stuff like:
>
> > --- Code ---
>
> namespace {
>
> > DisplayWindow *msgWnd, *gameWnd, *statsWnd;
> }
>
> --
> Ian Collins

Hmm. But I'm curious: might there be a way that avoids the global
altogether?
Or is this a situation in which a global may really be a good option?

[toc] | [prev] | [next] | [standalone]

#11680

On Nov 22, 5:08 am, mike3 <mike4...@yahoo.com> wrote:
> On Nov 21, 5:39 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 11/22/11 01:07 PM, mike3 wrote:
>
> > > Hi.
>
> > > I've got this problem. I was building a game in C++, and ran into
> > > this, which is causing me some trouble. I was wondering if I could
> > > avoid using a global here since I've heard that globals are "bad".
>
> > Global variables are best avoided.
>
> > > I've also heard global _functions_ are bad too. If that's the case,
>
> > It isn't, it's nonsense!
>
> > --
> > Ian Collins
>
> Hmm. Now I've got another question. In this program, I have a number
> of
> objects that represent various parts of the screen to draw in
> ("windows").
> These are "global" to the source code file that handles the display,
> but
> are not accessed anywhere outside that -- or at least not visibly,
> since
> there are functions that can be called from outside that use them. Is
> this
> global bad? If so, what can be done to replace it?
>
> Namely, I've got some stuff like:
> -
> --- Code ---
> DisplayWindow *msgWnd, *gameWnd, *statsWnd;
> ("globals" within the source file UH OH)
>
> ...
> (Functions that use them -- this is all you see from "outside")
> void InitializeGameDisplay()
> {
> ...}
>
> ...
> --- End code ---
>
> What to do? I suppose one could wrap the whole display as an
> object, but that'd be a "singleton", no, and SINGLETONS ARE
> BAD just like globals, no?
>
> ???

I don't want to sound patronizing, but given what I think is your
proficiency in programming, you should start building stuff that works
first. You seem to think too much about things that aren't your
primary concern.

That said... Global variables are code obfuscation technique. You
should wrap the display in an object. That object can contain your
windows or whatever. You can add functions to your object, they will
represent what your object can do (their "responsibilities, if you
will). Don't make that display a global object. Rather, declare it
e.g. in main (or whatever is the place that you want to use it), and
(possibly) pass it around, as a parameter, to other places in your
code. That alone beats having global variables. It also gives a
visible data structure to your code ("ah, I see, I have a display, who
has this and that window etc, and I use display in functions 1, 2 and
3), as opposed to not having said structure, but deducting from the
use of said global variables in various places.

Goran.

[toc] | [prev] | [next] | [standalone]

#11684

"Goran"  wrote in message 
news:b9a94118-1ddd-4ac2-bd27-38a330d9afa8@c18g2000yqj.googlegroups.com...
>
>On Nov 22, 5:08 am, mike3 <mike4...@yahoo.com> wrote:
>> On Nov 21, 5:39 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On 11/22/11 01:07 PM, mike3 wrote:
>>
>> > > Hi.
>>
>> > > I've got this problem. I was building a game in C++, and ran into
>> > > this, which is causing me some trouble. I was wondering if I could
>> > > avoid using a global here since I've heard that globals are "bad".
>>
>> > Global variables are best avoided.
>>
>> > > I've also heard global _functions_ are bad too. If that's the case,
>>
>> > It isn't, it's nonsense!
>>
>> > --
>> > Ian Collins
>>
>> Hmm. Now I've got another question. In this program, I have a number
>> of
>> objects that represent various parts of the screen to draw in
>> ("windows").
>> These are "global" to the source code file that handles the display,
>> but
>> are not accessed anywhere outside that -- or at least not visibly,
>> since
>> there are functions that can be called from outside that use them. Is
>> this
>> global bad? If so, what can be done to replace it?
>>
>> Namely, I've got some stuff like:
>> -
>> --- Code ---
>> DisplayWindow *msgWnd, *gameWnd, *statsWnd;
>> ("globals" within the source file UH OH)
>>
>> ...
>> (Functions that use them -- this is all you see from "outside")
>> void InitializeGameDisplay()
>> {
>> ...}
>>
>> ...
>> --- End code ---
>>
>> What to do? I suppose one could wrap the whole display as an
>> object, but that'd be a "singleton", no, and SINGLETONS ARE
>> BAD just like globals, no?
>>
>> ???
>
>I don't want to sound patronizing, but given what I think is your
>proficiency in programming, you should start building stuff that works
>first. You seem to think too much about things that aren't your
>primary concern.
>
>That said... Global variables are code obfuscation technique. You
>should wrap the display in an object. That object can contain your
>windows or whatever. You can add functions to your object, they will
>represent what your object can do (their "responsibilities, if you
>will). Don't make that display a global object. Rather, declare it
>e.g. in main (or whatever is the place that you want to use it), and
>(possibly) pass it around, as a parameter, to other places in your
>code. That alone beats having global variables. It also gives a
>visible data structure to your code ("ah, I see, I have a display, who
>has this and that window etc, and I use display in functions 1, 2 and
>3), as opposed to not having said structure, but deducting from the
>use of said global variables in various places.
>
>Goran.

And the additional advantage is, that if you encounter a situation with two 
displays, each display can have its own variables. If global variables are 
used you are less flexible in such a situation. 

[toc] | [prev] | [next] | [standalone]

#11688

On Nov 22, 12:36 am, Goran <goran.pu...@gmail.com> wrote:
> On Nov 22, 5:08 am, mike3 <mike4...@yahoo.com> wrote:
>
>
>
> > On Nov 21, 5:39 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > > On 11/22/11 01:07 PM, mike3 wrote:
>
> > > > Hi.
>
> > > > I've got this problem. I was building a game in C++, and ran into
> > > > this, which is causing me some trouble. I was wondering if I could
> > > > avoid using a global here since I've heard that globals are "bad".
>
> > > Global variables are best avoided.
>
> > > > I've also heard global _functions_ are bad too. If that's the case,
>
> > > It isn't, it's nonsense!
>
> > > --
> > > Ian Collins
>
> > Hmm. Now I've got another question. In this program, I have a number
> > of
> > objects that represent various parts of the screen to draw in
> > ("windows").
> > These are "global" to the source code file that handles the display,
> > but
> > are not accessed anywhere outside that -- or at least not visibly,
> > since
> > there are functions that can be called from outside that use them. Is
> > this
> > global bad? If so, what can be done to replace it?
>
> > Namely, I've got some stuff like:
> > -
> > --- Code ---
> > DisplayWindow *msgWnd, *gameWnd, *statsWnd;
> > ("globals" within the source file UH OH)
>
> > ...
> > (Functions that use them -- this is all you see from "outside")
> > void InitializeGameDisplay()
> > {
> > ...}
>
> > ...
> > --- End code ---
>
> > What to do? I suppose one could wrap the whole display as an
> > object, but that'd be a "singleton", no, and SINGLETONS ARE
> > BAD just like globals, no?
>
> > ???
>
> I don't want to sound patronizing, but given what I think is your
> proficiency in programming, you should start building stuff that works
> first. You seem to think too much about things that aren't your
> primary concern.
>

However, I've already made a fair number of "working" programs. But
does this mean it is OK to use these "bad" things so long as you can
make it work? But what would _maintaining_ that program be like?

> That said... Global variables are code obfuscation technique. You
> should wrap the display in an object. That object can contain your
> windows or whatever. You can add functions to your object, they will
> represent what your object can do (their "responsibilities, if you
> will). Don't make that display a global object. Rather, declare it
> e.g. in main (or whatever is the place that you want to use it), and
> (possibly) pass it around, as a parameter, to other places in your
> code. That alone beats having global variables. It also gives a
> visible data structure to your code ("ah, I see, I have a display, who
> has this and that window etc, and I use display in functions 1, 2 and
> 3), as opposed to not having said structure, but deducting from the
> use of said global variables in various places.
>
> Goran.

However, the thing is, the display may be accessed by a great variety
of different functions and objects, especially to print messages. What
should be done? Is it OK to have a "display" parameter to all those
different diverse things?

[toc] | [prev] | [next] | [standalone]

#11700

On Nov 22, Goran wrote:
> > I don't want to sound patronizing, but given what I think is your
> > proficiency in programming, you should start building stuff that works
> > first. You seem to think too much about things that aren't your
> > primary concern.


On 22 Nov., mike3 wrote:
> However, I've already made a fair number of "working" programs. But
> does this mean it is OK to use these "bad" things so long as you can
> make it work? But what would _maintaining_ that program be like?

Let's put it like this: Getting things to work should be your primary
concern. If you use "bad" techniques, you'll pretty soon experience
some kind of glass ceiling: You'll find that it is getting more and
more difficult to add  features to your code.

Whenever you reach such a point you can start to re-design or re-
factor. Of course, this is much more time-consuming than if you had
used better techniques in the first place, but unfortunately humans
learn fastest when they make mistakes ;-) Seriously, finding the
proper design is magnitudes more difficult than getting things just
done. So you'll get discouraged over getting things tidy right from
the start. Most beginners stop working on some project because they
struggle with the wrong objectives (not that I mean that you are a
beginner).

BTW, I'd rather say "inappropriate" techniques, since IMHO there are
no bad techniques, at least not in the sense that a "bad" technique is
a technique that must be avoided at all costs. For example, you can
write pages of code in order to implement a proper thread-safe
singleton, or just use a global variable. Only if the global variable
is not sufficient, you should replace it by something that is more
complicated.


On Nov 22, Goran wrote:
> > That said... Global variables are code obfuscation technique. You
> > should wrap the display in an object. That object can contain your
> > windows or whatever. You can add functions to your object, they will
> > represent what your object can do (their "responsibilities, if you
> > will). Don't make that display a global object. Rather, declare it
> > e.g. in main (or whatever is the place that you want to use it), and
> > (possibly) pass it around, as a parameter, to other places in your
> > code. That alone beats having global variables. It also gives a
> > visible data structure to your code ("ah, I see, I have a display, who
> > has this and that window etc, and I use display in functions 1, 2 and
> > 3), as opposed to not having said structure, but deducting from the
> > use of said global variables in various places.

On 22 Nov., mike3 wrote:
> However, the thing is, the display may be accessed by a great variety
> of different functions and objects, especially to print messages. What
> should be done? Is it OK to have a "display" parameter to all those
> different diverse things?

I'd rather use the global variable. Just like std::cout, you'll don't
want to pass around a pointer to std::cout.

That's my 2 cents. (I don't want to start a flame war over this)

Regards,
Stuart

[toc] | [prev] | [next] | [standalone]

#11722

On Nov 22, 6:02 am, Stuart Redmann <DerTop...@web.de> wrote:
> On Nov 22, Goran wrote:
>
> > > I don't want to sound patronizing, but given what I think is your
> > > proficiency in programming, you should start building stuff that works
> > > first. You seem to think too much about things that aren't your
> > > primary concern.
>
> On 22 Nov., mike3 wrote:
>
> > However, I've already made a fair number of "working" programs. But
> > does this mean it is OK to use these "bad" things so long as you can
> > make it work? But what would _maintaining_ that program be like?
>
> Let's put it like this: Getting things to work should be your primary
> concern. If you use "bad" techniques, you'll pretty soon experience
> some kind of glass ceiling: You'll find that it is getting more and
> more difficult to add  features to your code.
>

Hence why I'm asking about "good" techniques :)

> Whenever you reach such a point you can start to re-design or re-
> factor. Of course, this is much more time-consuming than if you had
> used better techniques in the first place, but unfortunately humans
> learn fastest when they make mistakes ;-)

Oh, because it's not so easy to understand how to do things right,
until
you've done them wrong, and so can see just how it went wrong, right?

> Seriously, finding the
> proper design is magnitudes more difficult than getting things just
> done. So you'll get discouraged over getting things tidy right from
> the start. Most beginners stop working on some project because they
> struggle with the wrong objectives (not that I mean that you are a
> beginner).
>

Yet if it's "magnitudes more difficult" to "find the proper design",
then how is the "make it work then re-factor/re-design" approach
necessarily "much more time-consuming" than the approach of "use
better techniques in the first place", when to do the latter requires
more time "designing"? In other words, from the way you describe it it
would be roughly equal in time requirements, just proportioned
differently:

1. the first approach takes a "great deal of time", but that great
deal
of time is spent coding/re-coding,

2. the second approach takes a "great deal of time", but that great
deal
of time is mostly spent "designing".

> BTW, I'd rather say "inappropriate" techniques, since IMHO there are
> no bad techniques, at least not in the sense that a "bad" technique is
> a technique that must be avoided at all costs. For example, you can
> write pages of code in order to implement a proper thread-safe
> singleton, or just use a global variable. Only if the global variable
> is not sufficient, you should replace it by something that is more
> complicated.
>
> On Nov 22, Goran wrote:
>
> > > That said... Global variables are code obfuscation technique. You
> > > should wrap the display in an object. That object can contain your
> > > windows or whatever. You can add functions to your object, they will
> > > represent what your object can do (their "responsibilities, if you
> > > will). Don't make that display a global object. Rather, declare it
> > > e.g. in main (or whatever is the place that you want to use it), and
> > > (possibly) pass it around, as a parameter, to other places in your
> > > code. That alone beats having global variables. It also gives a
> > > visible data structure to your code ("ah, I see, I have a display, who
> > > has this and that window etc, and I use display in functions 1, 2 and
> > > 3), as opposed to not having said structure, but deducting from the
> > > use of said global variables in various places.
>
> On 22 Nov., mike3 wrote:
>
> > However, the thing is, the display may be accessed by a great variety
> > of different functions and objects, especially to print messages. What
> > should be done? Is it OK to have a "display" parameter to all those
> > different diverse things?
>
> I'd rather use the global variable. Just like std::cout, you'll don't
> want to pass around a pointer to std::cout.
>
> That's my 2 cents. (I don't want to start a flame war over this)
>
> Regards,
> Stuart

[toc] | [prev] | [next] | [standalone]

#11737

On Nov 22, Stuart Redmann wrote:
> > Seriously, finding the
> > proper design is magnitudes more difficult than getting things just
> > done. So you'll get discouraged over getting things tidy right from
> > the start. Most beginners stop working on some project because they
> > struggle with the wrong objectives (not that I mean that you are a
> > beginner).

On 22 Nov., mike3 wrote:
> Yet if it's "magnitudes more difficult" to "find the proper design",
> then how is the "make it work then re-factor/re-design" approach
> necessarily "much more time-consuming" than the approach of "use
> better techniques in the first place", when to do the latter requires
> more time "designing"? In other words, from the way you describe it it
> would be roughly equal in time requirements, just proportioned
> differently:
>
> 1. the first approach takes a "great deal of time", but that great
> deal of time is spent coding/re-coding,
>
> 2. the second approach takes a "great deal of time", but that great
> deal of time is mostly spent "designing".

Simple:
1. great deal of time for better design + great deal of time for re-
coding
    = 2 x great deal of time.
2. great deal of time for good design
    = 1 x great deal of time.

Maybe one could argue that the 1st approach is more likely only 1.5
times a great deal of time as one gets valuable insights into the
shape of the problem from the previous coding phase. It really
depends.

I like the first approach more (which is roughly the Agile approach).
Management prefers the second approach: Their mental picture of the
development process is almost always the waterfall model.

Regards,
Stuart

[toc] | [prev] | [next] | [standalone]

#11762

On Nov 23, 12:04 am, Stuart Redmann <DerTop...@web.de> wrote:
> On Nov 22, Stuart Redmann wrote:
>
> > > Seriously, finding the
> > > proper design is magnitudes more difficult than getting things just
> > > done. So you'll get discouraged over getting things tidy right from
> > > the start. Most beginners stop working on some project because they
> > > struggle with the wrong objectives (not that I mean that you are a
> > > beginner).
>
> On 22 Nov., mike3 wrote:
>
> > Yet if it's "magnitudes more difficult" to "find the proper design",
> > then how is the "make it work then re-factor/re-design" approach
> > necessarily "much more time-consuming" than the approach of "use
> > better techniques in the first place", when to do the latter requires
> > more time "designing"? In other words, from the way you describe it it
> > would be roughly equal in time requirements, just proportioned
> > differently:
>
> > 1. the first approach takes a "great deal of time", but that great
> > deal of time is spent coding/re-coding,
>
> > 2. the second approach takes a "great deal of time", but that great
> > deal of time is mostly spent "designing".
>
> Simple:
> 1. great deal of time for better design + great deal of time for re-
> coding
>     = 2 x great deal of time.
> 2. great deal of time for good design
>     = 1 x great deal of time.
>
> Maybe one could argue that the 1st approach is more likely only 1.5
> times a great deal of time as one gets valuable insights into the
> shape of the problem from the previous coding phase. It really
> depends.
>
> I like the first approach more (which is roughly the Agile approach).
> Management prefers the second approach: Their mental picture of the
> development process is almost always the waterfall model.
>

So then would this mean that perhaps it might be better to just try
it with the global, then get a basic system working, and once that is
done, try and see if there's some way to rework it so as to get rid
of that global (since then one would have more of an idea of how
everything fits together, and thus could better see what alternatives
there may be to the global)?

[toc] | [prev] | [next] | [standalone]

#11768

On 23 Nov., mike3 wrote:
> So then would this mean that perhaps it might be better to just try
> it with the global, then get a basic system working, and once that is
> done, try and see if there's some way to rework it so as to get rid
> of that global (since then one would have more of an idea of how
> everything fits together, and thus could better see what alternatives
> there may be to the global)?

Yes, that's how I'd do it.

Happy coding!
Stuart

[toc] | [prev] | [next] | [standalone]

#11702

On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
> On Nov 22, 12:36 am, Goran <goran.pu...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 22, 5:08 am, mike3 <mike4...@yahoo.com> wrote:
>
> > > On Nov 21, 5:39 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > > > On 11/22/11 01:07 PM, mike3 wrote:
>
> > > > > Hi.
>
> > > > > I've got this problem. I was building a game in C++, and ran into
> > > > > this, which is causing me some trouble. I was wondering if I could
> > > > > avoid using a global here since I've heard that globals are "bad".
>
> > > > Global variables are best avoided.
>
> > > > > I've also heard global _functions_ are bad too. If that's the case,
>
> > > > It isn't, it's nonsense!
>
> > > > --
> > > > Ian Collins
>
> > > Hmm. Now I've got another question. In this program, I have a number
> > > of
> > > objects that represent various parts of the screen to draw in
> > > ("windows").
> > > These are "global" to the source code file that handles the display,
> > > but
> > > are not accessed anywhere outside that -- or at least not visibly,
> > > since
> > > there are functions that can be called from outside that use them. Is
> > > this
> > > global bad? If so, what can be done to replace it?
>
> > > Namely, I've got some stuff like:
> > > -
> > > --- Code ---
> > > DisplayWindow *msgWnd, *gameWnd, *statsWnd;
> > > ("globals" within the source file UH OH)
>
> > > ...
> > > (Functions that use them -- this is all you see from "outside")
> > > void InitializeGameDisplay()
> > > {
> > > ...}
>
> > > ...
> > > --- End code ---
>
> > > What to do? I suppose one could wrap the whole display as an
> > > object, but that'd be a "singleton", no, and SINGLETONS ARE
> > > BAD just like globals, no?
>
> > > ???
>
> > I don't want to sound patronizing, but given what I think is your
> > proficiency in programming, you should start building stuff that works
> > first. You seem to think too much about things that aren't your
> > primary concern.
>
> However, I've already made a fair number of "working" programs. But
> does this mean it is OK to use these "bad" things so long as you can
> make it work? But what would _maintaining_ that program be like?

You have to find this out by yourself ;-). Seriously, doing "good"
things means understanding why they are good. One of best ways to find
out why is to do bad things and hopefully learn from mistakes.

>
> > That said... Global variables are code obfuscation technique. You
> > should wrap the display in an object. That object can contain your
> > windows or whatever. You can add functions to your object, they will
> > represent what your object can do (their "responsibilities, if you
> > will). Don't make that display a global object. Rather, declare it
> > e.g. in main (or whatever is the place that you want to use it), and
> > (possibly) pass it around, as a parameter, to other places in your
> > code. That alone beats having global variables. It also gives a
> > visible data structure to your code ("ah, I see, I have a display, who
> > has this and that window etc, and I use display in functions 1, 2 and
> > 3), as opposed to not having said structure, but deducting from the
> > use of said global variables in various places.
>
> > Goran.
>
> However, the thing is, the display may be accessed by a great variety
> of different functions and objects, especially to print messages. What
> should be done? Is it OK to have a "display" parameter to all those
> different diverse things?

Passing a parameter normally beats having a global (sometimes not by
much, though, see below). If nothing else, you can track where things
are used by looking at function signatures (as opposed to chasing down
their uses by reading everything).

About "especially to print messages" part: you should probably think
about that in a more abstract way. Program elements that want to
"print messages" don't really want to print messages. What they really
want is for their messages to go somewhere, and where that is, they
don't really care. They don't care about message window. So you should
probably do exactly that: pass, to those program elements, a facility
that they can use to "send" their messages. E.g.

file: messageReceiver.h
struct IMessageReceiver
{
  virtual void Receive(const Message& m) = 0;
};

file: MessageDisplay.h
class MessageDisplay : public DisplayWindow, IMessageReceiver
{
// ...
 virtual void Receive(const Message& m)
 {
  show message...
 }
};


file: gameDisplay.h
class GameDisplay
{
  MessageDisplay messageWnd;
  DisplayWindow gameWindow;
  // ...
};

file: partOfTheGame.cpp
void randomFunction(IMessageReceiver& r)
{
  workworkwork;
  r.Receive(Message("some text", Important));
  workworkwork;
}

What I am talking about here is also known as "interface segregation
principle": for a given part of your code, you want to pass in things
it needs to do the work. To do that in a clean way, a good way is to
create the interface (from the rest of your code) to another part, and
pass that interface in. You don't want one big great massive thing
that can do everything, and then cherry-pick what you need from that
great big thing. That's akin to a global variable, except that you
avoided having it as one, by passing it -everywhere- through a
parameter.

Goran.

[toc] | [prev] | [next] | [standalone]

#11715

On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
> On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
<snip>
> > However, I've already made a fair number of "working" programs. But
> > does this mean it is OK to use these "bad" things so long as you can
> > make it work? But what would _maintaining_ that program be like?
>
> You have to find this out by yourself ;-). Seriously, doing "good"
> things means understanding why they are good. One of best ways to find
> out why is to do bad things and hopefully learn from mistakes.
>

However, what if you do the "bad" thing but manage to get away with
it, i.e.
it doesn't cause a problem in the particular program in question?

[toc] | [prev] | [next] | [standalone]

#11740

On Nov 22, 9:32 pm, mike3 <mike4...@yahoo.com> wrote:
> On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
>
> > On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
> <snip>
> > > However, I've already made a fair number of "working" programs. But
> > > does this mean it is OK to use these "bad" things so long as you can
> > > make it work? But what would _maintaining_ that program be like?
>
> > You have to find this out by yourself ;-). Seriously, doing "good"
> > things means understanding why they are good. One of best ways to find
> > out why is to do bad things and hopefully learn from mistakes.
>
> However, what if you do the "bad" thing but manage to get away with
> it, i.e.
> it doesn't cause a problem in the particular program in question?

Well, what about it? I mean, if it works, good. If you know why it's
badly written, also good. If you find it hard to work with later, bad,
but at least you have a working version right now, and hopefully you
see first hand, from that working version, what works and what
doesn't.

Goran.

[toc] | [prev] | [next] | [standalone]

#11719

On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
> On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
<snip>
> What I am talking about here is also known as "interface segregation
> principle": for a given part of your code, you want to pass in things
> it needs to do the work. To do that in a clean way, a good way is to
> create the interface (from the rest of your code) to another part, and
> pass that interface in. You don't want one big great massive thing
> that can do everything, and then cherry-pick what you need from that
> great big thing. That's akin to a global variable, except that you
> avoided having it as one, by passing it -everywhere- through a
> parameter.
>

However, the display isn't a "great big thing that does everything",
is
it? Aren't you talking about this?:

http://en.wikipedia.org/wiki/God_object

But I fail to see how the display ends up being one of those. It's
just
a display.

[toc] | [prev] | [next] | [standalone]

#11741

On Nov 22, 9:46 pm, mike3 <mike4...@yahoo.com> wrote:
> On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
>
> > On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
> <snip>
> > What I am talking about here is also known as "interface segregation
> > principle": for a given part of your code, you want to pass in things
> > it needs to do the work. To do that in a clean way, a good way is to
> > create the interface (from the rest of your code) to another part, and
> > pass that interface in. You don't want one big great massive thing
> > that can do everything, and then cherry-pick what you need from that
> > great big thing. That's akin to a global variable, except that you
> > avoided having it as one, by passing it -everywhere- through a
> > parameter.
>
> However, the display isn't a "great big thing that does everything",
> is
> it? Aren't you talking about this?:
>
> http://en.wikipedia.org/wiki/God_object

Yes.

> But I fail to see how the display ends up being one of those. It's
> just
> a display.

It's a display who, I presume displays all sorts of stuff (text,
graphics, possibly interacts with the user). But your concern is to
emit messages. If so, your "clients" of the display see one great big
thing that does text/graphics/interaction, and yet, they merely want
to emit messages. So in that sense, it is a God object.

BTW: http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29

Goran.

[toc] | [prev] | [next] | [standalone]

#11761

On Nov 23, 1:02 am, Goran <goran.pu...@gmail.com> wrote:
> On Nov 22, 9:46 pm, mike3 <mike4...@yahoo.com> wrote:
>
>
>
> > On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
>
> > > On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
> > <snip>
> > > What I am talking about here is also known as "interface segregation
> > > principle": for a given part of your code, you want to pass in things
> > > it needs to do the work. To do that in a clean way, a good way is to
> > > create the interface (from the rest of your code) to another part, and
> > > pass that interface in. You don't want one big great massive thing
> > > that can do everything, and then cherry-pick what you need from that
> > > great big thing. That's akin to a global variable, except that you
> > > avoided having it as one, by passing it -everywhere- through a
> > > parameter.
>
> > However, the display isn't a "great big thing that does everything",
> > is
> > it? Aren't you talking about this?:
>
> >http://en.wikipedia.org/wiki/God_object
>
> Yes.
>
> > But I fail to see how the display ends up being one of those. It's
> > just
> > a display.
>
> It's a display who, I presume displays all sorts of stuff (text,
> graphics, possibly interacts with the user). But your concern is to
> emit messages. If so, your "clients" of the display see one great big
> thing that does text/graphics/interaction, and yet, they merely want
> to emit messages. So in that sense, it is a God object.
>
> BTW:http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29
>
> Goran.

So then should the "display" object be partitioned up into a few more,
like one to do messages, one to do graphics, one to handle input?

[toc] | [prev] | [next] | [standalone]

#11782

On Nov 23, 10:25 pm, mike3 <mike4...@yahoo.com> wrote:
> On Nov 23, 1:02 am, Goran <goran.pu...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 22, 9:46 pm, mike3 <mike4...@yahoo.com> wrote:
>
> > > On Nov 22, 7:08 am, Goran <goran.pu...@gmail.com> wrote:
>
> > > > On Nov 22, 11:02 am, mike3 <mike4...@yahoo.com> wrote:
> > > <snip>
> > > > What I am talking about here is also known as "interface segregation
> > > > principle": for a given part of your code, you want to pass in things
> > > > it needs to do the work. To do that in a clean way, a good way is to
> > > > create the interface (from the rest of your code) to another part, and
> > > > pass that interface in. You don't want one big great massive thing
> > > > that can do everything, and then cherry-pick what you need from that
> > > > great big thing. That's akin to a global variable, except that you
> > > > avoided having it as one, by passing it -everywhere- through a
> > > > parameter.
>
> > > However, the display isn't a "great big thing that does everything",
> > > is
> > > it? Aren't you talking about this?:
>
> > >http://en.wikipedia.org/wiki/God_object
>
> > Yes.
>
> > > But I fail to see how the display ends up being one of those. It's
> > > just
> > > a display.
>
> > It's a display who, I presume displays all sorts of stuff (text,
> > graphics, possibly interacts with the user). But your concern is to
> > emit messages. If so, your "clients" of the display see one great big
> > thing that does text/graphics/interaction, and yet, they merely want
> > to emit messages. So in that sense, it is a God object.
>
> > BTW:http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29
>
> > Goran.
>
> So then should the "display" object be partitioned up into a few more,
> like one to do messages, one to do graphics, one to handle input?

I was merely commenting on "various places" who want to "display
messages". In general, even without knowing a lot about the rest of
the code, I felt it's safe to say that it's a bad idea to give them a
display object, even if it's a display that displays messages. Hence I
reacted: passing a mere "MessageReceiver" --interface-- is better.

Now, whether MessageReceiver interface will be implemented by
DisplayWindow, or whether it will be a separate object that references
DisplayWindow, I don't know. I would venture that a separate object is
better because... What if you're not showing DisplayWindow object for
message? I'd personally destroy the object: not on screen, not in
"code". If so, you --need-- a separate object to receive messages. If,
however, you elect to have DisplayWindow object always there, then he
itself can be your MessageReceiver. But dig this: either way you
decide, parts of your program that depend on services of a
MessageReceiver --do not care-- about any of that. As long as you can
pass them a MessageReceiver, you can do what you want "behind" it. In
other words, you just gained a thing caller looser coupling, and that,
in programming, means freedom ;-).

Goran.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web