std::is_invokable не работает для фунций членов

Это так и должно бытьили я чтото неправильно делаю ?

0

Сообщение от TheCalligrapher ??? Процитированный вами отрывок говорит, что, например, lvalue типа void () можно [неявно] преобразовать к типу void (*)(). То есть к рассматриваемому вопросу он вообще никак не относится. К функциям-нестатическим членам класса это тоже не относится никак. Функции-члены класса не имеют function type. Function type в С++ по определению имеют только самостоятельные функции.

Это сырая гипотеза. Я щас занят другим вопросом и предпочёл бы читать молча Вашу дискуссию с hoggy, но она зашла нетуда.

Сообщение от TheCalligrapher Прямое. Каждое сказанное мною до сих пор слово - прямая цитата правил языка С++.

Про размер указателей это вы лишнего хватили :-) Никогда небыло такого в стандарте и не будет.

0

Сообщение от squareroot Это сырая гипотеза.

Не совсем понял, что именно тут по-вашему является "сырой гипотезой".

Сообщение от squareroot Про размер указателей это вы лишнего хватили :-) Никогда небыло такого в стандарте и не будет.

Вы выдумываете. Стандарт языка открытым текстом говорит, какие типы обязаны иметь одинаковые object representation. Все остальные типы, согласно стандарту, запросто могут иметь разные object representation. В том числе и размеры.

А дальше начинается реальная жизнь, т.е. то, что я назвал опытом.

И если мы знаем, что в реальной жизни указатели int * и void * скорее всего будут иметь одинаковые внутренние представления, мы в то же время знаем, что в реальной жизни указатели void (*)(Class *) и void (Class ::*)() будут иметь совсем разные внутренние представления, включая разные размеры.

http://coliru.stacked-crooked.... c6b9214136

Более того, мы прекрасно знаем, почему это так.

---

А когда опыта у вас будет еще больше, вы узнаете, что бывает такая экзотика, где и int * с void * имеют разные представления и даже разные размеры. "Есть многое на свете друг Горацио..."

1

Сообщение от squareroot Почему не вполне законно ?

потому что нельзя просто так взять и скастить указатель-на-функцию-член к void*

у них sizeof может различаться.
могут быть ещё какие то противопоказания.


если тебе интересна эта тема, рекомундую: Указатели на функции-члены и реализация самых быстрых делегатов на С++.

а насчет стандарта:

Сообщение от squareroot function type

"функция-член" - это не "функция".
"указатель-на-функцию-член" - не "указатель-на-функцию".

Сообщение от TheCalligrapher Я уже десять раз повторил, что полноценный указатель-на-член в любой корректной реализации

котёночек!
ты реально какой то трудный.

из того факта, что в каких то случаях sizeof может различаться никак не следует,
что преобразование невозможно.

в каких то случаях невозможно.
в каких то возможно.

0

Сообщение от hoggy в каких то случаях невозможно. в каких то возможно.

Ну... Вчера работало, сегодня не работает

С одной стороны видно, что начинается "включение задней", т.е. постепенное прозрение наклевывается, но в остальном пока "как об стенку горох". Понимание архиважной фундаментальной разницы между преобразованием и реинтерпретацией еще даже на горизонте не засветилось...

0

Сообщение от hoggy потому что нельзя просто так взять и скастить указатель-на-функцию-член к void* у них sizeof может различаться. могут быть ещё какие то противопоказания.

И что с того ? Вы мыслите в рамках своих стереотпов. Вот представьте что разработчики придумали то что порвёт все ваши шаблоны.
А именно функциональный тип как категорию типов, у которых sizeof может быть разный, а на других вычислительных платформах, где нет такого разнообразия вариантов адрессации sizeof будет одинаковый и это будет тотже самый C++. Давайте не выходить за флажки.

Сообщение от hoggy "функция-член" - это не "функция". "указатель-на-функцию-член" - не "указатель-на-функцию".

Да типы разные а к чему это ? Я пример привел выдержки из стандарта для целой категории типов(которая включает и функции члены тоже), а не для отдельного типа. Если у вас функция член этот какаято отдельная категория, то давайте читать стандарт вместе.

Добавлено через 14 минут

Сообщение от hoggy [URL="https://www.rsdn.org/article/cpp/fastdelegate.xml"]

Я уверен что никаких других ссылок, кроме ссылок на черновик стандарта Вам не требуется чтобы выразить свои мысли.

0

