read image from url

[Keith Thompson]

And this means that both languages are binary compatible, hence very
close, as I am arguing since quite a few posts.

No, C and C++ are not "binary compatible"; that's not even a
meaningful statement.

A given *implementation* of C might be binary compatible with a given
*implementation* of C++. My understanding (I'm not a C++ expert) is
that C++'s extern "C" feature allows you to invoke a C function from a
C++ program only if the two implementations happen to be binary
compatible. It's very common that such implementations are available
(possibly from the same vendor), but I'm not aware of anything in
either standard that requires it.

[remaining jacobspeak snipped]

 

[Mark McIntyre]

And this means that both languages are binary compatible,

Sort of, yes...

hence very close,

.... but no, this isn't true.

On my vax I could call Fortran libraries from C, and vice-versa. This
doesn't make the languages very close, merely callable from one
another.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Sort of, yes...


... but no, this isn't true.

On my vax I could call Fortran libraries from C, and vice-versa. This
doesn't make the languages very close, merely callable from one
another.

If the *languages* were callable from one another, I could call a
Fortran library on your VAX from my C program on my PC.

The Fortran and C *implementations* on your VAX are binary compatible,
not the languages themselves.

 

[Al Balmer]

A given *implementation* of C might be binary compatible with a given
*implementation* of C++. My understanding (I'm not a C++ expert) is
that C++'s extern "C" feature allows you to invoke a C function from a
C++ program only if the two implementations happen to be binary
compatible.

Yes. In fact, binaries generated by two perfectly conforming C
compilers may not be compatible, since it's common for library code to
call invisible helper functions which are not standardized. If you
link C code with C++ code, it's best if they're generated by two
different modes of the same compiler. That's the reason that
commercial libraries come in different versions for different
compilers.

 

[Mark McIntyre]

The Fortran and C *implementations* on your VAX are binary compatible,
not the languages themselves.

Indeed, this is what I meant, though I agree I was unfortunately
ambiguous. Languages aren't binary at all.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Old Wolf]

jacob navia posted:

Not quite "any"; the function declaration must still be correct
C++ code, e.g. this is no good:

extern "C" int new(int delete);

and I think it mustn't have the same name as any overloaded C++
function in the same module (due to name mangling requirements).

Also, the function body must conform to a C ABI that the C++
compiler knows about.

Must every C++ compiler provide a facility for compiling C code?

No, but I don't know of any that don't.

Can the following program be considered universally portable?

/* stuff.c */

#include <stddef.h>
#include <stdlib.h>

char *AllocCharArray( size_t const len )
{
return malloc(len);
}

/* main.cpp */

#include <cstdlib>

extern "C" { char *AllocCharArray( std::size_t const len ); }

Note, the braces are unnecessary.

int main()
{
char * const p = AllocCharArray(64);

std::free(p);
}

I guess it is a semantic issue about the word "portable". If you're
happy for it to include "portable to systems with both a C++
compiler and a compatible C compiler" , then yes. Note that
there are other practical issues too; the two compilers must
also be configured to link gainst the same runtime library.

 

[Kenny McCormack]

In interpretation, as in translation, there is a prima-facie principle: if
an interpretation (or translation) renders a phrase patently wrong or
meaningless or non-sensical, chances are that the interpretation is
mistaken. The goal of interpreting some statement or question should be
understanding not ridicule.

That's not how it works on Usenet. Generally, you assume that the
poster is a complete dumbdumb and go from there. Generally, you are
right to do so. But not always.

And, of course, clc is the worst offender - that's what makes this NG so
much fun. It's like shooting fish in a barrel. Here, Jacob made it
real clear that his posts were *not* to be interpreted in the default
way, that is, as if he had an IQ of 6, but the "regulars" couldn't give
an inch. They have made a life's work of ignoring your quite reasonable
rule (above). So typical.

Useful clc-related links:

http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/C_programming_language

 

[Kenny McCormack]

Today good manners are considered a thing from the past. Violence
and provocation are the best way to impose your opinions. It is no
longer important to convince other participants in the discussion but
to be crowned as the "alpha male" of the group and build a circle
of religious followers.

So true, so true. Of course, all the alpha male wannabees will deny it.
Mark my words. Read the links below and your anger will be replaced by
amusement and pity. You will be the better for it.

People that do not feel this urgent need to make a sect, are "free
game" and can be insulted at will.

You got it.

Useful clc-related links:

http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/Aspergers
http://en.wikipedia.org/wiki/C_programming_language

 

[Philipp]

for
a newbie it can be difficult to verify that the code has the same meaning
in both languages,

So what you are saying is that the same lines of code may have different
meanings if compiled with a C++ compiler or a C compiler?
Can you show an example?
Thanks

 

[Gavin Deane]

So what you are saying is that the same lines of code may have different
meanings if compiled with a C++ compiler or a C compiler?
Can you show an example?
Thanks

See

Character literals
const linkage
Empty parameter lists
Enumeration constants
Nested structure tags

and others at http://david.tribble.com/text/cdiffs.htm

Gavin Deane

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

So what you are saying is that the same lines of code may have different
meanings if compiled with a C++ compiler or a C compiler?
Can you show an example?

#include <stdio.h>

int main ()
{
printf ("'a' does %slook like a char\n",
(sizeof 'a' == sizeof (char) ) ? "" : "not ");
return 0;
}

As C:
'a' does not look like a char

As C++:
'a' does look like a char

 

[Ian Collins]

So what you are saying is that the same lines of code may have different
meanings if compiled with a C++ compiler or a C compiler?
Can you show an example?
Thanks

int main()
{
const unsigned size = 42;

float stuff[size];
}

Gives a 'normal' array in C++ and a VLA in C(99).

 

[Marcus Kwok]

No, but I don't know of any that don't.

The HP aCC C++ compiler will not compile C code that uses the old-style
function parameter declarations, e.g.,

int func(a, b)
int a;
int b;
{
return 0;
}

as opposed to the modern

int func(int a, int b)
{
return 0;
}