2 ms·
Probably you'd end up with this: foo->bar(foo,arg1,arg2) It's not as simple-looking, but that isn't all bad. It's very clear what is going on. The overhead is
by burfog 10y ago
Probably you'd end up with this:
foo->bar(foo,arg1,arg2)
It's not as simple-looking, but that isn't all bad. It's very clear what is going on. The overhead isn't hidden.
Things needing call-back functions need to support an extra void* of course, and sadly it is often left out.
Understanding how compilers translate C into assembly is a skill that must be practiced. I suggest getting in the habit of looking at the binary. After a while, you will know what to expect. The optimizers are not magic. They do fairly predictable transformations on the code. You can get a feel for when hand-optimization matters, and when it is just pointless. An awareness of cache lines and TLB entries is helpful too.
- lmm 10y ago> Things needing call-back functions need to support an extra void* of course, and sadly it is often left out. Well when doing the right thing means writing more verbose code, it's no surprise that people do the quick-and-dirty thing (see http://www.haskellforall.com/2016/04/worst-practices-should-be-hard.html http://www.haskellforall.com/2016/04/worst-practices-should-... ). Since "everyone knows" that best practice for a callback is to take a function pointer and a void * , wouldn't it be better to have that idiom built into the language? (i.e. a concise syntax for the pair of callback-and-void * , and a concise syntax for "invoking" the pair, passing the extra void * along with the "ordinary" arguments).