4 ms·

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the fea

by zanny 12y ago

Why not just write C style C++? I never understand the arguments to use C anymore - you can write C style C++ and get on with your life, and cherry pick the features you want. In C++ unicode is as simple as: string s = u8"This is always a utf8 string.";

pmelendez 12y ago
Well there are people who really hates C++[1] and to be honest C++03 had some flaws an inconveniences that made the language a bit awkward. Right now it feels like it is going in the right direction. [1]http://article.gmane.org/gmane.comp.version-control.git/57918 http://article.gmane.org/gmane.comp.version-control.git/5791...
akira2501 12y ago
Is 'extern "C"' still a thing to avoid name mangling? Some C++ features are easier not to use than others.
- mpyne 12y ago
  Yes, extern "C" is still a thing to interoperate with the C FFI. It is required if for nothing else than to use C headers.
conistonwater 12y ago
The main problem with using C++ as C is that everyone has different ideas about which ideas to cherry pick. So without a lot of discipline and a good coding standard, lots of (maybe subjectively) bad ideas will make it into the code as well. And once they do, you can't do anything about them any more.
programmarchy 12y ago
Firmware development. For some microcontrollers, you'll be lucky to even have a C compiler let alone a C++ compiler. Even then, I'd rather use C than C++ for firmware. I often find myself running into odd compiler issues, having to inspect/modify assembly, deal with resource constraints, etc. and I imagine C++ would make that more difficult.
millstone 12y ago
Unicode is much more complex than that. For example, how would you then convert that string to uppercase, or truncate it? For Unicode strings in C++, you can either limp along with the wchar_t support, or leverage something like ICU. Neither is especially easy.
- zanny 12y ago
  If you want string manipulation in C++ you need an external library no matter what encoding you use. Also, std::toupper inherits the system locale (or whatever you set it to), so if it is utf8 it would do proper utf uppercase conversions. You need to parse per character though, and that depends on the locale again.
antimagic 12y ago
Weeellll, your position is defensible if you're writing an application. If you're writing a library though, let me just let you know that every time I encounter a package with a C++ API, I want to drive stakes into the author's eyes, as compensation for the pain I'm about to experience. Like it or not, C is the lingua franca of the programming world. Pretty much every other language out there provides C bindings, not C++ bindings. Which means that when your function exports something wonderful like smart pointers, my world just becomes painful. Furthermore, in embedded environments, it can be challenging (to use a euphemism) to get source code debugging up and running. If your code is written in C, it's not so bad, non-optimised machine code generated from C tends to match the actual C code fairly closely, to the point that you can very nearly read it as easily as the original source. This is not true for C++, which means that every time something goes wrong in C++ code, I'm probably going to lose a week of my life inserting trace into the code, compiling, deploying to target, and running the test, ad infinitum. Not fun. Even in the case where you're writing an application, I'm personally dubious about the benefits of C++. Write the application in a higher-level language, personally I like Javascript (JavaScriptCore) for this, but I've had good success with Ruby and lua as well. When you hit a performance bottleneck, push the performance sensitive code into C, and create bindings. As a bonus, your C code is now easily available to be used as a library from any other language, without inducing homicidal tendencies in the user.
- zanny 12y ago
  extern "C" { } Hey look, C API. > This is not true for C++, Depends on the code you write. If you write C in C++, you get the same near machine parity, since its the same source material. If you do not use namespaces you don't even get name mangling.

by zanny 12y ago

pmelendez 12y ago

Well there are people who really hates C++[1] and to be honest C++03 had some flaws an inconveniences that made the language a bit awkward. Right now it feels like it is going in the right direction. [1]http://article.gmane.org/gmane.comp.version-control.git/57918 http://article.gmane.org/gmane.comp.version-control.git/5791...

akira2501 12y ago

Is 'extern "C"' still a thing to avoid name mangling? Some C++ features are easier not to use than others.

mpyne 12y ago
Yes, extern "C" is still a thing to interoperate with the C FFI. It is required if for nothing else than to use C headers.

conistonwater 12y ago

The main problem with using C++ as C is that everyone has different ideas about which ideas to cherry pick. So without a lot of discipline and a good coding standard, lots of (maybe subjectively) bad ideas will make it into the code as well. And once they do, you can't do anything about them any more.

programmarchy 12y ago

Firmware development. For some microcontrollers, you'll be lucky to even have a C compiler let alone a C++ compiler. Even then, I'd rather use C than C++ for firmware. I often find myself running into odd compiler issues, having to inspect/modify assembly, deal with resource constraints, etc. and I imagine C++ would make that more difficult.

millstone 12y ago

Unicode is much more complex than that. For example, how would you then convert that string to uppercase, or truncate it? For Unicode strings in C++, you can either limp along with the wchar_t support, or leverage something like ICU. Neither is especially easy.

zanny 12y ago
If you want string manipulation in C++ you need an external library no matter what encoding you use. Also, std::toupper inherits the system locale (or whatever you set it to), so if it is utf8 it would do proper utf uppercase conversions. You need to parse per character though, and that depends on the locale again.

antimagic 12y ago

Weeellll, your position is defensible if you're writing an application. If you're writing a library though, let me just let you know that every time I encounter a package with a C++ API, I want to drive stakes into the author's eyes, as compensation for the pain I'm about to experience. Like it or not, C is the lingua franca of the programming world. Pretty much every other language out there provides C bindings, not C++ bindings. Which means that when your function exports something wonderful like smart pointers, my world just becomes painful. Furthermore, in embedded environments, it can be challenging (to use a euphemism) to get source code debugging up and running. If your code is written in C, it's not so bad, non-optimised machine code generated from C tends to match the actual C code fairly closely, to the point that you can very nearly read it as easily as the original source. This is not true for C++, which means that every time something goes wrong in C++ code, I'm probably going to lose a week of my life inserting trace into the code, compiling, deploying to target, and running the test, ad infinitum. Not fun. Even in the case where you're writing an application, I'm personally dubious about the benefits of C++. Write the application in a higher-level language, personally I like Javascript (JavaScriptCore) for this, but I've had good success with Ruby and lua as well. When you hit a performance bottleneck, push the performance sensitive code into C, and create bindings. As a bonus, your C code is now easily available to be used as a library from any other language, without inducing homicidal tendencies in the user.

zanny 12y ago
extern "C" { } Hey look, C API. > This is not true for C++, Depends on the code you write. If you write C in C++, you get the same near machine parity, since its the same source material. If you do not use namespaces you don't even get name mangling.