11 ms·
Orthodox C++
- tomohawk 6y agoI thought this was a good point: > Don't do this: http://archive.md/2014.04.28-125041/http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/design.html http://archive.md/2014.04.28-125041/http://www.boost.org/doc... Maybe he is looking to use golang?
- amelius 6y agoThat's actually a very good example of what's wrong with C++'s templates and also shows how we got there.
- arcticbull 6y agoThat entire writeup is a scathing indictment of C++'s template system. It just gets progressively more horrifying and less understandable the further you read, until you're left with a mess of angle brackets, scope resolution operators and a pounding headache.
- northwindfoo 6y agoI think it goes to show that the combination of C++ giving the developer a lot of flexibility in how to approach a problem, as well as being unopinionated, leaves room for stuff like this to be built. There are a lot of decent ways to use templates; that link is definitely not one of them.
- amelius 6y agoTrue. It must be said, however, that the Boost libraries are built using a peer-review system. So this is not some "random" C++ code.
- eps 6y agoIt's a peer review in an echo chamber. What Boost project churns out is absolutely terrifying in its lack of rudimentary elegance and good programming taste.
- northwindfoo 6y agoI think that about sums up my experience with boost. I've found boost to be hit and miss in terms of elegance. One of the things I've liked about the standards track is how they've cleaned up many of the same boost concepts that ultimately ended up in std.
- gumby 6y agoAll of that is so that most user code doesn’t have to worry about corner cases. Libraries (of all languages) are full of weird stuff so that users can blithely use them without thinking about it.
- arcticbull 6y agoAgreed, but it should be possible to read and understand. This is solidly neither.
- gumby 6y agoThe sources to glibc are no clearer, for the same reasons.
- billfruit 6y agoI should say, after a quick glance most of the stuff is only adding greater typefullness and type saftey, which IMHO is good thing, considering the total type anarchy found in most large c projects. When some projects/domains even now prefer C to C++, aren't they trading off safety for vague expectation of greater execution speed?
- jcelerier 6y agoSo, how would you write it instead ?
- MaxBarraclough 6y agoInteresting idea, pity about the name. There's a vaguely similar effort with a similarly poor choice of name, Clean C, which is guaranteed to compile as both C and C++ with the same behaviour (provided there's no undefined behaviour or platform-specific behaviour). [0][1] > Exception handling is the only C++ language feature which requires significant support from a complex runtime system, and it's the only C++ feature that has a runtime cost even if you don't use it I don't think that's true. I believe that if you enable RTTI you pay for it even if you don't use it, which is why it's banned in the LLVM codebase. [2] > Don't use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.) I believe this is still supported, but is officially deprecated, for what that's worth. [3] [0] http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fhat_Clean_C.html http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%... [1] https://stackoverflow.com/a/9695020/ https://stackoverflow.com/a/9695020/ [2] https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-o... [3] https://stackoverflow.com/a/13643019/ https://stackoverflow.com/a/13643019/ edit Correction: It's called Clean C not Clean C++
- kllrnohj 6y agoThis is rather awful. The concept isn't terrible necessarily, but the execution and condescension sure is. And some of the rules are just pointlessly argumentative. Such as refusing to use <cstdio> and instead using <stdio.h> - those are officially documented to be different things with different behaviors. Blanket banning one of them doesn't improve simplicity, especially if you're blanket banning the "wrong" set of headers. Unless the goal is to also ban namespaces, but that's not called out as such (and namespaces are one of the least contentions C++ features - everyone seems to like them well enough). Or similarly: > Don't use anything from STL that allocates memory, unless you don't care about memory management. So don't use std::vector? Or std::unordered_map? Or std::string? These are all perfectly fine classes, banning them makes no sense at all. Maybe the goal was to ban "hidden cost" classes like std::function, but rolling your own 'C-style' is a hell of a lot more complex & error prone (raise your hand if you've seen a C pointer callback that forgot to have a void* context or a mismanagement of said void* context...)
- simias 6y agoI think any attempt at defining a strict subset of a language is going to face some pushback like yours, but I do agree that while I agree with most choices this one seems strange. Rolling your own containers is boring and error-prone and won't have all the features of the STL. Also, while iostream is a bit of a mess, having it be strongly typed means that it's, in my opinion, well worth using over cstdio. One thing I was surprised not to see mentioned here is multiple inheritance. In my experience it gets really messy really fast. Also I really recommend reading the linked archived Boost discussion about a geometry library, it's quite funny. It starts with: double distance(mypoint const& a, mypoint const& b) { double dx = a.x - b.x; double dy = a.y - b.y; return sqrt(dx * dx + dy * dy); } And after a couple of pages of refinements ends up with: template <typename G1, typename G2> double distance(G1 const& g1, G2 const& g2) { typedef typename strategy_distance < typename coordinate_system<G1>::type, typename coordinate_system<G2>::type, typename point_type<G1>::type, typename point_type<G2>::type, dimension<G1>::value >::type strategy; return dispatch::distance < typename tag<G1>::type, typename tag<G2>::type, G1, G2, strategy >::apply(g1, g2, strategy()); } But hey, it can compute distances in non-cartesian hyperspaces so that's pretty cool.
- aazaa 6y agoReminds me of JavaScript: The Good Parts by Crockford: https://www.youtube.com/watch?v=hQVTIJBZook https://www.youtube.com/watch?v=hQVTIJBZook Strip away an older language's bad features. You end up with a sub-language with the advantage of portability and better maintainability. The problem can be deciding (and agreeing on) which language features are good and which are bad.
- zabzonk 6y agoVery dubious stuff here. For example: > and it's the only C++ feature that has a runtime cost even if you don't use it – sometimes as additional hidden code at every object construction, destruction, and try block entry/exit, and always by limiting what the compiler's optimizer can do, often quite significantly. C++ doesn't do "hidden code" - "if you don't use a feature you don't pay for it" is one of the bedrock principles of the language.
- david2ndaccount 6y agoThat’s just marketing. See: https://godbolt.org/z/q9zEj4 https://godbolt.org/z/q9zEj4 With exceptions turned on there’s a hidden call to _Unwind_Resume. Additionally, the destructor has to be duplicated.
- microtherion 6y ago"you don't pay for it" doesn't mean that no code gets generated for exceptions in this case, but that no code gets executed unless an exception gets thrown, and your example does not disprove that.
- arcticbull 6y agoGenerated code has a cost in terms of size, of course, and in terms of performance via the addition of branching, branch mis-prediction penalty and decreased cache locality. This function invocation will also of course flush the pipeline and harm inlining. On a hot path this could be non-trivial.
- kllrnohj 6y agoWhile true it's also fewer branches than manual error handling via return values. So the only "fast" option is to just not handle errors at all. Which is a terrible recommendation, of course.
- alisonkisk 6y ago
- deleted 6y ago[deleted]
- ktpsns 6y agoI find the Arduino C++ "dialect" being quite orthodox. Maybe a bit too rigorous, since it doesn't use the STL (which is mostly quite fine). I personally don't like C++ code which exploit all Turing completeness of the templating language. Code using such libraries can get a horror to debug on cryptic compiler error messages.
- gmueckl 6y agoGCC isn't very clever about generating small binaries for embedded targets. Combining this with the code bloat from templates and heap allocator that must then also be linked into the program will make useful programs a tight squeeze in limited microcontroller program memory at the best of times. Dynamic memory management in long running programs with a small heap also invites fragmentation and spurious allocation failures.
- 37ef_ced3 6y agoI just use Go (golang) instead, whenever I can Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized as slices, packages are part of the language instead of just being naming convention, etc.) The longer I used C++, the more I despised it. I used C++ for 11 years and I literally hate the language. But C has always remained a pleasure, and Go is a continuation/modernization/enhancement of that Go is mature, stable, widely-used, well-supported, well-understood, etc., so it's fully mainstream If you like C, you will love Go
- Rendello 6y agoDo you have any thoughts on Zig? It's nowhere near stable yet, but it seems like the a promising C replacement, in terms of maintaining simplicity, strict memory control, etc. (speaking as someone who's only worked a few months in C, as a hobby)
- shrimp_emoji 6y agoYou misspelled Rust several times in your post here.
- 37ef_ced3 6y ago
- hegzploit 6y agoTerry Davis did it first haha. https://en.m.wikipedia.org/wiki/TempleOS https://en.m.wikipedia.org/wiki/TempleOS
- MauranKilom 6y agoI don't want to outright dismiss this piece as "argument bait", but it is essentially just a bunch of assertions on what other people should do with virtually no rationale and a bunch of shade thrown around deliberately. Sure, we all like to have a good argument, and C++ is an easy target, but this seems wholly unproductive from the get-go. If there was any intent of convincing others then this isn't how to do it. I would also like to know who or what the "Orthodox C++ committee" is. A search only gets you this exact gist. Is the author himself the committee? That really doesn't put this piece into a better light.
- userbinator 6y agoI wonder if it is satire, but then again it doesn't seem particularly too out-there, and "orthodox" reminds me of Russian culture, largely due to this: https://en.wikipedia.org/wiki/File_manager#Orthodox_file_managers https://en.wikipedia.org/wiki/File_manager#Orthodox_file_man...
- alisonkisk 6y agoWhat is Russian about that?
- VladimirGolovin 6y agoRussian here. Guys at my company still use Far (https://en.wikipedia.org/wiki/Far_Manager https://en.wikipedia.org/wiki/Far_Manager) as their primary file manager, and I'm not aware of any people other than us Russians who are still using Norton-like file managers in their day-to-day work.
- dagw 6y agoI know lots of people here in Sweden that do
- qalmakka 6y agoThis is somewhat exaggerated, especially because while there are several poorly designed areas in C++ and the STL, it's not all that bad and it can lead to safer, less fragile code than the C equivalent with less effort (but arguably, more skill is required in order to learn and proficiently use C++). It can even be faster than C in the hands of a skilled developer that knows where and how use the right features. It doesn't hurt that the STL is extremely optimized, and often provides you tools that accomplish what you cared about without lots of the gotchas and pitfalls you're almost certainly doomed to fall for if you're not aware of their existence. Almost every single C project I've seen (including some of mine, I've to admit) end up involuntarily reimplementing some basic algorithm or container, and most often than not it ends up being less efficient, or unnecessarily using the heap. One thing I think most people largely misunderstood is exceptions; they're actually totally fine if used in _exceptional_ circumstances, as if they were some kind of softer assertion, when you expect some kind of contract to be always true, but calling abort is just too unreasonable. This is basically the same approach Rust and Go use with panic(), and in both languages this facility by default causes the runtime to unwind the stack, as with C++ exceptions. I think lots of people have been turned off by certain bad designs in older C++ revisions, where exceptions where indiscriminately used for error handing. They were a nightmare to use right, and the lack of helpers like unique_ptr made exception safety very hard. Modern practices, an arguably better language after C++11 and guidelines/libraries such as the GSL vastly help in mitigating most of these issues, as long as people actually stick to them (i.e., no C style code without RAII). I may also argue that the whole "C++ exceptions are expensive" argument is 100% moot in 2020, I've been running code on microcontrollers with half a megabyte of ram with them turned on and they add an almost insignificant amount of overhead; they only cause a small amount of binary bloat, but that's nothing compared to the size of certain modern libraries (and storage is cheap).
- franklampard 6y agoi don’t get it. Why not spend ing the time and energy developing better language standards and then driving adoption of new standards?
- ncmncm 6y agoOrthodox C++ echoes the old "Embedded C++" scam. In that case, the impetus was to dress up having failed to implement templates, exceptions, and other "new" language features, typically as a result of budget cuts. In this case, it appears to be, rather, to avoid learning anything new. Make no mistake: code written to this, or any old-school subset, is Bad Code. Features are not added to C++ on a whim. They are added because they make programming in new C++ a better experience than old C++. New C++ code is faster, safer, smaller, less bug-prone, and more fun than old C++. C++20 is much more fun than C++17, which is better than C++14, which filled out lots of features from C++11. Do not trust anyone suggesting any virtue in more C-like C++ code, or in actual C code. We left those behind for reasons. C++23 will be better than C++20.
- fwsgonzo 6y agoI completely agree. The fact that the first example is using printf just shows that the best it can offer is some things we already know (template metaprogramming sucks etc.). C++20 has std::format which is insanely more powerful, safe and performant than printf. To say that you should only be using the non-allocating functions is also bad advice. The whole thing reeks of someone who didn't bother to measure where he was actually spending time. I didn't read the whole thing but I'm expecting that hes bashing exceptions too, even though they don't cost anything other than code size unless you actually throw. And it's perfectly fine to turn them off, if you're fine with abort. Really, the only thing I can think of that I really dislike about both C and C++ is that backtraces should have been a first class citizens since the early 2000s. I think that's a huge reason why people pick up other languages more quickly too.
- mempko 6y agoI'm sorry, but the STL, especially the Stepanov designed parts are brilliant pieces of software. Written in a style unlike anything else. Generic programming is often misunderstood and that's a damn shame.