How to export a class that inherits from unmanaged exception class

  • Thread starter Thread starter Bob Altman
  • Start date Start date
B

Bob Altman

In my unmanaged C++ app (VS 2005) I have written a class that inherits from
exception. I want to export this class from a library DLL, but the compiler
complains because exception is not itself exported. Any words of wisdom?

TIA - Bob
 
In my unmanaged C++ app (VS 2005) I have written a class that inherits from
exception. I want to export this class from a library DLL, but the compiler
complains because exception is not itself exported. Any words of wisdom?
Click to expand...

You need to compile for the multithreaded DLL (/MD or /MDd).
 
Thanks. That raises a question I've long wondered about: What is the
actual difference between the single-threaded, multi-threaded, and debug
versions of the DLL? The documentation is very vague on this issue. My
guess is that the non-debug versions of the DLL are compiled with
optimizations enabled, thus making it more difficult to step through the
included library source code in a debugger. But what does the
multi-threaded DLL get me, and what is the cost?

- Bob
 
Bob said:
Thanks. That raises a question I've long wondered about: What is the
actual difference between the single-threaded, multi-threaded, and debug
versions of the DLL?
Click to expand...

Theoretically there can be 8 different versions of the standard library,
as there are 3 completely independent parameters that you could adjust:

- Threading model. The single-threaded std library doesn't work with
multi-threaded applications. As of VS 2005, there is no longer a single
threaded standard library. Microsoft no longer wants to go through the
trouble of maintaining 8 differnt versions of the C standard library.
When most applications are multi-threaded, and the benefits of a
single-threaded library are marginal.

- Dynamic or static linking. Dynamic linking means that the standard
library is provided as DLLs. Static linking means your application is
self standing and doesn't depend on any non-system DLL (your EXE is all
you need to ship in that case). With .NET, static linking is ruled out.

- Debug or release version. In a VC++ project you can't successfully mix
debug and release units -- you have to compile all your units with
either debugging enabled or disabled uniformly. The standard library has
to match your settings as well. So if you want to be able to debug your
application, you have to link the debug version of the runtime library.

If you program in .NET, you don't have too many choices: Either use the
debug or release build of the multi-threaded DLL version of the standard
library. If you program native, and you really really want a
self-standing executable with no dependencies, link either the debug or
release build of the multi-threaded static version of the standard library.

Unless you really know what you're doing, you should compile every
module of your project with the very same compiler and linker settings.
There are special rules to follow when you intermix modules built with
different settings (or even worse, different compilers).

Most importantly, if you want to write your own DLLs, and you choose to
use the static version of the standard library, then the DLL will have a
different memory manager than your EXE, which is very painful to handle
(and it is not a trivial task to manage). By using the DLL version of
the standard library, you can forget about most of the trouble, as long
as everything is built with the same compiler using the same settings.

Tom
 
Back
Top