c++20

CTAD and designated initializers in C++20

回眸只為那壹抹淺笑 提交于 2019-12-05 05:36:25
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), float> ); } It seems like the deduction guide causes the type of first to be deduced to float , even

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

半腔热情 提交于 2019-12-05 04:29:12
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 = type_hash(y); constexpr std::size_t zhash = type_hash(z); std::cout << (xhash == yhash) << std::endl; //

Why is std::filesystem::u8path deprecated in c++20?

老子叫甜甜 提交于 2019-12-04 23:19:28
Introduced in c++17, std::filesystem::u8path seems to be deprecated in c++20. What is the reason for this choice? What should I use in c++17? What should I use in c++20? Because, thanks to the existence of the C++20 feature char8_t , this will work: path p(u8"A/utf8/path"); u8path existed to allow the detection of the difference between a UTF-8 string and a narrow character string. But since C++20 will give us an actual type for that, it is no longer necessary. What should I use in c++17? Use u8path . Deprecation does not mean removed or inaccessible . It merely means subject to eventual

std::is_constant_evaluated behavior

放肆的年华 提交于 2019-12-04 22:51:18
GCC9 already implements std::is_constant_evaluated . I played a little bit with it, and I realized it is somewhat tricky. Here’s my test: constexpr int Fn1() { if constexpr (std::is_constant_evaluated()) return 0; else return 1; } constexpr int Fn2() { if (std::is_constant_evaluated()) return 0; else return 1; } int main() { constexpr int test1 = Fn1(); // Evaluates to 0 int test2 = Fn1(); // Evaluates to 0 int const test3 = Fn1(); // Evaluates to 0 constexpr int test4 = Fn2(); // Evaluates to 0 int test5 = Fn2(); // Evaluates to 1 int const test6 = Fn2(); // Evaluates to 0 } According to

Lambda closure type constructors

我怕爱的太早我们不能终老 提交于 2019-12-04 19:32:46
问题 The cppreference shows that there are different rules for lambda closure type constructors. Default Construction - Until C++14 ClosureType() = delete; (until C++14) Closure types are not Default Constructible. Closure types have a deleted (until C++14)no (since C++14) default constructor. Default Construction - Since C++14 Closure types have no (since C++14) default constructor. Default Construction - Since C++20 If no captures are specified, the closure type has a defaulted default

How to use C++20's likely/unlikely attribute in if-else statement

余生颓废 提交于 2019-12-04 17:40:27
问题 This question is about C++20's [[likely]] / [[unlikely]] feature, not compiler-defined macros. This documents (cppreference) only gave an example on applying them to a switch-case statement. This switch-case example compiles perfectly with my compiler (g++-7.2) so I assume the compiler has implemented this feature, though it's not yet officially introduced in current C++ standards. But when I use them like this: if (condition) [[likely]] { ... } else { ... } , I got a warning: "warning:

C++20 with u8, char8_t and std::string

我与影子孤独终老i 提交于 2019-12-04 15:27:52
问题 C++11 brought us the u8 prefix for UTF-8 literals and I thought that was pretty cool a few years ago and peppered my code with things like this: std::string myString = u8"●"; This is all fine and good, but the issue comes up in C++20 it doesn't seem to compile anymore because u8 creates a char8_t* and this is incompatible with std::string which just uses char. Should I be creating a new utf8string? What's the consistent and correct way to do this kind of thing in a C++20 world where we have

the purpose of the -Wlifetime flag?

穿精又带淫゛_ 提交于 2019-12-04 11:07:13
What is the purpose of the -Wlifetime compile flag in clang ? The information I found on the Internet about it are very vague. Is this any noticeable feature? This flag analyzes the local file to see if the code may use pointers to objects that are dead. You can see Herb Sutter cppcon video on YouTube where he explains this very well: https://youtu.be/80BZxujhY38 来源: https://stackoverflow.com/questions/52662135/the-purpose-of-the-wlifetime-flag

Is the three-way comparison operator always efficient?

醉酒当歌 提交于 2019-12-04 08:57:46
问题 Herb Sutter, in his proposal for the "spaceship" operator (section 2.2.2, bottom of page 12), says: Basing everything on <=> and its return type: This model has major advantages, some unique to this proposal compared to previous proposals for C++ and the capabilities of other languages: [...] (6) Efficiency, including finally achieving zero-overhead abstraction for comparisons: The vast majority of comparisons are always single-pass. The only exception is generated <= and >= in the case of

Why does same_as concept check type equality twice?

為{幸葍}努か 提交于 2019-12-03 23:52:34
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 redundant? Interesting question. I have recently watched Andrew Sutton's talk on Concepts, and in the Q