- Forum
- General C++ Programming
- Implements If statement in different way
Implements If statement in different way - more optimized way
Hi,
Once I was in Interview, Intel , and one of the interviewers asked me , if you have if statement , how can you implement that in more optimized way (Do not use switch).
How can you do that?
Thank you
Once I was in Interview, Intel , and one of the interviewers asked me , if you have if statement , how can you implement that in more optimized way (Do not use switch).
How can you do that?
Thank you
Optimized how? In terms of speed or the amount of assembly code generated? Interviewers ask a lot of dumb, condescending, trivia questions in my opinion. It doesn't mean that you won't get the job just because you don't know the answer. Just be honest and say I don't know. I was onced asked a weird question by a panel of interviewers. Other people on the panel admitted that they didn't even understand the question and were surprised by the answer. I simply said, I don't know. I still got the job.
I do not know what to say - 2 stupid engineers made me so nervous.. Just they try to show so smart... :-(
Tell the losers to get a better compiler. The C and C++ if statement translates to very few machine instructions.
The Intel optimizing compiler is one of the best for x86 hardware... Make sure that you don't preload your if statements with extra stuff they don't need, turn on the appropriate optimization level at compilation, and you'll get perfect code every time.
There is a difference, particularly with older compilers, that the ternary operator will produce better code when assigning a value based upon a test. For example, something inspired straight off the Wikipedia ( http://en.wikipedia.org/wiki/Conditional_operator ):
This can potentially compile more efficiently than the equivalent:
A really good compiler should catch that the two are identical, but not necessarily so. If it doesn't, then the code to dereference the target could be duplicated for each branch, whereas it would not be duplicated when using the
Here's the rub: the exact code generated by the compiler has nothing to do with your ability to write efficient, succinct, readable C or C++. The same code will compile and work properly, and usually optimally, everywhere a C or C++ compiler is available. Some CPUs can do X more efficiently than others. Writing code that assumes optimization of a specific processor is ugly, hard to read and maintain, and makes it unportable or exceedingly inefficient on other processors.
Whereas, clean, well-written code compiles everywhere and gives the compiler the ability to do its job: generate optimal machine code. Engineers who want to second-guess the compiler and play assembler themselves are a detriment to the company -- they are wasting time playing with stuff that makes no difference.
In specific instances it is worthwhile to code to a specific CPU and/or architecture. This is where assembly programming becomes useful. But outside specific needs like that it is an abuse of your employer's time to quibble about a 'more optimized if statement'.
Hope this helps.
The Intel optimizing compiler is one of the best for x86 hardware... Make sure that you don't preload your if statements with extra stuff they don't need, turn on the appropriate optimization level at compilation, and you'll get perfect code every time.
There is a difference, particularly with older compilers, that the ternary operator will produce better code when assigning a value based upon a test. For example, something inspired straight off the Wikipedia ( http://en.wikipedia.org/wiki/Conditional_operator ):
*opening_time = is_weekend( day ) ? 1200 : 930;This can potentially compile more efficiently than the equivalent:
|
|
A really good compiler should catch that the two are identical, but not necessarily so. If it doesn't, then the code to dereference the target could be duplicated for each branch, whereas it would not be duplicated when using the
?: operator -- producing a "more optimized" if.Here's the rub: the exact code generated by the compiler has nothing to do with your ability to write efficient, succinct, readable C or C++. The same code will compile and work properly, and usually optimally, everywhere a C or C++ compiler is available. Some CPUs can do X more efficiently than others. Writing code that assumes optimization of a specific processor is ugly, hard to read and maintain, and makes it unportable or exceedingly inefficient on other processors.
Whereas, clean, well-written code compiles everywhere and gives the compiler the ability to do its job: generate optimal machine code. Engineers who want to second-guess the compiler and play assembler themselves are a detriment to the company -- they are wasting time playing with stuff that makes no difference.
In specific instances it is worthwhile to code to a specific CPU and/or architecture. This is where assembly programming becomes useful. But outside specific needs like that it is an abuse of your employer's time to quibble about a 'more optimized if statement'.
Hope this helps.
It could be done with function pointers in an array, but its a bit risikier and I don't know about speed.
like f[0]=&functionfalse;f[1]=&functiontrue;*f[the_bool_or_int]();
I don't know the exact syntax for function pointers....
h
The advatage of this is that it could do more branches of an if; Instead of saying if 1 else if 2 else if 3... (which could be what he meant because he said not to use switch).
like f[0]=&functionfalse;f[1]=&functiontrue;*f[the_bool_or_int]();
I don't know the exact syntax for function pointers....
h
The advatage of this is that it could do more branches of an if; Instead of saying if 1 else if 2 else if 3... (which could be what he meant because he said not to use switch).
Topic archived. No new replies allowed.