Two minor language questions

1. This compiled in GCC, but is it okay to return a void type in a void function?

Code:

---

void g() {}

void f() { return g(); }

int main() { f(); }

---

2. Does "forwarding" inlined functions incur any overhead? Tell me if the first code should run any differently from the second.

Code:

---

struct func
{
  void operator()() { /*something*/ }
};

---

Code:

---

struct func
{
  func(bool which_) : which(which_) {}
  void operator()() { return which ? fun1() : fun2() }
  void fun1() { /*something*/ }
  void fun2() { /*something similar*/}
 private:
  bool which;
};

---

I'm trying to add a feature, without any overhead, and without having to rewrite a ton of code. My advisor has "but now we should make it do this" syndrome.

Thanks in advance for all of your wisdom.

*edit* I could use virtual functions for #2. Would that be efficient?

For the first, I believe you're ok, but I'm not sure what's wrong with

Code:

---

g();
return;

---

or even

Code:

---

g();

---

since it's not as though return is expected in a void function.

As for the second (there's that extra return again), I would suggest you do both and see which one works better. My instinct tells me that the second is going to have to be at least a very tiny bit slower than the first (since there's always going to be an if/?: hanging around), and inlining two functions in one spot may not look good to the compiler. Since that's what my instinct says, I would imagine it's going to come out the other way.

True. I'll try both.

I must admit that the virtual solution is tantalizing. Do optimizers ever look through virtual calls?

Regardless, I'll do as you said and try all of the options.

Quote:

---

Originally Posted by CodeMonkey

I'm trying to add a feature, without any overhead, and without having to rewrite a ton of code.

---

Quote:

---

Originally Posted by CodeMonkey

I must admit that the virtual solution is tantalizing.

---

As you may know, the use of such polymorphism can help in implementing the open-closed principle, and hence it is possible that with an appropriate design you can "add a feature" without having to rewrite any code, except for the small portion that handles the invoking of the new code.

Unfortunately, since we have no idea as to what is your current code, it may well the case that you still have to "rewrite a ton of code".

Quote:

---

Originally Posted by CodeMonkey

Do optimizers ever look through virtual calls?

---

I have little idea of what kind of optimisations could be performed on virtual calls other than to make it a non-virtual call if possible. On the other hand, it may well be the case that your aim of zero overhead is too aggressive, and that even this presumably time critical code can perform within expectations with the overhead of a virtual function call. You would need to measure to find out.

Thanks, Laserlight. I'll post with more contextual code tomorrow, when I'm not so tired.

As it turns out, I can apply the feature in such a way that this difference is not time critical. Thank you, though, for your time.
*I'll be using the virtual method*

The overhead of a virtual call vs. a non-virtual is normally not a lot - one or two extra instruction(s) on RISC processors, and an extra indirection on the call instruction x86 and other CISC processors. This will most likely be less than the effect of a conditional, e.g

Code:

---

which ? fun1() : fun2()

---

unless you are expecting ALL of that to be inlined. The only case where there will be a huge difference is where the compiler can determine what the value of "which" is at compile-time (and fun1() and fun2() are so short that they amount to less than half a dozen instructions).

Without knowing further what which, fun1 and fun2 actually look like, it's hard to say what the difference it would make - but virtual is ALMOST always better than the alternatives, because you avoid (possibly unpredictable) branches.

--
Mats