Can any C program be compiled with the C++ compiler and obtain a useful executable?

See "Language basics" in: Objective-C - Definition, which says that the C++ compiler can't produce a "meaningful executable" from a C program. I don't believe that; do you?

To my knowledge there were only a couple of things 'removed' from C, but every time the question comes up I forget what they are. They were removed precisely because the committee observed they were very seldom used features, and wouldn't break much of existing code, where any modification required was minimal and local. It was such a trivial thing that I dare say most developers, I among them, can't manage to recall just what it is.

There may be details in implementation whereby the claim "any" C program could be denied, and we'd have to say merely "most" C programs could be compiled in C++ and produce a functional executable (meaningful, a curious choice, I think means a running executable).

I'd go so far as to say you'd have to search far and wide to find a C program that wouldn't compile, but there may be some linker complications. Objective-C doesn't use the same kind of name mangling that C++ uses, so perhaps there could be situations where shared libraries, static libraries or DLL pre-requisites would not always work, but the alterations would be minimal.

Objective-C developers generally hold the opinion of the superiority of that language, especially of the message paradigm and dynamic typing. Most of the reported advantages are not clear cut, and several of the reported exclusive features of Objective-C are only exclusive if the comparison insists on base language constructs, ignoring libraries and modern generic programming methods, and even when the results are comparable there can be continued denial for trivial reasons.

While it's true that C++ was originally more or less a superset of C, as the two languages develop they're starting to grow further apart. For example, the following is valid in C99 but not C++:

Code:

---

int foo(int n)
{
    double array[n];
}

---

I would assume they're talking about how many C programs will require minor modifications to compile as C++, since C++ is more strict about certain things than C, particularly type casting. Eg, the following

Code:

---

int* ptr = malloc(sizeof(int));

---

is valid C, but not valid C++ (malloc returns void*, C++ requires an explicit cast from void* to int*).

Or perhaps they are just plain wrong. They seem to be over-emphasizing other languages and exagerating the uniqueness of Objective-C. For example, their comment about structured programming is not justified. The Objective-C - Wikipedia, the free encyclopedia article has text similar to the wordIQ.com article but the Wikipedia article does not have the comment C not being compiled by C++.

I am hoping for comments from someone experienced with C, not guesses.

The precise quote:

Quote:

---

Objective-C is a strict superset of C. That is, you can compile any C program with an Objective-C compiler and obtain a meaningful executable, which can't be said of C++.

---

This is true. C++ is not a strict superset of C.

Actually, none of us are guessing, though I qualified my own response. I wrote in C for years before C++ was made available, though I've not studied the C99 standard; never had a reason.

Speedo's point is rather pertinent. My point is we're left to guess exactly what they mean without performing an experiment. They're correct that Objective-C is tacked onto C, and if the compiler is otherwise C99 compliant, Speedo's and Lindley's examples would compile.

However, it gets complicated because the same compilers have an "Objective-C++" mode, where Speedo's example would also give rise to a complaint. Further, there are several versions of GCC supporting Objective-C and Objective-C++, each with their own quirks and levels of compliance for all of the supported language standards.

This gives support to their claim in the article, but as we're observing, they're minor issues (red herrings, in my view).

Modern C++ compilers will operate in a C mode, much like GCC does. That is, if you used a typical modern compiler to compile C99 code, it would produce an executable and pass C99 constructs without complaint, subject to it's own quirks, because it was NOT compiling in a C++ mode. This means the article may be technically correct, but not meaningfully honest and accurate. In other words, we can freely mix C and C++ code in a project, and compile C code in C mode without issue. The issue, which they are technically correct about, is if code like Speedo's example were compiled in a C++ compilation unit, which may not be wise anyway, it would generate an error. For that scenario, there is a small amount of C code that would generate minor complaints within a C++ compilation unit, but proper organization of the project would eliminate that, primarily the separation of genuine C code and C++ code into separate compilation units.

Their point is that Objective-C doesn't alter C at all (the syntax of the Objective-C component is so entirely different there's no chance for collision). Speedo's and Lindley's example is one of a few such C constructs that would compile in Objective-C, but would fail in Objective-C++, exactly - I mean exactly - the same way it would in a mixed compilation of C and C++ code, where the C code is placed in C compilation units, and C++ code is placed in C++ compilation units. Some C constructs would fail if "mis" placed into C++ compilation units.

That's not guessing.

The article's point is misleading if technically accurate.

I would put it this way. The "objective" part is of such a unique syntax that it can be tacked on to C or C++ without interference with either. Most any compiler that accepts C++ code also has a C mode of operation which accepts compliant C code as is, without alteration, generating correct executables. It could be said they're trying point out you can't write C++ code when the compiler is in C mode, and you can't expect all C code to compile in C++ mode. They're happily ignoring the fact that these compilers will compile in C mode, and like a dishonest politician, trying to use that as a point of contention.

