Вариант с прехраненной лямбдой тоже нормально работает. Только с immediately invoke проблемы, т.к. слегка дикий кейс, видимо.

Почему constexpr лябмду нельзя использовать в качестве шаблонного параметра? return stuff<[]() constexpr { return 37; }()>::value; приходится делать так: constexpr auto x = []() constexpr { return 37; }(); return stuff<x>::value; Понятно, что constexpr лямбда имеет шанс выполниться только в рантайме, но почему компилятор не может самостоятельно попытаться сделать аналог 2 варианта?

по тому что constexpr лямбда это инстанс, а не тип вместимо, с C++20 можно будет

Почему constexpr лябмду нельзя использовать в качестве шаблонного параметра? return stuff<[]() constexpr { return 37; }()>::value; приходится делать так: constexpr auto x = []() constexpr { return 37; }(); return stuff<x>::value; Понятно, что constexpr лямбда имеет шанс выполниться только в рантайме, но почему компилятор не может самостоятельно попытаться сделать аналог 2 варианта?

интересно вообще почему второ вариант скомпилировался https://godbolt.org/g/mv9zas

интересно вообще почему второ вариант скомпилировался https://godbolt.org/g/mv9zas

потому что это пишется так https://godbolt.org/g/3fqwS4

Почему constexpr лябмду нельзя использовать в качестве шаблонного параметра? return stuff<[]() constexpr { return 37; }()>::value; приходится делать так: constexpr auto x = []() constexpr { return 37; }(); return stuff<x>::value; Понятно, что constexpr лямбда имеет шанс выполниться только в рантайме, но почему компилятор не может самостоятельно попытаться сделать аналог 2 варианта?

кленг может в это https://godbolt.org/g/qdmZFt

потому что это пишется так https://godbolt.org/g/3fqwS4

но тогда мы не передаем лямбду в качетсве параметра, а уже посчитанный параметр

но тогда мы не передаем лямбду в качетсве параметра, а уже посчитанный параметр

так и у него в вопросе тоже про результат

там скобки же после лямбды

так и у него в вопросе тоже про результат

ок, тогда сорри, я думал именно лямбду как параметр, чтобы статический полиморфизм на лямбдах получить

я вот как-то случайно сейчас узнал что structured binding нельзя капчурить в лямбду, вот это грусть вообще https://en.cppreference.com/w/cpp/language/lambda

ок, тогда сорри, я думал именно лямбду как параметр, чтобы статический полиморфизм на лямбдах получить

так тоже можно, чо ты https://godbolt.org/g/6KNtA5

так тоже можно, чо ты https://godbolt.org/g/6KNtA5

даже лучше вот так - https://godbolt.org/g/xZ7ECK

так тоже можно, чо ты https://godbolt.org/g/6KNtA5

круть, я думал нужно C++20 ждать

Всем привет

Можно попробовать decltype

Может кто знает? Какие из перечисленных ключевых слов не являются зарезервированными в С? then, undo, go,less

Может кто знает? Какие из перечисленных ключевых слов не являются зарезервированными в С? then, undo, go,less

знаешь как правильно самому искать ответ на подобные вопросы? открываешь стандарт С и ищешь keywords

кленг может в это https://godbolt.org/g/qdmZFt

О, спасибо. Но, блин, опять какие-то implementation defined штуки.

Может кто знает? Какие из перечисленных ключевых слов не являются зарезервированными в С? then, undo, go,less

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

@GorbunovAleksey смотри, тебе Surreal уже полработы сделал, дело за малым: найти keywords :)

Да все там все 4 не зарезервированы

Может кто знает? Какие из перечисленных ключевых слов не являются зарезервированными в С? then, undo, go,less

опять на экзамене не спалили мобилу?

опять на экзамене не спалили мобилу?

Ахаха

Ага

значит /репорт

Зачем отвечаете на такие мусорные вопросы?

Удалять такое надо...

ну так, почему не удалось удалить?

Зачем отвечаете на такие мусорные вопросы?

если ты заметил, он сам ответил на свой вопрос.

он вынесет из экзамена по языку C, что then, undo, go,less не являются зарезервированными словами. это немало.

если ты заметил, он сам ответил на свой вопрос.

Но и другие пытались...

