general advice on programming pratices

[monkey_king]

Hi I have a some general questions, some are c others are c++ related.
So I'll just post them here in the c++ forum.
These question only relates to speed not so much design issues.

So far most of my programming has just been about making it work.
That is getting the program done fast and correct.
I haven't been concerned about speed and portability.

1. I know it's good programming practice to make accessor's const.
   But does it impact speed.
   An example:
   If I have a huge matrix class, which I will only read from, after I have instantiated the object.
   Will I get any speed benifits from making the the accessors const. (making it nonmutable)?
2. Will I get any performance gains by using static keywords, where ever it's possible
3. Will I get any performance gains by using const keywords, where ever it's possible
4. If I made a uml diagram of my programs, they look relative alike. I never use the "smart" stuff, like protected and virtual function. Should I start looking into this. Or is it simply something that you use when you have to give a presentation. According to http://people.redhat.com/drepper/dsohowto.pdf the virtual functions are especially to avoid.
5. scope of variables. I was always told to avoid using global variables, usually after being told never to use gotos. But other than the confusion of variable shadowing, what is so bad about it. Also recycling of temp vars.
   An example:
   Given a huge function, for the ease of of code reading, I normally just throw new variabels around, even though they are relatively easy to calculate from one another. Like b=2*a an so forth. Does the compiler now adays do this lowlevel optimization.
6. loops. I have some very long loops, these will make no sense to unroll. But the smaller ones. Say 5-10 times, should I manually unroll these, or are there no speed benefit from unrolling them.
7. dynamic arrays vs fixed sized arrays. I mostly use dynamic arrays. But I read in the dsohowto, that these should be avoided. that is int[5] is prefereble to int*, since these can be fixed in the relocation table. Does it make a difference, or is it just academia

thanks in advance.

[Ancient Dragon]

1) 2) and 3). Very little, if any, performance gain. Those are not areas to optimize because the compiler will do that.

4) You talking about c++ classes? vertual class methods are extremly handy and I've used them often at my work (before I retired that is).

>>the virtual functions are especially to avoid.
That just a bold-faced lie.

5) >> I was always told to avoid using global variables
Yes, absolutely. Globals should be avoided whenever possible, but there are times when its not possible to avoid them. MS-Windows GUI programs (especially MFC) is a prime example.

>>usually after being told never to use gotos
Agree. NEVER EVER (almost anyway) use gotos. There is almost always a better way to create a branch.

>>Does the compiler now adays do this lowlevel optimization
yes, at least it tries to. Optimizing compilers will even toss out code that it thinks does nothing and move code around to make the program more efficient. Some compilers are better at that than others.

7) Depends on the situation whether to use dynamic arrays or not. IMO it is better to just use statically allocated arrays for small arrays. Its even better to use std::vector or similar containers in c++ programs than c-style arrays.

>>Does it make a difference, or is it just academia
Probably does make a very very small difference, but its mostly academic. Readability, clarity, and maintainability are significantly more important.

[AceofSpades19]

7) Depends on the situation whether to use dynamic arrays or not. IMO it is better to just use statically allocated arrays for small arrays. Its even better to use std::vector or similar containers in c++ programs than c-style arrays.

are STL containers faster then c-style arrays?

[Ancient Dragon]

>>are STL containers faster then c-style arrays?
No. you can't get any faster access than c style arrays. But that isn't the point -- c++ STL eliminate many of the problems with c style arrays, such as dynamic array allocations. vector and other containers expand/contract by themselves, and they always know their size, unlike c style arrays.

[Alex Edwards]

>>are STL containers faster then c-style arrays?
No. you can't get any faster access than c style arrays. But that isn't the point -- c++ STL eliminate many of the problems with c style arrays, such as dynamic array allocations. vector and other containers expand/contract by themselves, and they always know their size, unlike c style arrays.

Don't forget the Pattern-implementation of iterators too! They provide an interface for unrelated iterable types to be related.

[ArkM]

