12 ms·
C++'s refusal to maintain compatibility with C while scrupulously maintaining compatibility with some C practices is the problem. They modified the type system
by msla 8y ago
C++'s refusal to maintain compatibility with C while scrupulously maintaining compatibility with some C practices is the problem.
They modified the type system so good, idiomatic C code won't compile, but they refuse to make writing unsafe code any safer in any meaningful way.
They added new syntax and reserved words, again breaking C compatibility, but they refuse to clean up C syntax even to the extent of removing the bizarre octal notation which makes 0100 do something deeply, deeply unexpected to anyone who doesn't know some obscure bits of lore.
Finally, they moved a bunch of real complexity to the compile phase, something C largely doesn't do, but they refuse to replace the file-based system they inherited from C with anything which would make C++ compiles even a little bit faster.
- htfy96 8y agoYour stance reminds me of this post: C++ Modules - a chance to clean up the language? https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_chance_to_clean_up_the_language/ https://www.reddit.com/r/cpp/comments/agcw7d/c_modules_a_cha... In short, C++ is a company-driven language instead of a community-driven one like Python and Rust. Some C practices are maintained because voters from the committee agree that these practices are necessary (for their code) and it's impossible to make a completely backward-incompatible change when they have >1M LOC code base.
- glouwbug 8y agoHow many 40 year old projects have we maintained that has broken _some_ backwards compatibility? C++ is a triumph in engineering rivalled by something like a megacity transportation system - it's massive, some of it is dark and scary, but it works really really well. The C++ team is up against huge corporations that actively lobby for and against any of their changes - and to top it all, they do it for free. Some obscure C feature is bound it get trampled on.
- steveklabnik 8y agoAll of them, really. Both C and C++ have made technically breaking changes. This isn’t to denegrate them, of course! It’s that the reality is that “no breakage” is literally impossible. It’s a spectrum, and about the experience.
- sli 8y ago> This isn’t to denegrate them, of course! I totally understand why you included this, but it's a shame that you felt it to be necessary. Refusing to make any breaking changes is how we end up with... well, PHP. There's nothing inherently wrong with breaking change. Too much of it can annoy developers, sure. And sometimes it has to hurt a little bit so progress can be made (see Python). But doing little to no breaking changes ever will eventually cause problems and/or headaches. That said, I wonder how many people moved to (for example) Rust simply because C++ moves slowly. Probably not that many, but surely it's nonzero.
- deleted 8y ago[deleted]
- kazinator 8y ago"No breakage" is possible in a Lisp dialect. With each rev of the dialect, put all new functions and variables into a new namespace like "std2019:...". Old code that doesn't know about new features doesn't run into them at all. Keep the old namespaces untouched: old code finds everything it expects. There is no bullshit like reserved keywords: all symbols are namespaced in packages. New syntax is just macros named by symbols. The only kind of breakage left is system requirements (new tools don't target old hardware well due to larger footprints; new dev environments don't run on old dev hardware; implementations drop support for unpopular platforms).
- coldtea 8y agoThat's only if you make superficial changes, and is already possible in non-Lisp languages. What about changing core semantics though?
- titzer 8y ago> C++ is a triumph in engineering I guffawed and then threw up in my mouth a little bit at this. C++ is riddled with dozens of horrible design flaws and kludges that make me think your definition of engineering is just plain wonky. Build time is one. Because of an inherent O(n^2) build system complexity, many large C++ codebases require massive, massive compile farms to achieve even reasonable turnaround times. They produce huge build artifacts that take practically forever to link and are still only barely debuggable. E.g. a recent audit of the V8 build time revealed that it compiles at an effective overall throughput of 186 lines of code per second. How do we deal with that? Distributed build system and 50+ core workstations. This is a travesty of engineering.
- einpoklum 8y agoThe feat of engineering is that these problems are gradually being _solved_ or worked around while maintaining backwards compatibility. For example, C++20 will have modules, which means you won't need to include everything again and again in each translation unit.
- psyclobe 8y agoAnd still... there are many reasons why you'd chose this language over others. They're probably doing _something_ right.
- msla 8y agoI think there's an underlying concept here. C is three things: 1. A mid-level language, by which I mean a language where you do all of the mechanics but you abstract most of the machine-specific details. Memory management is manual, but you don't know or care about how malloc() works behind the scenes, and you can't even ask. You get integers with defined semantics up to things like overflow/wraparound, but you don't know or care if they're implemented in terms of multiple machine words or even if there's such a thing as a carry flag. It's midway between a macro assembler and, say, Python, which does nontrivial magic behind the scenes. 2. An unsafe language, with nontrivial undefined behavior (the overflow/wraparound stuff I mentioned above) with no guide rails like the ones Java provides, where if you overflow the language specifies an error will occur. In C, very little checking code of that type is emitted or specified. 3. A systems programming language, where programmers do unsafe things, like writing values to DMA registers, things the language can't abstract away because... well... you have to write an OS kernel in something, after all. This is unsafe by design, as opposed to the above, where things are unsafe because of a safety/speed trade-off. Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. That's just an uncomfortable position for a language to be in. My point is, it could move Rust-ward and high-level-ward if it ditched some C-isms from the language... but you gave a good explanation of why it won't.
- pjmlp 8y ago> Rust proponents want to separate 2 from 1 and 3, and make a language where you can do things by hand and do unsafe things on purpose, but the language has more guide rails to prevent you from doing unsafe crap by accident. The first systems programming language to introduce this concept was ESPOL , created in 1961, already with the notion of unsafe code blocks. Even better, according to surviving manuals, binaries with unsafe blocks were tainted and required enabling execution by the admin user.
- danra 8y ago> C++ apparently wants to separate 1 from 2 and 3, to move more high-level and get more "language magic" (templates, iteration stuff... ) without making the language any safer in any respect. How so? Take std::unique_ptr for example, which exists since C++11. It facilitates using the language in a safer manner, and at a higher level of abstraction (you no longer have to manually malloc and free/new and delete - you just have the concept of scoped ownership), while at the same time not adding any “behind the scenes” magic (e.g. garbage collection) so as not to leave room for any high-level language to be more performant than it is - that’s the real motto of C++, to my understanding.
- gumby 8y ago> n short, C++ is a company-driven language instead of a community-driven one like Python and Rust. Some C practices are maintained because voters from the committee agree that these practices are necessary (for their code) and it's impossible to make a completely backward-incompatible change when they have >1M LOC code base. Well the community has more than 1 MLoC of code and is quite reluctant to break compatibility: look at how hard it has been to get Python to really migrate from v2 to v3. If anything c++ is more willing to make breaking changes (e.g. abandoning the terrible auto_ptr) because of the better tooling (willingness of compiler vendors to put in multi-standard support and appropriate warning flags).
- misnome 8y agoWhat made this incredibly clear to me was when await/yield was renamed co_await and co_yield because some extreme minority of companies (farming? from some statement I read somewhere 'yield' was the problem) would have to change variable names. It's like it gets a chance to be cleaner, but is then quickly hammered back into ugly syntax that reminds you that you are writing C++. Almost any actual potential leaps in improvement get watered down and neutered way before they have a chance to get near the language.
- evanpw 8y ago> farming? from some statement I read somewhere 'yield' was the problem bond yields in finance
- Something1234 8y agoWhat does 0100 actually do? Is it not supposed to be 64_{10}?
- steveklabnik 8y agoIt does make a value of 64 decimal. This is really surprising to a lot of people. It's really nice when you're dealing with unix permissions, and a potential footgun elsewhere.
- dnautics 8y agoA potentially better syntax would be 0o100, e.g.
- twic 8y ago> good, idiomatic C code Well which is it?
- kazinator 8y ago> They modified the type system so good, idiomatic C code won't compile. As someone with 30 years of C experience, maintaining one a 60,000 LOC code base that compiles as C and C++, I don't agree, not even slightly. Each one of the things diagnosed in C++ but not in C is a good idea. > bizarre octal notation which makes 0100 That would be a serious incompatibility. POSIX code like chmod(file, 0644) stops working. Under no circumstances would it be acceptable to just treat 0644 like 644; it would have to be diagnosed. Octal notation is so needed here, that if it were removed, programmers would resort to macros like OCT(6,4,4). What's strange in C is octal character constants, which must be exactly one, two or three octal digits. So \0000 is \000 (same as \0) followed by the literal character 0. There is no leading zero; there are only octal constants: \123 is octal, not a hundred twenty-three.
- steveklabnik 8y agoRust uses 0o for octal literals, so that you can still have them, but you don't run into the footguns with just a leading 0. It adds a nice symmetry with 0x and 0b (for hex and binary, respectively.)