Elysian Shadows

pubby8 wrote:

TheBuzzSaw wrote:

pubby8 wrote:Which would look cleaner in switch. I dunno, it's just style choice, however you really should avoid "default: break;" - it is bad practice.

According to who? Frankly, I do stuff like that all the time to prevent the compiler from blasting out warnings: "YOU DIDN'T ACCOUNT FOR EVERY POSSIBILITY! WE'RE ALL GONNA DIE!" If you know you haven't hit every option, you really should have the default there, even if it doesn't do anything.

The whole reason compiler complains is because not having a default label is identical to a "default: break;" label!

And? Nobody is denying that. Does that mean you are cool with a slew of compiler warnings because you know that behind-the-scenes it's still getting your shit done correctly?

GyroVorbis wrote:

pubby8 wrote:

TheBuzzSaw wrote:

pubby8 wrote:Which would look cleaner in switch. I dunno, it's just style choice, however you really should avoid "default: break;" - it is bad practice.

According to who? Frankly, I do stuff like that all the time to prevent the compiler from blasting out warnings: "YOU DIDN'T ACCOUNT FOR EVERY POSSIBILITY! WE'RE ALL GONNA DIE!" If you know you haven't hit every option, you really should have the default there, even if it doesn't do anything.

The whole reason compiler complains is because not having a default label is identical to a "default: break;" label!

And? Nobody is denying that. Does that mean you are cool with a slew of compiler warnings because you know that behind-the-scenes it's still getting your shit done correctly?

Most compiler warnings are stupid, and it makes more sense to disable the stupid ones rather than write code around them.

pubby8 wrote:

GyroVorbis wrote:

pubby8 wrote:

TheBuzzSaw wrote:

pubby8 wrote:Which would look cleaner in switch. I dunno, it's just style choice, however you really should avoid "default: break;" - it is bad practice.

According to who? Frankly, I do stuff like that all the time to prevent the compiler from blasting out warnings: "YOU DIDN'T ACCOUNT FOR EVERY POSSIBILITY! WE'RE ALL GONNA DIE!" If you know you haven't hit every option, you really should have the default there, even if it doesn't do anything.

The whole reason compiler complains is because not having a default label is identical to a "default: break;" label!

And? Nobody is denying that. Does that mean you are cool with a slew of compiler warnings because you know that behind-the-scenes it's still getting your shit done correctly?

Most compiler warnings are stupid, and it makes more sense to disable the stupid ones rather than write code around them.

Clearly demonstrating your lack of experience here...

I really miss arguing with avansc and people who are actually intelligent over whether the trivial little things took more clock cycles at a low level or used more memory. Arguing based on compiler warnings and style is honestly below me. I'm done.

@op, Im actually kind of interested in these kinds of things. I always enjoy reading schoolwork code, I like to see what it may be like when I get to college. And this kind of code is usually a good reference, especially with all the commenting and whatnot.

@drama ...really?

JaxDragon wrote:@op, Im actually kind of interested in these kinds of things. I always enjoy reading schoolwork code, I like to see what it may be like when I get to college. And this kind of code is usually a good reference, especially with all the commenting and whatnot.

@drama ...really?

frlz. It be all elysian shore up in here.

pubby8 wrote:

GyroVorbis wrote:

pubby8 wrote:

TheBuzzSaw wrote:

pubby8 wrote:Which would look cleaner in switch. I dunno, it's just style choice, however you really should avoid "default: break;" - it is bad practice.

According to who? Frankly, I do stuff like that all the time to prevent the compiler from blasting out warnings: "YOU DIDN'T ACCOUNT FOR EVERY POSSIBILITY! WE'RE ALL GONNA DIE!" If you know you haven't hit every option, you really should have the default there, even if it doesn't do anything.

The whole reason compiler complains is because not having a default label is identical to a "default: break;" label!

And? Nobody is denying that. Does that mean you are cool with a slew of compiler warnings because you know that behind-the-scenes it's still getting your shit done correctly?

Most compiler warnings are stupid, and it makes more sense to disable the stupid ones rather than write code around them.

People thought I say stupid things

GyroVorbis wrote:

N64vSNES wrote:

Code: Select all

