next »

[Boreal]

@Boreal - perhaps more readable? certainly terser

Code:

result = (!mode && test(a,b) || mode == 1) ? foo(a,b) : bar(a,b);

This is the original piece of code where the concept was taken from:

http://pigeonsnest.co.uk/stuff/pigeons-device.html

You could argue for splitting that code up into functions but this is very old code (from before C99) so inline functions were not standard and this was done instead as an optimization.  It's similar to Duff's Device in that it uses a switch statement to jump into the middle of a flow control expression.

[Layl]

This is why I love C.

Code:

switch(mode)
{
    case(0): if(test(a, b))
             {
    case(1):     result = foo(a, b);
                 break;
             }
             else
             {
    case(2):     result = bar(a, b);
                 break;
             }
}

Just let that sink in for a bit.

I have no idea what's going on in that code and I'm very scared.

[Geti]

http://pigeonsnest.co.uk/stuff/pigeons-device.html

Today I learned. I wonder how (badly) this kind of thing interacts with modern CPUs. The gruesome hack is certainly unfortunate.

[Boreal]

http://pigeonsnest.co.uk/stuff/pigeons-device.html

Today I learned. I wonder how (badly) this kind of thing interacts with modern CPUs. The gruesome hack is certainly unfortunate.

I doubt that it's an issue, but I don't think it's useful enough for any production-level code to have it.  It's hardly gruesome, just convenient at the time.  Same as the Duff's Device.

If you look at it from the perspective of C89, it's quite safe.

[Geti]

Of course, but it's a shame to have to write that kind of code with extra wrappers to set static variables in your search function. I used the word gruesome because the author did, not to be hyperbolic - I'm talking about the mode setting code at the start of the function that relies on NULL signalling to set or get a static variable storing the mode, not the switch itself. I hope that was clear.

[Boreal]

Of course, but it's a shame to have to write that kind of code with extra wrappers to set static variables in your search function. I used the word gruesome because the author did, not to be hyperbolic - I'm talking about the mode setting code at the start of the function that relies on NULL signalling to set or get a static variable storing the mode, not the switch itself. I hope that was clear.

Oh, yeah, that was some nasty stuff.

[tjcbs]

Today I learned. I wonder how (badly) this kind of thing interacts with modern CPUs. The gruesome hack is certainly unfortunate.
[/quote]

It's just an indirect branch, right? The Gruesome Hack seemed like a consequence of anti global variable ideology, or maybe the author just wanting to be different, hardly something he had to do.

[Geti]

But it creates a global anyway! Doesn't polute the namespace I guess but it's not concurrency safe, invokes overhead each time the function is called and isn't a usable pattern for anywhere you may need to compare nulls - the last one not an issue for qsort etc but prevents it from being a general-use comparator. It's certainly an interesting way of doing it while getting around the interface requirement, but I'm not sold on it As you said, could be accomplished in other ways.

[Sik]

Honestly it seems more of waiting to avoid repeating code. I mean, the more usual (and much more readable) way to do it would be:

Code:

switch (mode) {
   case 0:
      if (test(a, b)) {
         result = foo(a, b);
      } else {
         result = bar(a, b);
      }
      break;
   
   case 1:
      result = foo(a, b);
      break;
   
   case 2:
      result = bar(a, b);
      break;
}

If one wants to avoid repeating code there's always the possibility of doing this instead, assuming the original value of mode doesn't need to be retained (or that specific value of mode can be altered to mean what the test says, which is very likely the case and would simplify any code after it):

Code:

if (mode == 0) {
   if (test(a, b)) {
      mode = 1;
   } else {
      mode = 2;
   }
}

switch (mode) {
   case 1:
      result = foo(a, b);
      break;
   
   case 2:
      result = bar(a, b);
      break;
}

(leaving the switch there for the sake of example, e.g. you could have a default clause as well, or also more modes)

[tjcbs]

I think geti got that logic to almost its tersest form, but if you reeeallly want to avoid duplication:

Code:

result = (((test(a,b) | mode) == 1) ? foo : bar)(a,b);

[Geti]

Hahaha, I actually considered going that route but I'm not sure the functions can be inlined there if necessary. If someone knows concrete details for any compiler let me know but as far as I can see semantically you're treating them as function pointers there, albeit deterministically. Certainly very terse though, the OR is a nice (if fragile) touch.

[Sik]

Compilers will inline when given the chance or make a normal function call if they can't (as long as the code produces the same result they can do whatever they want). In fact the inline keyword is kind of a no-op in practice, the only thing it does is tell the compiler that you can't take a pointer to that function (inlining will be always up to the compiler, keyword or not).

[oahda]

Aw. Guess I should remove the inline modifiers from my maths header then.

[Cheesegrater]

It can still be worth doing.

inline mandates that the linker merge multiple definitions of the function (if it does not actually inline), so even if you include the header in multiple places you'll end up with only one compiled version of the function in your final exe. Also it keeps you from getting errors about the symbol being defined multiple times.

[oahda]

Well, there's a header guard so that shouldn't happen anyway, right?

[Cheesegrater]

Header guards only protect you from multiple copies in one file/translation unit.

At link time. If you put a function + function body in a header and #include the header in multiple files, you end up with one copy per .cpp file you had the #include in. Then the linker will note the multiple definitions and throw an error.

You have three options, then:

1) Split the function body and the prototype, like most people usually do.
2) Mark the function inline, which will merge the copies from multiple files into one.
3) Mark the function static, which will maintain a separate copy for each file (you only want to do this in certain special sorts of circumstances I won't go into).

[oahda]

Ah, right. I've been splitting things up for so many years that I haven't really remembered that, and now I've been using inline functions and so it has been working out anyway.

[Sik]

Also it keeps you from getting errors about the symbol being defined multiple times.

Oh damn, I forgot about that one too.

In any case it doesn't hurt to use it (especially since it indicates intent), just take into account that merely because you don't include the inline keyword that doesn't mean that the compiler won't inline the function if it's short enough (and now there are linker optimizations too, so you may have inline optimization across files, which is nice). Of course you need to have optimizations turned on, but it's important to understand if you're trying to speed up slow code.

EDIT: actually for a better explanation: inline was always used to specify intent. It tells the compiler that you expect the function to be inlined, but if the compiler thinks it's too large it won't be inlined. This was the case since it was introduced. The only thing that changed since then is that now compilers do the inverse too if they think it's appropriate (it's OK as long as the behavior of the program remains the same, performance aside), but it's still useful if you want to affect its semantics instead of its performance.

[Geti]

Fwiw there are ways to force inlining on each major compiler, and building a nice macro to put the right identifier for your compiler in, and default to "inline" isn't hard.

 Re: the function pointers there, I'm not concerned about whether the compiler will want to inline or not for a given case, but whether it would be able to given that (as far as I can see) they are decided on locally and passed out of the ternary as function pointers. I realise it's a very local transformation but I'm curious how well that construct would optimise in practice.

[tjcbs]

I tried on VS2008, and the trinary function pointer thingy does indeed inhibit inlining.