Size: a a a

2021 February 22

A

Alex in pro.cxx
Вот у clang нормальный ворнинг
источник

CD

Constantine Drozdov in pro.cxx
Alex
ну как это, value - это функция
#include <utility>

int func();
static_assert(
   std::is_same_v<decltype(func), int()>
);
источник

A

Alex in pro.cxx
А хотя нет, это же только прототип функции
источник

A

Alex in pro.cxx
это не определение, поэтому value - не функция?
источник

CD

Constantine Drozdov in pro.cxx
Constantine Drozdov
#include <utility>

int func();
static_assert(
   std::is_same_v<decltype(func), int()>
);
вот этот пример вызывает какие-то вопросы?
заметьте, не int (*)() а int()
источник

A

Alex in pro.cxx
Заметил, поэтому и задумался)
источник

A

Alex in pro.cxx
typeid(int()).name() пишет int __cdecl(void), но это не помогает мне понять, почему GCC именно так формулирует ошибку.
источник

A

Alex in pro.cxx
ну и возникает вопрос, зачем в этом контексте вообще разрешается писать int() вместо int (*)()
источник

CD

Constantine Drozdov in pro.cxx
Alex
typeid(int()).name() пишет int __cdecl(void), но это не помогает мне понять, почему GCC именно так формулирует ошибку.
а какая ошибка будет в примере выше, если написать func.data?
источник

CD

Constantine Drozdov in pro.cxx
Alex
ну и возникает вопрос, зачем в этом контексте вообще разрешается писать int() вместо int (*)()
для int(*)() это static assertion failed
источник

A

Alex in pro.cxx
Constantine Drozdov
для int(*)() это static assertion failed
Вот так у GCC нормальное сообщение: error: request for member 'data' in 'func', which is of non-class type 'int()'
источник

A

Alex in pro.cxx
зато у MSVC их любимое бесполезное сообщение left of .data is not not a struct/class/union type
источник

A

Alex in pro.cxx
промахнулся с цитированием, это для func.data
источник

SE

Stanislav Ershov in pro.cxx
Alex
зато у MSVC их любимое бесполезное сообщение left of .data is not not a struct/class/union type
ну местами у них таки есть более полезные варнинги
источник

A

Alex in pro.cxx
При написании шаблонного кода регулярно приходится переключаться между всеми тремя компиляторами в надежде, что какой-то один покажет нормальное сообщение, и удастся понять, где проблема) И да, в разных ситуациях каждый из трёх может помочь, золотой пули нет.
источник

CD

Constantine Drozdov in pro.cxx
Alex
ну и возникает вопрос, зачем в этом контексте вообще разрешается писать int() вместо int (*)()
int func();
int (&func_lref)() = func;
int (&&func_rref)() = func;
int (*func_ptr)() = &func;

const int (&var_lref) = 0;
const int (&&var_rref) = 0;
const int (*var_ptr) = &0;

меня немного другое удивляет в этой системе, но не суть
источник

A

Alex in pro.cxx
Хм, у меня не получается ошибка, как у Джейсона, GCC тоже нормально показывает. Мой первый вопрос можно снять.
https://godbolt.org/z/rYx1PE
источник

DK

David Kravets in pro.cxx
Саша Петров
математика крч.
for(int i = 0; i < 1000000000; ++i){5 * 8;}
Ты такой скромный
источник

DK

David Kravets in pro.cxx
Саша Петров
математика крч.
for(int i = 0; i < 1000000000; ++i){5 * 8;}
Есть вероятность что код выйдет за пределы оп
источник

A

Alex in pro.cxx
Constantine Drozdov
int func();
int (&func_lref)() = func;
int (&&func_rref)() = func;
int (*func_ptr)() = &func;

const int (&var_lref) = 0;
const int (&&var_rref) = 0;
const int (*var_ptr) = &0;

меня немного другое удивляет в этой системе, но не суть
у меня вопрос к &0, у компилятора тоже других вопросов не возникло.
А func_lref - действительно ссылка на функцию, или только прикидывается?
источник