Re: Binary Data | VarSetCapacity | VarSetLength | Heap Object
Posted: 07 Jul 2018, 18:21
I don't know how you came up with that crazy idea. I don't believe I said anything about my plans aside from keeping NumGet/NumPut.nnnik wrote:Then are you planning on implementing a hard-coded version for every possible struct that is out there?
I think you are still deviating from the original topic, and that it would be a misuse of the hypothetical binary/struct interface.Though I want to get back on topic which is how a user would implement a binding to a COM object with an IUnkown Interface with NumGet and with the stream object (or the struct object if it is more suited)
Unless you are working with a singleton object, you would need a unique set of variables for each object/instance. There is no guarantee that any two objects implementing a given interface have the same implementation.Towards me it makes way more sense to read all the values from the table that you need once and then put them into variables.
You would read all functions at some point, then cache them somewhere, to be later retrieved and called. In that case, you must compare the retrieval mechanism to NumGet, and add on top of that the initial caching overhead. Caching must be done independently for each object (or if you want to bypass the contract and rely on implementation, for each v-table address), which may not be feasible let alone efficient, depending on where the object comes from and how it is used. The cache must somehow outperform the original v-table (a straightforward array of integers) far enough to outweigh the initial cost of building the cache.If all functions are read then the stream object is superior.