language-lawyer

问题 This question already has an answer here : Template template parameter and default values [duplicate] (1 answer) Closed last year . While helping with problem noted in too many template parameters in template template argument a question arose in my head: which compiler is right about the compilation in this case: template <template <typename, typename> class Op> class Function { }; template <typename A, typename B, bool is_f = std::is_floating_point<A>::value || std::is_floating_point<B>:

问题 consider the following example program: #include <iostream> using namespace std; struct t { ~t() {cout << "destroyed\n"; } }; int main() { cout << "test\n"; t(), cout << "doing stuff\n"; cout << "end\n"; } The output I get with GCC 4.9.2 is: test doing stuff destroyed end cpp.sh link: http://cpp.sh/3cvm However according to cppreference about the comma operator: In a comma expression E1, E2, the expression E1 is evaluated, its result is discarded, and its side effects are completed before

问题 consider the following example program: #include <iostream> using namespace std; struct t { ~t() {cout << "destroyed\n"; } }; int main() { cout << "test\n"; t(), cout << "doing stuff\n"; cout << "end\n"; } The output I get with GCC 4.9.2 is: test doing stuff destroyed end cpp.sh link: http://cpp.sh/3cvm However according to cppreference about the comma operator: In a comma expression E1, E2, the expression E1 is evaluated, its result is discarded, and its side effects are completed before

问题 Here's a short example that reproduces this “no viable conversion” with lemon for clang but valid for g++ difference in compiler behavior. #include <iostream> struct A { int i; }; #ifndef UNSCREW_CLANG using cast_type = const A; #else using cast_type = A; #endif struct B { operator cast_type () const { return A{i}; } int i; }; int main () { A a{0}; B b{1}; #ifndef CLANG_WORKAROUND a = b; #else a = b.operator cast_type (); #endif std::cout << a.i << std::endl; return EXIT_SUCCESS; } live at

问题 Is it technically valid to use mismatched std::allocator specialization (surely, except its specialization for void ) as a template parameter for STL containers (not all of them, but enumerated below plus unordered_(multi)map/set)? Following code compiles fine. #include <list> #include <forward_list> #include <deque> #include <set> #include <map> int main() { struct A { bool operator < (A) const { return true; } }; struct B {}; struct C {}; std::list< A, std::allocator< C > > l; std::forward

问题 Based on this Question ( strange output issue in c) there was an Answer ( provided by @Lundin ) about this line: int *ptr = (int*)(&a+1); where he said: the cast (int*) was hiding this bug . So I came with the following: #include <stdio.h> int main( void ){ int a[5] = {1,2,3,4,5}; int *ptr = *( ( &a ) + 1 ); printf("%d", *(ptr-1) ); } I would like to know if this: int *ptr = *( ( &a ) + 1 ); Is well-defined by the Standard? EDIT : At some point @chux pointed to §6.3.2.3.7 which is: A pointer

问题 Is the following code valid? If so, what is the scope of x ? int main() { if (true) int x = 42; } My intuition says that there is no scope created by the if because no actual block ( {} ) follows it. 回答1: GCC 4.7.2 shows us that, while the code is valid , the scope of x is still simply the conditional. Scope This is due to: [C++11: 6.4/1]: [..] The substatement in a selection-statement (each substatement, in the else form of the if statement) implicitly defines a block scope. [..]

问题 Consider the following example: class X { public: X() = default; X(const X&) = default; X(X&&) = delete; }; X foo() { X result; return result; } int main() { foo(); } Clang and GCC disagree on whether this program is valid. GCC tries to call the move constructor when initializing the temporary during the call to foo() , which has been deleted leading to a compilation error. Clang handles this just fine, even with -fno-elide-constructors . Can anyone explain why GCC is allowed to call the move

问题 A Scala class's "companion object" can be viewed as a singleton object with the same fully qualified name as the class (i.e. same name, in same package). They are used to hold utility functions common to all instances of the class, as a replacement for Java's static methods. However, in various places in the docs and in questions, it say that companion objects must be defined in the same compilation unit. For example, they must be defined in the same file; companion objects cannot be defined

问题 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