Tristan Sehgal wrote:
I am completley new to the .NET framework but have
a good understanding of Visual C++.
I am starting to develop a new class libary which other
programmers can use in their applications. To do this in
Visual C++, I'll be creating a DLL with exported classes.
I would like to develop this class libary in Visual
C++ .NET but am concerned it won't be able to be used by
standard Visual C++ developers.
If I created a DLL in .NET which makes use of some of the
.NET framework classes, could it be used in Visual C++
(assuming the header file presented hides away the .NET
class stuff)?
I'm going to take a leap and assume that by "Visual C++" you mean VC6. If
by "standard Visual C++" you mean Visual C++ .NET, but generating unmanaged
(native) code only, then you can ignore the rest of this post, and take the
short answer: yes.
Short answer: yes: You can build a DLL with Visual C++ .NET 2002 or 2003
that can be used by "standard Visual C++ developers".
Long answer: It sounds like what you're wanting to do is produce a DLL
that's usable by programmers using a different version of Visual C++. This
can be done, but you have to be careful about the interface you expose.
Mixing compiler versions exposes you to all the same sorts of problems as
mixing compiler brands (e.g. Borland compiled DLL used from a VC compiled
EXE), with the added twist that mixing versions usually makes the problems
more subtle and easier to overlook.
To produce a DLL that can be used from any C/C++ compiler that can target
Windows, you need to restrict your exposed interface to a pure 'C'
interface, with all resource management handled explicitly through your
exposed APIs.
You have to assume that:
- Object layout between the two compilers might be incompatible.
- C Runtime library resources, such as <stdio.h> file handles are not
sharable across the interface.
- C++ runtime library resources, such as <iostream> streams are not sharable
across the interface.
- Heap allocations have permanent affinity with their original allocator
(e.g. if it's allocated by the DLL, it must be freed by the DLL).
- C++ name mangling is incompatible between the two systems, so only 'extern
"C"' functions can be exposed.
- Library designs in general will be incompatible: you can't pass
std::string, or CString, or ATL::CStringT<> across the interface.
If you adhere to these guidelines, you can produce a DLL that can be used by
anyone.
-cd