dbe@cs.exeter.ac.uk (Dave Ratt) (03/02/91)
How do I link c and c++ code using turbo c++? Specifically I
want to use the TEGL Windows Toolkit using Turbo in C++ mode.
--
------------------------------------------------------------------------------
DAVE : dbe@uk.ac.exeter.dcs
------------------------------------------------------------------------------COE10026@ufrj.bitnet (03/16/91)
In article <2796@izar.cs.exeter.ac.uk>, dbe@cs.exeter.ac.uk (Dave Ratt) says: > >How do I link c and c++ code using turbo c++? Specifically I >want to use the TEGL Windows Toolkit using Turbo in C++ mode. > >-- >------------------------------------------------------------------------------ > DAVE : dbe@uk.ac.exeter.dcs >------------------------------------------------------------------------------ try: extern "C" { /* All extern functions you want to link */ }; I'm not sure it's ANSI, but it's how TC++ works... Joao Carlos Mendes Luis
sdm@cs.brown.edu (Scott Meyers) (04/15/91)
Suppose I'm writing a program in both C and C++, and I've got globals
requiring compile-time initialization in both. Then both languages will
want to own "main" (i.e., have main written in their language). Is there a
nice way to solve this problem, particularly if, say I'm including two
read-only modules, one in each language (i.e., I can't change the source)?
I assume that both languages generate a routine "real_main" (often called
_main) that looks like this:
real_main()
{
initialize_globals();
main();
cleanup_after_globals();
}
However, only one real_main() will get called, the one belonging to
whichever language writes main. Is there a portable solution?
Scott
-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."steve@taumet.com (Stephen Clamage) (04/15/91)
sdm@cs.brown.edu (Scott Meyers) writes: >Suppose I'm writing a program in both C and C++, and I've got globals >requiring compile-time initialization in both. Then both languages will >want to own "main" (i.e., have main written in their language). Is there a >nice way to solve this problem... >I assume that both languages generate a routine "real_main"... >However, only one real_main() will get called, the one belonging to >whichever language writes main. Is there a portable solution? What you describe is common in implementations of C++, but does not usually apply to C. C++ allows specification of runtime code to be executed (conceptually) before main(), and (conceptually) after main() exits. C provides no such facility to the C programmer, and it is unusual for a C compiler to require that main() be compiled by that C compiler (but some have that requirement for other reasons). If you use a C++-to-C translator, it is usually packaged to work with a particular C compiler (or any of a group), and you just write main() in C++. The C compiler sees main(), and does whatever it needs to do with it. Of the C++ object-code compilers I am familiar with, all provide a companion C compiler, and none have any requirement on main() that would prevent mixing C and C++ code. Some C++ object-code compilers do not even require main() to be written in C++. So: is your question theoretical, or do you actually have separate C and C++ compilers which each require main() to be compiled by that compiler? -- Steve Clamage, TauMetric Corp, steve@taumet.com
sdm@cs.brown.edu (Scott Meyers) (04/15/91)
In article <670@taumet.com> steve@taumet.com (Stephen Clamage) writes: | What you describe is common in implementations of C++, but does not | usually apply to C. C++ allows specification of runtime code to | be executed (conceptually) before main(), and (conceptually) after | main() exits. C provides no such facility to the C programmer, and | it is unusual for a C compiler to require that main() be compiled by | that C compiler (but some have that requirement for other reasons). | | Of the C++ object-code compilers I am familiar with, all provide a | companion C compiler, and none have any requirement on main() that | would prevent mixing C and C++ code. Some C++ object-code compilers | do not even require main() to be written in C++. | | So: is your question theoretical, or do you actually have separate C and | C++ compilers which each require main() to be compiled by that compiler? My question is theoretical (i.e., I don't have a particular problem right now), but of importance because of portability: just because one or two combinations of C and C++ work together, does that mean I can sleep soundly at night before porting to a new platform with a new pair of compilers? As an example, suppose I have the following in C: const x = 10; /* global */ int y = x + 1; /* global */ A good C compiler will do the arithmetic at compile time, but I don't think the language requires that. If not, then sometime before main there has to be the computation of x+1 to initialize y. Or am I missing the point entirely? Thanks, Scott ------------------------------------------------------------------------------- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."
mike@taumet.com (Michael S. Ball) (04/16/91)
In article <72158@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes: >As an example, suppose I have the following in C: > > const x = 10; /* global */ > int y = x + 1; /* global */ No, you can't rest easy with this initialization since it is quite illegal in C. The value of a global initializer must be a constant expression, which this is not since it involves the value of the variable x (which happens to be of type "const int"). It is legal in C++, of course. Whether particular C and C++ compilers will work together is a matter to discuss with your compiler vendors. Not all C compilers for a given machine will work together. -- Michael S. Ball mike@taumet.com TauMetric Corporation (619)697-7607
dlw@odi.com (Dan Weinreb) (04/19/91)
In article <72158@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
does that mean I can sleep soundly
at night before porting to a new platform with a new pair of compilers?
It is axiomatic that all porting activities are preceeded by
sleepless, fearful nights and the consumption of large amounts of
antacid. :-)pwang@MCS.KENT.EDU (04/20/91)
Our g++ compiler issues a warning after seeing the function name
``flock'' inside a extern "C" { ... }
and then seeing the
struct flock { ...
...
};
in the fctlcomm.h header file on the SUN.
The warning is
flock declared `extern' and now declared again as `static' ...
Question: Why is the second declaration of flock static? How in general
to avoid such name conflicts when including C/UNIX header files?
Thanks.