Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Crash on Exit Passing RenderWindow to Class  (Read 6669 times)

0 Members and 1 Guest are viewing this topic.

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: Crash on Exit Passing RenderWindow to Class
« Reply #15 on: October 26, 2015, 10:31:14 am »
Global variables makes spagetti code, you will not be able to reuse it and it will be hard to split the code on smaller parts. Also it makes big troubles with multithreading.

By the way, as I remember, there is no way to implement thread safe initializer for global variables with old c++ standard compiller. Does new c++ standard provides the way to do it?

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: Crash on Exit Passing RenderWindow to Class
« Reply #16 on: October 26, 2015, 11:40:22 am »
Tell that to the makers of Valve's Source Engine. Tons of globals there, that's kind of where I was getting some inspiration from. I've been programming under the Source Engine for quite a while now. But there's tons of global variables, externs all over the place, and whatnot.
The programmers at Valve know what they are doing so I'd say its safe to give them a bit of an exception here  :P
Typical fallacy: argument from authority

The fact that one big company does something may be the result of various reasons, including historical or political ones -- in short, you don't know the backgrounds. Assuming that it's purely because of better design is risky, and applying the same reasoning to your own code, which has completely different preconditions, is a mistake.

This from a purely logical standpoint. There are objective arguments why global variables are problematic if used too often, see for example here. Please inform yourself carefully and be skeptic what you hear, instead of just thinking "ah, the big guys do it, so it must be right". Most progress in C++ during the decade of C++98 has been made by guys who questioned the common old ways of doing things -- and that was a huge step forward, considering that the language hasn't changed at all until 2011.

Tip: in C++, it's usually better to look at how people don't do things ;)sion can go on uninterrupted. Don't open a thread now -- but thanks for reproducing the issue :)

While I agree with you whole heartedly I'd still like to make the point that global variables are strongly discourages BUT that doesnt mean you cant/shouldnt use them ever, just use them with caution.

Satus

  • Guest
Re: Crash on Exit Passing RenderWindow to Class
« Reply #17 on: October 26, 2015, 12:55:56 pm »
While I agree with you whole heartedly I'd still like to make the point that global variables are strongly discourages BUT that doesnt mean you cant/shouldnt use them ever, just use them with caution.

Instead of using them with caution, it is way better and easier to just not use them at all since you probably will never need them anyway.

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: Crash on Exit Passing RenderWindow to Class
« Reply #18 on: October 26, 2015, 01:11:25 pm »
I would have thought "use them only if you have a logical and valid reason to use them" would be the best version of the advise. As it is with most other things that people use that they generally shouldn't. If they can justify why they use them and that justification is logically sound, then fine, let them use them.

mkalex777

  • Full Member
  • ***
  • Posts: 206
    • View Profile
Re: Crash on Exit Passing RenderWindow to Class
« Reply #19 on: October 26, 2015, 03:18:07 pm »
I'm sometimes using it for variables which have no sense to instantiate several times, for example - read only per application dictionary which.

Spirrwell

  • Newbie
  • *
  • Posts: 11
    • View Profile
Re: Crash on Exit Passing RenderWindow to Class
« Reply #20 on: October 26, 2015, 06:15:35 pm »
Wow, I never expected to come back here and see a full blown debate about the use of global variables. I apologize for kind of deferring from the original topic.

Tell that to the makers of Valve's Source Engine. Tons of globals there, that's kind of where I was getting some inspiration from. I've been programming under the Source Engine for quite a while now. But there's tons of global variables, externs all over the place, and whatnot.
The programmers at Valve know what they are doing so I'd say its safe to give them a bit of an exception here  :P
Typical fallacy: argument from authority

The fact that one big company does something may be the result of various reasons, including historical or political ones -- in short, you don't know the backgrounds. Assuming that it's purely because of better design is risky, and applying the same reasoning to your own code, which has completely different preconditions, is a mistake.

This from a purely logical standpoint. There are objective arguments why global variables are problematic if used too often, see for example here. Please inform yourself carefully and be skeptic what you hear, instead of just thinking "ah, the big guys do it, so it must be right". Most progress in C++ during the decade of C++98 has been made by guys who questioned the common old ways of doing things -- and that was a huge step forward, considering that the language hasn't changed at all until 2011.

Tip: in C++, it's usually better to look at how people don't do things ;)

It may be related with topic starter issue and may not be related.
Because of that it would have been nice to open a different thread and post a link here, so the original discussion can go on uninterrupted. Don't open a thread now -- but thanks for reproducing the issue :)

Oh I was never defending what they do, by God I hate the Source engine, yet I now program with it almost every day. I hate it, I hate it, I hate it. Also the Source engine was built off of old Quake engines and whatnot. I just find it interesting that programming under this for so long has influenced my coding style. I don't think I ever made a single global variable when coding under Unity, but that's C# not C++.

Agh, I'm doing it again. Sorry for the off topic rant, feel free to lock the topic, I just really get into these types of discussion, even if it is off topic.
« Last Edit: October 26, 2015, 09:04:45 pm by Spirrwell »

 

anything