я про статический ассерт и говорил

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

и нет, я не подразумевал. что это можно сделать существующими средствами, возможно, просто их расширить

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

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

потому что тело функции иногда оптимизируют

функции после компиляции может вообще не существовать

забавно, пример действительно есть в реализации std::function в MSC virtual const _XSTD2 type_info& _Target_type() const _NOEXCEPT = 0;

http://en.cppreference.com/w/cpp/utility/functional/function/target_type

так это здесь неважно, важно, чтобы функция имела вид return constexpr

и как это проверить через static_assert?

ввести новый тип ассерта

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

я к тому, что такое изменение гораздо локальнее, чем лезть в vtbl

пока функция не помечена constexpr она не может быть constexpr выражением

пусть компилятор убедится, что она constexpr, и вызовет

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

и нет, я не подразумевал. что это можно сделать существующими средствами, возможно, просто их расширить

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

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

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

Просто =0 без виртуал

Я правда не совсем вижу профит

Я хочу избежать синтаксиса "virtual static", поскольку взятие адреса такой функции не должно давать статическую функцию

Какое-то ооп

Я хочу избежать синтаксиса "virtual static", поскольку взятие адреса такой функции не должно давать статическую функцию

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

Я хочу избежать синтаксиса "virtual static", поскольку взятие адреса такой функции не должно давать статическую функцию

А Профит не трогать this какой?

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

потому что это НЕ статическая функция

А Профит не трогать this какой?

Смотри. Ты реализуешь target_type для std::function

const?

У тебя под std::function лежит интерфейс

Так а Профит то какой?

Может ли значение target_type измениться вообще когда-нибудь при каких-нибудь обстоятельствах при вызове неконстантной функции этого интерфейса?

Профит в том, что ты пишешь более сильный контракт метода

Может ли значение target_type измениться вообще когда-нибудь при каких-нибудь обстоятельствах при вызове неконстантной функции этого интерфейса?

Почему неконстантной

Сделай константный

Константными все методы интерфейса?

Профит в том, что ты пишешь более сильный контракт метода

Какая-то строгая математика в ооп

Константными все методы интерфейса?

То что должно быть константным

Ну в твоём случае не трогать this

target_type это не просто константа, target_type это constexpr

target_type это не просто константа, target_type это constexpr

У тебя виртуальность констекспр допустим ещё не завезли

Ну ты просто выбрасываешь эту часть контракта

Да и если завезли то в чем проблема?

Читать нельзя?

А потом тебе короче вписывают под твой контракт реализацию, в которой при перемещении на новый адрес target_type пропадает

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

Ну, кроме комментария

А потом тебе короче вписывают под твой контракт реализацию, в которой при перемещении на новый адрес target_type пропадает

Звучит как хреновая архитектура

А у тебя ваще есть гарантия что например виртуальная таблица валидна там?

Интересный вопрос, полагаю, что да, есть

this невалиден а виртуальная таблица валидна?

this не бывает невалиден

For non-union class types (class and struct), the move constructor performs full member-wise move of the object's bases and non-static members, in their initialization order, using direct initialization with an xvalue argument

Так что таблица виртуальных функций валидна

Она безусловно инициализируется, а не копируется

Кажется, это ровно вопрос типа "что будет при копировании со срезкой"

this не бывает невалиден

Тогда я не понял зачем тебе не const virtual а новая штука

Тогда я не понял зачем тебе не const virtual а новая штука

Потому что const это другая гарантия. Грубо говоря const гарантирует повторяемость вплоть до не-const вызова

static является гарантией повторяемости независимо от вызовов методов

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

Странно все это

Слишком математично

ERROR: S client not available

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

static является гарантией повторяемости независимо от вызовов методов

Можно не делать неконст

Например, представь, у меня есть интерфейс IntegerType

Тогда вызывать нечего

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

ты не думал вместо плюсов на идрис писать?

ты не думал вместо плюсов на идрис писать?

что такое идрис?)

язык

struct IntegerInterface abstract { virtual std::string to_chars() const = 0; virtual intmax_t limit_max() const = 0; //декларация равносильна to_chars ?????? virtual void assign_integral(intmax_t) = 0; }; template <typename T> struct IntegralInteger : IntegerInterface { T inner; virtual std::string to_chars() const { return std::to_chars(inner); }; };

вот как я должен в данном случае описать std::numeric_limit?

ты не думал вместо плюсов на идрис писать?

я не верю в функциональное программирование общего назначения

ах соо

struct IntegerInterface abstract { virtual std::string to_chars() const = 0; virtual intmax_t limit_max() const = 0; //декларация равносильна to_chars ?????? virtual void assign_integral(intmax_t) = 0; }; template <typename T> struct IntegralInteger : IntegerInterface { T inner; virtual std::string to_chars() const { return std::to_chars(inner); }; };

это-таки статическая штука

это-таки статическая штука

можно пример в коде?

можно пример в коде?

в общем, отмена. я ничего не понял

на самом деле я должен грубо говоря объявить интерфейс, потом объявить шаблонную реализацию с параметром Traits, которая закроет через final методы с реализацией из Traits

и не дай ?-? у меня что-то там будет наследоваться

собственно внутренний интерфейс std::function virtual _Myt *_Copy(void *) const = 0; virtual const _XSTD2 type_info& _Target_type() const _NOEXCEPT = 0;

Вобщем ты хочешь стратегии в компильтайм без наследования?

Я хочу атрибуты фактических классов в рантайм без мапы с RTTI

Тоесть чтоб в контейнер упихать

В компильтайм все хорошо

Шаблончик специализирую и все

Ладно, вроде замечаний по существу не было, напишу потом. Есть более безумная вещь. 2. В конце выполнения auto return type deduction вместо ошибки в случае различия аргументов инстанцировать std::lang::common_type, специализация которого разрешена (с дополнительными условиями во избежание циклической зависимости)

слушайте, а можно линковаться с вайновскими либами?

чтобы вызывать вайновские методы в голом лянехсе

можно, только без запущенного рантайма толку от этого никакого

не, мне вызывать методы

ну ведь развалится без рантайма

ну ведь развалится без рантайма

а можно запустить рантайм на время вызова методов?

какое-то извращение, давай рассказывай, зачем тебе оно надо