Essentially there is special wording all around the c++17 draft standard that gives std::byte the same properties with regard to aliasing as char and unsigned char. To give you an example, the the C++17 standard, [basic.lval] p8 states: If a program attempts to access the stored value of an object through a glvalue of other … Read more
From the current Standard draft ([basic.types.general]/2): For any object (other than a potentially-overlapping subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes ([intro.memory]) making up the object can be copied into an array of char, unsigned char, or std::byte ([cstddef.syn]). If the content … Read more
I posted this in the cpplang slack, and Casey Carter responded: The description of the algorithm in the standard is defective. The intent is to determine [if] every element in the needle appears in order in the haystack. [The algorithm it actually performs is:] “Returns true if the intersection of sorted sequences R1 and R2 … Read more
[variant.visit] in C++17 doesn’t use variant_size_v, but it does in the current working draft as a result of an editorial change. I don’t see any indication that LWG reviewed the change before it went in, but it has looked at this part of the standard several times since then and has yet to object to … Read more
Yes. The problem with std::string_view is that it doesn’t remember if it points to a null-terminated string or not. If you’re writing a wrapper for a C api that uses null-terminated strings, you would have to constantly copy your std::string_views into std::strings to make sure you have null-terminators.
There are a number of differences. Some were, I believe, Boost changes that were never propagated. For example, there is no path.filename_is_dot() query (as discussed below, it would be less useful in std::filesystem anyway). There was also a good bit of late-breaking news on this front: Support for non-POSIX-like filesystems: Specify whether a string is … Read more
The standard doesn’t say much about the discarded statement of an if constexpr. There are essentially two statements in [stmt.if] about these: In an enclosing template discarded statements are not instantiated. Names referenced from a discarded statement are not required ODR to be defined. Neither of these applies to your use: the compilers are correct … Read more
This syntax is slightly different. First, because types are easier to work with than packs, a type that holds a pack. The using type=types; just saves me work in the code that generates a types: template<class…>struct types{using type=types;}; Here is the workhorse. It takes a signature, and produces a types<?…> bundle containing the arguments for … Read more
It’s because you declare b to be a pointer, and initialize it to be a null pointer. But a null pointer to what type of data you don’t say, so the compiler can’t deduce the type. If you want b to be a std::nullptr_t object, you should drop the asterisk: auto b{nullptr};
Update a few years later: My answer here may be a cool answer, but this is the correct one. That is how I would solve this problem today. We could take advantage of the fact that index() almost already does the right thing. We can’t arbitrarily create instances of various types – we wouldn’t know … Read more