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

> 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 




[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