6 ms·
The one real reason to use C++ is for templates. Exceptions, object orientation, etc. is all fluff. C++ is far better captured as “C with metaprogramming” rathe
by tines 8y ago
The one real reason to use C++ is for templates. Exceptions, object orientation, etc. is all fluff. C++ is far better captured as “C with metaprogramming” rather than “C with classes”, and the other features are the supporting cast for that, not the other way around.
- zem 8y agoi'd use it above C for strings alone, to be honest!
- hackits 8y ago`object orientation` oh lord are you kidding?
- dman 8y agoTemplates + RAII
- Koshkin 8y agoAnd operator overloading: I want to write A + B instead of matrix_add(A, B).
- dymk 8y agoThis is actually one of the strongest arguments against writing performance sensitive code in C++. Because of operator overloading, I don't know if `A * B` is incurring a (nontrivial, arbitrary) function call. Maybe it's just normal scalar multiplication, maybe it's finding the dot product of two arbitrarily sized matrices.
- jcelerier 8y agoHaving used multiple maths libs over the year I have never been in a position when I did not know immediately what A * B does. Why are you writing it if you don't know what happens ? At which point in your life would you write A * B and not know if one of A or B is a matrix ?
- dymk 8y agoYou'll know what it does if you're the author. But code is read much more often than it's written, and it's easier to spot bugs and understand what each line of code does without operator overloading. Operator overloading obscures what the actual code is doing. Because of this, it's is generally not used in kernels, virtual machines, etc. As an example, if I give you this line of C++ code, and no other information (which would require further effort to determine, e.g. the types of identifiers), can you tell me if it's a function call, performs I/O, or does dynamic memory allocation? auto C = A + B;
- kllrnohj 8y agoHere's the equivalent C code: typeof(A) C = add(A, B) Now tell me if it involves a function call, performs I/O, or does dynamic memory allocation? And, of course, things like macros and typeof are totally used in kernels, virtual machines, etc... The ultimate obfuscation is alive & well in those areas. So no, the potential to do terrible things in operator overloading is not even remotely a concern there. No more than anything else.
- dymk 8y agoThat's not equivalent C code - because there is no equivalent C code. I can tell you, if I write this in C, it performs no I/O, memory allocation etc: typeof(A) C = A + B; I know for a fact that (modulo people doing incredibly stupid things with macros), that this is simple arithmetic addition. I don't know that for a fact in C++ - because of operator overloading.
- kllrnohj 8y ago> I know for a fact that (modulo people doing incredibly stupid things with macros), that this is simple arithmetic addition. I don't know that for a fact in C++ - because of operator overloading. The only way to know for a fact what happens in either C or C++ is to know the types of A & B, which you (seemingly intentionally) omitted. But if A & B are the types that can be added in C, then it's going to be literally identical in C++ with no chance of operator overloading. If A & B are not types that can be added in C, then you would see an add() function called instead and you'd be right back to not knowing what it does.
- gpderetta 8y agoAnd if you do matrix_add you do not know if it is a bunch of primitive operations or doing MPI operations.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- jeremyjh 8y agoRAII is just as important as templates, and it does require you to use classes/structs.
- johannes1234321 8y agoTrue it requires classes as RAII is based on a destructor. However this doesn't require OOP design, which typically is associated with classes and objects.
- jeremyjh 8y agoYou don't have to use inheritance, but you will certainly use object composition and encapsulation to manage the lifetimes of your data in a coherent way.
- ndesaulniers 8y agoRAII strictly for preventing leaks of resources is the lone thing I miss in C. Constant folding via constexpr in C++ is much much better than C. Templates help write generic code that results in specialized machine code; it may be hyper optimized at the cost of binary size. They make it harder to write code that at runtime is a little more type generic (if that makes sense). You can't always afford those additional copies generated. Not that it's a bad thing; just an observation as I write both strictly C and C++ at my day job. Stealing the below; string handling is significantly safer with std::string. I'm not sold on std::string_view.
- humanrebar 8y agostring_view is about expressiveness and design flexibility (vector<char> and char* can trivially convert) that safety. That being said, string_view is arguably safer than passing around a char* and a length.
- ndesaulniers 8y agohttps://bugs.llvm.org/show_bug.cgi?id=34729 https://bugs.llvm.org/show_bug.cgi?id=34729 Literally had to write a psuedo borrow checker to stop it: https://youtu.be/80BZxujhY38?t=1095 https://youtu.be/80BZxujhY38?t=1095 So much work rather than admit the interface is bad and you should feel bad. C++: "shoot yourself in the ~~foot~~ face."
- rwbt 8y agoSooner or later, C++ is going to get a borrow checker anyways. I guess it's all going to be ok? :) I'm not entirely sold on string_view or span yet. But I wasn't sold on tuples either and I use them a lot now.
- deleted 8y ago[deleted]
- humanrebar 8y agoThe bug there is implicitly converting an r-value to a non owning reference. We wouldn't call the same semantics a bug with a 'char const*' to be fair. We would complain that string implicitly converts or reject the application code as buggy. That being said, yes, string semantics are hard. Passing around copies of a string buffer (std::string) or calling to_string_view everywhere don't seem better.
- electrograv 8y agoIf you're interested in alternate languages along the lines of 'C with metaprogramming' (and without the bad stuff C++ forces you to deal with in some cases), you may enjoy taking a look at Zig (https://ziglang.org/ https://ziglang.org/) or Rust (+ RAII).
- edflsafoiewq 8y agoZig doesn't really support RAII.
- derefr 8y agoC++ also has a fair number of built in STL smart-pointer types that do approximately the same thing as the "move/borrow" semantics which everyone gets excited about in Rust. These alone are a worthwhile "dialect" on top of C, the use of which results in a far safer C; and—as far as I know—these smart-pointer types and their compile-time semantics would be impossible to implement without C++'s additional layered-on "C with classes" type system. (It's clear that these smart-pointer types are a valuable addition to C, because they were independently implemented as part of all sorts of other C macro libraries in the early 90s. I think there were at least four C smart-pointer implementations that existed as part of various parts of Windows, for example.)
- sifoobar 8y agoSTL smart pointers are all fun and games until you start using threads, at which point you realize that automagically flipping the (now atomic) counter back and forth behind the scenes every time the pointer can't be safely passed as a reference is a performance disaster. Manually referencing and de-referencing exactly when needed avoids most of this. Sometimes it's perfectly safe to pass the same reference through several layers without changing the number of references. As an added bonus YOU get do decide which references, if any, need to support multiple threads.
- gpderetta 8y agoReference counted smart pointers are just one of the many smart pointer types. Atomically reference counted smart pointers are a smaller subset of those.
- sifoobar 8y agoRight, if the discussion isn't going your way you can always side track by making up faults and projecting agendas. How is this helping us go anywhere worth going? I was talking about std::shared_ptr, which is the closest thing to reference counting that STL offers.
- 8y ago
- yarrel 8y agoI'd use it for objects. Templates, exceptions, streams, the STL etc. are all badly thought out debugging and maintenance nightmares.
- lenkite 8y agoUmm..things like standard library strings, futures, threads, memory management via shared_ptr, unique_ptr, RAII etc are also other great reasons to use C++. Every time I attempt to code in C, its like my hands and legs are cut-off. I suppose some folks enjoy this.
- interesthrow2 8y agoThe biggest problem with C isn't even it's lack of type safety, undefined behavior but that antiquated macro system which does more harm than anything. Imagine if C had a solid AST-based macros system...