Кажется я пару недель назад обещал пост, о C++20. Вот он: https://habrahabr.ru/company/yandex/blog/336264/

прекрасно и замечательно!

Чего-то мне цикл твой не нравится... Уверен, что MSVC насквозь не видит? Или ты с результатом делаешь потом что-то?

Естессно делаю - на cout его подаю. Дизассм смотрел, все норм.

Естессно делаю - на cout его подаю. Дизассм смотрел, все норм.

?

Хранение в виде ветора из std::tuple, конечно, вариант, но вроде не особо эффективный.

Вот именно

Естессно делаю - на cout его подаю. Дизассм смотрел, все норм.

А ты в Натив скомпил да?

Так стоп там вижак

На Линукс протести крч с -mnative

March*

March*

Марш натив

/shrug

¯\_(ツ)_/¯

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0458r0.html госсподи, наконец-то, спустя 20 с лишним лет....

Да...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0458r0.html госсподи, наконец-то, спустя 20 с лишним лет....

Плюсую за каст к булу

И ваще такой треит нужен тогда в итераторы

Плюсую за каст к булу

Это ж весь ABI поломает, так как придется хранить в итераторе флаг. Хотя я тоже за

Это ж весь ABI поломает, так как придется хранить в итераторе флаг. Хотя я тоже за

Да и неясно, чему этот флаг должен равняться для обычных ситуаций. Когда мы просто по коллекции идём, понятия is_found не существует

Это ж весь ABI поломает, так как придется хранить в итераторе флаг. Хотя я тоже за

Не придется

Нужно просто будет находить контейнер, не уверен что они сейчас так не умеют

Или проверку на условие энда

Оно там и так есть возможно

Это оверхед лишний. Тому же итератору для вектора ничего не надо знать, только указатель на элемент

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

Так что он никак не узнает end он или нет

А, ну да.

Треитсы

Это фича а не ограничение

Во! Придумал синтаксис. Хочу для виртуальных функций два дополнительных модификатора ref-значения static и constexpr. struct base { virtual int get_attribute() constexpr = 0; }; struct derived : base { virtual int get_attribute() constexpr override { return 1; } };

Модификатор 'static' означает, что в теле функции не определен this; модификатор 'constexpr' дополнительно означает, что сама функция должна быть constexpr

Модификатор 'static' означает, что в теле функции не определен this; модификатор 'constexpr' дополнительно означает, что сама функция должна быть constexpr

А причем тут виртуальность?)

А причем тут виртуальность?)

При том, что это - виртуальная функция со всеми вытекающими последствиями

В частности, модификатор 'static' не создает полноценно статическую функцию, он лишь гарантирует, что возвращаемое значение зависит только от динамического типа объекта

В случае с constexpr компилятор имеет возможность вписать в таблицу виртуальных функций непосредственно результат вычисления constexpr выражения

В частности, модификатор 'static' не создает полноценно статическую функцию, он лишь гарантирует, что возвращаемое значение зависит только от динамического типа объекта

Какая-то микрооптимизация

В случае с constexpr компилятор имеет возможность вписать в таблицу виртуальных функций непосредственно результат вычисления constexpr выражения

Может легче просто virtual const int Answer = 42; А то то, как ты описал, уж больно долго писать.

а есть

а есть какой то враппер d3d9->opengl на линукс?

мне чтобы не вайн

только dx

Во! Придумал синтаксис. Хочу для виртуальных функций два дополнительных модификатора ref-значения static и constexpr. struct base { virtual int get_attribute() constexpr = 0; }; struct derived : base { virtual int get_attribute() constexpr override { return 1; } };

С такими идеями текущий механизм виртуальных функций поломается

Да и сейчас это всё реализуемо

Может легче просто virtual const int Answer = 42; А то то, как ты описал, уж больно долго писать.

Это не обязательно const

С такими идеями текущий механизм виртуальных функций поломается

Чем ломается?

И да, это не реализуемо без проверок

Не хочется портить вам счастье, но если объект содержит виртуальные функции, его нельзя сделать constexpr

Чем ломается?

Например, хранением в таблице виртуальных функций не функции, а значения

Это не обязательно const

Ты же хочешь значение, зависящее от динамического типа объекта ?

Не хочется портить вам счастье, но если объект содержит виртуальные функции, его нельзя сделать constexpr

Антон, подразумевается, что сама по себе функция является constexpr, грубо говоря как если бы она была в точности так же написана как статическая функция класса

В текущем стандарте языка все эти хотелки и так работают, просто да, где-то лишний раз передаётся this, который фактически не требуется

В текущем стандарте языка все эти хотелки и так работают, просто да, где-то лишний раз передаётся this, который фактически не требуется

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

Не хочется портить вам счастье, но если объект содержит виртуальные функции, его нельзя сделать constexpr

Т.е. подразумевается, что модификатор 'static' равносилен требованию "функция возвращает результат статической функции (тело функции) этого же класса с теми же параметрами", модификатор constexpr "функция возвращает результат статической constexpr функции (тело функции) этого же класса с теми же параметрами"

