Followers 0

# Your one stop shop for the cause of all coding horrors

## 37 posts in this topic

My personal project right now is a world conquest game that has various source files for rendering the globe. The internal name of the project (i.e. the one I use in code, not the one it will release under) is Globo.

I think of that Smurf Naming thing every time I type: #include "Globe/Globo_Globe.h"

0

##### Share on other sites

"Heisenbug"

yeah, those are annoying...

like, bug which is annoyingly hard to recreate and occurs rarely, may appear only when not run in a debugger, or when the code is stopped/single-stepped there is no evidence of the bug's existence... (ex: program runs with a bug, set a break-point, single-step, and everything works as intended...).

may sometimes be due to "spooky action at a distance", like (off somewhere in some distant part of the program) instead of writing "foo[x*y+z]=...;" one wrote "foo[x*y*z]=...;" which may otherwise go largely unnoticed if it fails to land on an unused memory address (may be very common for programs where most of the address space is in-use).

may be also be called "dude, where's my RAM?" if it also results in an intermittent memory leak.

Edited by BGB
0

##### Share on other sites

I have to admit, the Egyptian brackets do annoy me. But then, lower-cased first letters of functions names annoyed me, but now I prefer it that way. So did underscores in variable names.

0

##### Share on other sites

Egyptian brackets do annoy me

I prefer Egyptian brackets because it eats less lines. Indents give enough information what is inside which block so I don't need brackets to tell me same thing.

0

##### Share on other sites
function EgyptianizeTheBracket(){
looks missing;
}

function UnEgyptianizeTheBracket()
{ for short lines;}

function UnEgyptianizeTheBracket()
{
for longer lines;
}


Good point Zaoshi. I just think that having them on the next line shows the start and end of the code inside the function. Along with indentation it just looks neater.

Edited by Tutorial Doctor
0

##### Share on other sites

I've been using Egyptian brackets for a long time, so I read indentation, not brackets. When I have to read code based on brackets instead of indents it's too hard for me (luckily VS2013 has autoformatting!).

0

##### Share on other sites

I love egyptian brackets but not everywhere, i think they are most fitted for ifs and while/for loops. Function and switch should use normal brackets style.

void Function()
{
if(x == 1){

}

for(;;){

}

switch(x)
{
case 0: ...
}
}

1

##### Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

Edited by Vortez
2

##### Share on other sites

is ok, e.g. sscanf

0

##### Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

This is not a quirk of the language, its only returning true if the assigned value is truthy, this allows for constructs like the following that are allowed in almost all languages i've ever used:

while (mesh = imaginaryMeshStack.pop()) {
// do stuff with "mesh" here
}



EDIT: "returning true" is the wrong wording, "evaluates to true" fits better here.

Edited by LJ_1102
0

##### Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

It doesn't really return true, it "returns" the result of the assignement.

if(var = 5) // -> if(5) => true

if(var = 0) // -> if(0) => false


It has its uses though

if(auto pMesh = GetMesh(L"Lala") // only enters when pMesh is no nullptr
{
// DO SOMETHING
}

// pMesh not accessible here
// VS

auto pMesh = GetMesh(L"Lala");
if(pMesh != nullptr)
{
// DO SOMETHING
}

// pMesh still accessible



EDIT:

It does warn you of the opposite, though:

const int constant = 5;
int variable = 0;
variable == constant;

warning C4553: '==': operator has no effect; did you intend '='?

Edited by Juliean
2

##### Share on other sites

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

In my experience, at least VC++ versions 2008/2010/2012/2013 will give "warning C4706" - if your warning level is at least /W4. However, some of the warnings are just noise (constant conditional expression). "/w44706" might be more preferable option (sets warning level for C4706 to 4, without affection others).

http://msdn.microsoft.com/en-us/library/thxezb7y%28v=vs.120%29.aspx

edit: Forgot to add my 2 cents. I hate "Yoda Conditions" and consider it a strictly bad practice. Just do not do it.

Edited by tanzanite7
0

##### Share on other sites

Actually, since i mentioned the existence of useless/unhelpful/bogus warnings - why not share them. For readers benefit:

#pragma warning(disable : 4201) // (BOGUS) nonstandard extension used : nameless struct/union  // C++11 allows it
#pragma warning(disable : 4510) // (BOGUS and USELESS) default constructor could not be generated // generates an incorrect warning with "struct Foo { const int; } snafu[] = {{1}, {2}}; "
#pragma warning(disable : 4610) // (BOGUS and USELESS) struct can never be instantiated - user defined constructor required // this is just wrong (caused by const member variable)
#pragma warning(disable : 4512) // (BOGUS and USELESS) assignment operator could not be generated // it is only a problem when you use it - and it is an error then. What was the point of this warning again?
#pragma warning(disable : 4100) // (UNHELPFUL) unreferenced formal parameter // i prefer to keep the name of the parameter for clarity even if the particular implementation does not use it
#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired
#pragma warning(disable : 4310) // (UNHELPFUL) cast truncates constant value // BOGUS: int16(0x8000), VALID: int16(100000). However - i have never encountered the later.

With thous i have no warnings at all with warning level 4.

0

##### Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

Beside, i dont know about other compilers, but doesn't visual studio warn us about this kind of error as a warning at compile time?

EDIT: Seem like it dosent warn you after all... i was mistaken. That's a weird quirk of the language tho, assigning a value returning true, i never understood why c++ allowed that in the first place.

Depends on how your read it. "if blue matches (is) the color of the sky" or "if tall matches (is) the height description of the man" Gotta name your variables something meaningful. ;)

