On Mon, 6 Oct 2003, Jon Griffiths wrote:
Hi,
Part 3 of oleaut32 updates.
Hi Jon,
Cool stuff, but I don't understand why we have all these forwards:
+HRESULT WINAPI VarDecFromUI1(BYTE bIn, DECIMAL* pDecOut) +{ + return _VarDecFromUI1(bIn, pDecOut); +}
We don't seem to pass any additional info to _VarDecFromUI1, why not simply get rid of it, and implement stuff in the real VarDecFromUI1?
Hi Dimitrie,
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
We don't seem to pass any additional info to _VarDecFromUI1, why not simply get rid of it, and implement stuff in the real VarDecFromUI1?
Size and speed.
The inlined versions are to meant to be used within the variant code, the biggest user being the coercion functions when I get round to updating them (after the low level stuff). The code for the vast majority of conversions is smaller than the code needed to push the args and call the functions, since they are simply casts. Where a common function is used for the conversion of most types the calls can be combined skipping a level of indirection.
Cheers, Jon
===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live
jon_p_griffiths@yahoo.com
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
On Mon, 6 Oct 2003, Jon Griffiths wrote:
Size and speed.
The inlined versions are to meant to be used within the variant code, the biggest user being the coercion functions when I get round to updating them (after the low level stuff). The code for the vast majority of conversions is smaller than the code needed to push the args and call the functions, since they are simply casts. Where a common function is used for the conversion of most types the calls can be combined skipping a level of indirection.
I see, I did not notice the _-versions where inlined. But since all uses seem to be in the same file (is this correct), can't we just mark the regular ones as extern inline?
On Mon, Oct 06, 2003 at 11:51:22AM -0400, Dimitrie O. Paun wrote:
On Mon, 6 Oct 2003, Jon Griffiths wrote:
Size and speed.
The inlined versions are to meant to be used within the variant code, the biggest user being the coercion functions when I get round to updating them (after the low level stuff). The code for the vast majority of conversions is smaller than the code needed to push the args and call the functions, since they are simply casts. Where a common function is used for the conversion of most types the calls can be combined skipping a level of indirection.
I see, I did not notice the _-versions where inlined. But since all uses seem to be in the same file (is this correct), can't we just mark the regular ones as extern inline?
Yes, please do.
Newer gccs will use unit optimization and optimize better, regardless of order of functions.
And/Or place Coerce last in the file ;)
Ciao, Marcus
Hi,
I see, I did not notice the _-versions where inlined. But since all uses seem to be in the same file (is this correct), can't we just mark the regular ones as extern inline?
I didn't put all the functions in the same file, because a) they split pretty logically into groups of 12-20 functions b) combined they account for over 5k lines (where variant.c is currently 4.5k and nowhere near complete) and c) it made the patches easier to send. Keeping them in variant.c and completing all the functions would make it over 15k lines which is too much. Even at its current size its too big.
However Alexandre doesn't want multiple files so I'll be resending the changes placing all low level calls into a single file. That should be OK, even though it'll be big; the tests I have for those functions are very thorough and I don't expect they'll need to be hacked on going forward. The high level functions (including coerce) wont go in there though; they'll stay in variant.c.
Cheers, Jon
===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live
jon_p_griffiths@yahoo.com
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
-
Dimitrie O. Paun -
Jon Griffiths -
Marcus Meissner