11 ms·
Even as a C++ programmer with too much spare time, it has become obvious that learning and using all of C++ is beyond impractical. To the point where I find tha
by hackingthenews 6y ago
Even as a C++ programmer with too much spare time, it has become obvious that learning and using all of C++ is beyond impractical. To the point where I find that my C++ code more than ever before looks like C.
Nowadays I am using C++ mainly for the high-performance libraries, and only if I can't archive the same in jit-ed python, cython or rust.
The Java strategy of being very conservative about what you add to the frontend would have done C++ a lot of good after C++11 (or even before that).
- rightbyte 6y agoThe notion of using C++ like "as C but with namespaces, std::vector, string and map" is way underrated.
- pansa2 6y agoThat’s your choice of C++ subset, but the problem with these huge languages is that everyone chooses a different subset to use. Sticking to plain C has the advantage of probably being the subset of C++ (I know, it’s not technically a subset) that’s in widest use.
- krychu 6y agoI’d add that deciding on the subset is a high cost operation. Design of such a smaller subset-language will likely not be on par with language that is small by design.
- taneq 6y ago> (I know, it’s not technically a subset) Is it not? I thought C++ was explicitly a strict superset of C?
- einpoklum 6y agoSyntactically, it almost was; and even this is no longer true today with C11 and later, More importantly, though - the syntax is not what matters. The languages are very very different in idiomatic use. You just don't write programs the same way with C and with C++. And the gulf between the two only expands with time. A decent C program is almost certainly a poor C++ program, in terms of idioms, utilization of library facilities, and sometimes even in terms of performance (!).
- janoc 6y agoIt is not and never was. Look at for ex. what const means in each, or auto. Or variable length arrays (feature that doesn't exit in C++). Or designated initializers that C++ didn't have for a long time. Here is a good list of differences: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html
- gmueckl 6y agoC++ is almost a perfect superset of old C before C99. There are odd corner cases where prograns are parsed differently, but these are quite contrived. The 3rd edition of The C++ Programming language lists a few cases. Since then, C has had may additions to the language that made it diverge from C++. Your linked article is almost entirely about these new C additions.
- janoc 6y agoEven for the old C it wasn't a superset. There are plenty of legal C programs that aren't legal C++ - if for nothing else, then because C++ has more reserved keywords which are perfectly legal identifier names in C. E.g. this is legal C but not legal C++: int template = 10;
- gus_massa 6y ago> everyone chooses a different subset to use I prefer using C++ like "C but with cin and cout" and I informally call it C+ :)
- rubber_duck 6y agoWhen you add those to the mix you're dealing with destructors, ownership, etc. so I don't see anything wrong with using stuff like unique_ptr/shared_ptr. And C tends to reinvent object oriented programming with each library so you might as well use language defined classes. So I don't really see the point. You don't need to use stuff like concepts, or "showing off how smart I can be with template libraries" (looking at boost), but C++ has a lot of features that make it much more productive than C.
- stjohnswarts 6y agoYeah that's basically how I use it for embedded programming c with classes, raii, better strings, and smart pointers :) . I generally avoid rolling my own pointers and anything much fancier that the simpler algorithms/sorts/etc
- taneq 6y agoAgreed. The bigger C++ gets, the more important it becomes to treat it as "C with some cool extras" and to consider any and all new features as optional extras that you only use if you legitimately need them. The moment you start seeing "C with classes" style as a bad thing, you will slowly wander off into the wilderness.
- zerr 6y agoThe vast majority of the real world code a C++ programmer writes day to day is just that.
- pornel 6y agoI think the niche of "more than C, but not C++" is going to be eaten by Rust. It's like C with modules, Vec, String, HashMap, and one standard sensible cross-platform build system.
- pjmlp 6y agoIt might, but Rust still needs to grow a matching eco-system.
- kccqzy 6y agoRust has plenty of advanced language features that can entertain the same kind of people who enjoy writing C++ template metaprogramming as a brain teaser.
- blub 6y agoIn practice Go is making inroads in that area. Since Rust has similar complexity to C++ it's not really comparable to C or Go.
- pornel 6y agoGo is a nice language growing in popularity, but it's not a C replacement. Garbage collection, big runtime, and non-zero-cost FFI are acceptable trade-offs in many areas of programming, but they are deal-breakers for domains where C (or Rust) is necessary. Rust is somewhat similar to C++ in the feature set, but not in complexity. Rust's features are more orthogonal, without duplication and backwards-compat warts, and you get hand-holding by the compiler.
- blub 6y agoC is "misused" for a lot of things and Go is a contender in those areas though. Technically you could be right about complexity vs. feature set, but from the POV of someone that's using a simple language, the two don't look that different. One does help you avoid certain errors, although whether that counts as hand holding or hand slapping is in the eye of the beholder.
- 6y ago
- bitwize 6y agoAnd templates, and standard algorithms, and move semantics, and lots of other things that are pretty much necessary in modern code. Well, not necessary, but by restricting yourself from using them you are needlessly: * creating more work for yourself, and * introducing bugs in your code. Don't do that. Use C++ as C++.
- stjohnswarts 6y agoIf I want all the advantages of that stuff I'll just use rust.
- rubber_duck 6y ago>The Java strategy of being very conservative about what you add to the frontend would have done C++ a lot of good after C++11 (or even before that). Java lost a lot of mindshare to C# and Kotlin due to that "strategy".
- pansa2 6y agoIt seems to me that for many developers, all they want from a language is more and more features. I’m grateful for languages like Go and Lua that try to buck this trend.
- pjmlp 6y agoYeah, it is so liberating to write boilerplate libraries.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- pjmlp 6y agoJust for the HN crowd. C# still doesn't deliver on all platforms where there is a JVM available, and has yet to even offer something as portable as Swing across all those platforms. Kotlin really only matters on Android. In fact right now we are having issues with .NET RFPs, because everything that comes through the door are Java related RFPs.
- rubber_duck 6y agoNot really - Java designers were just plain wrong and it took forever to admit it - things like local type inference (var) made the language pointlessly verbose for ages, and simple features like lambdas made the standard libraries terrible. There was a 8 year gap where C# users could use stuff like enumerable operators while Java users were stuck in the stone age of writing loops for collection manipulation in a high level language ...
- creato 6y agoWhy does this post need to appear any time C++ is a topic? Do you learn and use all of any language you use?
- pjmlp 6y agoBecause there is this urban myth that other languages aren't as complex, yet drop someone with a beginners loved language like Python 3.8 and they will have fun throughout the almost 2000 pages of documentation plus all major libraries in use across the ecosystem, and Python implementations.
- tylerhou 6y agoOther languages are definitely less complex — you generally don’t see language lawyering for Python or Java — but I think that there are many useful features in C++14/17/20 as well. Writing only C++11 will lead to suboptimal code.
- jcelerier 6y ago> you generally don’t see language lawyering for Python or Java But my experience for instance when having to do stuff in C#, Java or Python is that when I'm looking for advice on the internet, stackoverflow, etc etc... 80% is reaaalllly bad, in the sense that if it were C++ everybody would be screaming "wtf don't do that this is insane" and write 12 blog posts and 40 twitter flamewars about why this is a bad idea and you should never ever do this... but apparently the "tolerance to bad code" is much higher in other communities.
- tylerhou 6y agoOne way Herb Sutter looks at it is — most advanced programmers could probably write a Python or a Java interpreter. It might take them a few years, and they might struggle with some complex language features like metaclasses, reflection, or the type system, but the language spec is understandable enough that it’s feasible. But give them five years and they would generally not be able to write a C++ compiler.
- pjmlp 6y agoDrop someone in front of C# 9, Java 15, Python 3.8, Typescript 4.0, Ada 2012… and watch how they manage.
- AlexSW 6y agoJava 15?! I hardly realised they'd moved past 8.
- hackingthenews 6y agoNew version bumps after 8 are not necessarily major.
- logicchains 6y ago>Nowadays I am using C++ mainly for the high-performance libraries, and only if I can't archive the same in jit-ed python, cython or rust. Is anyone aware of a library for another language that's as fast as Eigen?
- singhrac 6y agoThis is a hard comparison because pretty much all of these libraries call a BLAS implementation under the hood, so what you might be comparing is actually the cost of stuffing the array with your data in each language (which is obviously task specific). I think it'd be difficult to argue one way or another: Eigen gives you flexibility one way (custom kernels) and Python gives you another (interactive debugging and easy visualization). Cython/Numba make it even more muddied.
- shaklee3 6y agoI can definitely takes the cake for an easy to use syntax for doing all kinds of linear algebra. It's only able to do that because the extensive operator overloading that C++ allows. However, don't want that for you for a speed. Using something like MKL directly is always going to be faster than eigen. The trade-off is the API is much more complex.
- einpoklum 6y agoC++ is not a "language for all things". It's a tradeoff of features, and that's ok. However, the idea that you should learn and use "all of C++" is a mistake to begin with. It's something that sort-of happens with C, but doesn't really make sense with larger languages. Specifically, remember that C++ is _multi-paradigmatic_ - you can write more object-oriented code, functional code, highly templated generic imperative code, or, well, C-style code. The standard library also now has something for everyone, and there's no reason to know _all_ of it. On the other hand, many things which used to be difficult to write and required some deep "voodoo" or a lot of boilerplate are easier and more straightforward these days.
- roenxi 6y agoC++ looks more like a union of many other languages than anything else I know of. Forget the old joke of mimicking Common Lisp, C++ is a hacky implementation of all other programming language. It is quite marvellous in a way, almost a statement of "we don't want design, we just want something that compiles". It has worked out remarkably well in practice.
- hellofunk 6y ago> it has become obvious that learning and using all of C++ is beyond impractical. Doesn’t really make sense why you’d want to anyway. Why would you want to use all of any language? C++ offers so many features because of its extraordinary flexibility and application to a wide range of domains. Unless you’re writing an app that is a game that also trades high frequency transactions on the financial exchange, while performing physics simulation and 2-D vector rendering, all while serving up a Web server, it would not make sense why you need to use all of the language. It’s perfectly fine to find those parts of a language that you are personally interested in.
- tomtomtom777 6y agoThe set of features a language provides is part of an unwritten contract: We write our code such that it minimizes the amount of effort to read it, under the assumption the reader knows the language. This way, it makes sense not to use a library for something that can already be cleanly expressed by the language because this introduces additional mental overhead for the reader. Yet is doesn't make sense to avoid modern, simplifying language constructions, as we can assume these are known by the reader. This unwritten contract is jeopardized by an overload of language features, as suddenly we may want to avoid certain features considered complicated. Hence, the notion of optimal code becomes more subjective.
- flohofwoe 6y agoIt becomes a problem when using code written by other people. Since everybody is using a different subset of C++, a project with external dependencies quickly becomes a hodgepodge of different idioms, coding practices and language subsets and as a result becomes harder to maintain. Some of the language features are incompatible with others (e.g. using exceptions for error handling vs disabling exceptions for performance).
- ben-schaaf 6y agoPretty close to none of the things added to C++ over the years are specific to certain kinds of problems. It's not like you can't write a game/hft/physics/svg rendering perfectly well in C.
- asveikau 6y agoI think my objection along those lines, if I were searching for one, is not with the quality of what is being added but with the fact that it takes effort to keep up with them. C++11 introduces hugely useful stuff. I would much rather have it than C++03, c++98, etc. Whenever I come across things introduced in 14 or 17, I usually evaluate it and say, that addition makes sense, maybe it should have been there sooner. But I am not actively seeking out that information. So I am never up to date. It is a big contrast from a few decades earlier, where you would expect to use very few new features from the standard for a period of many years. That is also the expectation the C standard gives: it hasn't changed substantially since 1999, and even that you could call relatively minor since 1989. But I still think they are doing a good job with modern c++, even if these old expectations are no longer the case.
- Const-me 6y ago> learning and using all of C++ is beyond impractical I agree in general, but still, some of the newly introduced features are actually awesome. Here’s ones I’m using almost every day. C++/11: initializer lists, range-based for loops, strongly-typed scoped enums, raw and UTF8 string literals, thread_local, thread synchronization classes including atomics, alignas C++/14: binary literals C++/17: if constexpr, std::string_view, better static_assert And in C++/20, pretty sure I gonna use std::span and std::bit_cast. In C++ we don’t pay for features we don’t use. I’m totally fine with other people getting the features they want (despite finding them unreadable and overcomplicated), I simply don’t use the stuff I don’t like.
- higerordermap 6y agoMy objection is lot of features are being added as library features in ad-hoc ways. The old "if it can be library, it should be library" fallacy. The classic example is C++ ranges' pipe operator. If it was implemented in language, like OCaml and Elixir do - There would have been no need to write range adapters - the error messages and debugging could be much better than 100000 line template implementation. - debug build would be fast as well - compile times would not suffer Implemet-it-as-library is often a leaky, brittle abstraction. That's the reason LISP, with its proclaimed magic capabilities, didn't take off. The C++ committee seems quite academic at moment. Last time I read C++ performance report, all I could find was some old advice like "use list if you want insertion"™. They didn't mention difficulties in using realloc in vectors. They didn't mention inefficiencies in stl HashMap implementations due to iterator invalidation constraints. They didn't mention exceptions requiring dynamic storage and RTTI. Note that many of these problems are not yet fully solved with move constructors. At the same time they are also less academic than required. Given how they managed to put pipelines into an ugly template library without any of the considerations I mentioned above. I can't help but I feel similarly towards all standards committees. The JS standards people are still unable to deliver a standard library, and a "use strict"-like flag that enables easy tree-shaking. If anyone here is in C++ standard committee, you owe us an answer.
- gpderetta 6y ago> Last time I read C++ performance report, all I could find was some old advice like "use list if you want insertion"™. They didn't mention difficulties in using realloc in vectors. They didn't mention inefficiencies in stl HashMap implementations due to iterator invalidation constraints. They didn't mention exceptions requiring dynamic storage and RTTI. Note that many of these problems are not yet fully solved with move constructors. The TR18015 (Technical Report on C++ Performance) goes into details on most of the above (and much more) and it was written in 2006. The only thing missing is a discussion of hash_map as it wasn't part of the standard yet.