3 ms·

> C++ is (almost) a superset of C, you can mostly drop C code onto your C++ compiler and it will work. The devil is in the details. The "almost" and "mostly" p

by shric 4y ago

> C++ is (almost) a superset of C, you can mostly drop C code onto your C++ compiler and it will work. The devil is in the details. The "almost" and "mostly" parts are really important here, especially given that the entire topic is safety. If you compile "C code" with your C++ compiler (as C++), you're no longer compiling C code; you're now compiling C++ code that looks like C. It would be fine if C code, when compiled as C++ had one of two outcomes: 1. Behaved identically to C code compiled as C. 2. Refused to compile Unfortunately, there are things that exist in both languages but have different semantics such as the type of character literals, e.g. 'a' (int in C, char in C++). As for the superset thing, there's been quite significant divergence especially since C99 (e.g. variable length arrays) Other subtly different things include: the bool type (C++ has a bool type, C99 has _Bool with a macro for bool as bool isn't a reserved word in C). designated initializers (C99 had them first then C++20 introduced them to C++ but with more restrictions)

jstimpfle 4y ago
The things you mention are true but wholly besides the point. C/C++ normally means "C flavoured C++, or just C, I don't care", or it can mean "more modern C++, maybe do a bit of plain C or interface with C libraries". It's more about the domain you're working in and the general approach (compiled language, caring about performance, ....), and results, than about the minutiae of the language you're using. It doesn't mean thinking of C/C++ as literally a language that you can compile, and doesn't mean compiling random C code as C++.
ncmncm 4y ago
None of that matters. There are plenty of other differences, and they also don't matter. What does matter is that, while you probably can compile your C code with a C++ compiler with minimal changes, it is very bad code. It might be the best C code ever, but as C++, it is just crappy. I mean that technically: the C++ code you could have written instead would have been much, much better. As C++, that C code is just embarrassing. This is not a reason to avoid switching your project over to building with a C++ compiler, which you could do in an hour or a day. Gcc did this, and Gdb, both with rousing success: Gcc and Gdb are now better programs, and you can tell that just using them. Yes, after the switch, all the code will have instantly become bad code. But the secret is, it was always bad code. It was just (one hopes) the best anybody could have done in C. Now you can begin to make it into good C++ code. Incrementally, a little at a time. Probably starting with new features, and some key infrastructure, always resolving immediate frustrations. Each bit makes your program better. Probably most of it will still look a lot like C, forever. That is the code you don't touch much, and haven't needed to. Where you get the real benefit is in places you already have reasons to change. Those are likely to be near where future changes will be, too. There is never any confusion, looking at an evolving project, about which parts are C, which parts are in (say) 2000s-era C++, and which are modern. So, there is no value in trying to stay "consistent". New code is different because it can be. Old code is different because it still is. Some of it will change, and come to look modern, too. Most won't. And that is OK. Keeping code consistent would mean not applying things you have learned, and not doing things better than you could have before. Inconsistent code indicates learning and growth.
redox99 4y ago
The point here isn't copy pasting C code into C++ verbatim. The changes needed to translate C code into valid C++ code that does the same are very simple. One could translate many thousands of lines of C into C++ in an hour. More so, the point here isn't even translating an existing codebase where small bugs could surface. It's just explaining concepts. None of the C to C++ differences would matter. If an answer to OPs question was in C, he could trivially convert that C example into C++.

by shric 4y ago

jstimpfle 4y ago

The things you mention are true but wholly besides the point. C/C++ normally means "C flavoured C++, or just C, I don't care", or it can mean "more modern C++, maybe do a bit of plain C or interface with C libraries". It's more about the domain you're working in and the general approach (compiled language, caring about performance, ....), and results, than about the minutiae of the language you're using. It doesn't mean thinking of C/C++ as literally a language that you can compile, and doesn't mean compiling random C code as C++.

ncmncm 4y ago

None of that matters. There are plenty of other differences, and they also don't matter. What does matter is that, while you probably can compile your C code with a C++ compiler with minimal changes, it is very bad code. It might be the best C code ever, but as C++, it is just crappy. I mean that technically: the C++ code you could have written instead would have been much, much better. As C++, that C code is just embarrassing. This is not a reason to avoid switching your project over to building with a C++ compiler, which you could do in an hour or a day. Gcc did this, and Gdb, both with rousing success: Gcc and Gdb are now better programs, and you can tell that just using them. Yes, after the switch, all the code will have instantly become bad code. But the secret is, it was always bad code. It was just (one hopes) the best anybody could have done in C. Now you can begin to make it into good C++ code. Incrementally, a little at a time. Probably starting with new features, and some key infrastructure, always resolving immediate frustrations. Each bit makes your program better. Probably most of it will still look a lot like C, forever. That is the code you don't touch much, and haven't needed to. Where you get the real benefit is in places you already have reasons to change. Those are likely to be near where future changes will be, too. There is never any confusion, looking at an evolving project, about which parts are C, which parts are in (say) 2000s-era C++, and which are modern. So, there is no value in trying to stay "consistent". New code is different because it can be. Old code is different because it still is. Some of it will change, and come to look modern, too. Most won't. And that is OK. Keeping code consistent would mean not applying things you have learned, and not doing things better than you could have before. Inconsistent code indicates learning and growth.

redox99 4y ago

The point here isn't copy pasting C code into C++ verbatim. The changes needed to translate C code into valid C++ code that does the same are very simple. One could translate many thousands of lines of C into C++ in an hour. More so, the point here isn't even translating an existing codebase where small bugs could surface. It's just explaining concepts. None of the C to C++ differences would matter. If an answer to OPs question was in C, he could trivially convert that C example into C++.