Path: utzoo!attcan!uunet!ogicse!emory!hubcap!grimlok
From: grimlok@hubcap.clemson.edu (Mike Percy)
Newsgroups: comp.lang.c++
Subject: Re: C/C++ link in TC++
Message-ID: <10453@hubcap.clemson.edu>
Date: 13 Sep 90 14:19:27 GMT
References: <4800101@m.cs.uiuc.edu> <577@dptechno.UUCP>
Organization: Clemson University, Clemson, SC
Lines: 52

cw@dptechno.UUCP (Charles Haden) writes:

>Your main problem lies primarily in the command line invocations
>of the compiler. What I mean by that is your problem is not in
>your source code it is in the way you are using the compiler.
>As you should know from the manuals that you can compile both
>"C" and "C++" source code with the compiler. What you probably
>didn't read it that the compiler treats prototyping differently
>based on the file extension ( default setting ). When compilling
>a C++ source file, the function name is "tweaked" you might say
>internally to allow for function overloading. This tweaking is
>not normally done to standard C source code prototypes, since
>overloading of function names is not allowed. There is a switch
>however, that will force standard C source files to be tweaked
>when compiling. ( see below ) A note of caution : this switch
>can only be used when you have the source code and re-compile it.
>Proper command line invocations ( tested with omitted source. ) :
>	tcc -c -P y.c
>	tcc x.cpp y.obj
 
EEEnnnnnttttt.  Close.  The -P option is instructing the compiler that
no matter what the extension of the file, assume the contents of the
file is C++ source.  This would force code.pas to be treated (probably
incorrectly) as C++ code.  This allows you to not follow Borland's .cpp
extension and use something else, perhaps Gnu's extension of .cc, or if
using a different command.com which allows '+' in filenames (DOS has no
problems with it, just the command.com parser) to use a more clear .c++
extension.  
 
Let's assume that the contents of y.c is really C code and not C++, or
better still that we have y.obj and y.h (for the prototypes) but not
y.c, but we know that y.obj came from a C compiler.  The change to make
to y.h is
 
#ifdef __cplusplus
extern "C" {
#endif
int try(int x);
#ifdef __cplusplus
}
#endif
 
This lets us use y.h in both the C compiler and the C++ compiler (hey
what a concept).
 
It always helps to look at the standard header files in a case like this
to see how it's done... 

"I don't know about your brain, but mine is really...bossy."
Mike Percy                    grimlok@hubcap.clemson.edu
ISD, Clemson University       mspercy@clemson.BITNET
(803)656-3780                 mspercy@clemson.clemson.edu