Re: Need to create a C lib - using C++ classes - is it possible
* James Kanze:
On May 25, 5:53 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Angus:
We have a lot of C++ code. And we need to now create a
library which can be used from C and C++. Given that we
have a lot of C++ code using classes how can we 'hide' the
fact that it is C++ from C compilers?
The C++ code will need the C++ runtime library.
Good point. If you don't use any standard components from the
library, nor new, nor typeid, maybe not, but then what's the
point.
Within the standards of C and C++ the only way to achieve that
is to insist that the C code using the library is called from
a C++ main program.
No. There are two separate issues involved here. Neither the C
nor the C++ standards say anything about how the compiler is
invoked; to get the C++ library with gcc, for example, you can
either invoke it as g++, or specify the library explicitly
(-lstdc++, with the normal Unix linkers). Formally, the C++
standard requires that main() be written and compiled in C++, or
you have undefined behavior.
That last sentence contradicts the "No" at the start.
Anyway, this is a FAQ item,
<url: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html#faq-32.1>
"You must use your C++ compiler when compiling main() (e.g., for static
initialization)"
and as you note also it's stated by the Holy Standard that static variables may
be (dynamically) initialized after entry of main(), which implicitly requires a
C++ main(). Even though that part of the standard is IMHO defective, talking
about "after the first statement of main" instead of entry of main.
[snip]
In Windows an alternative is to have the library as a DLL,
because Windows DLLs are more decoupled.
That sort of works in Unix, as well, if the C++ standard library
is also a DLL. (Which is generally NOT recommended, of course.)
Well, the Windows situation is sort of opposite. Windows dynamic libraries are
strongly decoupled modules. In particular, the OS provides automatic per-DLL
initialization and cleanup calls, so a DLL is almost free to use whatever (the
main problem with this scheme has to do with per-thread-per-DLL storage).
[...]
The best is to forget that silly idea. Using C library from
C++, OK. But C++ has additional requirements from runtime
library, so other way, generally !OK, unless you're working at
a low level where you wouldn't have to ask...
It's actually a frequent requirement, and the original posters
question reflects one of the more common ways of migrating to
C++.
Ouch. :-)
It's very backwards, in many ways: structurally, learning-wise, safety,
simplicity. Just think about it. The programmer is trying to implement a type
safe little part of the program in C++, but since using C as main language
doesn't even manage to do this in a good way or learn the Right Things, then to
top it off throws away all that hard-won type safety and language-enforced
correctness by using this part only via a non-enforcing C language interface.
I guess with proper insulating abstractions, like XCOM, it could be better, but
when the aim is to "migrate" to C++ I doubt such abstractions will be in place.
However, technically it should be no big deal to write
extern "C" int c_language_main( int, char*[] );
int main( int argc, char* argv[] )
{
return c_language_main( argc, argv );
}
and compile that top-level as C++.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?