C++ Proposals please...

published at 16.02.2017 11:10 by Jens Weller
Save to Instapaper Pocket

A quick overview over the newest mailing of proposals for the upcoming C++ Committee Meeting in Kona, Hawaii. With C++17 being "done" but not yet an official standard, its a good time to start new proposals aiming for C++20 and beyond. After all, a new proposal which might needs to go through a TS might not make it to the C++20 timeframe...

You find the full list of proposals here.

TS Related

These are the mature proposals that are a TS or related to one:

Proposals of new things into Standard C++

Generic Scope Guard and RAII Wrapper for the Standard Library

Adding factories and scope_exit, scope_sucess and scope_fail to C++. make_scope_* takes a lambda which will be executed in the context.

A proposal to add a ring span to the standard library

SG14 proposing a ring span type for the standard library. Proposed is std::ring_span<class T, class popper = default_popper<T> > with null_popper and copy_popper as alternatives. The elements are stored in contiguous memory, the ring is of fixed size. The ring span does not own memory, avoiding allocations which would be needed with std::queue. It offers the interface of an std::queue, as that is the currently offered standard solution. This is an excellent paper, with a very limited focus on a single, simple container like type.

Static reflection

This paper adds the $ sign to the C++ standard, for the purpose of reflection. e.g. $reflect will be a thing soon. This can be found under <experimental/reflect>, and as it seems Enums, Classes, Unions, Types, Aliases, Namespaces, (member) variables and enumerators seem to be reflectable, e.g $reflect(_) will work on these. But, if you are interested in reflection, you might want to reflect on the paper it self.

Data-Parallel Vector Types [&] Operations

Proposing vector types for SIMD programming. The paper aims at being a starting point, rather then a complete solution.

Adding 2D Graphics Rendering and Display to C++

A simple 2d drawing API for C++ takes slowly shape. With 183 pages this is a complex paper dealing with completly new field for C++: drawing on a surface. This seems currently not to include text rendering.

Adding Classes and Functions Required for Dynamic Library Load

The proposal handles mangled types only, the proposed class has the name mangled_library. You are able to load functions via get<void(int)>("foo::bar") member function. The library builds upon std::filesystem for path usage.

Extending <chrono> to Calendars and Time Zones

What about timezones? This paper aims at making minimal changes to <chrono> in order to add support for calender (gregorian) and timezones. The scope is realtively small, only one calendar (gregorian) is actually proposed, while others could be implemented easily, the paper mentions the coptic calendar.

Static reflection: Rationale, design and evolution

More on reflection, this paper might be a better read then the first one, as it aims to provide a rationale behind the proposed design.

A Unified Executors Proposal for C++

Executors are an important step towards parallelism in the C++ Standard. So it is good to see that this is taking shape. This image gives you a good overview on the proposed types:

Introduction of std::colony to the standard library

This is an interesting paper from SG14. From the paper:

Colony is a higher[-]performance container for situations where the ratio of  insertions/erasures to iterations is relatively high. It is unordered but sortable, allows for both fast iteration and direct pointer linkage, and does not invalidate pointers/iterators to non[-] erased elements during insertion or erasure. It also frees or reuses unused memory on the fly, and is it's own abstract data type; similar to a "bag", "bucket[-]array" or "unordered multiset" but without key values.

 

Based on this description, I'm not sure if colony is able to write a declaration of independence or not ;)

Proposed RCU C++ API

Proposing a Read, Copy, Update API for C++, also reviewing the existing ones in C. The paper contains the design for a few types handling the RCU related talks in a clean and modern C++ way.

A Qualified Replacement for #pragma once

#pragma once, while widely used, is not in the standard. This paper proposes to add a replacement for #pragma once with #once and also #forget. Where #once identifier is the replacement for the include guard/#pragma, and #forget identifier is similar to #undef.

Support for contract based programming in C++

This is a unique paper, the authors goal is to add contracts to the C++ language by using attributes. Paper includes wording and a few examples.

Operating principles for evolving C++

This is a very important paper, its goals are to lay down the principles on which the C++ standard should operate on. This document is a starting point for this.

Towards Better Embedded programming support for C++ and an update on the status of SG14, 2 years later

Interesting read on what SG14 has accomplished in the last two years, and how to have better support for embedded in C++.

Static Reflection in a Nutshell

The TL;DR version and maybe best starting point for understanding the proposed static reflection for C++.

A design static reflection

Herb Sutter and Andrew Sutton weigh in on the static reflection debate. This paper shows how an object level reflection can provide a better meta programming not based on TMP, rather then an type-level only reflection.

To boldly suggest an overall plan for C++20

To boldy go where no C++ programmer... This paper is written by a very experienced committee member, and hence can be seen as a first blue print for C++20. Yet, history has shown, that expectations on new standards are often to high. But the aim of having Modules, Conceptes, Ranges and Networking in C++20 would be something worth fighting for. With higher attendance and more activity in the committee, the needed resouces to achive this goal could be there.

Reflect Through Values Instead of Types

And one more paper on reflection. This time aiming at the fact that with constexpr, values don't have to be types:

P0194R2 proposes adding compile-time reflection facilities to the language. I’m looking forward to the capabilities themselves, but I’m concerned about using types to perform computations when we’ve come such a long way in providing efficient compile-time computation facilities through constexpr. Let’s design with modern C++ in mind and leave the template metaprogramming shackles of the past behind.

Even more Proposals...

There is more proposals, but I decided to focus mostly on proposals on future standards, new ideas. There is also lots of interesting reads on ways to improve or add to the current standard.

 

Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!

Copyright Meetingcpp GmbH 2024 ImprintPrivacy Policy