Сообщение от squareroot И что с того ? Вы мыслите в рамках своих стереотипов. Вот представьте что разработчики придумали то что порвёт все ваши шаблоны. А именно функциональный тип как категорию типов, у которых sizeof может быть разный, а на других вычислительных платформах, где нет такого разнообразия вариантов адресации sizeof будет одинаковый и это будет тот же самый C++.

squareroot, знания содержат, в том числе стереотипы. Однако, неумение отличать стереотипы от остального, оставляет именно стереотипы. Они являются базой знания. Не мышления, а знания. О мышлении мы мало знаем, но много мыслим). То, что всё в информации есть "переинтерпретация", а лучше -интерпретация, вообще не удачный подход в теме приведений. Есть разные уровни интерпретации. Часть преобразований, вообще не интерпретирует представление. Оно конвертирует одно в другое на основе заложенных семантических правил. А указатели, это очень специфические типы. Как уже отметил TheCalligrapher, стандарт не гарантирует совпадение размера void* и char*. Что же касается указателей на методы, то там дескриптор может включать адресацию через промежуточные уровни. Например, доступ к виртуальным методам через указатель на базовый класс, а это значит, что запрос должен быть передан конкретному динамическому типу, а потом вычисляется адрес. То есть, схема указания адреса на метод класса в такой же степени похожа на указатель на"обычную свободную функцию" , в какой обычная функция - массив байт. Сравнение с С тут не к месту.
Думаете зря придуман такой вид упаковки вызова в объект как std::function+std::bind ? Создание функционального объекта будь оно хоть лямбда хоть биндинг, это же дополнительные расходы. Но это выход для получения универсального способа обобщения "вызываемого" объекта.
зы. Прощу у всех прощения за выступление в "лёгком весе". Не спится.

0

Хотя нет, должен признать всётаки разные категории семейство типов функций и нестатических членов. Но в остальном прошу вести дискуссию в рамках правил языка.

Добавлено через 6 минут

Сообщение от IGPIGP squareroot, знания содержат, в том числе стереотипы. Однако, неумение отличать стереотипы от остального, оставляет именно стереотипы. Они являются базой знания. Не мышления, а знания. О мышлении мы мало знаем, но много мыслим). То, что всё в информации есть "переинтерпретация", а лучше -интерпретация, вообще не удачный подход в теме приведений. Есть разные уровни интерпретации. Часть преобразований, вообще не интерпретирует представление. Оно конвертирует одно в другое на основе заложенных семантических правил. А указатели, это очень специфические типы. Как уже отметил TheCalligrapher, стандарт не гарантирует совпадение размера void* и char*. Что же касается указателей на методы, то там дескриптор может включать адресацию через промежуточные уровни. Например, доступ к виртуальным методам через указатель на базовый класс, а это значит, что запрос должен быть передан конкретному динамическому типу, а потом вычисляется адрес. То есть, схема указания адреса на метод класса в такой же степени похожа на указатель на"обычную свободную функцию" , в какой обычная функция - массив байт. Сравнение с С тут не к месту. Думаете зря придуман такой вид упаковки вызова в объект как std::function+std::bind ? Создание функционального объекта будь оно хоть лямбда хоть биндинг, это же дополнительные расходы. Но это выход для получения универсального способа обобщения "вызываемого" объекта. зы. Прощу у всех прощения за выступление в "лёгком весе". Не спится.

Попробую ещё раз объяснить. Пофигу какие там дескрипторы, размеры указателей. Язык C++ это абстракция от аппаратуры, и тут форум по языку C++, а не про системное программирование, тема про Си++, а не про то какие есть варианты ассемблерной инструкции call, отличия прямой и косвенной адрессации. Любые доказательства из системного программирования ИМХО некорректные.
Всё остальное я готов слушать и матать на ус у тутошних карифеев.

0

Сообщение от squareroot Попробую ещё раз объяснить. Пофигу какие там дескрипторы, размеры указателей. Язык C++ это абстракция от аппаратуры, и тут форум по языку C++, а не про системное программирование, тема про Си++, а не про то какие есть варианты ассемблерной инструкции call, отличия прямой и косвенной адрессации. Любые доказательства из системного программирования ИМХО некорректные.

squareroot, вы думаете, что сужающее преобразование с потерей информации (if any), имеет что-то общее с уровнем ручного байтоконструирования? Есть указатель и указатель, - два типа. Один в другом не помещается. Причём, не помещается источник в приёмнике. Это или понятно или нет. Какие могут быть домыслы? Кто-то создаст такие указатели, что смогут поглотить любой указатель на метод? А как же быть с принципом - не плачу за то, что не использую?