class A { virtual void Foo(); }; class B : public A { virtual void Foo() { // some code A::Foo() } }; Всякий раз, когда нужно обратиться к реализации предка, мне не хватает паскалевского ключевого 'inherited'. Потому, что если в последствии в иерархию между A и B вклинится класс со своим вариантом Foo(), то реализация B::Foo() перестанет работать так, как это было задумано при её написании. Есть ли возможность косвенно сослаться именно на тип предка, а не на конкретный тип в иерархии?

class A { virtual void Foo(); }; class B : public A { virtual void Foo() { // some code A::Foo() } }; Всякий раз, когда нужно обратиться к реализации предка, мне не хватает паскалевского ключевого 'inherited'. Потому, что если в последствии в иерархию между A и B вклинится класс со своим вариантом Foo(), то реализация B::Foo() перестанет работать так, как это было задумано при её написании. Есть ли возможность косвенно сослаться именно на тип предка, а не на конкретный тип в иерархии?

Ну можно сделать typedef, но не сильно спасёт.

Ну можно сделать typedef, но не сильно спасёт.

Да, получится, что перед каждым наследованием нужно заводить свой псевдоним в общей области видимости, что очень уродливо.

Всё упирается во множественное наследование.

Всё упирается во множественное наследование.

Понятно, что это создаёт сложность, но кажется, что не большую, чем обращение к функции, имеющейся у обоих предков МН, что должно просто заканчиваться 'ambiguous call'

Да, получится, что перед каждым наследованием нужно заводить свой псевдоним в общей области видимости, что очень уродливо.

Заведи внутри класса

Заведи внутри класса

Тогда получится, что тип предка нужно указывать дважды: один раз при наследовании, второй - в псевдониме. Так? Тоже криво.

ERROR: S client not available

@evgusk достаточно давно было обсуждение super, можно начать читать с сообщения, на которое я ответил или чуть выше

Тогда получится, что тип предка нужно указывать дважды: один раз при наследовании, второй - в псевдониме. Так? Тоже криво.

Именно typedef посчитали достаточным и отклонили пропозал

Denis has been warned (1/3)

class A { virtual void Foo(); }; class B : public A { virtual void Foo() { // some code A::Foo() } }; Всякий раз, когда нужно обратиться к реализации предка, мне не хватает паскалевского ключевого 'inherited'. Потому, что если в последствии в иерархию между A и B вклинится класс со своим вариантом Foo(), то реализация B::Foo() перестанет работать так, как это было задумано при её написании. Есть ли возможность косвенно сослаться именно на тип предка, а не на конкретный тип в иерархии?

У микрософта для этого есть __super - https://docs.microsoft.com/en-gb/cpp/cpp/super

У микрософта для этого есть __super - https://docs.microsoft.com/en-gb/cpp/cpp/super

Спасибо! Жаль, что в стандарт это решили не вносить. Принятая альтернатива (typedef), на мой взгляд, неудовлетворительна. Ну а привязываься или нет к нестандартным расширениям - отдельный вопрос.

Спасибо! Жаль, что в стандарт это решили не вносить. Принятая альтернатива (typedef), на мой взгляд, неудовлетворительна. Ну а привязываься или нет к нестандартным расширениям - отдельный вопрос.

Clang его тоже поддерживает с -fms-compatibility, так что если gcc не интересует и очень хочется, то я думаю можно :)

И все же C++ лучше, чем футбол, меньше нервов надо :)

И все же C++ лучше, чем футбол, меньше нервов надо :)

?

И все же C++ лучше, чем футбол, меньше нервов надо :)

убегал в соседнюю комнату во время пенальти)

И все же C++ лучше, чем футбол, меньше нервов надо :)

наша сборная это ub

gg wp

со сборкой кстати, также были времена.

Ваша сборная хорошо сыграла

И все же C++ лучше, чем футбол, меньше нервов надо :)

И сюрпризов не меньше :) Всех с выходом в 0.25

И сюрпризов не меньше :) Всех с выходом в 0.25

Ага, грац)

Похоже, что завтра в допинге обвинят)

И сюрпризов не меньше :) Всех с выходом в 0.25

повторили таки, молодцы

повторили таки, молодцы

Впервые. В прошлый раз таки платформозависимо, а теперь -- универсально.