Hacker News Reader

Comment by RcouF1uZ4gsC | Hacker News Reader

I have found that most people who classify themselves as a “C/C++ programmer” are incompetent at both C and C++.

There are many competent C and there are competent C++ programmers, but people who try to be C/C++ programmers end up with the worst of both worlds. They lose the simplicity of C without going far enough to gain the full benefits of C++.

View on HN

I've had to ping pong between C and C++17 on some projects where I've written Linux kernel modules, and then userland C++ code to exercise said modules.

I find it very hard to transition back to a C mindset coming from modern C++, not so much the other way around. Going from kernel C to userland modern C++ is akin to getting that first gasp of fresh air after nearly drowning.

Granted, that _could_ be a function of the "complexity" of writing kernel code, in that it can take up a lot of mental real estate, and there's less "risk" involved with userspace code...

But would you call yourself a C/C++ programmer? Or a C programmer and C++ programmer?

In English / is an abbreviation for and.

An abbreviation widely accepted by several institutions with a saying in programming language standards, only people in forums get uptight about writing C/C++.

I would call myself a programmer. No language prefix.

Languages are tools.

This is completely misguided. People who call themselves C/C++ Programmers are basically developers who are proficient in Systems Programming and not necessarily C or C++. It just happens to be that C and C++ were the only primetime options until the likes of Go and Rust entered the scene.

Also if you know C++ to a decent enough extent, you are going to have a certain level of command over C too. And there is no reason why calling yourself a C/C++ Programmer should undermine your proficiency in either of those languages.

Broad generalizations are generally bad.

Thankfully no ISO C++ official documents don't mention C/C++ anywhere, neither has Bjarne ever written such thing.

I agree that people that think there is a language called C/C++ probably don't have much of a clue, but it is certainly possible to program in both C and C++ and do a good job in both.

The common subset of C and C++ is different enough from "idiomatic" C and C++ that it almost can be called a separate "C/C++" language ;)

The common subset should probably be called something like "better C" - it won't be able to use any major (or many minor) C++ features. Basically, it will be ANSI C (give or take). Noticeably, the code for the 2nd Ed of The C Programming Language was tested using a C++ compiler, not a C compiler

The common C/C++ subset is an outdated and non-standard C though. For instance standard-conforming C++ compilers cannot compile C99 code and onward, they're stuck at a non-standard C version that would roughly be C95, minus some things that are valid C but not valid C++.

They can compile more C11 code than C99, thanks to the stuff dropped in C11.

They also support most of the C standard library additions.

As of C++20, the biggest difference is that designated initializers must follow field declaration order, restrict and _Generic aren't supported, and the type safety semantics are stronger.

There's also a handful of small differences like this, e.g. in C it's possible to construct a value and take the address for a pointer argument right in the function call:

    func(&(bla_t){ .x=1, .y=2 });

This is completely valid C, but invalid C++ (C++ has references as "workaround" for such adhoc-constructed parameters which shouldn't be passed by value).

Yes, that falls under my "type safety semantics are stronger" part of the comment.

In my perception there is a group of considerable size who thinks that C++ is largely b*s*, but still uses C++ (technically) for one reason or another (availability of compilers, interfacing with existing ecosystems, availability of jobs) - in a way that is basically C with almost no C++ features.

This is a group of people that considers themselves systems programmers in the first place, and doesn't really care about the language very much, except that they don't want to have to deal with stuff like this: https://twitter.com/fabynou/status/784905829866614784

I don't see any reasons for the people in this group to not consider them "C/C++ programmers". Au contraire, I've found the people that like to point out that "C/C++ isn't a language" to be annoying nit-pickers that care too much about the language and too little about systems programming.

I guess FANNG are full of such programmers given that they use C/C++ everywhere on their docs.

I don't call myself a C/C++ programmer but I have done both professionally, am productive in both, like them both.

I understand and appreciate where idioms differ and that there are pros and cons to each.

"C/C++" is a valid term for the common subset of C and C++. Even if both are different languages, it's possible to write code which is both valid C and valid C++ (but is a subset of both languages). Usually the goal when writing "C/C++" is to write C code that also compiles in C++ compilers (and this, contrary to popular believe, is a very restricted subset of C, and is almost a 3rd language).

Also, what else would you call yourself if you write both lots of C++ code (for the job) and C code (for fun) ;)

I would call myself a C and a C++ programmer. If I also wrote Java (which I do), I would call myself a C, C++ and Java programmer.

Reply on news.ycombinator.com