There's a boatload of C code that will compile in C++ mode, another boatload that will if very minor modifications are made, and some that would take some effort, but it's effort that's simply not required with any modern compiler.

I suppose they could wave a flag of victory if they're trying to somehow point out that there's two modes, C or C++, and not 4, C, Objective-C, C++ and Objective-C++ - the "objective" component doesn't require that the compiler break into these 4 modes.

The syntax is still ugly :)

Note that what you call "a C mode" is called the C compiler by language experts. Language experts don't consider the C compiler to be the C++ compiler executing in a C mode; they consider them to be distinct compilers.

Sam, if you really want to consult a language expert, you'll need to find one at a University.

I know they're separate standards.

The article you cite isn't aimed at language experts. It reads more like a technical advertising brochure.

Think of it this way. The Objective-C component is implemented in GCC somewhat like the implementation of inline assembler within VC++. The syntax is so isolated there's no impact. You have the same inline assembler in C or C++, and there's even a similar kind of "reaching over the barrier" to get to values from the opposing language. It doesn't require a separate compiler to implement.

Like the article, the point that they are separate compilers is technically accurate. What meaning does it have? The same command line tool is invoked, merely with different options. From a developer's standpoint, what relevant point is being made here?

It's true, you can't take any C program (as in all C code) an run it through a C++ compiler.

However, to the non-expert, what does that really mean? It gives the impression that you can't compile standard C with the compiler they have. That's not true. I doubt you can find a modern compiler toolset for which that point has any practical implication - that they could compile C++ code, but not C code with their toolset.

From the developers viewpoint, what selects between C and C++ compilers? Form many, it's whether the filename ends in .c or .cpp

Quote:

---

Originally Posted by Sam Hobbs

Or perhaps they are just plain wrong.

---

They aren't. Ignoring the vagueness of the "meaningful executable" statement, their basic point is correct. Not every C program can be directly compiled as C++.

Thanks for reminding me why I don't use the codeguru forums anymore.

If I am incorrect about my question, then I apologize. I truly believe that the answers being provided here are not accurate, but I won't dwell on that. I will simply agree to disagree.

The problem is you're interpreting the question differently than it is intended.

If the question is, "Can I build any C program with a C++ compiler," then the answer is probably yes.

If the question is, "Can I put C code into a .cpp file and expect a C++ compiler to always build it correctly," then the answer is no.

Quote:

---

Originally Posted by Lindley

If the question is, "Can I build any C program with a C++ compiler," then the answer is probably yes.

If the question is, "Can I put C code into a .cpp file and expect a C++ compiler to always build it correctly," then the answer is no.

---

I feel that those two questions ask the same thing: to build a C program with a C++ compiler is to place the source code of the C program in a file that will be detected as C++ by the compiler, or by explicitly specifying options to compile as C++. What I find inaccurate about JVene's answer is the assertion that "modern C++ compilers will operate in a C mode". Change it to "modern compilers can operate in a C mode" (and such usage can be found in the rest of his post), and I will be satisfied.

Quote:

---

Originally Posted by laserlight

I feel that those two questions ask the same thing: to build a C program with a C++ compiler is to place the source code of the C program in a file that will be detected as C++ by the compiler, or by explicitly specifying options to compile as C++. What I find inaccurate about JVene's answer is the assertion that "modern C++ compilers will operate in a C mode". Change it to "modern compilers can operate in a C mode" (and such usage can be found in the rest of his post), and I will be satisfied.

---

I agree.

Laserlight, I don't take exception to your point. The article cited suggests that it can't be done, but from a practical standpoint it can.

At the moment I haven't found one that doesn't (XLC for AIX, GCC, VC++, Intel C++ - each in several versions).

Sam, I'm not sure what you would otherwise think is inaccurate - with the exception of Laserlight's recommended diction, it might be useful if we could learn what fact isn't correct.

Quote:

---

Originally Posted by Sam Hobbs

Thanks for reminding me why I don't use the codeguru forums anymore.

If I am incorrect about my question, then I apologize. I truly believe that the answers being provided here are not accurate, but I won't dwell on that. I will simply agree to disagree.

---

Are you just trolling or something? If you think we're wrong how about telling us why you think we're wrong so that we can actually have a discussion, instead of making snide comments because we aren't giving the answer you want to hear.

Quote:

---

Originally Posted by Speedo

Are you just trolling or something? If you think we're wrong how about telling us why you think we're wrong so that we can actually have a discussion, instead of making snide comments because we aren't giving the answer you want to hear.

---

Criticisms such as that are best ignored. They do not contribute to meaningful discussion. It is comments such as that that make codeguru less useful.

You especially need to be careful about calling people a troll. That word has much more emotional significance than factual, and has a clear negative connotation. The negative significance of that word can easily start flame wars. It is language such as that that cause me to avoid further participation here.

I hope you realize the irony in criticizing a criticism instead of simply addressing it.