structured bindings do not decay.
i.e
struct S {
const char x[6];
const char y[3];
};
S s1{};
auto [a, b] = s1; // a and b get the exact member types
the type of
a still is const char[6].
This is different from initializing a new object with auto, where types decay:
auto a2 = a; // a2 gets decayed type of a
std::decay
MyStruct ms = { 42, "Jim" };
auto&& [v,n] = std::move(ms);
此時 anonymous entity r-value reference to ms.
v,n r-value reference to anonymous entity.
We can also capture as a forwarding reference using auto&&.
That is, auto&& will resolve to auto& for lvalue references, and auto&& for rvalue references.
MyStruct ms = { 42, "Jim" };
auto [v,n] = std::move(ms); // new entity with moved-from values from ms
此時 anonymous entity 由 move constructor construct from ms.
也就是 ms 的內容已經 invalidate.
Note that there is only limited usage of inheritance possible.
All non-static data members must be members of the same class definition.
struct B {
int a = 1;
int b = 2;
};
struct D1 : B {
};
auto [x, y] = D1{}; // OK
struct D2 : B {
int c = 3;
};
auto [i, j, k] = D2{}; // Compile-Time ERROR
std::pair
std::tuple
std::array
array:
std::array<int,4> getArray();
auto [i,j,k,l] = getArray();
tuple:
std::tuple<char,float,std::string> getTuple();
auto [a,b,c] = getTuple();
pair:
std::map<std::string, int> coll;
...
auto [pos,ok] = coll.insert({"new",42});
if (!ok) {
// if insert failed, handle error using iterator pos:
...
}
or
if (auto [pos,ok] = coll.insert({"new",42}); !ok) {
// if insert failed, handle error using iterator pos:
const auto& [key,val] = *pos;
std::cout << "already there: " << key << ’\n’;
}
Aggregate Extensions
struct Data {
std::string name;
double value;
};
Data x{"test1", 6.778};
struct MoreData : Data {
bool done;
};
MoreData y{{"test1", 6.778}, false};
struct Data {
const char* name;
double value;
};
struct PData : Data {
bool critical;
void print() const {
std::cout << ’[’ << name << ’,’ << value << "]\n";
}
};
PData y{{"test1", 6.778}, false};
y.print();
PData a{}; // zero-initialize all elements
PData b{{"msg"}}; // same as {{"msg",0.0},false}
PData c{{}, true}; // same as {{nullptr,0.0},true}
PData d; // values of fundamental types are unspecified
template<typename T>
struct D : std::string, std::complex<T>
{
std::string data;
};
D<float> s{{"hello"}, {4.5,6.7}, "world"}; // OK since C++17
std::cout << s.data; // outputs: ”world”
std::cout << static_cast<std::string>(s); // outputs: ”hello”
std::cout << static_cast<std::complex<float>>(s); // outputs: (4.5,6.7)
Definition of Aggregates
- either an array
- or a class type (class, struct, or union) with:
- no user-declared or explicit constructor
- no constructor inherited by a using declaration
- no private or protected non-static data members
- no virtual functions
- no virtual, private, or protected base classes
To be able to use an aggregate it is also required that
- no private or
- protected base class members
- or constructors
are used during initialization.
is_aggregate<>
struct Derived;
struct Base {
friend struct Derived;
private:
Base() {
}
};
struct Derived : Base {
};
int main()
{
Derived d1{}; // ERROR since C++17
Derived d2; // still OK (but might not initialize)
}
Before C++17, Derived was not an aggregate. Thus,
Derived d1{};
was calling the implicitly defined default constructor of Derived, which by default called the default constructor of the base class Base.
Although the default constructor of the base class is private, it was valid to be called as via the default constructor of the derived class, because the derived class was defined to be a friend class.
Since C++17, Derived in this example is an aggregate, not having an implicit default constructor
at all (
the constructor is not inherited by a using declaration).
So the initialization is an aggregate initialization, for which it is not allowed to call private constructors of bases classes. Whether the base class is a friend doesn't matter.
RVO
class MyClass
{
public:
...
// no copy/move constructor defined:
MyClass(const MyClass&) = delete;
MyClass(MyClass&&) = delete;
...
};
// Works even no copy constructor
void foo(MyClass param) {}
// Works even no copy constructor
MyClass bar() {
return MyClass();
}
NRVO
Copy/move constructor still needs to be around.
MyClass foo()
{
MyClass obj;
...
return obj; // still requires copy/move support
}
-
MyClass bar(MyClass obj) // copy elision for passed temporaries
{
...
return obj; // still requires copy/move support
}
So, how this benefits us?
Any type that is
_not_ copyable can be used in a factory function
which return the type instance, which is not going to be copied!
#include <utility>
template <typename T, typename... Args>
T create(Args&&... args)
{
...
return T{std::forward<Args>(args)...};
}
int i = create<int>(42);
std::unique_ptr<int> up = create<std::unique_ptr<int>>(new int{42});
std::atomic<int> ai = create<std::atomic<int>>(42);
Also, any type with it's move constructor deleted, as in factory function,
we still can pass a r-value instance back.
class CopyOnly {
public:
CopyOnly() {
}
CopyOnly(int) {
}
CopyOnly(const CopyOnly&) = default;
CopyOnly(CopyOnly&&) = delete; // explicitly deleted
};
CopyOnly ret() {
return CopyOnly{}; // OK since C++17
}
CopyOnly x = 42; // OK since C++17
Value Categories
It's worth emphasizing that strictly speaking glvalues, prvalues, and xvalues are terms for expressions and not for values.
A variable itself is not an lvalue;
only an expression denoting the variable is an lvalue:
int x = 3; // x here is a variable, not an lvalue
int y = x; // x here is an lvalue
In the first statement 3 is a prvalue initializing the variable (not the lvalue) x.
In the second statement x is an lvalue (its evaluation designates an object containing the value 3).
The lvalue x is converted to a prvalue, which is what initializes the variable y.
The key approach to explain value categories now is that in general we have two kinds of expressions:
- glvalues: expressions for locations of objects or functions
- prvalues: expressions for initializations
An xvalue is then considered a special location, representing an object whose resources can be reused (usually because it is near the end of its lifetime).
C++17 then introduces a new term, called
materialization (of a temporary) for the moment a prvalue becomes a temporary object.
Thus, a temporary materialization conversion is a prvalue-to-xvalue conversion.
Lambda
It's constexpr iff it doesn't capture.
auto squared = [](auto val) {
// implicitly constexpr since C++17
return val*val;
};
std::array<int,squared(5)> a; // OK since C++17 => std::array<int,25>
auto squared2 = [](auto val) {
// implicitly constexpr since C++17
static int calls = 0;
// OK, but disables lambda for constexpr contexts
...
return val*val;
};
std::array<int,squared2(5)> a;
// ERROR: static variable in compile-time context
std::cout << squared2(5) << ’\n’; // OK
如何測試lambda expression 為constexpr?
將lambda expression 冠上constexpr，如果compile出錯，則非constexpr.
Evaluation Order
To fix all this unexpected behavior, for some operators the evaluation guarantees were refined so
that they now specify a guaranteed evaluation order:
For:
e1 [ e2 ]
e1 . e2
e1 .* e2
e1 ->* e2
e1 << e2
e1 >> e2
e1 is guaranteed to get evaluated before e2 now, so that the evaluation order is left to right.
However, note that the evaluation order of different arguments of the same function call is still undefined.
That is, in
e1.f(a1,a2,a3)
e1 is guaranteed to get evaluated before a1, a2, and a3 now. However, the evaluation order of a1,
a2, and a3 is still undefined.
In all assignment operators:
e2 = e1
e2 += e1
e2 *= e1
...
the right-hand side e1 is guaranteed to get evaluated before the left-hand side e2 now.
In new expressions like: (重要!)
new Type(e)
the allocation is now guaranteed to be performed before the evaluation e, and the initialization of the new value is guaranteed to happen before any usage of the allocated and initialized value.
Enum Initialization from Integral Values
For enumerations with a fixed underlying type, since C++17 you can use an
integral value of that type for direct list initialization.
This applies to unscoped enumerations with a specified type and all scoped enumerations, because they always have an underlying default type:
unscoped enum with underlying type
enum MyInt : char { };
MyInt i1{42}; // OK since C++17 (ERROR before C++17)
MyInt i2 = 42; // still ERROR
MyInt i3(42); // still ERROR
MyInt i4 = {42}; // still ERROR
scoped enum with default underlying type
enum class Salutation { mr, mrs };
Salutation s1{0}; // OK since C++17 (ERROR before C++17)
Salutation s2 = 0; // still ERROR
Salutation s3(0); // still ERROR
Salutation s4 = {0}; // still ERROR
The same applies if Salutation has a specified underlying type:
scoped enum with specified underlying type
enum class Salutation : char { mr, mrs };
Salutation s1{0}; // OK since C++17 (ERROR before C++17)
Salutation s2 = 0; // still ERROR
Salutation s3(0); // still ERROR
Salutation s4 = {0}; // still ERROR
For unscoped enumerations (enum without class) having no specified underlying type,
you still
can't use list initialization for numeric values
