u/GregCpp

The only times I've used virtual inheritance in my career was answering interview questions about virtual inheritance.

I know that Jason was reddit nerd-sniping when he mentioned warnings-as-errors.

Nonetheless, I think the only question is *when* you should turn on warnings-as-errors. For us, certainly, on for development and CI builds. However, a lot of the C++ community is developing software for internal use only, or for a very controlled environment, and that colors a lot of the conventional wisdom.

We develop C++ code that we ship as source that goes into various Linux distros, among other places. The distros (and other source users) get to choose the compiler and version (within reason, of course). There's no way any reasonable human (or AI, I'm guessing) can write non-trivial lines of C++ that will compile without warnings on any future compiler than you have not seen yet. So, when we ship our source code, the cmakery defaults to warnings-as-warnings.

Think about this: the best advertisement ever for Traveller was Free Trader Beowulf's mayday.

You misspelled "fopen".

The headline makes this sound much worse than it is. A couple dozen lines of diff for a project that must be, what, 1 million? certainly hundreds of thousands of lines of code doesn't seem so bad to me.

Dunno if they'd be willing, but a conference keynote from the EDG folks about their history with C++, language design, implementation choices, lessons learned, etc. would be something I'd be very interested in hearing.

It must be a ton of work, and while conducting the interviews seems fun, I bet there's 10 hours of non-fun administrative work to do for every hour of interviewing. This seems like a heavy ask for what must be a volunteer gig at the end of the day.

I'd like to thank Timur and Phil, and Jason and Rob before them for hundreds of hours of great content.

I'm curious if anyone has a recommendation for a good C++ podcast. I believe this leaves us with no major active C++ centric podcasts, but I'd be happy to be shown otherwise.

Can you comment about the level of effort to get things this far?

FWIW, I read somewhere that the cppcon acceptance rate is something like 30%.

But I still agree with not piling on additional work onto speakers. As a listener, I'd prefer that any additional time a speaker could invest be spent on polishing the talk, not generating additional artifacts.

Did you present the 2024 talk on making exceptions smaller? If so, that was a fantastic talk, and thank you very much for it. Very inspiring.

I like the "zoom" idea. For me, as a listener of talks, I'm not trying to cut & paste slideware into my code, so i don't care so much if it is perfect, meets any particular coding standard, etc. What I do want is to be able to focus on the point the speaker is trying to make about the code.

Is this chart saying that that average Uber/Lyft trip is less than 2 km? Can that be right? I get that there are lots of short trips, but even a handful of long trips (e.g. to airport) ought to greatly extend the average distance.

I'm sure the video releases will be staggered again. Conventional wisdom is that staggering the releases increases viewership on YouTube.

We ship source code, and do not have complete control over the compilers used. We certainly can't mandate bleeding edge compilers.

I assume that a modularization of existing code would break source code users with older compilers, though, and least without some form of ifdef'ery or conditional compilation.

Feel like it's time for a hardening/safety meta-knob. In the same way that `-Wall` is a curated set of warnings that an expert has decided is a good default, containing elements that can be individually enabled or disabled, maybe we need a `-fhardening-default-options`

Interest from attendees? Or from implementers? Personally, though committee work is enlightening, new features in the standards are often years and years away from being available to me. Newly implemented features in the compilers, though, are much closer to being used in production.

It is unfortunate that this kind of talk isn't presented annually at cppcon. cppcon has lots of vc++ content every year, but little directly from the other two big c++ implementers. What would it take to make that happen?

I can't seem to be able to use the C++ 17 parallel algorithms, for two reasons:

1.) As far as I know, there's no libc++ implementation.

2.) There's no standard way to constrain the parallelism to some fixed upper bound.

I'm curious if the parallel range algorithms will help at all with these?

This is a post about compiling postgres, which is written in C, not C++.

As postgres is not written in C++, I would humbly suggest this post is off topic for this sub.

The problem with this is that sometimes one implementation is considerably worse than others

I'm curious if you have a good example of this (other than just missing implementations)? VC++'s `std::deque` comes to mind, which is stuck with small block size due to ABI issues.

I would boldly assert though, that the most overlooked part of the original Stepanov STL is the performance guarantees written into the standard. Furthermore, it should be a bug in the standard if any given algorithm could be implemented in O(n) or O(n^2) in a compliant manner.

For example, I think it was a bug in the standard that std::string could be implemented either with CoW or SSO. This could cause huge performance regressions when switching from one compiler to another.

I would humbly suggest that before boost support modules, the boost community should come to a consensus on what the goal of the boost project is.

Before C++11, the role of boost was clear -- to be a stepping stone to standardization for libraries. At the time, it provided a set of libraries that was more formalized, reviewed and trustworthy than the huge, undifferentiated code archives that other languages have, like PyPi or npm. Still, it was more agile and faster than the ISO standard. It served a very useful goal of getting a lot of real-world experience with library design, implementation and usage before going into the standard.

Today, it is not so clear. Boost just added charconv, which is backward-looking: it backports support for features that have already been standardized and implemented in newer compilers for older systems. Noble work, to be sure , but not the original goal of boost. If the major goal of boost is to support older compilers, working on modules seems misguided.

The newer big library additions to the standard (and proposed ones), like ranges, executors, senders/receivers, etc. have not gone through boost. I read somewhere that a library author felt that it was harder to get a library into boost than into the standard. Seems to me like these large libraries would benefit the most from someone module-izing them, and conversely, that work would probably improve the quality of the modules implementation and tooling.

While boost as an organization has recently decided to allow some code to drop support for C++ 98, the minimal compiler needed for each boost library is all over the map. This adds to the feel of the library as a large stew of unrelated parts, and not a coherent whole. Would we add module support to a boost library that still can compile on C++ 98? If some boost libraries are available as modules and others aren't, doesn't that add to the sense that boost is not a coherent whole?