Thread: General questions about style, syntax and best practices.

No, the lesson is, "Use exceptions for errors that are forced on you by the environment." Files that have gone missing, network connections that are broken, memory that has run out.
When your application consists of smaller components, one component could treat all other components as "environment" which would extend this notion beyond things that are really outside the program, but the general idea is still there.

So, what I gathered from this thread: "Avoid exceptions unless the problem is 'somewhat' irrecoverable".

O_o

That's a little extreme while being vague.

I can't presently think of a way to put it in words.

I would not phrase it the way CornedBee has either, but as he said, the general idea is there. ^_^;

Soma

I tend to use exceptions for situations that should not happen. How you define "should" varies, of course, but it could mean that most executions of the program will never fire that exception, or it could mean that there's no good way to recover, etc. Basically, it's something very unusual. It's worth keeping in mind that exceptions are expensive in terms of execution speed, so you really don't want an exception firing every time the player tries to unsuccessfully fire a weapon.

asserts are for programmer errors that shouldn't happen. Exceptions are a similar mechanism for runtime errors, the way I see it.

Originally Posted by skyliner

1- Sould non void functions always return a value ?
Lets say I have a function that returns true if some condition is met. Should it return false if it isn't ?

Yes.

Originally Posted by skyliner

2- does checking many conditions at once affects performance more than using nested if-elses ?

It depends on what the compiler does, and in fact the result could be exactly the same. So, strive for readable code.

Originally Posted by skyliner

3- is it OK to allow a variable to be assigned the same value over and over, for convenience purposes. Or is it better to check if the variable has the value already ?

It depends on how expensive it is to copy the value versus how expensive it is to check the value, with other factors that may come into play, plus what the compiler does.

Originally Posted by skyliner

4- Which leads to the main question, what is more expensive for the cpu; retrieve the contents on a var and compare them, or simply writte to to memory ?

It depends. If there is a performance bottle neck related to this, I would test and measure rather than try and reason about it, though I might reason about it when analysing the results.

Originally Posted by manasij7479

Would many if's in a row utilize short circuiting like the conditional operators ?

Logically,

Code:

if (a && b) {
    // ...
}

is equivalent to:

Code:

if (a) {
    if (b) {
        // ...
    }
}

The short circuiting is implied in the logical structure.

Originally Posted by skyliner

4- Which leads to the main question, what is more expensive for the cpu; retrieve the contents on a var and compare them, or simply writte to to memory ?

It's unlikely to matter very much, especially if optimizations are enabled. The compiler will likely reason that

Code:

var = 7;

and

Code:

if(var != 7) var = 7;

are exactly equivalent. In fact I'd be inclined to give it the first and simpler version, just so that the compiler's internal data structures are simpler (thus giving it a better chance of being able to perform more complex, and ultimately more useful, compiler optimizations).

Let me explain in a bit more detail what's going on in each case. The compiler will place variables in registers (especially in the context of a loop), so that "var = 7" probably won't immediately put a request to set var onto the system bus. It will just set a register. When the function exits or whatever, the register value will be put back into memory. But while var is in a register, it involves almost no cost to check it against 7; it will literally be one instruction cycle (well, maybe a few more but certainly very few).

When the value is put on the system bus, however, that's when things slow down. (This is why you should enable compiler optimizations.) It will probably take at least a hundred CPU cycles for the value to be written to memory, maybe less if it happens to be able to fit into the L1 cache. See, main memory access (RAM) is so slow that computers have an L1 cache, a larger but slower L2 cache, and sometimes even an L3 cache to speed it up. This is why the compiler will put your variables into registers.

I'm not certain, but an educated guess would be that a write-only instruction would be faster than "if(var != 7) var = 7"; your program wouldn't have to read var into memory, just put a write on the bus. So that's another reason in favour of "var = 7".

Finally, modern CPUs almost always execute several instructions simultaneously (in parallel, in the "pipeline"). If your program has 100 instructions a CPU will start with the first 8 at least, execute different stages of each instruction, shuffling them around so that there aren't any dependencies. If the CPU can't do this, it stalls -- it waits, idle, doing nothing. You could have a pipeline stall if you have lots of memory accesses (but for certain programs, you can't avoid this). You could also have a pipeline stall if a branch-prediction went wrong. Because the CPU has to guess which way a branch (e.g. for an if statement) will go: to take the branch, or not to take it? And if it guesses wrong it has to flush all those partially-executed instructions it was evaluating and start over. Pretty bad for performance.

The upshot? I think "if(var != 7) var = 7" will introduce a branch in unoptimized machine code. And any branch like that has the potential to be incorrectly guessed and cause a pipeline stall. Basically, don't introduce branches if you don't have to. But again, if you have optimizations enabled the compiler will almost certainly do away with the branch.

I should mention that these are very low-level details that won't matter one whit unless your code is inside a whole bunch of loops that execute millions or billions of times. An average unoptimized function call has way more impact (plus memory accesses!) than you introducing a branch ever would. And if it's optimized, chances are the compiler will rewrite it so much that you wouldn't recognize your own code, if you ever looked at its assembly.

So basically, don't worry about it unless you've really determined that something is a bottleneck with some kind of profiler. Write whatever code makes the most sense, in the context of your program; readability is what matters. If it's slow, turn up the optimization level and let the compiler do what compilers do best: magic.

[The "magic" numbers in this post are meant as rough approximations only. Take them with a grain of salt, but the overall idea holds.]

Originally Posted by dwks

The compiler will likely reason that

Code:

var = 7;

and

Code:

if(var != 7) var = 7;

are exactly equivalent.

They aren't under the C++11 memory model, and a compiler that reasons this way is buggy. Yes, it's weird, but in theory you could construct a program that produces a race condition with the first snippet but none with the second.
That said, the first snippet is still better unless the type of var is really far more expensive to copy than to compare.

Thank you all very much for your answers.
Please, allow me to clarify that I have absolutely no problems with performance. At this point my limited skills allow me to write little more than simple console applications, which barely make my CPU yawn.

The reason behind my question is purely academical; I'd like to build a solid base and acquire good programming habits, that's all.

Originally Posted by dwks

I should mention that these are very low-level details that won't matter one whit

I am fascinated by those low level details. It is the reason I switched my major to engineering instead of CS and I hope someday I can master those obscure secrets

Thanks for your explanation!


EDIT: is there any chance you guys have any advice on how to write proper source code documentation ?
I found this resource http://www.bgsu.edu/departments/comp...mentation.html while searching online, but I'm a bit overwhelmed by its level of detail. I think it might be overkill for my 450+ lines project.
Is all that really necessary, specially the pseudocode section ?

Originally Posted by skyliner

is there any chance you guys have any advice on how to write proper source code documentation ?
I found this resource C++ Program Documentation Guidelines while searching online, but I'm a bit overwhelmed by its level of detail. I think it might be overkill for my 450+ lines project.
Is all that really necessary, specially the pseudocode section ?

Please start a new thread for this topic. If not, those people who have something to say about "how to write proper source code documentation" but nothing to say about "style, syntax and best practices" simply won't help you because they had no inkling that you were asking about it.