static_assert(
    (static_cast<unsigned char>("💩"[0]) == 0xF0) &&
    (static_cast<unsigned char>("💩"[1]) == 0x9F) &&
    (static_cast<unsigned char>("💩"[2]) == 0x92) &&
    (static_cast<unsigned char>("💩"[3]) == 0xA9), "Source or compiler not UTF-8 compliant! Add flag /utf-8 for Visual Studio");

This actually detects whether the Visual Studio project has the proper UTF-8 flags set to compile it correctly.

^{I fully expect this post to be downvoted to hell.}

EDIT:

Bjarne forgive me, this is now the most upvoted /r/cpp post of all time... What have I done...

It's so annoying to see these sites pop up on literally 90% of google search results whenever it is c++ related(especially GeeksForGeeks). Their articles are mostly poorly written and often incorrect. Their code examples are full of memory leaks and undefined behaviors.
Edit: I posted this hoping that I could get a way to filter out these sites from the search results. This thread is so helpful to me😙

I recently realized something that's been annoying me for so long

How to add a library in JavaScript:

• Type npm install 'library' in a shell on your project's directory.

How to add a library in C#:

• Type dotnet add package 'library' in a shell on your project's directory.

How to add a library in Go:

• Type go get 'library_link' in a shell.

How to add a library in Rust (And this is so "C++ is compiled" isn't an excuse):

• Lookup the last version of the library.

• Type 'library' = 'library_version' on your project file.

• Restart your editor so the language server can get the symbols from the new library.

If you install cargo-edit you can alternatively just:

• Type cargo add 'library' in a shell on your project's directory. cargo-edit will do everything for you.

How to add a library in C++:

• Prepare two folders for header include files, and library binaries.

• Append flags to your compiler to recognize them accordingly.

• Investigate which way the library works, praying the documentation of that is actually good.

If the library is header-only:

• Add the header's required to your include path.

• You should probably moduralize the code or spend 30 minutes setting up precompiled headers to avoid adding a lot to your compile times.

• And also lower your warning level, because even if you put #pragmas around the headers editors probably wont recognize them.

Else, if the library distributes its binaries:

• Download the .lib or .a files from the last release and put them in your library folder.

• Tell the compiler to link your libraries.

• Put the downloaded header files in your include folder.

• If the library needs a .dll, download it and paste it in the folder of your compiled executable. Distribute it with your shipped application.

• If you want to keep your application as a single executable, or distribute less dependencies, or have no need for an installer, all perfectly valid reasons, library owners usually have a static version.

• If they don't have a static version, spend an afternoon fighting the linker figuring out how to build the library yourself.

• If you want the library to link against the static runtime, the step above is required as well.

• Make sure to select the correct runtime library, or face really weird linker errors.

If the library doesn't distribute its binaries:

• Clone the repository of the library and figure out how to build it yourself. There's usually a tutorial so it's not that complicated.

• Make sure to select the correct runtime library, or face really weird linker errors.

• Do this for every platform you want to distribute in.

If the library uses CMake ᵒʰ ᵍᵒᵈ ʷʰʸ:

• You can choose two options:

Use CMake too

• Abandon your project's build system and spend days learning an entirely new language that everyone complains about

• Spend a lot of time googling and figuring out the complicated "right" ways to do what's usually pretty simple

• Probably suffer from a loss in build time

Generate files for your compiler

• Install CMake GUI

• Learn how to use it and configure what you desire.

• Alternatively, learn yet another command line tool, or a tiny bit of CMake syntax to change what you want.

• Generate the files according to your platform and IDE.

• Build the library with a bloated IDE, or alternatively research how to build it with the much less known and documented command line tools.

• Make sure to select the correct runtime library, or face really weird linker errors.

If you run into linker errors when running your program (and you will):

• If it's an unresolved external symbol, most likely your library needs another dependency linked. Lookup the function's name, what library it belongs to, and link against that too.

• If the unresolved function belongs to the standard library, you messed up. Compile the library again with the runtime library your compiler wants.

• If it's something else, google the error code and spend 30 minutes staring at StackOverflow.

Just... why?

Am I missing something? Am I stupid and doing everything wrong? I really hope that's the case so I can get back to programming instead of fighting the linker. Every single time I see I need a library I'm like "Oh fuck..." to the point sometimes I just don't bother and decide to write things myself. Sorry about the rant. I'm kinda tired. Do you all have any similar experiences with this? Any tips to ease on the pain a bit? Thank you.

I MANAGE TO IMPORT RAYLIB!!!

I DONT CARE IF YOU THINK I AM AN BABY, THIS WAS THE BEST HIGH ON PROGRAMING OF THE YEAR

I decided to learn c++ because i want to fix an annoying bug in Godot, thats being an problem in my game, but man, i was humbled today, but i did it!

for some reason MSYS on windows have 5 editions, and i was using the wrong one :P

also, can some one explain why thats?

A very special video report from Prague.

C++20, the most impactful revision of C++ in a decade, is done! 🎉🎊🥳

At the ISO C++ Committee meeting in Prague, hosted by Avast, we completed the C++20 Committee Draft and voted to send the Draft International Standard (DIS) out for final approval and publication. Procedurally, it's possible that the DIS could be rejected, but due to our procedures and process, it's very unlikely to happen. This means that C++20 is complete, and in a few months the standard will be published.

During this meeting, we also adopted a plan for C++23, which includes prioritizing a modular standard library, library support for coroutines, executors, and networking.

A big thanks to everyone who made C++20 happen - the proposal authors, the minute takers, the implementers, and everyone else involved!

This was the largest C++ committee meeting ever - 252 people attended! Our generous host, Avast, did an amazing job hosting the meeting and also organized a lovely evening event for everyone attending.

This week, we made the following changes and additions to the C++20 draft:

• Improved the context-sensitive recognition of 'module' and 'import' to make it easier for non-compiler tools such as build systems to determine build dependencies.

• Added several new rangified algorithms.

• Added ranges::ssize.

• Refined the meaning of 'static' and 'inline' in module interfaces (P1779 and P1815).

• Resolved a lot of open core language and library issues and made many substantial improvements to specification.

The following notable features are in C++20:

• Modules.

• Coroutines.

• Concepts.

• Ranges.

• constexprification: constinit, consteval, std::is_constant_evaluated, constexpr allocation, constexpr std::vector, constexpr std::string, constexpr union, constexpr try and catch, constexpr dynamic_cast and typeid.

• std::format("For C++{}", 20).

• operator<=>.

• Feature test macros.

• std::span.

• Synchronized output.

• std::source_location.

• std::atomic_ref.

• std::atomic::wait, std::atomic::notify, std::latch, std::barrier, std::counting_semaphore, etc.

• std::jthread and std::stop_*.

ABI Discussion

We had a very important discussion about ABI stability and the priorities of C++ this week in a joint session of the Language Evolution and Library Evolution group.

Although there was strong interest in exploring how to evolve ABI in the future, we are not pursuing making C++23 a clean ABI breaking release at this time. We did, however, affirm that authors should be encouraged to bring individual papers for consideration, even if those would be an ABI break. Many in the committee are interested in considering targeted ABI breaks when that would signify significant performance gains.

‟How many C++ developers does it take to change a lightbulb?” — @tvaneerd

‟None: changing the light bulb is an ABI break.” — @LouisDionne

Language Progress

Evolution Working Group Incubator (EWGI) Progress

The EWG Incubator met for three days in Prague and looked at and gave feedback to 22 papers for C++23. 10 of those papers were forwarded to Evolution, possibly with some revisions requested. Notably:

• Guaranteed copy elision for named return objects

• Generalized pack declaration and usage

• Member templates for local classes

• Object relocation in terms of move plus destroy

Several papers received a lot of feedback and will return to the Incubator, hopefully in Varna:

• A pipeline-rewrite operator

• Universal template parameters

• Partially mutable lambda captures

• C++ should support just-in-time compilation

• move = bitcopies

Notably, the proposed epochs language facility received no consensus to proceed. One significant problem pointed out was that in a concepts and modules world, we really cannot make any language changes that may change the satisfaction of a concept for a set of types. If one TU thinks C<T> is true, but another TU in a later epoch thinks C<T> is false, that easily leads to ODR violations. Many of the suggested changes in the paper run afoul of this problem. However, we’re interested in solving the problem, so welcome an alternative approach.

Evolution Working Group (EWG) Progress

The top priority of EWG was again fixing the final national body comments for C++20. Once that was done, we started looking at C++23 papers. We saw a total of 36 papers.

Papers of note:

• We adopted the C++ IS schedule.

• We adopted a plan for C++23.

• We adopted a process for evolutionary proposals, to make sure that we reduce the chance that we’ll make mistakes

• We agreed to pursue the Undefined Behavior group’s effort to document Core Undefined or Unspecified Behavior going forward. They’re documenting all language undefined behavior that C++ contains today, and we agreed to document and justify any new language undefined behavior going forward.

We marked 3 papers as tentatively ready for C++23:

• Make declaration order layout mandated

• Guaranteed copy elision for named return objects

• C++ Identifier Syntax using Unicode Standard Annex 31

They’ll proceed to the Core language group at the next meeting if no issues are raised with these papers.

We continued reviewing pattern matching. This is one of our top priorities going forward. It’s looking better and better as we explore the design space and figure out how all the corner cases should work. One large discussion point at the moment is what happens when no match occurs, and whether we should mandate exhaustiveness. There’s exploration around the expression versus statement form. We’re looking for implementation experience to prove the design.

We really liked deducing this, a proposal that eliminates the boilerplate associated with having const and non-const, & and && member function overloads. It still needs wording and implementation experience, but has strong support.

We continue discussing floating-point fixed-layout types and extended floating point types, which are mandating IEEE 754 support for the new C++ float16_t, float32_t, float64_t, and adding support for bfloat16_t.

std::embed, which allows embedding strings from files, is making good progress.

In collaboration with the Unicode group, named universal character escapes got strong support.

if consteval was reviewed. We’re not sure this is exactly the right solution, but we’re interested in solving problems in this general area.

We saw a really cute paper on deleting variable templates and decided to expand its scope such that more things can be marked as = delete in the language. This will make C++ much more regular, and reduce the need for expert-only solutions to tricky problems.

Core Working Group (CWG) Progress

The top priority of CWG was finishing processing national body comments for C++20. CWG spent most of its remaining time this week working through papers and issues improving the detailed specification for new C++20 features.

We finished reviewing four papers that fine-tune the semantics of modules:

• We clarified the meaning of static (and unnamed namespaces) in module interfaces: such entities are now kept internal and cannot be exposed in the interface / ABI of the module. In non-modules compilations, we deprecated cases where internal-linkage entities are used from external-linkage entities. (These cases typically lead to violations of the One Definition Rule.)

• We clarified the meaning of inline in module interfaces: the intent is that bodies of functions that are not explicitly declared inline are not part of the ABI of a module, even if those function bodies appear in the module interface. In order to give module authors more control over their ABI, member functions defined in class bodies in module interfaces are no longer implicitly inline.

• We tweaked the context-sensitive recognition of the module and import keyword in order to avoid changing the meaning of more existing code that uses these identifiers, and to make it more straightforward for a scanning tool to recognize these declarations without full preprocessing.

• We improved backwards compatibility with unnamed enumerations in legacy header files (particularly C header files). Such unnamed enumerations will now be properly merged across header files if they're reachable in multiple different ways via imports.

• We finalized some subtle rules for concepts: a syntax gotcha in requires expressions was fixed, and we allowed caching of concept values, which has been shown to dramatically improve performance in some cases.

• We agreed to (retroactively, via the defect report process) treat initialization of a bool from a pointer as narrowing, improving language safety.

• We added permission for a comparison function to be defaulted outside its class, so long as the comparison function is a member or friend of the class, for consistency and to allow a defaulted comparison function to be non-inline.

Library Progress

Library Evolution Working Group Incubator (LEWGI) Progress

LEWGI met for three and a half days this week and reviewed 22 papers. Most of our work this week was on various numerics proposals during joint sessions with the Numerics group. A lot of this work may end up going into the proposed Numerics Technical Specification, whose scope and goals we are working to define. We also spent a chunk of time working on modern I/O and concurrent data structures for the upcoming Concurrency Technical Specification Version 2.

LEWGI looked at the following proposals, among others:

• Numerics:

  • Physical Units Library.

  • Linear Algebra.

• Concurrency:

  • Concurrent Queues.

• Low-level File I/O

  • Mapped File Handle.

• Narrowing Conversions

  • std::is_narrowing_conversion.

  • std::narrow_cast.

• Random Numbers

  • Improving std::random_device.

  • Portable Distributions.

  • Improving Engine Seeding.

Library Evolution Working Group (LEWG) Progress

After handling the few remaining National Body comments to fix issues with C++20, LEWG focused on making general policy decisions about standard library design standards. For example, we formally codified the guidelines for concept names in the standard library, and clarified SD-8, our document listing the compatibility guarantees we make to our users. Then we started looking at C++23 library proposals.

Moved-from objects need not be valid generated much internal discussion in the weeks leading up to the meeting as well as at the meeting itself. While the exact solution outlined in the paper wasn’t adopted, we are tightening up the wording around algorithms on what operations are performed on objects that are temporarily put in the moved-from state during the execution of an algorithm.

The biggest C++23 news: LEWG spent an entire day with the concurrency experts of SG1 to review the executors proposal — we liked the direction! This is a huge step, which will enable networking, audio, coroutine library support, and more.

Other C++23 proposals reviewed include

• a new status_code facility

• an ability for containers and allocators to communicate about the actual allocation size

• iterator range constructors for std::stack and std::queue

We’ve also decided to deprecate std::string’s assignment operator taking a char (pending LWG).

Library Working Group (LWG) Progress

The primary goals were to finish processing NB comments and to rebase the Library Fundamentals TS on C++20. We met both of those goals.

We looked at all 48 open library-related NB comments and responded to them. Some were accepted for C++20. Some were accepted for C++20 with changes. For some, we agreed with the problem but considered the fix to be too risky for C++20, so an issue was opened for consideration in C++23. For many the response was “No consensus for change,” which can mean a variety of things from “this is not really a problem” to “the problem is not worth fixing.”

The last of the mandating papers was reviewed and approved. All of the standard library should now be cleaned up to use the latest library wording guidelines, such as using “Mandates” and “Constraints” clauses rather than “Requires” clauses.

Some time was spent going through the LWG open issues list. We dealt with all open P1 issues (“must fix for C++20”). Many of the open P2 issues related to new C++20 features were dealt with, in an attempt to fix bugs before we ship them.

This was Marshall Clow’s last meeting as LWG chair. He received a standing ovation in plenary.

Concurrency and Parallelism Study Group (SG1) Progress

SG1 focused on C++23 this week, primarily on driving executors, one of the major planned features on our roadmap. Executors is a foundational technology that we'll build all sorts of modern asynchronous facilities on top of, so it's important that we land it in the standard early in the C++23 cycle.

At this meeting, LEWG approved of the executors design, and asked the authors to return with a full specification and wording for review at the next meeting.

SG1 reviewed and approved of a refinement to the design of the sender/receiver concepts. This change unifies the lifetime model of coroutines and sender/receiver and allows us to statically eliminate the need for heap allocations for many kinds of async algorithms.

Going forward, SG1 will start working on proposals that build on top of executors, such as concurrent algorithms, parallel algorithms work, networking, asynchronous I/O, etc.

Networking Study Group (SG4) Progress

SG4 started processing review feedback on the networking TS aimed at modernizing it for inclusion in C++23. SG4 also reviewed a proposal to unify low-level I/O with the high-level asynchronous abstractions and gave feedback to the author.

Numerics Study Group (SG6) Progress

The Numerics group met on Monday this week, and also jointly with LEWGI on Tuesday and Thursday, and with SG19 on Friday.

We reviewed papers on a number of topics, including:

• The scope and goals for the Numerics TS.

• Linear algebra.

• Units library.

Compile-Time Programming Study Group (SG7) Progress

Circle is a fork of C++ that enables arbitrary compile-time execution (e.g. a compile-time std::cout), coupled with reflection to allow powerful meta-programming. SG7 was interested in it and considered copying parts of it. However, concerns were raised about security and usability problems, so the ability to execute arbitrary code at compile-time was rejected.

Besides that, we also continued to make progress on C++ reflection including naming of reflection keywords and potential to enable lazy evaluation of function arguments.

We also looked at the JIT proposal and asked authors to try to unify the design with current reflection proposals.

Undefined Behavior Study Group (SG12)/Vulnerabilities Working Group (WG23) Progress

We set out to enumerate all undefined and unspecified behavior. We’ve decided that upcoming papers adding new undefined or unspecified behavior need to include rationale and examples.

SG12 also collaborated with the MISRA standard for coding standards in embedded systems to help them update the guidelines for newer C++ revisions.

Human Machine Interface and Input/Output Study Group (SG13) Progress

SG13 had a brief presentation of extracts from the 2019 CppCon keynote featuring Ben Smith (from 1:05:00)

We looked at A Brief 2D Graphics Review and encouraged exploration of work towards a separable color proposal.

Finally, we worked through the use cases in Audio I/O Software Use Cases. We have a couple of weeks before the post meeting mailing deadline to collect additional use cases and will then solicit feedback on them from WG21 and the wider C++ community.

Tooling Study Group (SG15) Progress

The Tooling study group met this week to continue work on the Module Ecosystem Technical Report. Three of the papers targeting the Technical Report are fairly mature at this point, so we've directed the authors of those papers to work together to create an initial draft of the Technical Report for the Varna meeting. Those papers are:

• Dependency Information Format

• Module Recipe and BMI Reuse

• User-Facing Lexicon and File Extensions

This draft will give us a shared vehicle to start hammering out the details of the Technical Report, and a target for people to write papers against.

We also discussed two proposals, about debugging C++ coroutines and asynchronous call stacks.

Machine Learning Study Group (SG19) Progress

SG14 met in Prague in a joint session with SG19 (Machine Learning).

The freestanding library took a few steps forward, with some interesting proposals, including Freestanding Language: Optional ::operator new

One of the biggest decisions was on Low-Cost Deterministic C++ Exceptions for Embedded Systems which got great reactions. We will probably hear more about it!

Unicode and Text Study Group (SG16) Progress

Our most interesting topic of the week concerned the interaction of execution character set and compile-time programming. Proposed features for std::embed and reflection require the evaluation of strings at compile time and this occurs at translation phase 7. This is after translation phase 5 in which character and string literals are converted to the execution character set. These features require interaction with file names or the internal symbol table of a compiler. In cross compilation scenarios in which the target execution character set is not compatible with the compiler’s host system or internal encoding, interesting things happen. As in so many other cases, we found an answer in UTF-8 and will be recommending that these facilities operate solely in UTF-8.

We forwarded Named Universal Character Escapes and C++ Identifier Syntax using Unicode Standard Annex 31 to EWG. Both papers were seen by EWG this week and are on track for approval for C++23 in meetings later this year.

We forwarded Naming Text Encodings to Demystify Them to LEWG.

We declined to forward a paper to enhance std::regex to better support Unicode due to severe ABI restrictions; the std::regex design exposes many internal details of the implementation to the ABI and implementers indicated that they cannot make any significant changes. Given the current state of std::regex is such that we cannot fix either its interface or its well-known performance issues, a number of volunteers agreed to bring a paper to deprecate std::regex at a future meeting.

Machine Learning Study Group (SG19) Progress

SG19 met for a full day, one half day with SG14 (Low Latency), and one half day with SG6 (Numerics).

Significant feedback from a ML perspective was provided on Simple Statistics functions, especially regarding the handling of missing data, non-numeric data, and various potential performance issues.

There was an excellent presentation of "Review of P1708: Simple Statistical Functions" which presented an analysis across Python, R, SAS and Matlab for common statistical methods.

The graph library paper had a great reaction, was also discussed, and will proceed.

Also, support for differentiable programming in C++, important for well-integrated support for ML back-propagation, was discussed in the context of differentiable programming for C++.

Contracts Study Group (SG21) Progress

In a half-day session, we discussed one of the major points of contention from previous proposals, which was the relationship between “assume” and “assert”, disentangling colloquial and technical interpretations. We also discussed when one implies the other, and which combinations a future facility should support.

• Previous Disagreements

• Assumptions

• Portable Assumptions

C++ Release Schedule

NOTE: This is a plan not a promise. Treat it as speculative and tentative. See P1000 for the latest plan.

• IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.

• TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.

• CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").

Status of Major C++ Feature Development

NOTE: This is a plan not a promise. Treat it as speculative and tentative.

• IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.

• TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.

• CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").

Changes since last meeting are in bold.

Last Meeting's Reddit Trip Report.

If you have any questions, ask them in this thread!

Report issues by replying to the top-level stickied comment for issue reporting.

/u/blelbach, Tooling (SG15) Chair, Library Evolution Incubator (SG18) Chair

/u/bigcheesegs

/u/c0r3ntin

/u/jfbastien, Evolution (EWG) Chair

/u/arkethos (aka code_report)

/u/vulder

/u/hanickadot, Compile-Time Programming (SG7) Chair

/u/tahonermann, Text and Unicode (SG16) Chair

/u/cjdb-ns, Education (SG20) Lieutenant

/u/nliber

/u/sphere991

/u/tituswinters, Library Evolution (LEWG) Chair

/u/HalFinkel, US National Body (PL22.16) Vice Chair

/u/ErichKeane, Evolution Incubator (SG17) Assistant Chair

/u/sempuki

/u/ckennelly

/u/mathstuf

/u/david-stone, Modules (SG2) Chair and Evolution (EWG) Vice Chair

/u/je4d, Networking (SG4) Chair

/u/FabioFracassi, German National Body Chair

/u/redbeard0531

/u/nliber

/u/foonathan

/u/InbalL, Israel National Body Chair

/u/zygoloid, C++ Project Editor

⋯ and others ⋯

C++ is getting more and more complex. The ISO C++ committee keeps adding new features based on its consensus. Let's remove C++ features based on Reddit's consensus.

In each comment, propose a C++ feature that you think should be banned in any new code. Vote up or down based on whether you agree.

I am sorry to report to /r/cpp that Beman Dawes passed away yesterday.

Beman had an unusually large impact on C++ over his long and very productive life. My personal opinion of his most monumental achievement was getting Filesystem into standard C++, which was probably the most tortuous, lengthy, and difficult library to have ever been standardised (to date), and that followed a preceding tortuous, lengthy and difficult Boost peer review involving multiple redesigns of the proposed library. Beman was on WG21 from nearly the beginning, served as the Library Working Group chair for some time, and was one of the original cofounders of the Boost C++ Libraries. He also had a long history of continuous contributions to open source, starting from when many on /r/cpp were still children.

He had periods of particularly poor health in his later years, yet kept up a work ethic which would shame most of us. He helped and advised me privately on a number of occasions, for which I was and still am immensely grateful.

I'll loop in /u/JonKalb at this point, who is collecting recollections and memories of Beman to be later posted to boost.org's website. If you'd like to recount any memories or tributes here, that would be great, thank you.

Thank you so much, u/katzdm-cpp and u/BarryRevzin for your heroic work this week, and during the months leading up to today.

Not only did we get P2996, but also a half dozen related proposals, including annotations, expansion statements, and parameter reflection!

(Happy dance!)

Despite the hate it gets, despite the complexity; the dizzying number of features and different ways to do things. C++ is an astonishing feat of engineering and people really don't appreciate this fact enough. I can do things with this language more quickly and expressively than I can with any other language.

There's no getting around the fact that programming is just hard, and all these attempts to replace C and C++ over the years just end up adding to our difficulties. That is my take, anyhow.

Well, I'm a little drunk, and just wanted to share some Christmas joy with you all. I love C++!

Crow is a simple and easy to use C++ web application framework. We picked it up as an abandoned project about a year and a half ago and have been fixing, optimizing, and adding many features.

Today we released version 1.0, which aside from being the first non pre-release version, improves considerably on all parts of the framework. The changes include Blueprints (similar to python flask), a new HTTP Parser, CMake support, easily allowing multiple source files in downstream projects, C++20 support, and many more features and fixes. full changelog here.

I was sweeping floors at a supermarket and decided to over-engineer it.

Instead of just… sweeping… I turned the supermarket into a grid graph and wrote a C++ optimizer using simulated annealing to find the “optimal” sweeping path.

It worked perfectly.

It also produced a path that no human could ever walk without losing their sanity. Way too many turns.

Turns out optimizing for distance gives you a solution that’s technically correct and practically useless.

Adding a penalty each time it made a sharp turn made it actually walkable:

But, this led me down a rabbit hole about how many systems optimize the wrong thing (social media, recommender systems, even LLMs).

If you like algorithms, overthinking, or watching optimization go wrong, you might enjoy this little experiment. More visualizations and gifs included!

The ISO C++ Committee met in Kona, Hawaii 🏄‍♂️ 🌊 🇺🇸 last week to finalize the feature set for the next International Standard (IS), C++20. The design of C++20 is now feature complete. At the upcoming July 2019 meeting in Cologne 🇩🇪, we’ll finish the specification for C++20 and send out a Committee Draft for review.

This week, we added the following features to the C++20 draft:

• Modules!

• Coroutines!

• static, thread_local, and lambda capture for structured bindings.

• std::polymorphic_allocator<>.

• std::midpoint and std::lerp.

• std::execution::unseq execution policy.

• std::ssize free function that returns a signed size.

• std::span usability enhancements.

• Precalculated hash values in lookup.

• std::is_bounded_array and std::is_unbounded_array.

The following features have been approved for C++20, either at this meeting or a prior meeting, but have not been added to C++20 yet because we're still completing the specification. Hopefully they'll be added at the July 2019 Cologne 🇩🇪 meeting, but we may not get to everything due to time constraints.

• Expansion statements.

• The C++20 synchronization library.

• std::format.

• Allow constexpr allocation, but disallow allocations that are not deleted at compile time.

• constexpr std::type_info::operator==.

• constexpr std::vector.

• Some constexpr in <cmath> and <cstdlib>.

• New conceptification of iterators.

• Monadic operations for std::optional.

• std::source_location.

• std::flatmap.

• std::flatset.

• std::any_invocable.

• std::ostream_joiner.

• Stack trace library.

• std::byteswap.

• constinit.

• Deprecating some uses of volatile.

• Implicit creation of objects for low-level object manipulation.

• using enum.

The following notable features have been approved for C++20 at prior meetings:

• Concepts.

• Contracts.

• Ranges.

• operator<=>.

• A lot more constexpr features: consteval functions, std::is_constant_evaluated, constexpr union, constexpr try and catch, constexpr dynamic_cast and typeid.

• Feature test macros.

• std::span.

• Synchronized output.

• std::atomic_ref.

TL;DR: C++20 may well be as big a release as C++11.

The Reflection Technical Specification Version 1 is now finalized and will be sent for publication. At the June 2018 Rapperswil meeting earlier this year, we sent a draft out for national body balloting and feedback ("beta testing"). This week, we reviewed their feedback (86 individual comments) and finalized the TS. While we expect a major update to improve the compile time programming model used (by moving towards a constexpr model instead of type-based metaprogramming), this TS will help encourage early implementation and usage experiments to verify and improve the underlying technology and designs.

The Tooling Study Group, SG15, has decided to explore creating a a C++ Ecosystem Technical Report, which will describe the best practices and state of the art for tools (build systems, etc) in the new modular C++ world.

Language Evolution Progress

Evolution Working Group Incubator (EWGI) Progress

The evolution incubator’s goal is to help EWG get higher quality papers. To that end, we saw 27 papers over 3 days:

• Forwarded 5 to EWG.

• 2 were sent to other groups to get feedback (will be seen again by EWGI).

• 3 had no consensus to move forward (we recorded objections, authors know what would get people to change their mind).

• Other papers got feedback, some need input from other groups, they'll be seen again by EWGI.

• 7 in the backlog (down from 27).

Evolution Working Group (EWG) Progress

At the last meeting, EWG finalized the feature set for C++20. At Kona, we focused on finalizing those features:

• Contracts: We worked on refining the feature. The only change this meeting was renaming expects/ensures to pre/post.

• Modules: Through the heroic efforts of some committee members, we fixed internal linkage escaping modules.

• Coroutines: We looked at all of the various coroutines proposals, and held an educational evening session. EWG decided once again to move forward with the TS.

• operator <=>: We looked at a proposal for making adoption of operator <=> easier, and sent it to CWG with minor modifications.

We also fixed some char8_t breakage, and sent the proposal for deprecating some uses of volatile to CWG for inclusion in C++20 (with minor changes).

Language Wording Group (CWG) Progress

CWG focused on completing the specification for C++20 language features and responding to the National Body comments for the Reflection TS.

We spent a lot of the week working on the merged modules paper so that it would be ready for a vote this week.

Library Evolution Progress

Library Evolution Working Group Incubator (LEWGI) Progress

This week, LEWGI primarily focused on post C++20 work:

• The Numerics TS (new number types, etc): P4038, P1438, P0828, P0037, P0554, and P0880. We really like the basic design of the new composable arithmetic types, although we want to make sure we focus on the most important ones for the TS.

• Linear Algebra. We had an evening session where we discussed the history of C++ linear algebra libraries and requirements for a standard linear algebra library. We also spent some time providing early library design review to one concrete linear algebra proposal.

• Audio. As with linear algebra, there was an evening session on audio to discuss the history, motivation, and use cases, and we also spent some time providing early library design feedback to the authors.

• Freestanding Reorganization. This large paper proposes bringing more parts of the standard library into freestanding. We discussed how this should be done; in particular, how do we deal with standard library types that can only be partially supported in freestanding environments.

• std::uuid. This is the second time that LEWGI has seen this paper. Last time, we decided we definitely wanted to pursue it, so now we're focusing on refining the design. At this meeting, we discussed possible security concerns relating to older UUID variants.

• std::colony. We took another look at this paper, which proposes a new container useful for managing the lifetime of a collection of objects. We still haven't committed to pursuing it, but we're still interested in learning more.

• The Concurrency TS v2: std::buffer_queue, Distributed Counters

• Text/Strings: Compile Time Regular Expressions, std::concat, std::ostringstream Wrapper, and std::cstring_view

• Ranges Enhancements and Fixes: Making View only require Moveable, std::to_address for ContiguousIterators, std::ranges::static_extent

• Networking TS Enhancements and Fixes: P1100, P1145, P1133, P1322, and P1442

Library Evolution Working Group (LEWG) Progress

At this meeting, LEWG completed the design of the C++20 standard library.

LEWG spent a lot of time this week looking at papers that address the deployment of operator<=> into the standard library: P0891, P0790, and P1189.

LEWG also discussed the options for modularizing the standard library in C++20. We decided that for C++20, the best option is to make it possible for traditional #includes to be transparently treated as module imports, and to make each standard library header importable. E.g. in C++20, you can import <vector>; - and of course you can still #include <vector>. In the future, we plan to reorganize the standard library and expose new standard library modules.

Also, we revisited adding sized counts to the standard library, and decided to add a free ssize function to get the size of a container or span as a signed type. std::span now matches the containers in that size returns an unsigned value.

Finally, LEWG continued looking at executors and properties. We decided that we need more time to refine properties, so both features are being retargeted for C++23, instead of C++20.

Library Wording Group (LWG) Progress

LWG continued working on the specification for the C++20 standard library. There's still a lot of work left to do at the next meeting.

At this meeting, LWG continued working on the C++20 synchronization library, std::flatmap and std::format. These should make it into C++20, but they won't be ready until Cologne.

We also spent a lot of time working on a series of papers (P1458, P1459, P1462, P1463, and P1464) that applies the new guidance on specifying type requirements, preconditions, and postconditions in the standard library. This addresses some of the technical debt we've accumulated over the years and cleans up the specification of the standard library a lot.

Concurrency and Parallelism Study Group (SG1) Progress

SG1 met for just four days this week; we had an unusually small number of work items.

We spent time talking about the fibers proposal and some related proposals (P1364 and P0866). We identified some new issues and implementability concerns; we'll have to do more work at future meetings.

We continued discussing the Concurrency TS v1, which is starting to take shape; its primary content will be concurrent data structures and building blocks for data structures. We discussed the proposed concurrent hashmap and some concerns about it.

We approved the wording for Deprecating volatile (as did EWG), discussed volatile_load<T> and volatile_store<T> as follow-up, and asymmetric fences.

We adjourned during LEWG discussions of executors and had some executors discussions of our own, notably whether execution agents have thread local storage and the future of asynchronous interfaces in the C++ standard library.

Compile Time Programming and Reflection Study Group (SG7) Progress

We discussed two reflection paper (P1447 and P0953) and compared their approaches, main differences was the use of multiple types of the reflection object based on reflexpr expression and style (free or member functions) of the API. We also pushed forward modern offsetof replacement to LEWG.

Also, the Reflection TS, which came out of SG7, was published at this meeting.

Undefined Behavior Study Group (SG12)/Vulnerabilities Working Group (WG23) Progress

SG12 and WG23 once again met to continue work on documenting security vulnerabilities that the C++ language is susceptible to. Additionally, we started the preliminary work for a new deliverable; an updated revision of the MISRA guidelines that covers C++11, 14, 17 and beyond.

We also discussed pointer provenance and signed integer overflow.

I/O Study Group (SG13) Progress

The study group met for a half-day and discussed std::audio. The main discussion centered around the proposed audio API. We discussed what the API should look like, which types and containers would be used, and what use cases we’re trying to help. Our intent is to ship an Audio TS. We also discussed feedback on std::audio, which will be available in the post-meeting mailing. The study group also briefly discussed higher-level audio interfaces, for example a facility to play a file to the default output device.

There was no discussion of 2D Graphics: the authors’ focus is currently on the linear algebra subset of that proposal. Linear algebra is being handled by other groups.

Tooling Study Group (SG15) Progress

First, there's been a change in leadership for SG15: Titus Winters, the original chair, is stepping down. Bryce Adelstein Lelbach will be taking over as the new SG15 chair.

SG15's focus for the near-term future is on modules interactions with the C++ ecosystem (tools, build systems, etc). We had two telecons before Kona and an evening session at Kona to discuss these interactions.

We've decided the best way to proceed is to create a C++ Ecosystem Technical Report which explores and describes the best practices and state of the art for modules tooling interactions. A Technical Report is a type of ISO document more similar to an essay or study than a normative specification. For example, take a look at the prior C++ Performance Technical Report. Note that we used to use a different type of Technical Report (e.g. TR1) for what we now call Technical Specifications.

Text Study Group (SG16) Progress

Two proposals that originated from SG16 were voted into C++20 this week:

• Make char16_t/char32_t string literals be UTF-16/32.

• Address wording issues related to ISO 10646.

This may come as a surprise to many, but the C++ standard did not previously guarantee that u"" and U"" literals were encoded as UTF-16 and UTF-32 respectively despite the fact that is what every implementation already did. We can now rely on this guarantee.

We discussed the three papers listed below in session.

• Compile Time Regular Expressions: We provided guidance to the author regarding how to align the proposed regular expression support with requirements of Unicode Technical Standard #18.

• Source-Code Information Capture: We provided guidance regarding the treatment of file names. On some platforms, it is not possible to associate any particular character encoding with file names. We encouraged treating file names as an implementation defined sequence of bytes for the purposes of source locations.

• Charset Transcoding, Transformation, and Transliteration: We gained valuable insight into requirements for interfaces providing transcoding and transliteration services based on long term experience working with legacy and private character encodings. The discussion made it clear that such interfaces must allow extensions if only to allow custom handling for use of the Unicode private use area.

Proposed C++20 Release Schedule

We've scheduled three additional meetings between now and the next full committee meeting to work on specific parts of C++20.

NOTE: This is a plan not a promise. Treat it as speculative and tentative. See P1000 for the latest plan.

• IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.

• TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.

• CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").

Status of Major C++ Feature Development

NOTE: This is a plan not a promise. Treat it as speculative and tentative.

• IS = International Standard. The C++ programming language. C++11, C++14, C++17, etc.

• TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.

• CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").

Changes since last meeting are in bold.

Last Meeting's Reddit Trip Report.

If you have any questions, ask them in this thread!

/u/blelbach

/u/bigcheesegs

/u/nliber

/u/chandlerc1024

/u/louis_dionne

/u/je4d

/u/hanickadot

/u/tahonermann

/u/jfbastien

and others