Goals and Priorities for C++
open-std.org
open-std.org
The reason C++ is the federal tax code of programming languages is that it is the accumulation of decades of ideas that seemed good at the time--some even were--where each better way to program ended up as the lifeblood of some special interest group that can never be removed, only piled on top of.
By subsetting C++, you can customize it into almost anything you want with just a few exceptions. You can't meaningfully simplify it in a backwards compatible way without breaking most subsets.
So these people are saying it should be simplified in a non-BC way, the only real way to do it, that preserves their own favored subset.
That's what most of us call a new programming language. Trying to turn C++ into !C++ guarantees they'll be fighting over this for years. With the resources Google has, I don't understand why they don't just throw off all C++-based constraints and use those years to create exactly what they need. With half the PL PhDs on the planet in their employ, you'd think somebody would be available. (Maybe even enough for multiple, parallel teams req'd to share ideas with each other.) It would take a few years to mature enough to rely on, but they'd be spending those years in the C++ cmte debates anyway. A new language called "non-BC C++" will need new tools, new libs, etc., anyway, and they'll have the current C++ to keep using until their alternative is ready.
Why not just create that simple, easy, customized-for-server apps language from scratch instead of making it by breaking C++?
It's expensive and inefficient to go it alone. It makes it harder to hire and harder to both benefit from and contribute back to the open source community. So they make their pitch and see if anyone else wants to get on board and only if that doesn't pan out will they try to go it alone. The price of going it alone might actually be higher then the benefit.
> Support maintaining and evolving software written in C++ for decades
...
> This requirement should not imply compatibility, but instead some (likely tool-assisted) migratability.
I think the idea is you can gradually deprecate outdated features if there's a way of automatically refactoring them out.
So you might still be able to compile old code, you might just need to run it through a bunch of migration scripts first.
Incidentally, golang did not end up replacing C++ or Java in the slightest, especially at Google. It is in the same space as python.
I am not saying that is the case here one way or the other, though.
Having a PhD means you studied for years to push boundaries, nothing more, nothing less. Lets not forget that the bosses usually decides exactly what should be done with sprints and standup, especially in teams that are not research focused.
This was in contrast to "developers" who wrote application code in numerous languages COBOL, Pascal, Fortran, BASIC, etc. And they in general, did not manage the underlying system.
Over the years I think those lines have blurred and the roles are all smashed together sometimes called devops or other terms.
They did that already with Go (one can argue that Go has very different priorities than C++, but Go matches "simple, easy, customized-for-server apps" perfectly).
I recently worked on a large system that had three virtual baseclasses. But trying to do it any other way would have involved a lot of painful head stands.
I designed BFD using a vtable implemented manually in C. It was quite painful though there was no other choice. I’m glad I don’t have to deal with that any more.
I wrote a “serializer/deserializer” package that did t actually save anything but could represent the data and swizzle it so the in-memory structures could use raw pointers. This could be validated as correct in CI.
Then in a separate I/O library I wrote a module that could generate JSON and store it in a file, using specializations of these virtual baseclasses. When the underlying library changed representation client code didn’t have to written.
My JSON thing was too slow so someone wrote one that backed into a SQL database. A lot faster, though versioning went out the window. Anyway someone could write a fast binary format if that matters and they should all continue to work.
* I mostly gave up on MI in the mid 80s when it was clear it made encapsulation harder to understand (and this was in a language with explicit method combinators too). However I still find mixin classes quite valuable, though again not in widespread use.
Also this means changes to the underlying representation don’t always require changes to the dependent classes, which I suppose you could consider an ABI change.
Maybe an easier way to characterize it is to consider the virtual classes a way to implement plug ins.
Many people consider virtual inheritance a complexity of the language. Why is it possible for a class to inherit from a base class multiple times through multiple paths (the standard case) or to have the compiler coalesce those paths so that the child class only inherits once from the parent/grandparent? The thing is, once you have multiple inheritance, somebody is going to try to inherit from the same base class multiple times. The language can either support it or declare it an error. It’s not clear to me why it’s wrong to for the language to allow it, even though everywhere I’ve worked with a C++ coding standard has said “if your design requires virtual inheritance, discuss your design with other experienced programmers to see if that can be changed.”
It's a no-win choice, though I agree C++ chose the wrong path: trying as much as possible to avoid adding new keywords. It leads to the problem you describe, as well as some confusion in this very thread (which could be my fault, but honestly I don't know -- that's the problem!).
The committee seems to have moved away from this over the years which has lead to complaints of too many keywords and identifiers. Which is why I call it no win.
The function virtual specifier in the base clause is reasonable: if you store something into parent_class.instannce_var and there are two copies of parent_class in your structure which one is stored to and is the choice consistent in all compilation units? This specifier guarantees that the answer is "yes". I don't know why it isn't the default though.
More generally, back in the day I used to use a bunch of different method combinators with flavors (later CLOS). Apart from the useful :before and :after, they generally lead to undebuggable code.
I do think it's a useful feature, except as I think most people finally agree, MI is more often than not a cause for confusion.
It's funny that of all the different method combinators (another source of confusion) only that one was chosen.
BTW I don't think a unique_ptr is needed in the case I described.
For example in some piece of graph-based code I’ve been working on recently, all types returned through public interfaces are pure abstract interfaces. There are different reasons for this, one of them being difficulty to automatically wrap the implementation classes themselves to Python and Java with SWIG, because they use CRTP and other template constructs that are fundamentally incompatible with automatic script interface generation. There is a base interface class INode with an implementation class template Node<T>, but there are also derived interface classes that add additional interfaces to INode, such as ICompositeNode for example. Without virtual base classes it is impossible to have an implementation class CompositeNode<T> that derives from both ICompositeNode (for the interface) and Node<T> (for the implementation), because it is ambiguous. Virtual inheritance solves this.
I never considered this a very special or difficult use case, it seems pretty much any kind of component-bases programming using abstract interface classes would require this sooner or later?
No. Virtual base classes come up in multiple inheritance.
Consider you have a class Circle. It derives from both Shape and Savable. But Shape and Savable both derive from a parent base class Base. Let's say that Base has some member function, print. Also assume that neither Circle, Shape or Savable have an implementation of print. So when you have a Circle object, and you call print, does it go to Shape::print or Savable::print? If Base is a normal (non-virtual) base class, it's ambiguous. The compiler can't resolve it, as the Circle object literally has two Base instances inside of it: one from Shape and one from Drawable. The inheritance hierarchy has two roots, both of which are an instance of Base.
But if Base is a virtual base class, then Circle will only have one instance of Base. The inheritance hierarchy has only one root, which is Base.
This is generally called "the diamond problem": https://stackoverflow.com/questions/2659116/how-does-virtual...
I get that it's a bit of an inconvenient workaround, but it doesn't seem impossible to handle? (At least as far as I've thought it through. I might be missing something though.)
Maybe I'm not even fully grasping the problem myself, but in any case virtual inheritance on the interface classes resolved it ;-S
Confused, isn't that already the case normally? Base classes are already destroyed after derived classes, and owning pointers die before their targets.
It's super common to implement mix-ins, which is as based on templates as it's possible to be, with multiple inheritance, e.g.
struct featureA { int x; };
struct featureB { const char* foo{}; void print(); };
and then
template<typename... Args>
struct mixin: Args... {
template<typename... CtorArgs>
mixin(CtorArgs... args)
: Args{args}...
{ }
};
using foobar = mixin<featureA, featureB>;
void f() { foobar{123, "foo"}.print(); }Curiously recurring, even! [0]
Although what you're showing seems to be a variation on the curiously recurring template pattern, as the classes being mixed are listed 'symmetrically' without much regard for which will inherit from which. I found a blog post on 'mixin classes', which are like the CRTP but invert the inheritance relation. [1] What you've shown seems to be a third way.
[0] https://en.wikipedia.org/wiki/Curiously_recurring_template_p...
[1] https://www.fluentcpp.com/2017/12/12/mixin-classes-yang-crtp...
It is unfortunate that there is no explicit way to distinguish OOP is-a from code reuse, other than the presence of virtual functions in base classes, but in my 15 years of professional use of c++ I can't remember it ever being an issue.
And sometimes the same feature is one, sometimes the other. There is no shame in it. Language features are there to be used.
ABI stability? Backwards compatibility? Shipping binary code? The classic Unix compiler&linker model? Those are some of my favorite features of C++ over the competition. Just because GOOG chose to abandon them in their processes doesn't mean the rest of us should be forced to.
"This paper describes the goals and priorities which the authors believe make C++ an especially effective programming language for our use cases. That said, our experience, use cases, and needs are clearly not those of every user. We aren’t pushing to directly build consensus on these points. Rather, this is presented as a vehicle to advertise our needs from C++ as a high-performance systems language."
I would say they are quite transparent about that...
> I would say they are quite transparent about that...
I don't even see the word "Google" anywhere?
I read it as as "We understand that this isn't what everyone wants the committee to adopt, but this is what we want the committee to adopt."
Well, nvidia does distribute software, but its users are happy to recompile it seems.
In lieu of C++ we hear a lot about Rust these days, with focus on performance and reliability. But I suspect the rate of adoption is such because of the productivity aspect (it seems to me the language itself has non-trivial concepts and its fair share of syntax cruft from what I saw): having integrated tooling, dependency management, all being a de facto standard for the language. Same for Go, it's just very easy to start a project, add a library, compile a project... everything is included.
I guess it's probably not a priority for experienced C++ programmers as they are probably used to it, but I'm sure more people could build stuff in C++ without those barriers.
I actually enjoy working in modern C++ much more than I did in Java, which I did professionally for almost 10 years before this.
I like the idea of Rust, and followed it since the earliest days when Graydon proposed it. I like the syntax and the tooling. But every time I begin a project in it, the cognitive overhead of the memory safety features just throws me a loop. I have no doubt if I were to dig into a large and established code base using it it would click within a few days, but starting on my own... I lose focus quickly.
I do like Zig, though. It is a very nice C++ alternative.
What do you like about working in C++ more than Java?
Generally, I hear from people working in C++ that it's the only tool for their job, and only use it because no other tool measures up (in a despairing tone). If you don't mind my asking, what do you use it for?
I mean, like, you can interface with TensorFlow via Python but the big-kid parts of the implementation are in C++ / CUDA.
I feel great joy coding C++, more than any other language. C++ is built to be used. Every part of it was put in to solve real problems, and they do. I can write thousands of lines of code, and when it finally builds, the program works first time.
This makes things a lot easier on both developers and end users but does not in theory scale well with increasing adoption (end users have a bunch of huge binaries bundling the same subset of libraries which all get hit with zero-days at the same time but are updated piecemeal across the apps bundling them). The tooling and package management stories are a similar case - they haven't fragmented yet, but as adoption increases you start having to deal with shit like packages from obscure hardware vendors and commercial language tooling - including compilers, providing functionality either absent from or superior to what's available in in the de-facto-standard project templates. Examples from my experience would be things like the Intel C++ toolchain, MPI compiler wrappers on supercomputers, and vendor-provided toolchains targeting alternative devices like CUDA.
Perhaps their community will deal with these challenges in a super-elegant way, I'm not ruling it out. But I'll believe it when I see it.
It's irrelevant on Mac, Windows, Android, and iOS, where the operating system is a monolith that applications depend on. Technically, it might be made up of multiple libraries, but the OS is almost guaranteed to be present in full, and it's the only thing that can be guaranteed to be present, and it might use integration systems that applications cannot or rarely use (VDSO, NTDLL, syscalls obviously, but also stuff like the System calling convention).
Or you might just use IPC for all components, like Plan 9.
It's also irrelevant if you're using a bare metal machine with no filesystem, a system with a weird linking paradigm like webassembly, or if your app basically owns the entire computer.
I also think a large amount of C++ is tied to a native platform, packaging system (or source repository), and possibly a native build system. That means the tooling is fragmented, though not universally poor. It's just that the tooling is not always available.
"Byte sizes other than 8-bits, or non-power-of-two word sizes
Source code encodings other than UTF-8
Big- or mixed-endian (at least for computation; accessing encoded data remains useful)
Non-2’s-complement integer formats (we supported C++20 dropping support for this)
Non-IEEE 754 floating point format as default floating point types
Source code in file systems that don’t support file extensions or nested directories"
What are you going to do if you declare that implementations must be little endian? (It seems that's where that particular goal is headed.)
Will this be well-defined behavior?
// Writing a 1 to u64 requires that u32 will read 1,
// because everything is little endian!
union u {
uint32_t u32;
uint64_t u64;
}
What's the good in it, other than that: whereas a big endian machine can still have a C++ compiler, that compiler just can't be called conforming any more?
Nothing changes other than classification. Nonportable code depending on little endian continues not to work on that machine, though now that code might be blessed as "strictly conforming".
Someone wanting code to work on that machine will make it work the same way as before, and quite possibly keep their code strictly conforming. Like before, it will be possible to express code without endian dependencies, and that will work on those "broken" implementations that support big endian systems.
What happened to the idea that systems require programming languages, not the other way around?
Compilers can be made more simple, saving the time of expert compiler authors to work on improving their compilers in other ways. This lines up with some of the other listed goals,
> Syntax should parse with bounded, small look-ahead.
> No semantic or contextual information used when parsing.
i.e. drop features from the language that significantly complicate the compiler.
> What happened to the idea that systems require programming languages, not the other way around?
Hardware got very standardized and software got very expensive.
> Compilers can be made more simple
In relation to this issue, I do not see how. Today, someone can make a C++ compiler for a little endian system, or a retargettable one only for a group of little-endian systems, without any additional difficulty coming from the fact that C++ can also be implemented on big endian. Quite literally, that compiler developer need exert zero brain cycles even thinking about big endian.
C++ doesn't require implementors to have anything to do with big-endian.
A language standard that doesn't talk about endianness at all is smaller and simpler than one which specifies it, because that represents extra detail which generates extra requirements that require more sentences.
For C++ to "support" big-endian, all it has to do is not mention it: not give any requirements about it. That's not something that then needs to be dropped at any time.
A compiler project can drop big-endian; that's obviously different. ISO C++ isn't a compiler project, though.
The compilers that the authors care about are a small number of open source compilers that have very comprehensive support, and consequentially are very complex, probably just gcc and clang. With regard to this perspective, something like “lines of text in the standard” isn’t a useful metric. Few people are going to read the entire standard, so there’s little harm in making it longer, but many people are going to work on large compiler projects, and many, many people are going to use the compilers these projects produce. The standard can be made more complex in ways that reduce the required complexity of comprehensive optimizing compilers.
> The compilers that the authors care about are a small number of open source compilers
If so, that is an unacceptable position for people on an ISO committee for that programming language.
There is no possibility that any of the authors are working under this confusion. The language specification heavily influences compiler projects because compiler authors tend to target standards. The argument that authors can just write their own non-standard compiler doesn't generally carry much water. Moreover it is extremely common for the standard to be written specifically to assist compiler authors. Consider the numerous instances of undefined or implementation defined behavior.
> If so, that is an unacceptable position for people on an ISO committee for that programming language.
The purpose of a standards committee is to standardize, not to standardize anything in particular. If the committee can be persuaded that these use cases are important to a large body of C++ programmers and that the alternative may be a split in the community, the committee may be inclined to adopt some of these topics as areas for improvement.
Oh no, no. There is something particular to standardize: namely something that is already out there and working.
Secondly, if there are multiple such somethings that are out there and working, but are not compatible, then this is where the standard is really in its own element, to help iron out that situation and improve interoperability.
In this second area, the standard may engage in a bit of invention. Pure, unprompted invention is something ISO standards should eschew.
No, it’s illegal in C++. Use std::bit_cast.
> 2.1. Stable language and library ABI
> 2.2. Backwards or forwards compatibility
> 2.3. Legacy compiled libraries without source code or ability to rebuild
For fucks sake, C has been stable for decades but somehow C++ just can't manage?
This is such an obnoxious attitude. At least let us automatically generate a set of C-style functions that take an opaque void* representing a C++ class instance if you can't be bothered to do the work.
The authors are (mostly) at Google. They build their binaries from scratch from a monolithic source repo with a reproducible build system every time they want to deploy software. Their use case is unusual and they recognize that. The document lays out their justification for what they prioritize and why, for example, they would happily sacrifice backwards compatibility or nonstandard architecture support for more performance.
Even Arduino like boards use C++ nowadays.
Unity and Godot have their graphics engine written in C++.
Rust, Swift are dependent on LLVM, written in C++.
Go, it isn't really in the same league of programmer expressiveness.
The Windows kernel is mostly written in C, too. iOS uses Objective C.
Modern C++ isn't bad, but robust classes require an enormous effort together with tests suites that approach the size of test suites required for an untyped Python module.
In practice segfaults are as prevalent in C++ as they are in C. Type errors by implicit conversions are more frequent in C++ than they are in C. Full testing of all conversion rules requires a superhuman effort.
So I think well written C is often safer than well written C++, because one does not have to deal with the case explosions introduced by classes and their implicit rules.
The often quoted safer strings in C++ are just a very tiny part of the equation.
If I had my way, we'd all be writing Ada or Standard ML, but no one listens.
30 years ago no one though commercial UNIXes would be wiped out by a "toy" UNIX clone project.
Windows kernel has been moving into C compiled as C++ since Vista introduced support for kernel mode C++.
iOS uses C++ for its drivers, Metal shaders and compiler toolchain. That Objective-C implementation relies on C++.
Yes, the Trojan horse of C's copy-paste compatibility is also its Achilles heel of security, however in contrast with C's attitude regarding security, C++ provides the library types to actually implement secure code, if one bothers to make use of them.
If I had my way, C would have bounds checking enabled by default, strong typed enums, proper arrays and strings, but no one at WG14 listens.
Then we have Pyston, and the ill fated unladen-swallow.
Still used lots and lots of places
Concurrency and parallelism without debugging hell is huge.
There is plenty of libraries in C++ that haves you concurrency and parallelism without debugging hell.
Hell in concurrent code comes when you have shared state, and that is valid for both Go and C++. Using shared Golang Map in multi-threaded code is a very good example of deathtrap, even if it's in Go.
While I have your attention, I see your comments here in C++ threads quite often. You seem to like the language and at the same time you have some experience with simpler languages like Oberon. My experience with C++ has been that people happily go on to create giant inheritance hierarchies, with no restraint for multiple inheritance to the point that it's so unmanagable that nobody knows where things go and what actually happens. With all that inheritance, they lose track that the same thing has actually been copied tens of times between different classes and now these tens of classes have code that is basically copy-pasted and who knows what benefit anyone has from all this inheritance. Google engineers are one of the offenders when it comes to overuse of inheritance. Then, modern C++ allegedly fixes some warts, but IME it introduces more of them. E.g. the initialization fiasco (I honestly can't say with 100% confidence what braces do when you initialize std::vector). Then there is this thing that when you create a lambda like so:
[&] { ... }
std::function<void()> create_lambda(args...) {
return [&] { ... };
}
Don't you experience the same fatigue as I do?
EDIT: Oh, I just remembered another thing: at a previous job we discovered that MinGW's implementation of std::random_device just returned 0 every time. It is major facepalm for MinGW, but also for the C++ standard for making this behaviour allowed (yes, it's actually compliant with the standard). And even after it was fixed, there are still systematic issues with this whole randomness API. E.g. you can't actually seed it properly[1].
[1]: https://codingnest.com/generating-random-numbers-using-c-sta...
Fun fact, due to continuous ranting regarding C++ support from game developers, not only did Google announce at GDC 2020 that they are upping their game regarding C++ tooling on Studio, they will also provide Android plugins for Visual Studio.
When people discuss Oberon, they tend to focus on Oberon (1992) or the minimalist approach that Niklaus Wirth has pursued later with Oberon-07.
When I talk about Oberon, I think beyond my early experiences with Native Oberon, and also include Oberon-2, Component Pascal, Zonnon and Active Oberon into the mix. The Oberon language linage, not all of them done directly by Wirth.
In that sense, for me Oberon is what EHTZ nowadays uses as Oberon, namely Active Oberon.
http://cas.inf.ethz.ch/projects/a2/repository/raw/trunk/Lang...
You will find out that minimalist Oberon is long gone and the language in a certain sense compares to C#, D in complexity, with support for generics, untraced references, exceptions, linkage models, inline Assembly.
Because that is the problem with minimalist languages, library boilerplate just grows to emulate what should have been in the language to start with. In Oberon's case, Active Oberon is the result of many years of research and student thesis doing OS implementations in Oberon, while noticing that stuff like generics, untraced references, inline Assembly are quite useful.
As for C++, while I still enjoy using it, nowadays it is mostly a tool for OS integration libraries and GPU shaders (HLSL/Metal/CUDA), I rather write the main code in .NET languages, Java or some other managed language.
Generics is something I can't live without, to be honest. But I don't like C++'s implementation of generics. The error messages they generate and the whole SFINAE business make for a horrible programmer experience. Rust has the best implementation that I know of currently. Inline assembly sure is useful.
Anyway, thanks for the extensive answer. I think I understand your point of view better now.
I feel like this is consistent with the "pay for what you use" design. Why capture all variables in scope by copies when you can just capture them all as references (which might go out of scope)? If you truly need to capture other stuff, you can do so using more syntax. If "[&]" did what you describe then "wtf, why is it saying I have a deleted copy constructor for some value I'm not using" or "wtf, why is my code so slow because of unnecessary copies of large objects" would be all sorts of fun.
it doesn't copy the stack pointer, but it enumerates all variables you use and captures a reference to it (I think the &, as used in address-of and references kind of gives it away). [=] {} unsurprisingly captures by value.
Some compilers do warn when you return lambdas capturing local vars by reference, but it is not super reliable.
#include <functional>
#include <iostream>
std::function<void()> create_lambda(const int& x, const int& y) {
return [&] {
std::cout << "x: " << x << "\n";
std::cout << "y: " << y << "\n";
};
}
int main() {
int x = 5;
int y = 7;
const auto f = create_lambda(x, y);
f();
}
this has been 'fixed' with jthread. FWIW I think it is a mistake, blocking in a destructor is can easily lead to deadlocks (I have first hand experience, it is not just a theoretical issue). Detaching is not an option either.
Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.
All major C compilers are written in C++ nowadays.
Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure.
Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process.
On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance.
One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
You say this as if it is the fault of C. I see it the other way around -- Microsoft's refusal to implement C11 is singlehandedly contributing to the decline of C, because they've leveraged their large OS market share to make it impossible to use an update of the language for cross-platform development. They are killing it on purpose, and it's infuriating.
Anyone that wants a C like language with better security has decided that the only path forward is to either ditch it, or impose hardware memory tagging (which Google is imposing on as of Android 11).
Microsoft still supports C in its Checked C variant and just like Google, Oracle and Apple on their platforms, its hardware hardened Azure Sphere Pluton runtime.
C was already on decline in the late 90's, all major desktop and mobile OSes were being written in C++, BeOS, Symbian, Windows with OWL/VCL/MFC, OS/2 with CSet++, Mac OS with MPW/PowerPlant, game developers were moving into C++ with Watcom C++ and PSOne devkit, it was the rise of FOSS UNIX clones with the FSF manifesto to use C as much as possible that changed the wind, thankfully that course has been finally overturned.
The decline of C in an always connected computing world is done by WG14's lack of action.
Embedded C++, and the kernel is pure C.
And as of Driver Kit introduction, 100% full C++ is now an option.
In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left.
Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.
From what cursory knowledge I have, Rust maintains both a bare bones standard library suitable for embedded work as well as a more fully featured standard library that is built on top of that minimal library.
What features would keep Rust from becoming a new C other than possibly some issues with ABI stability that from my understanding people are working to resolve?
Like you said, it's not even that far fetched.
It has has one on IBM i and z/OS, as part of the language environments.
I guess when one is bored might try to re-implement ATL, WTL or UWP projections with C macros.
I would argue that C++ needs to increase the pace of change if it wants to remain relevant. Rust, Go, Swift and Kotlin are though competition, while C++20 is still lacking in agility, safety and modularity.
C++ build systems are already worse than all the languages you mentioned in part because there's no module support.
I also disagree that it would hurt performance. If the logic contained in "-D_GLIBCXX_USE_CXX11_ABI=0" was formalized to allow backwards compatibility, libraries would snap together more easily while still preserving inlining better than C ABI exports are able to.
The point of the document is to lay out the goals and priorities of the authors, not to argue that they are universally applicable. The authors compile everything from scratch with the same version of the compiler, down to the OS kernel.
What is the point of fighting to stay relevant by going after use cases that are being served by these other languages? Is it just to win and have more "mind share"? Is it to make the biggest tribe? That seems like a social goal, not a technical one.
C has no strings.
The optimization was considered vital enough for a rare break to actually happen but there are multiple such clear wins that cannot be implemented because of ABI stability. Sometimes it's a major pain to have to keep piling the cruft on.
As a community, we absolutely should reject this proposal and insist that the standards committee continue to support compatibility. Repeating Python3's mistake in C++ would be a nightmare!
the -std=c++03 mode of the compiler is pretty stable... but not many people care about that anymore. If they cared google would be building their next kernel in C, not in C++
Some points: * There are still tons of 32 bit machines out there—old Windows machines chugging along, usually disconnected (thankfully), and you’d like to be able to use your _current_ codebase to target them.
* If C++ is to focus on performance, it needs much better tooling around UB, be a bit more permissive of old behavior that now triggers UB, with formal semantics, AND it needs to define semi-portable SIMD vector operations. Getting the utmost performance out of modern CPUs entails using vector operations.
* It also makes me sad to say goodbye to big endian.
Typo or sarcasm?
By default, everything is backward compatible, but to use new features you need to declare this compilation unit as being part of C++23 (or 26, 29). Then code that uses the new stuff also ignores the old and can have different rules. But it can still be combined with legacy code and libraries. You know at compile and linking time when crossing boundaries and can do the right thing. This actually combines nicely with modules since we already need a new build infrastructure to take advantage of modules.
CMake for instance makes this very easy with its set_properties() call.
* Of course there are caveats and corner cases. See eg. https://stackoverflow.com/questions/46746878/is-it-safe-to-l... But these seem like they could easily be avoided in real-world use-cases.
isn't that purely an implementation issue ? e.g. both Apple and NVidia have brought C++ to the GPU, one with Cuda and the other with Metal... that did not require any help from the committee.
In practice, Google is behind this statement. Nvidia is behind this statement. Two of the largest supercomputing facilities in the US are backing this. The document heavily implies that these are the goals for C++ based on their use cases. These are also organizations that have had a massive role getting the accelerator space to where it is today.
Sure, MLIR is technically a project underneath the LLVM foundation, but isn’t it mostly Google employees who were working on it. Lattner has moved on from there and is now setting his sights on RISC-V it seems.
As someone who likes modern C+ + and is interested in new, open hardware, I’m really happy RISC-V is being made a priority, along with bare metal compilation. But I’m also confused and here’s why.
I agree entirely that CUDA support for modern C++ is moving along nicely, especially since CUDA 11 supports C++17. However, a good chunk of these authors are Nvidia employees and now they’re implying their “use case” for C++ isn’t associated with accelerators?
I am a C++ and Python developer. I did C++ for 20 years then python for 9, then C++14/17 for 3. I really like the new C++ and think it could be made into a better language while still retaining the deterministic performance.
What we don't want is Python 2 to Python 3 situation. That might mean calling it a new language.
:(
Non-little-endian might be a bigger issue - it would rule out quite a few embedded CPUs.
In embedded, you're often talking directly to hardware chips. How you talk to those hardware chips absolutely depends on the endian-ness of the CPU... unless the chips all have 8-bit-only interfaces.
A specific open question is whether supporting 32-bit hardware and environments (including for example x32) is an important goal. While some communities, especially in the embedded space, currently rely on this, it comes at a significant cost and without significant advantage to other communities. We would like to attempt to address the needs of these communities within a 64-bit model to simplify things long-term, but this may prove impossible.
This is not just microcontrollers (hardly niche, but obviously different performance envelope), but also plenty of 32-bit Linux single-board computers (e.g. BeagleBoneBlack). Not to mention the earlier mention of endianess other than little.
on the other hand, rust does not support 32bit arm at tier1 either. https://forge.rust-lang.org/release/platform-support.html
golang so far still supports 32bit, but who knows for how long, after all it's Google who can do anything they want, plus golang is too fat for many embedded boards.
Thank goodness we will have C stick around for many decades in the long run, along with ash probably lua5.1 for scripting that is.
otherwise we need get rid of c++ for 32bit embedded fast.
I’m curious: Which divisive issues would have had obvious resolutions if there had been broad consensus on the C++ committee to adhere to these goals & priorities?
Edit: Actually, they specifically call out little-endianness as a priority.
These are smart, system-software-focused engineers, so there must be some interesting directions being blocked off by insistence that the standard be byte-order agnostic (and word-size agnostic, since they’re so keen on 64-bit)...
It was eye-opening when I read this blog post and learned that LLVM spends about 0.4% of all compilation time reading the bytes of the string "null-pointer-is-valid" over and over. Hot code paths can be pretty hot.
https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html
But the impression it gives me is that C++ is not fulfilling the expressed requirements, and it is not currently moving in the right direction.
I read it as a quite strong critic of the current state of the language...
But you don't need to go too far to find something you can argue has such a goal:
- RAII: it's easier to read and write a function when it's not full of resource deallocation code.
- Exceptions: It's simpler to understand code when you move the error handling away.
- algorithms: simpler to read and write than your for loop.
- ...
It's such a vague goal that you can argue it about anything from any language.
Very preliminary benchmark C++ Vs Rust on RISCV. C++ is just in its own league. Alone.
Having been at CppCon I can attest to the atmosphere of performance first in C++.
https://medium.com/@fwsgonzo/adventures-in-game-engine-progr...
The benchmarks are done here: https://github.com/fwsGonzo/script_bench
I am trying to reach out to someone who is really good at Rust to see if there's ways to balance the scales.
One of the things I am dealing with: https://gist.github.com/fwsGonzo/ff0b7f41c521eb0cc4212f3c42f...
> I am trying to reach out to someone who is really good at Rust to see if there's ways to balance the scales.
If you use reddit, posting to /r/rust will be super helpful. If you don't, users.rust-lang.org is a decent spot. If you tweet, I can retweet from the rust account.
Less charitably, it is saying, yes stable ABI is good but it is not our problem.
- Stealing C# attribute notation instead of having the ridiculous __stdcall sort of convention
- Making a real fucking keyword for pure virtual functions instead of = 0
- A real keyword for include guards
- Function pointer syntax sugar
I now realize I'm describing D but D went too far. I just want like three nice changes that still allow near unchanged compilation to C++.
If you want a modern language that compiles down to C (not C++), there's Vala. It even has some kind of async support now.
C++17 introduced the attributes in the form of [[attribute]], e.g. [[maybe_unused]], [[fallthrough]]. Clang also supports e.g. [[gnu::packed]] instead of __attribute__((packed)).
>- A real keyword for include guards
"#pragma once" is de facto supported everywhere. The general stance seems to have been to not bother with standardizing, as modules were a better solution anyway.
>- Function pointer syntax sugar
Aliasing function pointer seems mostly reasonable?
using my_function_pointer = double(*)(int a, int b);