Т.е. подразумевается, что модификатор 'static' равносилен требованию "функция возвращает результат статической функции (тело функции) этого же класса с теми же параметрами", модификатор constexpr "функция возвращает результат статической constexpr функции (тело функции) этого же класса с теми же параметрами"

Аааа... тут virtual в качестве "пользователь! не забудь переопределить эту фенкцию в наследнике, но она не виртуальная"

struct base { virtual int get_attribute() constexpr = 0; }; //предложение struct derived : base { virtual int get_attribute() constexpr override { return 1; } }; //развертка в действующий стандарт struct derived : base { static constexpr int get_attribute__inner() { return 1; }; virtual int get_attribute() override { return get_attribute__inner(/*форвард аргументов*/); } };

struct base { virtual int get_attribute() constexpr = 0; }; //предложение struct derived : base { virtual int get_attribute() constexpr override { return 1; } }; //развертка в действующий стандарт struct derived : base { static constexpr int get_attribute__inner() { return 1; }; virtual int get_attribute() override { return get_attribute__inner(/*форвард аргументов*/); } };

Ноо.. форвард аргументов. Сами аргументы же известны только во время выполнения

можно макросами обмазать

предлагаю вместо virtual использовать override

т.е. начинать декларацию с override?

Не, фигня получается struct base { override static constexpr int get_attribute(); };

struct base { virtual int get_attribute() constexpr = 0; }; //предложение struct derived : base { virtual int get_attribute() constexpr override { return 1; } }; //развертка в действующий стандарт struct derived : base { static constexpr int get_attribute__inner() { return 1; }; virtual int get_attribute() override { return get_attribute__inner(/*форвард аргументов*/); } };

VIRTUAL CONSTEXPR? ЧТО БЛЯ

override уже ведь занят.

в данном случае речь идет о наложении дополнительных требований на тело функции

весьма непонятен вопрос сигнатуры такой функции

virtual в таком случае должен резолвиться на этапе компиляции

он не может быть зарезолван

constvirual

Вводим новое

ERROR: S client not available

struct base { virtual int get_attribute() constexpr = 0; }; struct derived : base { virtual int get_attribute() constexpr override { return 1; } }; void foo(base const& b) { b.get_attribute(); //значение? //base::get_attibute(); //ошибка компиляции derived::get_attibute(); //все-таки должно быть нормально }

реальное применение можешь озвучить?

сериализация объектов с фабрикой по имени

фабрика по имени создает объект конкретного типа и безумно хочет, чтобы любой созданный ей объект в ответ на запрос имени возвращал то же самое

сейчас фабрика в этом случае может использовать map и RTTI

что является ручной реализацией vtbl по сути

вряд ли из-за одного маргинального юзкейса это надо тащить прямо в язык

почему маргинального?

ну потому что это и так уже можно сделать с RTTI

я вижу только один смысл тащить значение в vtbl - избежать лишнего вызова

реализация map+RTTI позволяет вообще не использовать виртуальные функции

что нужно только в условиях жестких требований к производительности

реализация map+RTTI позволяет вообще не использовать виртуальные функции

так и не надо

так и не надо

удалить виртуальные функции из языка как сахар?)

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

фабрика по имени создает объект конкретного типа и безумно хочет, чтобы любой созданный ей объект в ответ на запрос имени возвращал то же самое

Тут другая проблема, ты приводишь пример применения в программе, написанной на языке, А не в самом языке. Т.е. это будет полезно только в частной программе. Целиком языку будет не полезно.

Тут другая проблема, ты приводишь пример применения в программе, написанной на языке, А не в самом языке. Т.е. это будет полезно только в частной программе. Целиком языку будет не полезно.

Это какой-то софизм. Язык для программ, а не язык - вещь в себе

Ну как ещё сказать...

Можно пойти дальше и потребовать возможность задавать кастомные атрибуты

Ты улучшаешь язык для какого-то частного применения

Я все еще уверен, что в любой реализации есть такие функции

И есть контракты на уровне оговорок, которые я предлагаю в язык

Я все еще уверен, что в любой реализации есть такие функции

Ну их очень мало.

Просто STL совершенно не использует динамический полиморфизм

Прикинь, да... Открытие ?

Да, но это совершенно невозможно в разработке хоть немного сложной программы

При этом нет ни одного способа преобразовать контракты статического полиморфизма "задано constexpr поле" в динамический

Например, фактическая реализация std::function после потери типа не может потребовать проверить из внутреннего интерфейса по контракту "is_nothrow_move_constructible"

Кстати, надо запомнить, годные аргументы для преамбулы

пока что звучит так, что тебе скорее нужны хитрые ассерты, а не правка vtbl

это невозможно проверить никаким ASSERT-ом, потому что это статическая проверка

на MSC это очень условно можно проверить ассертом, передав 0 в качестве this в конкретную функцию