0

##### Share on other sites

#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

0

##### Share on other sites

Gamedev forum software crapped its pants again, so can not use any formatting. Did my best to make it readable.

------------------------

frob: "4201 is valid unless you told the compiler to use c++11."

VC++ does not have such a specific switch - all that it is capable of supporting is enabled by default. And i use a lot of c++11 features. One might say that vc++ is not really c11 - but that is not an useful distinction as it tries to be everywhere else.

frob: "The invalid automatic functions are correct, these are not things the compiler can automatically generate."

_Nor does it need to_. The warning is a very low priority bug in the compiler: http://connect.microsoft.com/VisualStudio/feedback/details/488660/improper-issuance-of-c4610

Even so, it is still an useless warning as the language does not allow improper use anyway (ie. more than it normally does) - there is nothing worth warning about.

And yes, one should generally avoid such structures. Exceptions excepted (funny: commented out the warning to see where i use them => apparently i do not use them at all anymore [except a few of the assignment ones - adding "=delete" assignments]).

frob: "4100 is a fun one that requires an understanding of the language history."

Interesting. I did not know that backstory. Thanks.

frob: "The 4310 case is VERY valid in this case. int16(0x8000) is an overflow"

Exactly. Which is why it is tagged "UNHELPFUL" instead of "BOGUS" or "USELESS". Unhelpful is a fairly subjective tag (*).

I use, in every language, hex-notation to signify bit-patterns. Ie. "int16(0x8000)" should be interpreted as bit-pattern 0x8000 in int16 storage (_ie. platform dependently interpreted as some 16 bit integer_). Obviously, C does not interpret it that way and never will - not a problem here.

The warning is very rare.

I have only a few of them from various macro-driven tests. Platform specific integer conversion ... the only place where anyone would write stuff like "int16(0x8000)". Hm, i should move the pragma there and undo it after the test section - much more sane. Thanks.

(*) I copy pasted thous few example lines out - leaving out some less likely useful ones (and commented out unused ones) and a few comments. One of them probably bited here. Pragma reminder-comment in split with "//": left of it is about the warning - to the right is for use-case reminders of how one might get the warning etc. So, BOGUS for "int16(0x8000)" does not mean the warning is bogus! - it signifies that it is UNHELPFUL as it is BOGUS for the use-case (the bit pattern fits nicely).

Perhaps i should have left out all the UNHELPFUL tagged ones here due of their high subjectivity.

0

##### Share on other sites

Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.

It happens an awful lot more than you might expect. Defensive coding is important, and it often comes at a perceived cost to readability.

I'd honestly be rather alarmed to meet a senior engineer who didn't write their conditions that way, when coding in C++.

1

##### Share on other sites

#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

while(RUNNING == gameState)
{
// Run Game Code
}
0

##### Share on other sites

Oh, missed a post.

#pragma warning(disable : 4127) // (UNHELPFUL) conditional expression is constant // this is actually almost always desired

It is? Isn't the conditional expression rather pointless if it is constant or am I missing something?

Typical direct example: "while(true) { ... }". But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).

Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

0

##### Share on other sites
while(RUNNING == gameState)
{
// Run Game Code
}

That's not a constant conditional expression, unless gameState is const, which I assume it is not...

But it usually comes indirectly from macros and templates (ie. stuff that is not, in its final, form written by the programmer).
Ie. the warning is valid, but unfortunately tends to flag code that is perfectly fine - which is just too annoying of a problem when one treats warnings as errors that could be temporarily ignored. Hence: UNHELPFUL.

Ah of course, got it.

0

## Create an account

Register a new account