c++20

Specifying a violation handler for contracts

由 亡梦爱人 提交于 2019-12-10 14:23:30
问题 Support for contract based programming in C++ was adopted ino the C++20 working draft in Rapperswil. One part of this language feature is this notion of a violation handler which will be invoked when a contract is violated. Herb Sutter's trip report states that: You get to install your own violation handler and ship a release build with the option of turning on enforcement at run time. But the wording in [dcl.attr.contract] that this paper added says: The violation handler of a program is a

Hashing types at compile-time in C++17/C++2a

由 岁酱吖の 提交于 2019-12-10 03:22:24
问题 Consider the following code: #include <iostream> #include <type_traits> template <class T> constexpr std::size_t type_hash(T) noexcept { // Compute a hash for the type // DO SOMETHING SMART HERE } int main(int argc, char* argv[]) { auto x = []{}; auto y = []{}; auto z = x; std::cout << std::is_same_v<decltype(x), decltype(y)> << std::endl; // 0 std::cout << std::is_same_v<decltype(x), decltype(z)> << std::endl; // 1 constexpr std::size_t xhash = type_hash(x); constexpr std::size_t yhash =

Why does same_as concept check type equality twice?

由 一世执手 提交于 2019-12-09 08:00:59
问题 Looking at the possible implementation of the same_as concept at https://en.cppreference.com/w/cpp/concepts/same_as i noticed something strange is happening. namespace detail { template< class T, class U > concept SameHelper = std::is_same_v<T, U>; } template< class T, class U > concept same_as = detail::SameHelper<T, U> && detail::SameHelper<U, T>; The first question is why a SameHelper concept is nedded? The second is why same_as checks if T is the same as U and U the same as T ? Isn't it

What is consteval?

由 我只是一个虾纸丫 提交于 2019-12-09 02:07:02
问题 Apparently, consteval is going to be a keyword in C++20. The cppreference page for it is currently blank. What is it going to be and how does it relate to constexpr ? 回答1: It declares immediate functions , that is, functions that must be evaluated at compile time to produce a constant. (It used to be spelled constexpr! in a previous revision of the paper.) In contrast, constexpr functions may be evaluated at compile time or run time, and need not produce a constant in all cases. The adopted

C++20 designated initializers with templated types

由 岁酱吖の 提交于 2019-12-08 17:00:48
问题 How are designated initializers (C++20) supposed to work with CTAD? This code works fine in gcc9.2, but fails with clang8 template <typename int_t=int, typename float_t=float> struct my_pair { int_t first; float_t second; }; template<typename ... ts> my_pair(ts...) -> my_pair<ts...>; int main() { my_pair x{.first = 20, .second = 20.f}; static_assert( std::is_same_v<decltype(x.first), int> ); static_assert( std::is_same_v<decltype(x.second), float> ); } Is this supposed to be valid? See an

Does C++20 well-define left shift for signed integers that “overflow”?

由 时光总嘲笑我的痴心妄想 提交于 2019-12-08 15:32:12
问题 In the current C++ Standard Draft, the left shift operator is defined as follows [expr.shift]: The value of E1 << E2 is the unique value congruent to E1×2^E2 modulo 2^N , where N is the width of the type of the result. Consider int E1 = 2^31-1 = 2'147'483'647 , E2 = 1 , and int having 32 bits. Then there is an infinite number of numbers congruent to E1×2^E2 = 4'294'967'294 modulo 2^N = 2^32 , namely, all the numbers 4'294'967'294 + k×2^32 where k is an arbitrary integer. Examples are 4'294

is bit_cast without compiler support for constexpr memcpy possible?

由 為{幸葍}努か 提交于 2019-12-08 04:32:51
问题 I had heard that std::bit_cast will be in C++20, and I am slightly puzzled about the conclusion that implementing it necessarily requires special compiler support. To be fair, the argument I have heard is that the implementation performs a memcpy operation, and memcpy is not typically constexpr , while std::bit_cast is supposed to be, so making std::bit_cast constexpr supposedly requires compiler support for a constexpr -compliant memcpy operation. I was wondering, however, if it was possible

CTAD and designated initializers in C++20

由 只谈情不闲聊 提交于 2019-12-07 00:05:10
问题 I have already stated confusion about CTAD with designated initializers in this question, but i have another confusion with a very similar code snippet template <typename int_t=int, typename float_t=float> struct my_pair { int_t first; float_t second; }; template<typename ... ts> my_pair(ts...) -> my_pair<ts...>; int main() { my_pair x{.second = 20.f}; static_assert( std::is_same_v<decltype(x.first), int> ); //FAILS <- its deduced to float static_assert( std::is_same_v<decltype(x.second),

is bit_cast without compiler support for constexpr memcpy possible?

由 [亡魂溺海] 提交于 2019-12-06 14:54:51
I had heard that std::bit_cast will be in C++20, and I am slightly puzzled about the conclusion that implementing it necessarily requires special compiler support. To be fair, the argument I have heard is that the implementation performs a memcpy operation, and memcpy is not typically constexpr , while std::bit_cast is supposed to be, so making std::bit_cast constexpr supposedly requires compiler support for a constexpr -compliant memcpy operation. I was wondering, however, if it was possible to implement a compliant bit_cast (ie, defined behavior, to same extent that using memcpy would have

Why is ranges::ostream_iterator default-constructible?

由 安稳与你 提交于 2019-12-05 06:55:17
This question follows a discussion in the comments here . In Eric Niebler's ranges-v3 library (which is sort-of becoming part of the standard for C++20), ranges::ostream_iterator is default-constructible - without an ostream. How come? I thought that "dummy" construction with effective construction later is an anti-pattern in C++, a wart we are gradually getting rid of. std::ostream iterator can only be constructed with a stream (for now - before C++20). And it's not as though we can do anything with the default-constructed range::ostream_iterator ... So, what's the deal? This follows the
订阅 c++20