3 ms·

Not guaranteed to be zero-cost I guess?

zozbot234 5y ago
Why wouldn't it be zero cost, if _Alias can be? (Note, the fact that the function pointer would be declared as "static const" at file scope is relevant in replicating the _Alias featureset.)
- sirwhinesalot 5y ago
  There is an extra degree of indirection the optimizer has to get rid of. There is no extra pointer in the _Alias version. Whether this minor difference is relevant I'll leave to better informed people.
  - zozbot234 5y ago
    Is there, though? AIUI there's no symbol created and no pointer when you declare a "static const int" at file scope. It's simple substitution, like a #define. So the question is why wouldn't a function label be the same.
    - monocasa 5y ago
      That's only an common optimization, not a guarantee, and it breaks down when you let that object or a pointer to that object leave the translation unit like you're suggesting.
- mananaysiempre 5y ago
  Among other things, because the ways to bind to a dynamic symbol are multitudinous and frequently painful. For example, IIRC, ELF dynamic linking occasionally forces the compiler and/or linker through spectacular contortions in order to ensure two pointers to a single function compare equal (as required by the C standard and as happens with static libraries) even if the values being compared originate from two different shared objects, the function itself resides in a third one, and the compiler has no idea which functions are external to the shared object its output will be linked into. (Windows tells the standard to go take a hike, or more charitably doesn’t attempt to badly emulate the semantics of static linking in dynamic linking. I’m actually with Windows here, even if their executable format is a horrible underdocumented mess.) Those contortions are not required when the function is only ever called and never has its address taken, except compilers can be pretty naive about that part. Not that they have to be, but at least it’s not an obvious sure thing.

Why wouldn't it be zero cost, if _Alias can be? (Note, the fact that the function pointer would be declared as "static const" at file scope is relevant in replicating the _Alias featureset.)

sirwhinesalot 5y ago
There is an extra degree of indirection the optimizer has to get rid of. There is no extra pointer in the _Alias version. Whether this minor difference is relevant I'll leave to better informed people.
- zozbot234 5y ago
  Is there, though? AIUI there's no symbol created and no pointer when you declare a "static const int" at file scope. It's simple substitution, like a #define. So the question is why wouldn't a function label be the same.
  - monocasa 5y ago
    That's only an common optimization, not a guarantee, and it breaks down when you let that object or a pointer to that object leave the translation unit like you're suggesting.
mananaysiempre 5y ago
Among other things, because the ways to bind to a dynamic symbol are multitudinous and frequently painful. For example, IIRC, ELF dynamic linking occasionally forces the compiler and/or linker through spectacular contortions in order to ensure two pointers to a single function compare equal (as required by the C standard and as happens with static libraries) even if the values being compared originate from two different shared objects, the function itself resides in a third one, and the compiler has no idea which functions are external to the shared object its output will be linked into. (Windows tells the standard to go take a hike, or more charitably doesn’t attempt to badly emulate the semantics of static linking in dynamic linking. I’m actually with Windows here, even if their executable format is a horrible underdocumented mess.) Those contortions are not required when the function is only ever called and never has its address taken, except compilers can be pretty naive about that part. Not that they have to be, but at least it’s not an obvious sure thing.