R
Randy Howard
I'm not sure about that, even Stroustrup himself admits that C99
and C++ are siblings, I.e. no parent/child relationship at all.
I'm not sure about that, even Stroustrup himself admits that C99
and C++ are siblings, I.e. no parent/child relationship at all.
C
Chris Torek
I do not know about "most important", and it is not something I
do often, but here is another trivial example of code that compiles
as C but not as C++. One might use something like this as a
"patchable constant" for ROMs, for embedded-system code:
% cat t1.c
const int n = 3;
% cat t2.c
#include <stdio.h>
extern const int n;
int main(void) {
printf("n = %d\n", n);
return 0;
}
% cc -o t t[12].c && ./t
n = 3
% cc -x c++ -o t t[12].c && ./t
/tmp/ccmoKUzh.o: In function `main':
/tmp/ccmoKUzh.o(.text+0xa): undefined reference to `n'
Another problem that comes up, albeit rarely, is the change in
sizeof 'a' (1 in C++, sizeof(int) in C). This one, like my earlier
example, usually results in silent breakage instead of compile-time
failure.
I am not sure whether I would say that -- it is hard to tell without
actually doing a statistical sample.
This *is* a good rule.
The code was never intended to be used with C++, and in fact, the
bones of it were written either before cfront existed, or -- at
the latest -- when C++ was "whatever cfront accepts". But in the
late 1990s, someone decided they wanted to import some of it into
a C++ program and, well.
B
Bjarne Stroustrup
Chris Torek said:
As in so many other cases, you get the identical result in C and C++
by adding a bit of information. In this case, adding an "extern" in
t1.c to tell C++ that "n" can be used elsewhere solves the problem.
Another problem that comes up, albeit rarely, is the change in
sizeof 'a' (1 in C++, sizeof(int) in C). This one, like my earlier
example, usually results in silent breakage instead of compile-time
failure.
I am not sure whether I would say that -- it is hard to tell without
actually doing a statistical sample.
This *is* a good rule.
The code was never intended to be used with C++, and in fact, the
bones of it were written either before cfront existed, or -- at
the latest -- when C++ was "whatever cfront accepts". But in the
late 1990s, someone decided they wanted to import some of it into
a C++ program and, well.
I, at least, never defined C++ as "whet Cfront accepted".
- Bjarne Stroustrup; http://www.research.att.com/~bs
S
Sidney Cadot
Clark said:
The fact that it happens to work on some compiler suites (gcc, for
example) doesn't help much. My library needs to work on AIX, SGI, HP-UX,
Solaris, an some more, with their various proprietary compiler suites.
7.5 of the C++ standard states:
"9. Linkage from C++ to objects defined in other languages and to
objects defined in C++ from other languages is implementation-defined
and language-dependent. Only where the object layout strategies of two
language implementations are similar enough can such linkage be achieved."
This effectively disqualifies C++ as an implementation language for my
project, since we have to link to IDL/Matlab (both written in C) on all
these platforms.
Best regards,
Sidney
C
Clark Cox
Sidney Cadot said:
extern "C" is by defintion implementation defined in either
direction, but where it works, it works in both directions. Extern "C"
tells the C++ compiler to use C calling and naming conventions, whether
you are applying it to a function whose implementation is in C, or a
function whose implementation is in C++.
Check out the comp.lang.c++ FAQ:
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
Pay attention to question 32.6 "How can I create a C++ function
f(int,char,float) that is callable by my C code?"
P
P.J. Plauger
Every one of the platforms you list above has at least one combined
C/C++ compiler. If *any* such combo has linkage or layout problems
between their C and C++ personae, I don't know about it. And I'd be
astonished to encounter such problems.
You may contrive other reasons to disqualify C++ for your project,
but this particular one is terminally lame.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
A
Arthur J. O'Dwyer
This may be terminally naive of me, and it's certainly off-topic,
but couldn't the problem be that those compilers that compile both C
and C++, do not produce object formats compatible with the object
formats supported by IDL/Matlab? Presumably Mr. Cadot does not
have either C or C++ source code for Matlab's libraries...
-Arthur
E
E. Robert Tisdale
Clark said:
No!
Extern "C" only *helps* with linkage.
There is *no* ANSI/ISO C++ interoperability standard
which governs function calling protocol.
Different compilers may pass and return values in different registers or
in different order on the program stack.
Built-in data types may have different sizes.
S
Sidney Cadot
P.J. Plauger said:
I do not have regular access to all the platforms we have to support,
much less so to all platforms with all used versions of Matlab and IDL
(ranging from +/- 5 years old, to current). We distribute the library as
source code; the user (or his sysadmin) has to compile it. The
installation process /has/ to be as simple as configure/make/make install.
Using C++ would imply that
(1) I'd have to know the C compilers with which the particular versions
of Matlab/IDL on the user system was compiled, and act appropriately on
different combibations.
(2) The user would need to have the (possibly old) C/C++ compiler suite
on his system, in many cases.
(3) The old C/C++ compiler suite needs to support dynamic linking of
C++ code to binary-only libraries (that's how matlab and IDL work).
Implementing it in C++ would be a maintenance nightmare, bound to end in
many more disgruntled users (because they couldn't get the damn thing to
work) than we currently have. I'd be busier special-casing for weird
combinations than anything else - there'd be little time left to improve
the library functionality.
One further note is that both Matlab and IDL do not officially support
linking to C++ code (although, yes, it can be done, for newer versions,
if one is careful).
Due to all these real-life constraints, we opted for the conservative
approach by sticking to C. Some special-casing still needs to be done,
but this is along the dimension of Matlab/IDL versions (which change
APIs between versions now and then).
Frankly, I'm pleasantly surprised that it works for so many users
without a hitch, when using C, given the many combinations of Matlab/IDL
versions and OS'es our library works for.
Your calling this "contrived" reason "particularly lame" suggests to me
that I failed to make the context of the problems we faced not clear
enough. I hope this helps.
Best regards,
Sidney
S
Sidney Cadot
Arthur said:
I don't. Floating even farther off-topic, I work in a commercial setting
where we have a product to deliver. We cannot afford to have too many
unpleasant surprises; if the Matlab and IDL docs (and newsgroups)
consistently state that one should not attempt to write plugins using
C++, that's all there is to it as far as I am concerned.
Best regards,
Sidney
C
Clark Cox
"E. Robert Tisdale said:
Which is why my first sentence, which you clipped, was:
P
P.J. Plauger
Now that you've listed six pretty good reasons for not using C++
with your project, that does help me understand why you don't use
C++. I understand and respect your decision based on those reasons.
But that doesn't alter the lameness of the single reason you
originally cited.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
S
Sidney Cadot
P.J. Plauger said:
The magic word is "context" I guess.
Best regards,
Sidney
C
CBFalconer
Clark said:
Trollsdale is famous for this sort of trick. He also revises
quotes without warning. Note his irrelevant referance to a stack,
in addition.
K
Keith Thompson
CBFalconer said:
I hate to say this, but ERT's reference to a stack is actually
relevant in this context. He mentions it as one of the
implementation-specific ways arguments can be passed.
That doesn't excuse his deliberate snipping of context and replying as
if the previous poster hadn't already acknowleged that extern "C" is
implementation defined.
T
The Real OS/2 Guy
Wrong. My C programs are using different functions in different
libraries compiled with compilers I've never seen. The truth is that
you have to define clearly the calling conventsions and interfaces you
should use. Anything else is definded by the liner - and not part of
the C language or the compiler itself.
I've used gcc to call functions in libraries written definitely with
IBM VAc++, and with Watcom. I use Watcom C to call fuctions in
libraries written with the C compiler of IBM VA C++ and GCC. I use the
C compiler in IBM VA C++ to call functions in libraries written with
other compilers.
I use even som functions definitely written in COBOL, fortran and
other languages. Some of them written in pure assembler too. But look,
the libraries are designed to have interfaces to most commonly used
languages - and for all C compilers - even such NOT existent at the
day the libraries were released.
A C compiler is designed to produce binaries, ready prepared to get
linked with a linker of your choice. An binary of a well designed
system is well designed to be understandable by any linker this system
environment knows or will known in forseable future.
You may link object module together to build an executeable program or
by inserting an interface module to build a library callable by any
language. Has nothing to do with the programming language you use to
write something in source.
The way from a source compilation unit to an executeable program or an
library is long. A C compiler is only starting point to get the source
translated into some kind of binary (or source) module that needs to
be handled by one or more other programs.
Me and thousends of other peoples have written programs in C who are
NOT understandable by any C compiler without passing another kind of
compiler prior, needing some different compilers of different sources
too to be linked separately, then commonly then again to get an
library that can linked at runtime to another program alreard exist to
extend its functionality on the fly.
T
The Real OS/2 Guy
1. use a text edtor of your choice to write the sources that contains
the functions you likes to share with other languages
2. use a text editor of your choice to write one or more interface
file(s) (known as header files) to define the interfaces right use the
calling conventions your compiler supports to get the external entry
points described completely
3. use a C compiler of your choice to compile it error free with
highest warning level on,
tell the compiler to use the headers defined in step one to check
the definitions against the declarations
4. use a linker that is woth its name to build a library from the
object code your compiler generates
5. use the linker (or another program if they are separately on you
system) to build an interface module that generates an interface
module for the library that generates the needed object code to call
the library dynamically instead to bind it statically to a single
program. As this step is optionally, you will need it only to share
the same library with other programs at runtime.
6. use a text editor of your choice to write functions in another
programming language of your choice...... continue 2. - 5 to build
another libraries and object interfaces, replace C with C++, Fortran,
Pascal or any other langugae you knows of.
At least you gets many libraries written in many different languages
compiled with many different compilers together to many separately
compiled modules linked to single executeables whereas none of the
compilers knows of the others - but wors perfectly together.
But only step 3 has something to do with the topic of this newsgroup.
But this should show why Tisdale owns his nickname Twitsdale.
T
The Real OS/2 Guy
There is none, not a single reason to recompile C code using something
that is NOT a C compiler. However use a C compiler to compile C code,
use a C++ compiler to compile C++ code use a <compiler of a language
of your choice> to compile <language of your choice> code. Use a
linker to build either a library of some to the compilation units
written in the same <language of your choice> and a linker again to
build the executeable of the other modules and again the linker to
link them together.
If you've done your homework right it works. Many times you can start
at compile stage on different mashines based on highly different
environments and anything works again.
Yes, you can't link directly object modules written in different
languages and compiled with different compilers - but linking
different libraries together is possible. Each partikular system will
give you the tools you need for.
R
Randy Howard
Or perhaps none that you can imagine, anyway. I am sure that Jack Klein
has a good reason or reasons, otherwise he would not be doing it. That
may or may not be true of others, especially ERT.
"When a distinguished but elderly scientist says that something is
possible, he is almost certainly right. When he says it is impossible,
he is very probably wrong."
-- Arthur C. Clarke
P
P.J. Plauger
Oh, to have such certainty.
I still cherish a cartoon I clipped from Punch roughly half a
century ago. It shows two knights errant resting on horseback
beneath a tree. One says to the other, "Isn't life simple
when you know you're right all the time?"
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com