Re: #pragma lib buggers everything up

"Bonj" <a@xxxxx> wrote in message
news:%23bu4IgnTFHA.4056@xxxxxxxxxxxxxxxxxxxx
> In the static library I have lots of classes. I am seemingly able to
> derive the client application's classes from the classes in the lib,
> but I am experiencing an error with a static member function of one
> of the classes in the lib that is only going to be called by the
> application, not by the lib.

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.

> Consequently when the lib builds, the
> static method is being discarded

This should not happen. Functions are never discarded when a static
library is built. They may be discarded later, when this library is used
to link the final executable (be it an EXE or a DLL) and it turns out
that some functions are never called by anything. Since an executable is
self-contained, there's no problem discarding unused functions at this
point.

> 2) Is it possible to go one step further and split it out into
> a DLL, and derive classes in the application from bases classes in
> the DLL?

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

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.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Problem with Borland C++ 5.02
    ... I am developing an application for ISA DLL driver for some equipment ... LIB into the LIB path and directory of compiler, ...
    (comp.lang.c)
  • Problem with linking - cant find the right solution.
    ... I am developing an application for ISA DLL driver for some equipment ... LIB into the LIB path and directory of compiler, ...
    (comp.lang.c)
  • Re: mex linker fails
    ... does this mean that the .lib is actually using the .dll? ... Try using "dependency walker" to look at the DLL. ... Matlab supported compiler for windows, so it's not straightforward to set up mex ... bash-3.1$ # Create import libraries ...
    (comp.soft-sys.matlab)
  • Re: Export C++ class from a Borland DLL and use it in Microsoft VC
    ... I have a DLL with its export library wrote in Borland C++ 6. ... This means that C++ code is incompatible between different compilers, ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Static Libraries and Assembly Language
    ... My experience with asm is from about 14 yrs ago, ... actual Processors and Assemblers. ... compile time or at .lib creation time. ... Every Zip API I've ever seen comes with a dll. ...
    (alt.lang.asm)