Re: #pragma lib buggers everything up

> What's the error message? I don't see any immediate problem in this setup.
> It is quite common to have functions in the static library that are never
> called by the library itself.

This issue was also fixed by aligning the /MTd switch I believe, but I've
now switched off from the static lib idea not because of this, but because
of the resource issue. A lot of the resources are relevant to the static
lib, but not all. There are (seemingly widely experienced and blogged-about)
issues with containing resources in a static lib and trying to use them from
a client exe, and I experienced these too, i.e. the exe can't use any
resources that are linked into the static lib.
Have a resource-only DLL, you might say, - yes, I did consider this but the
issue with this is it would involve too many code changes, e.g. when a
window class resides in the static library but I want to derive a class from
it in the application and use an icon from the application, it's probably
technically possible but it would involve too much tearing of hair out for
too little gain... as it is at the moment, at least the code is logically
separated between library and app-specific, so that if I want to use the
class library again for a different application I can just pull the source
files out.


> It is possible - mark your classes with __declspec(dllexport). For more
> details, see

I was getting a lot of C4251 errors ("....stl::xxxx ... must implement
dll-interface to be used by clients of yyy..."), I would be interested to
learn what the resolution to this is even though I am taking on board your
point below about it not being a great idea.

>
> http://msdn.microsoft.com/library/en-us/vclang/html/_pluslang_using_dllimport_and_dllexport_in_c.2b2b.asp
> http://msdn.microsoft.com/library/en-us/vccore/html/_core_export_from_a_dll_using___declspec.28.dllexport.29.asp
>
> However, it is not necessarily a good idea. An interface between a base
> and derived class is very fragile - it depends on a particular compiler,
> and often on a particular version of the compiler and particular compiler
> switches. It will work as long as you compile both EXE and DLL from
> sources with the same settings at the same time, but there's no practical
> way to maintain binary compatibility. E.g. it would be difficult to update
> the EXE and the DLL with new versions separately, or ship the DLL to other
> people to use in their applications.
>
> Microsoft tried to play this game with mfc42.dll (which exports MFC
> classes). They carefully maintained binary compatibility from VC4 through
> VC6, but then gave up and shipped mfc70.dll and mfc71.dll with VC7 and
> VC7.1 correspondingly. The reason cited was that the requirement to
> maintain backward compatibility got in the way of improvements in the
> library.

OK, thanks for that - sounds like good advice, just tell me... what would
you consider to be a safe limit on the operations that can safely be
implemented across a DLL-boundary ? e.g. is it safe to *consume* a class
that resides in a DLL from an application, but not to *derive* from one,
etc.



.

Relevant Pages

  • Re: ERROR_RESOURCE_TYPE_NOT_FOUND error comes
    ... Made DLL which contains resources like dialog, ... Made a static lib project which contains classes for resources ... This control is populated by lib classes. ... locale ID, and if not found, is defaulted to the app .exe itself. ...
    (microsoft.public.vc.mfc)
  • Re: #pragma lib buggers everything up
    ... > now switched off from the static lib idea not because of this, ... A lot of the resources are relevant to the static ... >> and often on a particular version of the compiler and particular compiler ... It will work as long as you compile both EXE and DLL from ...
    (microsoft.public.vc.language)
  • Re: Localization of my MFC application
    ... We create a set of resource files for each separate program (.EXE, .DLL, ... My resources are not so large that it makes a big ... > We have an application which has an exe and uses two MFC extension DLLs ...
    (microsoft.public.vc.mfc)
  • Re: ERROR_RESOURCE_TYPE_NOT_FOUND error comes
    ... This lib is also having a dependency of DLL. ... locale ID, and if not found, is defaulted to the app .exe itself. ... Actually My exe also has resources and my DLL ...
    (microsoft.public.vc.mfc)
  • Re: passing using "string" type in DLL Interface
    ... Since string is a dynamic data structure allocated on the heap there ... the .exe and .dll are compiled with different versions of the compiler ... same compiler and library versions so we have no problem passing any SCL ...
    (microsoft.public.vc.stl)
Loading