language-lawyer

问题 I was under the impression that while dereferencing pointers that don't point to a valid object is UB, simply computing such pointers is fine. However, if I'm understanding expr.add[4] correctly, that's not the case. So which of these pointer computations are well-defined? int a = 42; int *p = &a; p; // valid, and obviously ok p++; // invalid, but ok, because one past the end of 'array' containing 1 element? p++; // UB ? How about this case? int *p = nullptr; p; // invalid, and obviously ok

问题 This question already has answers here : Is const-casting away const-ness of references to actual const objects permitted if they are never modified through them? (2 answers) Const casting empty base class (1 answer) Closed 10 days ago . Code speaks more than thousand words, so... This is undefined behaviour for mutating a const int : struct foo { int x; void modify() { x = 3; } }; void test_foo(const foo& f) { const_cast<foo&>(f).modify(); } int main(){ const foo f{2}; test_foo(f); } What

问题 This answer raised the following question. Suppose we have a simple struct S { int& i; } Internally (in GCC and Clang, at least) S contains just a pointer to an int , and static_assert(sizeof(int*) == 8); static_assert(sizeof(S) == 8); Does S have a unique object representation? GCC and Clang disagree *: static_assert( std::has_unique_object_representations_v<int*>); static_assert(!std::has_unique_object_representations_v<S>); // GCC static_assert( std::has_unique_object_representations_v<S>)

问题 This answer raised the following question. Suppose we have a simple struct S { int& i; } Internally (in GCC and Clang, at least) S contains just a pointer to an int , and static_assert(sizeof(int*) == 8); static_assert(sizeof(S) == 8); Does S have a unique object representation? GCC and Clang disagree *: static_assert( std::has_unique_object_representations_v<int*>); static_assert(!std::has_unique_object_representations_v<S>); // GCC static_assert( std::has_unique_object_representations_v<S>)

问题 Why does emplace_back take a reference of the member that requires a definition? What is the difference between emplace_back(integer literal) and emplace_back(static constexpr integer member) ? If I switch to C++17, it compiles fine. I found that in C++17 static constexpr data members are implicitly inlined. Does it mean the compiler implicitly creates a definition for them? Example code: class base { int n; public: base(int n):n(n) {} }; struct base_trait { static constexpr int n = 1; }; int

问题 I have an abstract class that declares const and non-const member functions. For the sake of discussion let's say it looks like this: class record_interface { public: virtual ~record_interface() = default; virtual void set_foo(BoundedFloat) = 0; virtual BoundedFloat get_foo() const = 0; }; This is used as a high-level representation of a record that has different representations when saved to disc and transferred via the wire. So most implementations just need to convert their members to the

问题 #include <iostream> struct A{ A(int){ } }; struct B{ B() = default; B(A){ } B(B const&){} B(B&&){} }; int main(){ B b({0}); } For the given codes, the candidate functions are: #1 B::B(A) #2 B::B(const B&) #3 B::B(B&&) According to the standard, for #1, the object of type A is copy-list-initialized by {0} as A a = {0} , A::A(int) is considered for the initialization, so only the standard conversion within #1. For #2, it's an initialization of a reference form braced-init-list which is the

问题 Let's say I have 2 TUs with 2 non-inline function definitions with external linkage which differ only in their return types. Which paragraph(s) my program violates? [basic.def.odr]/4 says: Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program outside of a discarded statement; no diagnostic required. But This paragraph says "that is odr-used" which may or may not be the case. How do I tell if I define the same non-inline

问题 According to the C++ standard (§30.7.5.2.4 of C++17 draft (N4659)), out << ch will not perform a widening operation on ch , if ch is a char and out is a std::ostream . Does this imply that std::ctype<char>::widen() (i.e., char -> char ) is guaranteed by the standard to be an identity function ( widen(ch) == ch ) for all characters in the basic source character set? If so, does this, in turn, imply that all locales are required by the standard to use the same non-wide (or multi-byte) encoding

问题 About how lookup the dependent name for template, The standard only gives a little sentence like this, there's no more: In resolving dependent names, names from the following sources are considered: Declarations that are visible at the point of definition of the template . Declarations from namespaces associated with the types of the function arguments both from the instantiation context ([temp.point]) and from the definition context. Consider the below code struct Test{ using type = int; };