Сообщение от squareroot Всё остальное я готов слушать и матать на ус у тутошних карифеев.

Тут пишут для всех. Вы можете быть не готовы, а может и будете. Но это вопрос времени.

0

Сообщение от IGPIGP squareroot, вы думаете, что сужающее преобразование с потерей информации (if any), имеет что-то общее с уровнем ручного байтоконструирования? Есть указатель и указатель, - два типа. Один в другом не помещается. Причём, не помещается источник в приёмнике. Это или понятно или нет. Какие могут быть домыслы? Кто-то создаст такие указатели, что смогут поглотить любой указатель на метод? А как же быть с принципом - не плачу за то, что не использую? Тут пишут для всех. Вы можете быть не готовы, а может и будете. Но это вопрос времени.

Когда я пишу на плюсах я не должен думать что один указатель не поместиться в другой, это проблема компилятора. Если мне надо об этом думать, то первым делом надо выкинуть плюсы в окно и начинать писать на Си или даже на ассемблере.

0

Сообщение от IGPIGP Как уже отметил TheCalligrapher, стандарт не гарантирует совпадение размера void* и char*.

Ну здрасьте! Как раз таки совпадение представлений void * и char * стандарт гарантирует (!). Я вел речь о void * и int *.

Сообщение от IGPIGP Например, доступ к виртуальным методам через указатель на базовый класс, а это значит, что запрос должен быть передан конкретному динамическому типу, а потом вычисляется адрес. То есть, схема указания адреса на метод класса в такой же степени похожа на указатель на"обычную свободную функцию" , в какой обычная функция - массив байт.

Кстати, хороший пример. Я когда-то с удивлением обнаружил, что при указании на виртуальные методы реализация GCC хранит в указателе-на-метод не адрес метода, и индекс в таблице виртуальных функций. То есть в такой ситуации в GCC никакого адреса внутри такого указателя не хранится вообще. И, понятное дело, выцарапывать что-либо оттуда через переинтерпретауию памяти - бесполезно.

1

Итак что мы имеем. Есть стандартное преобразование из ссылки на функциональный тип в указатель на функциональный тип.
Есть прецентент из практики когда идёт преобразование из ссылки на функцию член в указатель на функцию член. Всё так ? Ничего не перепутал. Задача понять природу этого явления. Так ?

0

Сообщение от squareroot Итак что мы имеем. Есть стандартное преобразование из ссылки на функциональный тип в указатель на функциональный тип.

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

без явного применения оператора & к функции.

Никакого отношения к членам класса это преобразование не имеет. Этот вопрос я уже полностью закрыл раньше. Давайте не будем устраивать тут "сказку про белого бычка".

Сообщение от squareroot Есть прецентент из практики когда идёт преобразование из ссылки на функцию член в указатель на функцию член.

Нет, такого прецедента нет. То, что вы написали буквально - это вообще какой-то оксюморон. В языке С++ явным образом запрещены "ссылки на функцию член".

Сообщение от squareroot Всё так ? Ничего не перепутал. Задача понять природу этого явления. Так ?

"Понять природу неопределенного поведения" - бессмысленная трата времени. Это при том, что пару сообщений выше вы пытались рассказывать, что ведете речь только о языке С++, а не о системных особенностях. А здесь вдруг речь зашла о явлении, которое однозначно запрещено языком С++ и держится на системной случайности. Что за странная смесь?

1

Сообщение от TheCalligrapher Не из ссылки, а из из lvalue функционального типа в указатель на функциональный тип. С оговоркой, открытым текстом прямо в стандарте, что lvalue функционального типа бывает только для обычных функций. Это то самое преобразование, которое позволяет вам писать C++ 1 void (*p)() = foo; без явного применения оператора & к функции. Никакого отношения к членам класса это преобразование не имеет. Этот вопрос я уже полностью закрыл раньше. Давайте не будем устраивать тут "сказку про белого бычка".

Да, всё так как Вы говорите, только мне самому пришлось лезть в стандарт, когда начитался про то как много воды налили из системного программирования

Сообщение от TheCalligrapher Нет, такого прецедента нет. То, что вы написали буквально - это вообще какой-то нонсенс. В языке С++ явным образом запрещены "ссылки на функцию член".

Я потому и говорю про прецендент из практики, которому сложно найти объяснение в рамках правил Си++. Зачем к словам придираться ?
Надо было просто както назвать его.