1. Yes for a very good optimizing compiler. There are lots of non-performance advantages to do that.
2. As usually, no. Moreover, you have a good chance to get non-reenterable code then forget multi-threading and other acceleration methods.
3. See #1.
4. As usually, the virtual function call includes additional memory access (indirection) so formally it's (slightly) slower than non-virtual call. However there are lots of programming case where a proper using of polymorhism gets better performance (avoid if/switch cascades). The protected attribute does not bear a relation to performance at all. Since polymorphism and incapsulation are the most valuable aspects of OOP, you MUST become familiar with them ("simply something that you use when you have to give a presentation" - it's one of most absurd statements I have ever seen).
5. Global variables: see Ancient Dragon's reply. Apropos, globals in MS MFC GUI stuff is a sign of not so good design (not the generosity characteristic of GUI programming). Of course, performance issues are not the main reason to avoid globals. But almost every access to a global variable as usually requires save/load/restore CPU register (may be it's more expensive than virtual function call). About recycling of temp vars: see #1, the 1st point. Don't use it excessively: it's enough. Make a scope of an entity as local as possible - may be, it's the best solution for performance (too).
6. It depends. To unwind small loops: as usually, you need profiling for the right solution.
7. If you can to declare fixed size array - do that. Use minimal necessary dynamic data structures (for example, think about std::valarray instead of std::vector). About your example with int[5] array and a pointer to int: of course, your compiler knows an offset of an (local only!) array in the current stack frame and can use this knowledge to generate more effective code (as usually, it keeps stack frame register intact). See #1 again.

Moral: a good and impressive design (including thorough algorithmes and data structures selection - or better object model design) must have a priority over a narrow local performance issues. After that get a profiler (or other measurement tools) and start to refine your code. Don't disperse your programming talents on petty intrigues with local "effectiveness".

[monkey_king]

Thanks very informative.

But I had another question.
The use of unsigned vs signed variabels.
I never use negative values in, say, control variabels in loops.
So should I begin to use uint?
Alot of people are using size_t to denote non negative size's in datastructures.

Is this a good thing to adopt.

Thanks again for you replys.

[Nick Evan]

If I don't need negative numbers, I always declare them unsigned. In theory they should be marginally faster to process, but I use to give them to indicate that a number will never be negative. It improves the readability of the code.

And about goto's (question #5 in post #1), see the attachment:

[Narue]

>I know it's good programming practice to make
>accessor's const. But does it impact speed.
It can, but usually nowhere close to as much as many people believe. const is more for your benefit because it helps make your code easier to work with by adding compile-time invariants.

>Will I get any performance gains by using static keywords, where ever it's possible
Possibly, but it really depends on what you're doing. For example, let's say you have an array of large objects that won't fit in a single cache line. Hoisting some of the data members into statics (if possible) could drop the size of each object to the point where the array fits in a cache line and you might see a sudden and significant increase in performance.

>Will I get any performance gains by using const keywords, where ever it's possible
If saying yes will get you to use const more, then yes. :)

>I never use the "smart" stuff, like protected and
>virtual function. Should I start looking into this.
If you don't need it, don't use it. But if you don't understand it, you don't really know if you don't need it.

>According to <snip url> the virtual functions are especially to avoid.
Virtual functions have an overhead that needs to be considered. But that implies a trade-off, not an "avoid this feature" guideline. I highly recommend you take such advice with the context in which it's given.

>I was always told to avoid using global variables,
>usually after being told never to use gotos.
Both of those are of the "if you don't know how to do it right, don't do it" category. Keep that in mind.

>But other than the confusion of variable shadowing, what is so bad about it.
Transparency and maintenance. You want your code to be as easy to read and work with as possible. Global variables make both of those harder because you need to know exactly where and how the variable could be changed...but it could be changed anywhere. Goto is similar in that many people have trouble with the flow of control and the subtle rules involved in jumping unconditionally.

>should I manually unroll these, or are there no speed benefit from unrolling them.
Don't micro-optimize until it's the right time. More often than not you can gain more by changing higher level design choices than by tweaking low level ones.

>But I read in the dsohowto, that these should be avoided.
I think you're putting far too much weight on that document.

>So should I begin to use uint?
You should write for clarity as a primary goal. If an unsigned type makes your intentions more clear, by all means use it. But keep in mind that mixing signed and unsigned types in an expression can cause surprises.