language-lawyer

问题 Another "who's right between g++ and clang++?" This time I'm convinced it's a g++ bug, but I ask for a confirm from standard gurus. Given the following code template <template <auto...> class Cnt, typename ... Types, Types ... Vals> void foo (Cnt<Vals...>) { } template <auto ...> struct bar { }; int main () { foo(bar<0, 1>{}); // compile both foo(bar<0, 1L>{}); // only clang++ compile; error from g++ } Live demo clang++ (8.0.0, by example) compile and link without problem where g++ (9.2.0, by

问题 The following code which doesn't compile under clang but does under gcc and VS: template<typename T> class bar; namespace NS { template<typename T> class foo { foo() {} template<typename U> friend class bar; }; } template<typename R> class bar { public: bar() { NS::foo<int> f; } }; int main(int, char **) { bar<int> b; return 0; } It fails with: main.cpp:20:22: error: calling a private constructor of class 'NS::foo<int>' NS::foo<int> f; ^ main.cpp:8:9: note: implicitly declared private here

问题 (Note: this question was motivated by trying to come up with preprocessor hackery to generate a no-op allocation to answer this other question: Macro that accept new object ...so bear that in mind!) Here's a contrived class: class foo { private: int bar; public: foo(int bar) : bar (bar) { std::cout << "construct foo #" << bar << std::endl; } ~foo() { std::cout << "destruct foo #" << bar << std::endl; } }; ...which I will allocate like this: // Note: for alignment, don't use char* buffer with

问题 The following code which doesn't compile under clang but does under gcc and VS: template<typename T> class bar; namespace NS { template<typename T> class foo { foo() {} template<typename U> friend class bar; }; } template<typename R> class bar { public: bar() { NS::foo<int> f; } }; int main(int, char **) { bar<int> b; return 0; } It fails with: main.cpp:20:22: error: calling a private constructor of class 'NS::foo<int>' NS::foo<int> f; ^ main.cpp:8:9: note: implicitly declared private here

问题 I am trying to better understand a rather surprising discovery regarding unions and the common initial sequence rule. The common initial sequence rule says (class.mem 23):  In a standard-layout union with an active member of struct type T1, it is permitted to read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated. So, given: struct A { int a;

问题 Consider the following code snippet: union { int a; float b; }; a = /* ... */; b = a; // is this UB? b = b + something; Is the assignment of one union member to another valid? 回答1: Unfortunately I believe the answer to this question is that this operation on unions is under specified in C++, although self assignment is perfectly ok. Self assignment is well defined behavior, if we look at the draft C++ standard section 1.9 Program execution paragraph 15 has the following examples: void f(int,

问题 The Standard specifies that hexadecimal constants like 0x8000 (larger than fits in a signed integer) are unsigned (just like octal constants), whereas decimal constants like 32768 are signed long. (The exact types assume a 16-bit integer and a 32-bit long.) However, in regular C environments both will have the same representation, in binary 1000 0000 0000 0000 . Is a situation possible where this difference really produces a different outcome? In other words, is a situation possible where

问题 I have the following code: #include <iostream> class A; int main() { std::cout << std::is_constructible<A>::value << std::endl; } When I use GCC 8.3, this code compiles. However, when I use Clang 8.0, I get a compilation error that incomplete types cannot be used in type traits. Which one is correct? Am I allowed to use is_constructible on an incomplete type (with an expected value of false ), or am I not allowed to? 回答1: The behavior is undefined. [meta.unary.prop] template <class T, class..

问题 For subtraction of pointers i and j to elements of the same array object the note in [expr.add#5] reads: [  Note: If the value i−j is not in the range of representable values of type std​::​ptrdiff_­t , the behavior is undefined. —  end note ] But given [support.types.layout#2], which states that ( emphasis mine): The type ptrdiff_­t is an implementation-defined signed integer type that can hold the difference of two subscripts in an array object, as described in [expr.add]. Is it even

问题 C++14 has rules for what you can and can't do in a constexpr function. Some of them (no asm , no static variables) seem pretty reasonable. But the Standard also disallows goto in constexpr functions, even while it allows other control flow mechanisms. What's the reasoning behind this distinction? I thought we were past " goto is hard for compilers ". 回答1: My understanding is there was a desire to get relaxed constexpr semantics in C++14. A lot of the restrictions that were relaxed were