Сообщение от TheCalligrapher "Понять природу неопределенного поведения" - бессмысленная трата времени. Это при том, что пару сообщений выше вы пытались рассказывать, что ведете речь только о языке С++, а не о системных особенностях. А здесь вдруг речь зашла о явлении, которое однозначно запрещено языком С++ и держится на системной случайности. Что за странная смесь?

Нет не странная. Задача ведь не понять как под копотом, а задача понять чем руководствовались разработчики компиляторов, когда оставляли такую "бреш".

0

Сообщение от squareroot а задача понять чем руководствовались разработчики компиляторов, когда оставляли такую "бреш".

Не понял. О какой "бреши" вы говорите? Язык С++ не запрещает вам прямой доступ к сырой памяти ни по чтению, ни по записи. Эта "брешь" всегда была и будет частью языка.

А когда у вас есть прямой доступ к сырой памяти, вы можете копировать эту сырую память из одного места в другое, либо через memcpy, либо через переинтерпретацию+присваивание (как это было сделано здесь). Копированием байтов из одного места в другое вы можете "собирать" из разрозненных байтов бессмысленных монстров какой-угодно степени монструозности. Поведение таких монстров, разумеется, не определено.

Не надо жаловаться на таких монстров, если вы сами их собрали. Язык тут ни в чем не виноват.

А называть такое копирование сырой памяти преобразованием - это уже профанация. Термин преобразование в С++ уже занят и означает он совсем другое.

0

Сообщение от TheCalligrapher Не понял. О какой "бреши" вы говорите? Язык С++ не запрещает вам прямой доступ к сырой памяти ни по чтению, ни по записи. Эта "брешь" всегда была и будет частью языка. А когда у вас есть прямой доступ к сырой памяти, вы можете копировать эту сырую память из одного места в другое, либо через memcpy, либо через переинтерпретацию+присваивание (как это было сделано здесь). Копированием байтов из одного места в другое вы можете "собирать" из разрозненных байтов бессмысленных монстров какой-угодно степени монструозности. Поведение таких монстров, разумеется, не определено. Не надо жаловаться на таких монстров, если вы сами их собрали. Язык тут ни в чем не виноват. А называть такое копирование сырой памяти преобразованием - это уже профанация. Термин преобразование в С++ уже занят и означает он совсем другое.

Впринцепи согласен, посколько явное приведение типа относится к небезопасным преобразования, то последствия в виде UB это проблема разработчика, но вот что интересно. Если в результате такого шаманства появляется тип, который запрещён правилами,то это уже интересно.

0

Сообщение от squareroot Если в результате такого шаманства появляется тип, который запрещён правилами,то это уже интересно.

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

0

Не это правда интересно, что будет если сделать declval(*((Free*)proxy)), а потом этот тип заюзать в декларативном языке шаблонов.
Надо попробовать свести с ума компилятор.

0

Сообщение от squareroot Не это правда интересно, что будет если сделать declval(*((Free*)proxy)), а потом этот тип заюзать в декларативном языке шаблонов.

Не понял. Что такое declval(*((Free*)proxy)). О чем речь вообще? Или вы имеете в виду decltype?

Когда вы написали про "появление типа, который запрещён правилами", я подумал, что вы оговорились, и речь идет о появлении значения, которое запрещено правилами. Никакого типа "который запрещен правилами", пока что нигде тут не появлялось.

Тип decltype(*((Free*)proxy)) - это просто Free &. В этом типе нет ничего необычного или запрещенного. О чем вы?

0

Сообщение от TheCalligrapher Не понял. Что такое declval(*((Free*)proxy)). О чем речь вообще? Или вы имеете в виду decltype? Когда вы написали про "появление типа, который запрещён правилами", я подумал, что вы оговорились, и речь идет о появлении значения, которое запрещено правилами. Никакого типа "который запрещен правилами", пока что нигде тут не появлялось. Тип decltype(*((Free*)proxy)) - это просто Free &. В этом типе нет ничего необычного или запрещенного. О чем вы?

да, всё верно decltype. выражение decltypel(*((Free*)proxy)) какой тип даст ? Free & это что ? ссылка на указатель на функцию член, если сам по себе тип Free это указатель на функцию член ?

0

Сообщение от squareroot decltypel(*((Free*)proxy)) какой тип даст ? Free & это что ссылка на указатель, если сам по себе Free указатель на функцию член ?

Да, это обычная ссылка на указатель. Ничего необычного или "запрещенного" в ссылке на указатель нет. То, что это "указатель на функцию член" никакой роли не играет.

0