Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Redundant if statements

Status
Not open for further replies.

Nosferatu

Programmer
Jun 9, 2000
412
RO
Hello all...

I have this concern about redundant if statements.

I am coding a highly modularized C project and, of course, I want to get the best performance around.
As I know, the advantages of pipelining in processors are diminished by using an large number of conditional statements which reduce the chance of predictability over the program's execution path.
Now, considering that the structure of the code is going to be highly hierarchical (besides modular), I wonder if it wouldn't be the best to enforce parameter checking on the higher levels of the code and leave the params alone for the lower layers.

Usually, I proceed on checking virtually every parameter that gets into the function, but I believe that this would result in unnecessary wasted processor cycles.

My question is: Is this a wise/common thing to do in large application?

Thank you!

[red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro
 
Hello, Nosferatu

You can use 'assert' statements. This kind of statement are very useful in coding, debugging and in system integration labours.

One advantage is that when you compile in 'release' mode, assert's won't be included in executable. This way, you have a powerful tool in developing tasks and obtain a fast final code.

Regards.

Polu.
 
Indeed, thanks, Polu.
This is just what I am doing.
But I was more concerned about the implications of this line of coding if the final product is going to be a toolkit in source-code format.

What I want to say by coding this way is: if illegal parameters are going to be passed to functions of such level, the results are going to be dissastrous and that's the USER's fault, not mine.

Actually... I believe this is the way the standard C library works, right? Just pass NULL to strcpy and you get a crash...

So, I'll stick to this coding style.

Regards,
--Razvan Costea-B. [red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro
 
Two comments:

Why do you WANT to get the best performance around?
Do you NEED the best performance around?
Dont optimise unless you have to!

I'm not 100% sure of the structure that you describe, but I'm a bit worried. Bertrand meyer introduced the concept of a 'programmer's contract', where the called routines are assumed to provide correct data and so that data is never checked at a higher level. This is a very valuable concept. Basically, the guy who creates or retrieves the data checks it and every other routine accepts that he has done that.

However, it is still prudent to put checks in at other points, particularly if the data is critical. For example, if you create a module, the module interface may want to check it again, at least with an 'asserts'. In theory, for the same reason, this check should be on the module side of the interface, but I find it hard not to have the client check it as well.

Gil
 
Gil...

I am not sure I follow your first two comments. Yes I need the best performance around, simply because the system to be written has to be scallable at the extent Google is, thus the best performance around IS needed or the performance will get sucky as the system grows.

Indeed, the "programmer's contract" you point me to is what I intend to do: just check the data at the highest levels (you've put that the other way around) and assume it will go down smoothly till' reaching the point where it should be processed.
For that though, I guess I need some heavy data-flow diagrams which are not at hand yet (they're only in my head, and sometimes, the paths get mixed there :-().

Regards,
--Razvan
[red]Nosferatu[/red]
We are what we eat...
There's no such thing as free meal...
once stated: methane@personal.ro
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top