Lars Ivar Igesund wrote:
Andrei Alexandrescu wrote:
Lars Ivar Igesund wrote:
Andrei Alexandrescu wrote:
Lars Ivar Igesund wrote:
Andrei Alexandrescu wrote:
Lars Ivar Igesund wrote:
No, you misunderstand. I said safely call, not
exceptionally efficient. To me a virtual call would be
acceptable. However, at least in my cases, there would
normally not be more than one imlemented interface and
such it would be a tiny vtable.
Ok, so the scope is reducing nicely. We now have a few
problems to solve (some details glossed over for
simplicity).
a) Get from void* to the TypeInfo that's typing that void*.
This will involve a search as the void* could point really
anywhere, including untyped memory. So we have a core
function:
TypeInfo fromAddress(void * p);
b) Starting from a TypeInfo, get an interface in case the
underlying struct implements that interface:
Object TypeInfo.QueryInterface(TypeInfo someInterface);
c) Finally, given a void* and an interface, invoke a method
of that interface:
T structCast!(Interface)(p).method(arguments);
Since you used template lingo, it looks a bit like compile
time functionality, but yes, very close now :)
Also (I keep forgetting to mention important details) - I
typically see this used in variadic functions, such that the
typeinfo already is there.
But what are you ultimately trying to accomplish, and why do
you must lose all static information since it was just
available to the caller? Isn't there a simpler way to achieve
your goal (e.g. using the new variadics)? You are essentially
asking for full-blown runtime scripting for all structs.
Sorry; new variadics?
http://www.digitalmars.com/d/2.0/variadic-function-templates.html
Your use case suggests you are using the "look, ma, no templates"
solution, whereas the new variadics are shown below that section.
Right, but the "new variadics" cannot (being templates) be virtual
(which at least sometimes is useful).
Templates can always forward to non-templates the void* and pointers to
functions of interest that know how to handle the void*. The new code in
std.format does that. The solution can be easily extended to forward to
interfaces that are created and allocated suitably.
Essentially what I'm saying is, if you're asking for a feature there
should be a reasonably clear picture of the implementation possible
attacks and of the various consequences of the tradeoffs involved. I
understand it would be nice to have structs automatically offer
runtime-queriable interfaces at no per-instance cost, no dynamic
allocation, and with free bonus miles, but then that's only a
deceptively little part of the story.
Andrei
