language-lawyer

问题 #include <set> #include <string> #include <cassert> using namespace std::literals; int main() { auto coll = std::set{ "hello"s }; auto s = "hello"s; coll.insert(std::move(s)); assert("hello"s == s); // Always OK? } Does the C++ standard guarantee that a failed insertion into an associative container will not modify the rvalue-reference argument? 回答1: Explicit and unequivocal NO . Standard doesn't have this guarantee, and this is why try_emplace exists. See notes: Unlike insert or emplace,

问题 #include <set> #include <string> #include <cassert> using namespace std::literals; int main() { auto coll = std::set{ "hello"s }; auto s = "hello"s; coll.insert(std::move(s)); assert("hello"s == s); // Always OK? } Does the C++ standard guarantee that a failed insertion into an associative container will not modify the rvalue-reference argument? 回答1: Explicit and unequivocal NO . Standard doesn't have this guarantee, and this is why try_emplace exists. See notes: Unlike insert or emplace,

问题 Following the question titled Warning generated due wrong strcmp parameter handling, there seems to be some questions regarding what the Standard actually guarantees regarding value representation of character types. THE QUESTION This looks fine, but does the Standard guarantee that the (1) will always yield true ? char unsigned * p1 = ...; char * p2 = reinterpret_cast<char *> (p1); *p1 == *p2; // (1) 回答1: THIS MIGHT SURPRISE YOU, but there's no such guarantee in the C++11 Standard (N3337),

问题 Bitwise operators ( ~ , & , | and ^ ) operate on the bitwise representation of their promoted operands. Can such operations cause undefined behavior? For example, the ~ operator is defined this way in the C Standard: 6.5.3.3 Unary arithmetic operators The result of the ~ operator is the bitwise complement of its (promoted) operand (that is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set). The integer promotions are performed on the

问题 In C one can allocate dynamic arrays using malloc(sizeof(T) * N) and then use pointer arithmetic to get elements at i offset in this dynamic array. In C++ one can do similar using operator new() in the same way as malloc() and then placement new (for an example one can see solution for item 13 in a book "Exceptional C++: 47 engineering puzzles, programming problems, and solutions" by Herb Sutter). If you don't have one, the summary of the solution for this question would be: T* storage =

问题 In the C++ standard draft (N3485), it states the following: 20.7.1.2.4 unique_ptr observers [unique.ptr.single.observers] typename add_lvalue_reference<T>::type operator*() const; 1 Requires: get() != nullptr. 2 Returns: *get(). pointer operator->() const noexcept; 3 Requires: get() != nullptr. 4 Returns: get(). 5 Note: use typically requires that T be a complete type. You can see that operator* (dereference) is not specified as noexcept , probably because it can cause a segfault, but then

问题 This question already has answers here : Why is the gets function so dangerous that it should not be used? (11 answers) Closed 2 years ago . The declaration of gets is: char * gets ( char * str ); Note the glaring omission of a maximum size for str . cplusplus.com says 2 : Notice that gets is quite different from fgets: not only gets uses stdin as source, but it does not include the ending newline character in the resulting string and does not allow to specify a maximum size for str ( which

问题 I have come across some code which has horrified me. Essentially it follows this pattern : class Foo { public: //default constructor Foo(): x(0), ptr(nullptr) { //do nothing } //more interesting constructor Foo( FooInitialiser& init): x(0), ptr(nullptr) { x = init.getX(); ptr = new int; } ~Foo() { delete ptr; } private: int x; int* ptr; }; void someFunction( FooInitialiser initialiser ) { int numFoos = MAGIC_NUMBER; Foo* fooArray = new Foo[numFoos]; //allocate an array of default constructed

问题 I have come across some code which has horrified me. Essentially it follows this pattern : class Foo { public: //default constructor Foo(): x(0), ptr(nullptr) { //do nothing } //more interesting constructor Foo( FooInitialiser& init): x(0), ptr(nullptr) { x = init.getX(); ptr = new int; } ~Foo() { delete ptr; } private: int x; int* ptr; }; void someFunction( FooInitialiser initialiser ) { int numFoos = MAGIC_NUMBER; Foo* fooArray = new Foo[numFoos]; //allocate an array of default constructed

问题 I don't understand this: 3.8/1 "The lifetime of an object of type T ends when: — if T is a class type with a non-trivial destructor (12.4), the destructor call starts , or — the storage which the object occupies is reused or released." If the lifetime ends before the destructor starts, doesn't that mean accessing members in the destructor is undefined behavior? I saw this quote too: 12.7 "For an object with a non-trivial destructor, referring to any non-static member or base class of the