glOrtho(0, SCREEN_WIDTH, SCREEN_HEIGHT, 0, -100, 10000);

Wut?

Haha, what? Why you hating?

I'm not hating just through my entire OpenGL book I've never seen a depth distance as far apart as -100,10000

Out of curiousity when people here are developing in OpenGL do you ever use gltools. I use it a fair bit when I don't want to write custom shaders. It comes with stock shaders that would be enough for most basic ogl projects. Also it allows you to stay current because it uses the core implementation so there's no use of deprecated functions.

eatcomics wrote:

JaxDragon wrote:@op, Im actually kind of interested in these kinds of things. I always enjoy reading schoolwork code, I like to see what it may be like when I get to college. And this kind of code is usually a good reference, especially with all the commenting and whatnot.

@drama ...really?

frlz. It be all elysian shore up in here.

pubby8 wrote:The whole reason compiler complains is because not having a default label is identical to a "default: break;" label!

You're missing the point. It's a warning, not an error. It is good to have one because not having one generally implies you have not explicitly declared what happens if no match is found. It's not bad to have "default: break;" because it tells other programmers on your team, "If no matches are found, I acknowledge that I want nothing to happen." Having nothing is bad practice because it implies, "I assumed it would always hit one of the upper possibilities".

MrDeathNote wrote:Out of curiousity when people here are developing in OpenGL do you ever use gltools. I use it a fair bit when I don't want to write custom shaders. It comes with stock shaders that would be enough for most basic ogl projects. Also it allows you to stay current because it uses the core implementation so there's no use of deprecated functions.

Personally, I'm not a fan. It tries to mimic the old immediate mode for comfort's sake, and I have long since moved onto using my own VBO classes. As far as stock shaders go, those take like 2 seconds to write, and I have a nice Shader class. ^_^

TheBuzzSaw wrote:and I have long since moved onto using my own VBO classes. As far as stock shaders go, those take like 2 seconds to write, and I have a nice Shader class.

+1

TheBuzzSaw wrote:

MrDeathNote wrote:Out of curiousity when people here are developing in OpenGL do you ever use gltools. I use it a fair bit when I don't want to write custom shaders. It comes with stock shaders that would be enough for most basic ogl projects. Also it allows you to stay current because it uses the core implementation so there's no use of deprecated functions.

Personally, I'm not a fan. It tries to mimic the old immediate mode for comfort's sake, and I have long since moved onto using my own VBO classes. As far as stock shaders go, those take like 2 seconds to write, and I have a nice Shader class. ^_^

I agree about the VBO's and shaders, but for ppl with less experience i think it's a great idea. And isn't using it for comfort's sake the point, what I mean is that if i'm writing a quick app I don't want to have to go and write boiler plate code every time. For a larger project you're 100% right, and I prefer it the same way.

MrDeathNote wrote: I agree about the VBO's and shaders, but for ppl with less experience i think it's a great idea. And isn't using it for comfort's sake the point, what I mean is that if i'm writing a quick app I don't want to have to go and write boiler plate code every time. For a larger project you're 100% right, and I prefer it the same way.

Well, but I'm referring to quick projects too. My classes make it so easy to set stuff up that I just use them instead of GLTools even for small quick ideas.

I should write the OpenGL SuperQur'an.

N64vSNES wrote:

GyroVorbis wrote:

N64vSNES wrote:

Code: Select all

glOrtho(0, SCREEN_WIDTH, SCREEN_HEIGHT, 0, -100, 10000);

Wut?

Haha, what? Why you hating?

I'm not hating just through my entire OpenGL book I've never seen a depth distance as far apart as -100,10000

Looks like you need a book that covers a broader spectrum.

You're missing the point. It's a warning, not an error. It is good to have one because not having one generally implies you have not explicitly declared what happens if no match is found. It's not bad to have "default: break;" because it tells other programmers on your team, "If no matches are found, I acknowledge that I want nothing to happen." Having nothing is bad practice because it implies, "I assumed it would always hit one of the upper possibilities".

So you are saying that it is good or bad practice? :s

And on topic of stupid warnings, the "/*" inside comment warning is perhaps the most annoying of them all (although strict aliasing rules is close second)