Danny Smith wrote:
>>From MSDN
> "You can also define as inline a function declared with the dllimport attribute. In this
> case, the function can be expanded (subject to /Ob specifications), but never
> instantiated. In particular, if the address of an inline imported function is taken, the
> address of the function residing in the DLL is returned. This behavior is the same as
> taking the address of a non-inline imported function."
OK, thanks for finding this.
> With GNU, until GCC 4.0, having _any_ definition (inline or not) of a dllimport function
> caused so much havoc with RTL generation that the safest option seemed to be to simply
> ignore the dllimport if a function was declared inline.
> I tried to do the gnu_inline thing (use the external address if the function was not
> inlineable) but that caused bad things to happen with inline dllimport virtual methods
> (they need a constant address for vtable initialization). It may be easier to handle now
> at tree level, with the generation of the _imp__foo RTL code delayed until we really know
> whats virtual, but at the time easy way out (and the easiest way to debug inline
> functions) was to instantiate the function with linkonce semantics. This is what GCC does
> for non-dllimported classes (remove the dllimport from the testcase class and look at
> assembly generated without optimization)
And thanks for this explanation.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
