Hi, all across the GStreamer plugins we can find GST_DEBUG_FUNCPTR being used in the class_init.
Following it’s documentation the purpose of this macro is to add a function pointer to a hash table, so the name of the function could be retrieved with GST_DEBUG_FUNCPTR_NAME.
This comes with a not critical, but still visible cost:
Simplicity of the class_init function suffers, meanwhile it’s usually the most “obscure” part for the beginners.
Obviously it has some micro performance cost on the application startup.
It wouldn’t be a problem if we all knew very well why GST_DEBUG_FUNCPTR is there, but to me it gives an impression of a historical artifact that have been was copied “in a sake of consistency” from one class to another without understanding the purpose.
Personally I don’t find any usecase for this feature, if the function name can be retrieved from the debugging symbols… Maybe you can corrify this statement.
It’s not entirely clear to me from your post whether you understand the use/utility of this stuff and just disagree with the trade-offs made or if you’re asking about the use of it - could you clarify?
GST_DEBUG_FUNCPTR_NAME() is something you will find used in debug log statements of base classes that call virtual methods which may have been overridden by a subclass, and other code where callback functions are installed such as GstPad.
If the subclass has registered the virtual function with GST_DEBUG_FUNCPTR, you’ll get the name of function being called in the debug log.
Does it increase legibility of debug logs? Somewhat.
Is the performance overhead of registering these non-zero? Of course. Does it matter compared to the GObject GType machinery of instantiating a class? Doubtful, but would be interesting to see benchmarks. On the output/lookup side it’s probably negligible compared to the rest of the logging/output overhead.
Could it be done differently? Yes, but this mechanism has the advantage that it always works, on all operating systems, in all build configurations with debug logging enabled.
It is of course quite likely that there is code where GST_DEBUG_FUNCPTR is used even though it doesn’t really make sense, e.g. where it has just been cargo-culted applied to all vfuncs regardless of whether the code calling this function will ever make use of it.