reed@m.cs.uiuc.edu (09/11/90)
I've been trying to link C object modules with C++, both created
using Turbo C++. I must be doing something stupid, because the
Turbo linker is unable to find the C reference. I've attached a
code sample below that fails when I do the following:
tcc -c y.c
tcc -c x.cpp y.obj
This fails to resolve the reference to "try"
Any ideas on what I'm overlooking?
Thanks in advance,
Dan Reed reed@cs.uiuc.edu
Associated Professor
Department of Computer Science
University of Illinois
================================ y.c =========================
#include <stdio.h>
void try (int x)
{
printf ("Value is %d\n", x);
}
================================ x.cpp =======================
#include <iostream.h>
extern void try(int x);
main()
{
int y;
cout <<"Before call\n";
y = 10;
try (y);
cout<<"After call\n";
}
========= end of x.cpp ==========anto@vaxb.acs.unt.edu (09/11/90)
In article <4800101@m.cs.uiuc.edu>, reed@m.cs.uiuc.edu writes: > I've been trying to link C object modules with C++, both created [... Stuff deleted ...] > ================================ x.cpp ======================= > #include <iostream.h> > > extern void try(int x); Try: extern "C" void try(int x); Hope this helps. Anto. // no signature yet 8)
poffen@sj.ate.slb.com (Russ Poffenberger) (09/11/90)
In article <4800101@m.cs.uiuc.edu> reed@m.cs.uiuc.edu writes: > > >I've been trying to link C object modules with C++, both created >using Turbo C++. I must be doing something stupid, because the >Turbo linker is unable to find the C reference. I've attached a >code sample below that fails when I do the following: > > tcc -c y.c > tcc -c x.cpp y.obj > >This fails to resolve the reference to "try" > >Any ideas on what I'm overlooking? > >Thanks in advance, > >Dan Reed reed@cs.uiuc.edu >Associated Professor >Department of Computer Science >University of Illinois >================================ y.c ========================= >#include <stdio.h> > >void try (int x) >{ > printf ("Value is %d\n", x); >} >================================ x.cpp ======================= >#include <iostream.h> > >extern void try(int x); > >main() >{ > int y; > > cout <<"Before call\n"; > > y = 10; > try (y); > > cout<<"After call\n"; >} >========= end of x.cpp ========== Try this in your c++ program... extern "C" { void try(int); } as your function prototype in x.cpp. The problem is with naming conventions. C++ uses new internal naming conventions so it can distinguish between instances of overloaded functions and such. Using the above syntax forces the compiler to use standard C naming conventions. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
cw@dptechno.UUCP (Charles Haden) (09/13/90)
In article <4800101@m.cs.uiuc.edu> reed@m.cs.uiuc.edu writes: > > >I've been trying to link C object modules with C++, both created >using Turbo C++. I must be doing something stupid, because the >Turbo linker is unable to find the C reference. I've attached a >code sample below that fails when I do the following: > > tcc -c y.c > tcc -c x.cpp y.obj > >This fails to resolve the reference to "try" > >Any ideas on what I'm overlooking? 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
grimlok@hubcap.clemson.edu (Mike Percy) (09/13/90)
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
steve@taumet.com (Stephen Clamage) (09/13/90)
cw@dptechno.UUCP (Charles Haden) writes: >In article <4800101@m.cs.uiuc.edu> reed@m.cs.uiuc.edu writes: ... >>I've attached a code sample below that fails when I do the following: >> tcc -c y.c >> tcc -c x.cpp y.obj >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. This explanation is not really correct. Turbo C++ is really two compilers in one: it is a C compiler, and it is also a C++ compiler. In the absence of compiler flags, a file with an extension of ".CPP" will be compiled by the C++ compiler, and one with an extension of ".C" will be compiled by the C compiler. The "-P" flag forces ".C" files to be compiled by the C++ compiler. (I don't mean that there are necessarily two complete compilers hiding in one .EXE file, but that the behavior is as if there were two compilers.) C and C++ are different languages, and have some different rules. One C++ rule is that any function not declared extern "C" ... is expected to be a C++ function, and follows all C++ naming rules and calling conventions. If a function is declared so as to make it appear to be a C++ function, but is really a C function, the program can be expected to fail in some way. The most common way to fail (true for all current C++ systems I know of) is that the program will not link. The link failure is due to the different ways function names are treated in C and C++. The discussion in this paragraph is not unique to Turbo C++, but applies to any C++ implementation. -- Steve Clamage, TauMetric Corp, steve@taumet.com