c++20

问题 I've been following up C++ standardization and came across C++ modules idea. I could not find a good article on it. What exactly is it about? 回答1: Motivation The simplistic answer is that a C++ module is like a header that is also a translation unit . It is like a header in that you can use it (with import , which is a new contextual keyword) to gain access to declarations from a library. Because it is a translation unit (or several for a complicated module), it is compiled separately and

问题 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? 回答1: 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

问题 Context While I was reading Consistent comparison, I have noticed a peculiar usage of the verb to compare : There’s a new three-way comparison operator, <=>. The expression a <=> b returns an object that compares <0 if a < b, compares >0 if a > b, and compares ==0 if a and b are equal/equivalent. Another example found on the internet (emphasis mine): It returns a value that compares less than zero on failure. Otherwise, the returned value can be used as the first argument on a later call to

问题 [temp.concept]/5 says: A concept is not instantiated ([temp.spec]). [ Note: An id-expression that denotes a concept specialization is evaluated as an expression ([expr.prim.id]). [...]] Does it mean that this rule bellow ([temp.point]/8) does not apply? If two different points of instantiation give a template specialization different meanings according to the one-definition rule, the program is ill-formed, no diagnostic required. For example if this rule does not apply, this code bellow is

问题 I was reading the cppreference page on Constraints and noticed this example: // example constraint from the standard library (ranges TS) template <class T, class U = T> concept bool Swappable = requires(T t, U u) { swap(std::forward<T>(t), std::forward<U>(u)); swap(std::forward<U>(u), std::forward<T>(t)); }; I'm puzzled why they're using std::forward . Some attempt to support reference types in the template parameters? Don't we want to call swap with lvalues, and wouldn't the forward

问题 TL;DR Is there a Shorter syntax for the enum class type argument to a member function ( field_inst.write(decltype(field_inst)::Type::cpr1_4096); ) in the following code? namespace Hal { // complex template definition `Bit_Field` template< class Tregister, typename Tregister::Data Toffset, typename Tregister::Data Tmask, class Tfield_type, class Tmutability_policy = typename Tregister::Mutability_Policy > struct Bit_Field : Tregister { using Type = Tfield_type; static Field read() { // ...

问题 I'm writing some code that handles cryptographic secrets, and I've created a custom ZeroedMemory implementation of std::pmr::memory_resource which handles sanitizes memory on deallocation and encapsulates using the magic you have to use to prevent optimizing compilers from eliding away the operation. The idea was to avoid specializing std::array , because the lack of a virtual destructor means that destruction after type erasure would cause memory to be freed without being sanitized.

问题 I'm curious about the chapter "atomic constraints" https://en.cppreference.com/w/cpp/language/constraints it says The type of E after substitution must be exactly bool. No conversion is permitted and f(0); // error: S<int>{} does not have type bool when checking #1, // even though #2 is a better match ouch. which means there is no SFINAE mecanism when working with require clauses ? Isn't it a bummer ? Because I can see how some template types can result in bool after going through the

问题 Do the C++20 's strict aliasing rules [basic.lval]/11 arbitrarily allow following... cast between char* and char8_t* string str = "string"; u8string u8str { (char8_t*) &*str.data() }; // c++20 u8string u8string u8str2 = u8"zß水🍌" string str2 { (char*) u8str2.data() }; cast between uint32_t* , uint_least32_t* and char32_t* vector<uint32_t> ui32vec = { 0x007a, 0x00df, 0x6c34, 0x0001f34c }; u32string u32str { (char32_t*) &*ui32vec.data(), ui32vec.size() }; u32string u32str2 = U"zß水🍌" vector

问题 A previous question has asked for how to cast between integer types and GLvoid* in C++11 (based on the tags for that question) but here I'm interested in C++20. Now that there is std::bit_cast as an option for doing type conversion, I'm wondering if it would be the "correct" way to use integers with OpenGL functions that for historical reasons take a GLvoid* to represent a byte offset (e.g. glDrawRangeElements), or whether the methods referenced at the previous question should be used instead