Douglas Gregor wrote:
In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out?
You'll probably still get some benefit. Function tries to save on space by smashing about 7 different functions into 2 functions, so that less code is generated.
Yes, I was just examining the implementation yesterday. Currently, at the beginning of each function table, I have - an optional deletion function - a function which casts the stored void* to the static type of the object at the time of binding and then throws it as an exception - a function returning a type_info object I'm probably going to add a function that take a void function as an argument, invokes it, then tries to catch any exceptions it throws. These three or four functions could be combined into one as in Boost.Function, but I'll leave that for later.
You might want to measure the effect in some typical use cases first: using virtual functions is a heck of a lot nicer than dealing with a library coded like Boost.Function,
Tell me about it! :-)
so you _really_ want to make sure it's worth the effort (it can always be optimized later).
There were a number of reasons that virtual functions were not the best solution. Most importantly, I wanted full control of the ABI. Having already finished the implementation, I'm just trying to find as many retrospective justifications as I can ;-) Best, Jonathan