language-lawyer

问题 In cppref, the following holds until C++17: code such as f(std::shared_ptr<int>(new int(42)), g()) can cause a memory leak if g gets called after new int(42) and throws an exception, while f(std::make_shared<int>(42), g()) is safe, since two function calls are never interleaved. I'm wondering which change introduced in C++17 renders this no longer applicable. 回答1: The evaluation order of function arguments are changed by P0400R0. Before the change, evaluation of function arguments are

问题 I was confused when this wouldn't compile in C: int main() { for (int i = 0; i < 4; ++i) int a = 5; // A dependent statement may not be declaration return 0; } I'm used to C++ where this will compile. I just stared dumbfounded for a while until I remembered an answer here on SO about how in C and C++ different things are considered "statements". This was in regard to a switch statement. A "statement" after the for loop brackets must be present both in C and C++. This can be done in both

问题 This question already has an answer here : Why do gcc and clang allow me to construct an abstract class? (1 answer) Closed 3 years ago . I would like to understand why the compiler allows the following code to compile #include <iostream> struct A { A() { std::cout << "A::A\n"; } virtual void f() const = 0; }; void g(const A& a) { a.f(); } int main() { g({}); } It even outputs A::A when run. If I replace g({}) with g(A()) it obviously doesn't compile. It complains that A is abstract and cannot

问题 I couldn't find an answer to this anywhere. I just read K&R and saw them calling a function pointer like this: (*ptr)(arg1, arg2); I vividly remember, however, to have seen someone using them like this: ptr(arg1, arg2); That might have been in C++, though. How are the rules? Do they differ in C and C++? 回答1: TL;DR The rules in C and C++ are the same, there's no difference between the two. What does the C++ Standard (n3797) say? 5.2.2p1 Function call [expr.call] A function call is a postfix

问题 Suppose I have a base class with some member variables and no virtual functions: class Base { int member; }; and a derived class that derives in a non-virtual way from Base and has no new member variables an again no virtual functions: class Derived : Base { }; Obviously sizeof(Derived) can't be smaller than sizeof(Base) . Is sizeof(Derived) required to be equal to sizeof(Base) ? 回答1: From 5.3.2 [expr.sizeof] When applied to a class, the result [of sizeof ] is the number of bytes in an object

问题 For example, the following code piece compiles with gcc-4.9 and clang-602 class Base { public: static void foo() {} void badfoo(int i) {} }; template <typename T> class Derived : public Base { public: void bar() { Base::foo(); } void badbar() { Base::badfoo(); } // compiles ok //static void badbar() { Base::badfoo(); } // compile error //void worsebar() { Base::nonexist(); } // compile error }; int main() { return 0; } But the commented out lines won't compile. My questions are: Why badbar()

问题 As of last Saturday... This afternoon in Bristol, UK, the ISO C++ standards committee adopted generic lambdas, dynamic arrays (an improved version of C99 VLAs), variable templates, reader/writer locks, make_unique, optional, standard library user-defined literals, and a number of other language and library improvements – and approved the result as the feature-complete Committee Draft (CD) of Standard C++14 to be distributed for its primary international review ballot. I'm interested reading

问题 First, I want to say, according to cppreference.com, it is somewhat impossible to value-initialize an enum. According to http://en.cppreference.com/w/cpp/language/value_initialization, value-initializing an enum actually performs zero-initialization. It then follows that, according to http://en.cppreference.com/w/cpp/language/zero_initialization, the effect of zero-initializing an enum is: If T is a scalar type, the object's initial value is the integral constant zero implicitly converted to

问题 This (note the comma operator ): #include <iostream> int main() { int x; x = 2, 3; std::cout << x << "\n"; return 0; } outputs 2 . However, if you use return with the comma operator, this: #include <iostream> int f() { return 2, 3; } int main() { int x; x = f(); std::cout << x << "\n"; return 0; } outputs 3 . Why is the comma operator behaving differently with return ? 回答1: According to the Operator Precedence, comma operator has lower precedence than operator= , so x = 2,3; is equivalent to

问题 I frequently use a technique I call the "lazy man's enable_if ," where I use decltype and the comma operator to enable a function based on some template input. Here is a small example: template <typename F> auto foo(F&& f) -> decltype(f(0), void()) { std::cout << "1" << std::endl; } template <typename F> auto foo(F&& f) -> decltype(f(0, 1), void()) { std::cout << "2" << std::endl; } With --std=c++11 , g++ 4.7+ and Clang 3.5+ happily compile that bit of code (and it works as I would expect).