language-lawyer

case of template member function specialization that compiles on msvc, not others

谁都会走 提交于 2019-12-24 16:22:24
问题 [ EDIT ] I changed the title from works to compiles since it turns out that it doesn't truly work after all (thanks @bogdan for the comments). I added code at the end of the post showing why and how. The second part of the question still stands - is there a way to " fix " it? The crux of the matter is having a virtual function Observe in a base template<int N> class X be rerouted to a templated function Observe<N> in classes derived from X<N> , without requiring any supporting code in X . For

Why does declaration of the same name inside the same declarative region is denied?

此生再无相见时 提交于 2019-12-24 13:16:33
问题 The following code does not compile: #include <iostream> #include <stdio.h> int a=5; char a='a'; int main(){ std::cout << a;} It is because: test.cpp:5:6: error: conflicting declaration ‘char a’ test.cpp:4:5: error: ‘a’ has a previous declaration as ‘int a’ But where does this restriction specified in the standard? I can't find it. Please give me a reference. 回答1: This is a simple violation of the One Definition Rule (ODR). See n3797 S3.2/1. No translation unit shall contain more than one

Are conformant array parameters VLAs?

江枫思渺然 提交于 2019-12-24 10:39:41
问题 CERT's Secure Coding Standard includes an item (API05-C) which encourages the use of conformant array parameters, which is a recommendation I've implemented in a lot of my code (hidden behind a macro for compilers which don't support them). For those who don't know, a conformant array parameter is something like: void foo(int length, char data[length]); API05-C provides more information. Lots of compilers don't like variable-length arrays (for good reason). C11 demotes them from required (as

Will I be able to declare a constexpr lambda inside a template parameter?

萝らか妹 提交于 2019-12-24 09:29:36
问题 I know it's like opening the Pandora box but it doesn't stop bothering me. Consider a simple example: #include <type_traits> template <auto> struct Foo: std::false_type { }; template <> struct Foo<[](){return 1;}()>:std::true_type { }; int main() { static_assert(Foo<1>::value); } I know lambdas cannot be declared inside unevaluated context, but obviously this is not the case here. What is even more weird clang 5.0.0 (which, I guess, first partially supports constexpr lambda) does compile it.

Implicit function-pointer conversions

删除回忆录丶 提交于 2019-12-24 08:57:40
问题 Empirically on tcc, gcc, and clang, a pointer to an old-style function returning RetTp and a pointer to any prototyped function returning RetTp are mutually implicitly convertible to each other: //compiles without warnings typedef void RetTp; RetTp oldfn(){}; RetTp newfn(int X){}; RetTp (*oldfnp)() = newfn; RetTp (*newfnp)(int X) = oldfn; Is there anything in the C standard that guarantees such behavior or is it just an extension? 回答1: The implicitness of the conversion is guaranteed. 6.5.16

Understanding partial specialization of inherited nested class templates

谁都会走 提交于 2019-12-24 07:46:00
问题 This question is connected to a previous Q&A in which a bug report for gcc was mentioned (supposedly fixed in gcc 4.5.0) and concerns some peculiarities for partial specialization of nested class template. My setup is that I have a class Base with a nested class template Inner that is partially specialized for char (using the dummy parameter trick, because explicit speciliaztion is not allowed in-class). #include <type_traits> #include <iostream> #include <ios> struct Base { // dummy template

g++ and clang++ are both bugged with template function parameter pack expansion?

只谈情不闲聊 提交于 2019-12-24 05:32:35
问题 This is a follows up of another question where an answer point my attention to Templates [temp.param] 17.1.17 (last C++17 draft, but I suppose also preceding standardizations) where is stated that A template parameter pack that is a pack expansion shall not expand a parameter pack declared in the same template-parameter-list. with an example of this limitation template <class... T, T... Values> // error: Values expands template type parameter struct static_array; // pack T within the same

Why is this initializer_list constructor a viable overload?

一曲冷凌霜 提交于 2019-12-24 05:12:31
问题 #include <iostream> #include <string> #include <initializer_list> class A { public: A(int, bool) { std::cout << __PRETTY_FUNCTION__ << std::endl; } A(int, double) { std::cout << __PRETTY_FUNCTION__ << std::endl; } A(std::initializer_list<int>) { std::cout << __PRETTY_FUNCTION__ << std::endl; } }; int main() { A a1 = {1, 1.0}; return 0; } (This question is a follow-up to this.) The above program fails to compile with clang35 -std=c++11 init.cpp:15:14: error: type 'double' cannot be narrowed to

Why is this initializer_list constructor a viable overload?

笑着哭i 提交于 2019-12-24 05:12:06
问题 #include <iostream> #include <string> #include <initializer_list> class A { public: A(int, bool) { std::cout << __PRETTY_FUNCTION__ << std::endl; } A(int, double) { std::cout << __PRETTY_FUNCTION__ << std::endl; } A(std::initializer_list<int>) { std::cout << __PRETTY_FUNCTION__ << std::endl; } }; int main() { A a1 = {1, 1.0}; return 0; } (This question is a follow-up to this.) The above program fails to compile with clang35 -std=c++11 init.cpp:15:14: error: type 'double' cannot be narrowed to

How do bit fields interplay with bits padding in C

北城余情 提交于 2019-12-24 04:09:39
问题 I have two questions concerning bit fields when there are padding bits. Say I have a struct defined as struct T { unsigned int x: 1; unsigned int y: 1; }; Struct T only has two bits actually used. Question 1: are these two bits always the least significant bits of the underlying unsigned int? Or it is platform dependent? Question 2: Are those unused 30 bits always initialized to 0? What does the C standard say about it? 回答1: Question 1: are these two bits always the least significant bits of