Hacker News Reader

Comment by jagged-chisel | Hacker News Reader

Is this something that happens because someone thinks C/C++ is one language? I often see this single mythical language referred to in job postings, blog posts from folks with a range of experience in the field, and even in neophytes who got terrible information from their Java instructor at university. But I don't think I've ever come across it in an actual codebase.

I have seen .cc for C++ and it annoys me, but seems rather common.

View on HN

>> Is this something that happens because someone thinks C/C++ is one language?

No[1]:

> C++ source files conventionally use one of the suffixes `.C`, `.cc`, `.cpp`, `.CPP`, `.c++`, `.cp`, or `.cxx`; C++ header files often use `.hh`, `.hpp`, `.H`, or (for shared template code) `.tcc`; and preprocessed C++ files use the suffix `.ii`. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).

[1] https://gcc.gnu.org/onlinedocs/gcc/Invoking-G_002b_002b.html

This doesn’t speak to why the problem occurs. You didn’t even answer the question you quoted.

I don't work in C or C++ but I'm inferring from the context and other comments that it's actually because .c (lower case) is used to indicate C language code and .C (upper case) means C++ code. This then fails on windows because the OS is not case-sensitive wrt filenames.

So to make the implied answer to the question explicit: no, it's because someone who knew the difference between C and C++ sought to distinguish between their source code files using a filename extension convention that becomes invisible on a different OS.

They are incredibly similar, though. And they inter-link. It's easier to have one program that contains C and C++ code than it is to have one program that contains Python 2 and Python 3 code.

> They are incredibly similar, though.

Not even close. C++ is a vastly more complex language with a very different philosophy from that of C.

You might argue that C can very roughly be treated as a subset of C++, but this really is a very rough approximation. Which is to say, really, that it's wrong.

> And they inter-link

It's generally very easy to call C code from C++ code, yes. It is not easy to call C++ code from C.

> C can very roughly be treated as a subset of C++

Well, 99% of the time this holds, and you can generally use the same tooling in different modes for both. And they share a preprocessor.

> It's generally very easy to call C code from C++ code, yes. It is not easy to call C++ code from C.

Significantly easier than almost any other pair of languages, though. Especially if you take a little care on the C++ side (extern "C") or use COM or similar.

Again, C is more compatible with C++ than python 2 is with python 3. But not the other way round.

"99% of the time" may be stretching it a bit when you have to prevent yourself from using modern and useful C features in order to get a C++ compiler to accept your codebase.

> > It is not easy to call C++ code from C.

> Significantly easier than almost any other pair of languages, though.

I wouldn't say so. If you're using the features of C++ then you'd need to manually wrap it all to expose a C API.

Accessing C code from C++, Ada, Rust, Zig, Java, Python, C#, or just about any other language, would be easier than manually wrapping C++ to expose a C API.

(The LLVM compiler, written in C++, does this. It exposes a subset of its API as a C API. I get the impression it's no small task, or they'd expose the full LLVM library that way.)

> Especially if you take a little care on the C++ side (extern "C") or use COM or similar.

Agreed, but going the extern "C" route implies you're using C++ as a better C, rather than making full use of C++. I have to admit I don't know much about working with COM. It's vaguely like GObject, right? I imagine it must take quite a bit of work to expose a C++ API that way.

> Is this something that happens because someone thinks C/C++ is one language?

Nobody thinks that. Everybody knows what it means. Picking on it is like picking on people referring to amd64 as x86.

People think that. amd64 and x86 today mean the same thing, C and C++ not quite. I've also seen HR people think that java and javascript are the same thing.

Outside the world of people who do write C or C++, most people I talk to really do bucket the two together as if they were largely interchangeable or, at least, a lot more similar than they actually are.

Right I mean one project I was working on who had to write some JavaScript and would always refer to that language as Java. He was a developer, literally using one of the languages, so should have known better. And Java and JavaScript have less in common than C and C++.

Bucketing them together is fine. There are technical and organizational reasons for that. When you're working with C++, you're almost guaranteed to need to deal with C as well, so jobs for "C/C++ developers" make perfect sense. There is also a certain level of expectation that future versions of both languages keep incompatibility between one another to a bare minimum.

I'd happily apply for a "C/Rust" job as well.

In the olden days around VS 6, Microsoft only had one "C/C++" compiler. Needless to say it not very standard compliant, but C was still mostly a C++ subset, and the differences were anyway smaller than the deviations of MSVC from the C++ standard. So it made sense to just compile everything as C++.

AFAIK microsoft has never had a C compiler. C is enough of a subset of C++ that you can use MSVC to build most programs, but MSVC doesn't officially support C to this day. C++ tries to bring in everything of the latest C standard, but sometimes that isn't possible, or C++ has a better way (better generally because of some issue that doesn't exist in C in the first place). The C standard committee is aware of C++, and tries not to break the ability of C++ to use new C standards, but nobody is perfect.

> AFAIK microsoft has never had a C compiler.

Well, MSVC compiles .c files as C, which I guess makes it also a C compiler? It supports most of C99 by now.

> MSVC doesn't officially support C to this day.

Oh, it does: https://docs.microsoft.com/en-us/cpp/build/walkthrough-compi...

They had a standalone C compiler for kernel drivers.

Reply on news.ycombinator.com