language-lawyer

问题 Is a C++11-compliant compiler allowed to optimize/transform this code from: bool x = true; // *not* an atomic type, but suppose bool can be read/written atomically /*...*/ { while (x); // spins until another thread changes the value of x } to anything equivalent to an infinite loop: { while (true); // infinite loop } The above conversion is certainly valid from the point of view of a single-thread program, but this is not the general case. Also, was that optimization allowed in pre-C++11? 回答1

问题 class A{ public: A(){}; }; class B : public A{ public: using A::A; B(const B&) = default; B( B&&) = default; }; B b; The compiler (g++ (5.4.0-6ubuntu1) / c++11) says "no matching function for call to B::B()" and lists the copy and move constructors as candidates. If I comment those defaulted ones out then it compiles. What causes this? And what difference does it make that they are explicitly defaulted? If those 2 lines weren't there they would be defaulted anyway. 回答1: Before C++17, the

问题 Is the following defined behavior in C11 and C++11 1 ? bool has4() { char buf[10] = {0, 1, 2, 4}; return memchr(buf, 4, 20); } Here we pass a too-long length to memchr . The array has 10 elements but we pass 20. The element we are searching for, however, is always found before the end. It is clear to me if this is legal. If this is allowed, it would limit implementation flexibility, since the implementation cannot rely on the size being a valid indication of the size of the accessible memory

问题 Is it legal to invoke a variadic macro M with no arguments for its variadic parameter? The relevant standard quote is [cpp.replace]/4 : If the identifier-list in the macro definition does not end with an ellipsis, the number of arguments (including those arguments consisting of no preprocessing tokens) in an invocation of a function-like macro shall equal the number of parameters in the macro definition. Otherwise, there shall be more arguments in the invocation than there are parameters in

问题 Consider this program: #include <stdio.h> int main(void) { int x; while ( 1 == scanf("%d", &x) ) printf("%c\n", "hello"[x]); } The compiler must compile this successfully because the program has no UB so long as the user does not enter any numbers outside the range 0 - 4 . However, according to this thread UB can travel back in time. Now consider this program: int main(void) { printf("hello\n"); "hello"[6]; } Any invocation of this program results in undefined behaviour, and since that can

问题 I try to create template alias which cannot be distinguished from original. So, I create traits to check when 2 templates (not types) are equal: template <template <class...> class C1, template <class...> class C2> struct is_same_template : std::false_type {}; template <template <class...> class C1> struct is_same_template<C1, C1> : std::true_type {}; Now test it: // Expected alias template <typename ... Ts> using V_Ts = std::vector<Ts...>; // Variadic // Fallback alias template <typename T,

问题 My understanding of the semantics of volatile in C and C++ is that it turns memory access into (observable) side effects. Whenever reading or writing to a memory mapped file (or shared memory) I would expect the the pointer to be volatile qualified, to indicate that this is in fact I/O. (John Regehr wrote a very good article on the semantics of volatile ). Furthermore, I would expect using functions like memcpy() to access shared memory to be incorrect, since the signature suggests the

问题 The following code triggers a static assertion on libstdc++: #include <utility> using t = decltype(std::declval<const void>); Should it? Motivation for this question: The following declval implementation proposed by Eric Niebler (which is apparently a compile time optimization) template<typename _Tp, typename _Up = _Tp&&> _Up __declval(int); template<typename _Tp> _Tp __declval(long); template<typename _Tp> auto declval() noexcept -> decltype(__declval<_Tp>(0)); would be questionable if a

问题 Before you start to mark this as duplicate I've already read this .But It doesn't answer my question. The linked question talks about C++98 & C++03 but my question is about defaulted constructor introduced by C++11. Consider following program (See live demo here): #include <iostream> struct Test { int s; float m; Test(int a,float b) : s(a),m(b) { } Test()=default; }t; int main() { std::cout<<t.s<<'\n'; std::cout<<t.m<<'\n'; } My question is that is the defaulted constructor provided by

问题 If you use extern C it with C++ files, does that allow defined C behavior that is undefined in C++? blah.h extern "C" { struct x { int blah; char buf[]; }; char * get_buf(struct x * base); struct x * make_struct(int blah, int size); } some_random.cpp #include "blah.h" ... x * data=make_struct(7, 12); std::strcpy(get_buf(data), "hello"); Is using the defined behavior in C's flexible array member, defined behavior when used this way? 回答1: Flexible array members are a standard feature of C,