Re: [Foxgui-users] Hot Key in Main Window

[JVZ <je...@fo...>]

On Fri, 13 Jan 2017 16:11:05 -0500
"Julia Dudascik (Contractor)" <jul...@un...> wrote:

>Thank you. I tried to upgrade to the new version of FOX toolkit (version
>1.6.53). When I build my application, which dynamically links with the FOX
>libraries (FOX-1.6.lib and FOXDLL-1.6.lib). I built the FOX libraries as
>64-bit in Visual Studio 2013, I get the following warning message when it
>builds the FOX header file FXList.h:
>
>"warning C4251: FX::FXList::items : class
>FX::FXObjectListOf<FX::FXListItem> needs to have dll-interface to be used
>by clients of class FX::FXList"
>
>I did not get this warning message with version 1.6.51. Should I be
>concerned? Do you know what would cause it?


See:


http://stackoverflow.com/questions/4145605/stdvector-needs-to-have-dll-interface-to-be-used-by-clients-of-class-xt-war

https://msdn.microsoft.com/en-us/library/esew7y1w.aspx


The way I understand it, when you specialize a templated class (in this case,
FXObjectListOf<>), some of generated functions would have no DLL linkage.

In this case, the class is accessed only from FXList's API's which have DLL
linkage by virtue of FXAPI declaration in the header file.

But the concrete template instantiation produced by FX::FXObjectListOf<FX::FXListItem>
does not (generated inside FXList.cpp).

So, if it were possible for you to access API's of this class directly, those would
not have DLL linkage as expected.

Of course, FXList.cpp functions access the functions of FXObjectListOf<> without
such linkage; this is not a problem as the implementation of the specialized
FXObjectListOf<> lives in the same DLL as FXList.


It *could* be a problem if you would be able to access non-inlined API's via
FXObjectListOf<> API's (because the compiler would have to access the DLL's
import library for those functions, which don't exist due to not having 
DLL spec on them.

I hope I'm explaining this properly.


Basically, this is due to the way the Microsoft world does DLL's; a DLL is a blob
of code that has entry-points for functions marked in some way.

When the DLL is loaded, those entry points become available to the hosting executable.

On Linux, the references to the entry points are resolved "lazyly" on as-needed basis
[unless you pass the  magic linker flags (-Wl,-z -Wl,now).
On Windows, the executable is linked to a so-called "import" library, which is conceptually
simply an array of jump-instructions, where the target addess is not yet filled in.

When loading the DLL, those jumps will get filled in.  A problem exists if the caller 
would reference an object from the template that lives inside the DLL.

Most cases, this is not a big problem.


		Hope this helps,


				-- JVZ




+----------------------------------------------------------------------------+
| Copyright (C) 15:30 01/13/2017 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+