New wave

∧＿∧ ( ･ω･｡)つ━☆・*。 ⊂　 ノ 　　　・゜+. しーＪ　　　°。+ *´¨) 　　　　　　　　　.· ´¸.·*´¨) ¸.·*¨) 　　　　　　　　　　(¸.·´ (¸.·'* ☆

что, это тоже в 21 стандарте будет компилиться?

это Брагин. у него есть канал на ютубе

https://www.youtube.com/channel/UCFPPiFWtjf-y7cnUsjSeWxw

вот собсна канал и там даже первые лекции есть

что, это тоже в 21 стандарте будет компилиться?

Причем это печатает само себя в 21 стандарте

Zen of C++

Ребят, использую GTest, при написании ASSERT_EQ : ASSERT_EQ(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);Вываливается ошибка компиляции, жалуется на лямбду lambda expression in an unevaluated operandА если написать ASSERT_THAT ASSERT_THAT(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);То всё замечательно работает. Есть ли семантическая разница для простого сравнения значений между ASSERT_EQ и ASSERT_THAT? Если нет, то нафиг нужен ASSERT_EQ?

Ребят, использую GTest, при написании ASSERT_EQ : ASSERT_EQ(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);Вываливается ошибка компиляции, жалуется на лямбду lambda expression in an unevaluated operandА если написать ASSERT_THAT ASSERT_THAT(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);То всё замечательно работает. Есть ли семантическая разница для простого сравнения значений между ASSERT_EQ и ASSERT_THAT? Если нет, то нафиг нужен ASSERT_EQ?

хм, ASSERT_THAT как раз не должен работать - 21 * 21 не похоже на матчер

хм, ну тест нормально выполняется и проходит, причём если 21 * 21 заменить на другое значение то тест фейлится

(как и должно быть, разумеется)

загадочно

из документации: Asserts that value matches matcher

а матчеры бывают встроенные либо определяются через MATCHER(...)

мож есть какой то дефолтный для интов

а stream это вот эти? http://jscheiny.github.io/Streams/

не

это мои

ещё прикол в том, что если лямбду передать по lvalue ссылке, то всё работает и с ASSERT_EQ

а ошибка про lambda expression in an unevaluated operand вываливается одна и та же что в gcc что в clang

так что на багу компилятора непохоже

Ребят, использую GTest, при написании ASSERT_EQ : ASSERT_EQ(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);Вываливается ошибка компиляции, жалуется на лямбду lambda expression in an unevaluated operandА если написать ASSERT_THAT ASSERT_THAT(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);То всё замечательно работает. Есть ли семантическая разница для простого сравнения значений между ASSERT_EQ и ASSERT_THAT? Если нет, то нафиг нужен ASSERT_EQ?

Ну лямбду вызывать надо, если ты их используешь в тестах. Добавь () в конце...

лямбда вызовется

сама по себе

Ребят, использую GTest, при написании ASSERT_EQ : ASSERT_EQ(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);Вываливается ошибка компиляции, жалуется на лямбду lambda expression in an unevaluated operandА если написать ASSERT_THAT ASSERT_THAT(stream::Stream(Gen()) | map([](auto &&v){ return v * v; }) | nth(0), 21 * 21);То всё замечательно работает. Есть ли семантическая разница для простого сравнения значений между ASSERT_EQ и ASSERT_THAT? Если нет, то нафиг нужен ASSERT_EQ?

я читал где-то, что в целом - все эти GE, EQ, NE, TRUE варианты ASSERT и EXPECT это изначальные варианты. Потом добавлится ASSERT_THAT и в целом все точно так же можно выразить в матчерах

Хм, спасибо

Начал копать в сторону имплементации pImpl и наткнулся на то, что на cpp_reference предлагают его оборачивать в propagate_const, пропосал на который есть, но последний раз рассматривался 3 года назад. В бусте такой штуковины не нашёл. Кто-нибудь в курсе вообще что там с этой штукой происходит ? )

https://github.com/jbcoe/propagate_const репа автора если что

в exprerimental gcc уже должен быть

https://github.com/jbcoe/propagate_const репа автора если что

Да я уже нашёл.

Но что толку от репы, если кажется, что там всё затухло)

Но что толку от репы, если кажется, что там всё затухло)

Реализации 17 дней от роду.

Реализации 17 дней от роду.

Посмотри историю коммитов

И вот сюда ещё можешь посмотреть http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4388.html