Size: a a a

2020 August 16

D

Danya in pro.cxx
Alex
А, который strict? Он никогда не был юзабельным, с ним системные виндовые хедеры отродясь не дружили
windows.h не компилируется с /permissive-
источник

A

Alex in pro.cxx
Danya
windows.h не компилируется с /permissive-
Странно, не верю, у меня уже давно все проекты с /permissive-. Может, древний SDK?
источник

A

Alex in pro.cxx
это пофикшено в версии 10.что-то там
источник

АК

Александр Караев... in pro.cxx
Alex
вот живой пример, когда это заноза в заднице
Это надуманный бесполезный пример
источник

A

Alex in pro.cxx
Александр Караев
Это надуманный бесполезный пример
нет, это пример из моего живого кода
источник

A

Alex in pro.cxx
я дописал, прогнал тесты, порадовался, закоммитил, и получил сообщение от travis CI, что это не собралось
источник

VF

Vitaly Farmov in pro.cxx
Alex
Не искал, но местные гуру сразу сказали, что так и должно быть. if constexpr не допускает не компилирующийся код, даже в "мёртвых" ветках.
Понятно, учитывая, что вот это компилится работает https://godbolt.org/z/r8aK9x
Выглядит странновато, что тот код не компилится)
источник

D

Danya in pro.cxx
Alex
Странно, не верю, у меня уже давно все проекты с /permissive-. Может, древний SDK?
Не знаю
Однажды просто включил его в настройках проекта и включил windows.h
Оно не скомпилировалось, я взгрустнул
Но спасибо за наводку, наверное и правда старое было
источник

АК

Александр Караев... in pro.cxx
Alex
нет, это пример из моего живого кода
Пример из живого кода всегда шаблонный. Это может быть ошибка компилятора в конкретном случае, if constexpr не виноват
источник

A

Alex in pro.cxx
Александр Караев
Пример из живого кода всегда шаблонный. Это может быть ошибка компилятора в конкретном случае, if constexpr не виноват
Вряд ли, GCC 9 и 10 оба не компилят, clang не пробовал, MSVC компилит
источник

АК

Александр Караев... in pro.cxx
По крайней мере всё коммьюнити уже 3 года гоняет if constexpr и жалоб не было (кроме жалоб на static_assert(false))
источник

A

Alex in pro.cxx
да я тоже гоняю и не было жалоб, пока до такого юз кейса не дошло дело
источник

VF

Vitaly Farmov in pro.cxx
Alex
Вряд ли, GCC 9 и 10 оба не компилят, clang не пробовал, MSVC компилит
clang не компилит тоже в моем примере
источник

A

Alex in pro.cxx
Александр Караев
Пример из живого кода всегда шаблонный. Это может быть ошибка компилятора в конкретном случае, if constexpr не виноват
У меня из двух сравниваемых объектов a и b один шаблонный, а второй нет
источник

ВС

Владислав Смирнов... in pro.cxx
Вспомнилась статья про сложности if constexpr https://habr.com/ru/post/472780/
источник

O

Ofee in pro.cxx
Потому что я могу вызвать test_func<Poly<false>, Poly<true>>() и это будет другая функция

Если хочется сделать, как оно есть — внутри нешаблонной функции — можно, как обсуждалось выше, обернуть в лямбду. Но я не уверен, что тут есть выигрыш по читаемости, но есть и ещё одно решение с C++20 — шаблонная лямбда иногда может улучшить читаемость, а не ухудшить :)
источник

A

Alex in pro.cxx
В моём случае изящного решения не вижу. Объект b возникает в лямбде "шаблонным" образом, а вот объект a сконструирован на стеке "конкретно" и захвачен в лямбду для валидации на равенство c b.
источник

m

magras in pro.cxx
Alex
В моём случае изящного решения не вижу. Объект b возникает в лямбде "шаблонным" образом, а вот объект a сконструирован на стеке "конкретно" и захвачен в лямбду для валидации на равенство c b.
Если у тебя известен тип объекта a, зачем писать код на случай если a окажется каким-то другим типом?
источник

A

Alex in pro.cxx
потому что тогда его удобно расклонировать на три версии теста, где нужно только поменять объявление объекта. А так нужно ещё и лямбду везде править консистентно.
источник

m

magras in pro.cxx
Alex
потому что тогда его удобно расклонировать на три версии теста, где нужно только поменять объявление объекта. А так нужно ещё и лямбду везде править консистентно.
Для меня это звучит как веская причина по которой такой код _не_ должен компилироваться.
источник