lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx-2.7, MinGW gcc-3.4.5, inline + dllimport


From: Vadim Zeitlin
Subject: Re: [lmi] wx-2.7, MinGW gcc-3.4.5, inline + dllimport
Date: Sun, 2 Apr 2006 14:58:00 +0200

On Sun, 02 Apr 2006 02:09:37 +0000 Greg Chicares <address@hidden> wrote:

GC> Building lmi (with strong warning options), I get:
GC> 
GC>   C:/wx20060323/wxWidgets/include/wx/thread.h:685: \
GC>   warning: inline function `void wxMutexGuiEnter()' \
GC>   declared as dllimport: attribute ignored
GC> 
GC> wxWidgets/include/wx/thread.h
GC> 
GC>   685  inline void WXDLLIMPEXP_BASE wxMutexGuiEnter() { }
GC>   686  inline void WXDLLIMPEXP_BASE wxMutexGuiLeave() { }
...
GC> Vadim, is there any disadvantage to removing WXDLLEXPORT from these
GC> three inline functions?

 The problem is that while dllexport/import declaration is clearly
unnecessary when the function is indeed inlined, we can't know for sure if
this is the case. Of course, we do expect the compiler to be able to inline
an empty function, but what about the other ones, e.g. this one:

GC> wxWidgets/include/wx/dnd.h
GC> 
GC>   48  inline WXDLLEXPORT bool wxIsDragResultOk(wxDragResult res)
GC>   49  {
GC>   50      return res == wxDragCopy || res == wxDragMove || res == 
wxDragLink;
GC>   51  }

 Will it be inlined or not? If not, then we do need a WXDLLEXPORT here as
the compiler would put the body of the function in the DLL and you must use
dllimport to get it from there.

 I also wonder about what happens when inlining is disabled (as is usually
the case in debug builds). All in all I'm almost certain that removing
WXDLLEXPORT from here will break some DLL builds, unfortunately.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]