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

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

0

Нестатические функции члены стандарт относит к отдельному типу составного типа.

0

Сообщение от rat0r Ну, второе, допустим, верно. А первое? В [basic.compound] нет специального типа для функций-членов.

а тебе обязательно нужно,
что бы в [basic.compound] был специальный тип для функций-членов,
что бы ты понял, что "функция-член" - это не "функция"?

это - разные вещи уже лишь потому,
что у них разные особенности.

0

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

В каком месте?

0

Нумерация глав у разных версий стандартов разная. Данная нумерация справедлива для стандарта 11-го года.

3.9.2 Compound types [basic.compound] Compound types can be constructed in the following ways: — arrays of objects of a given type, 8.3.4; — functions, which have parameters of given types and return void or references or objects of a given type, 8.3.5; — pointers to void or objects or functions (including static members of classes) of a given type, 8.3.1; — references to objects or functions of a given type, 8.3.2. There are two types of references: — lvalue reference — rvalue reference — classes containing a sequence of objects of various types (Clause 9), a set of types, enumerations and functions for manipulating these objects (9.3), and a set of restrictions on the access to these entities (Clause 11); — unions, which are classes capable of containing objects of different types at different times, 9.5; — enumerations, which comprise a set of named constant values. Each distinct enumeration constitutes a different enumerated type, 7.2; — pointers to non-static class members, which identify members of a given type within objects of a given class, 8.3.3.

0

squareroot,

Сообщение от hoggy а тебе обязательно нужно, что бы в [basic.compound] был специальный тип для функций-членов, что бы ты понял, что "функция-член" - это не "функция"?

Что ты, конечно не обязательно. Если ты что-то заявил, то это несомненная правда.

0

Сообщение от rat0r TheCalligrapher, ну значит надо ещё [dcl.fct] почитать.

Хорошее замечание. Действительно, [dcl.fct] снимает все вопросы: функции-члены имеют "function type" и функция-член - это функция.

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

0

Сообщение от rat0r Что ты, конечно не обязательно. Если ты что-то заявил, то это несомненная правда

а если не кивать в мою сторону, а своими мозгами подумать?

никогда не замечал такую малююююсенькую разницу
между явлением "функции" и явлением "функцией-членом"?

совсем ничегошеньскую крохотуличку?

1

TheCalligrapher, да, у людей есть претензии к таким функциям.

3

Сообщение от hoggy "функция-член" - это не "функция"

http://eel.is/c++draft/class.mem#17.note-1

[ Note: The type of a non-static member function is an ordinary function type, and the type of a non-static data member is an ordinary object type. There are no special member function types or data member types.— end note]

1

Сообщение от argcargv http://eel.is/c++draft/class.mem#17.note-1

ну и нафиг ты мне это показываешь?

0

Сообщение от argcargv http://eel.is/c++draft/class.mem#17.note-1

Ценное замечание. Я почему-то его прошляпил.

После ссылки на "Abominable function types" от rat0r, у меня еще оставались сомнения: статья рассказывает о том, что можно описать abominable function types и использовать их для определения функций-членов классов. Но там как будто нет явного утверждения в обратную сторону: является ли тип готовой функции-члена класса таким abominable типом или все таки какие-то специальным типом для "функция-член класса"

А это замечание в стандарте полностью проясняет намерение авторов: тип функции-члена класса - это классический функциональный тип (возможно abominable), не какой-то специальный тип "функция-член класса".

0

Сообщение от TheCalligrapher тип функции-члена класса

не существует.

0

Сообщение от TheCalligrapher возможно abominable

abominable означает "омерзительный". Это улучшает положение дел. Когда я впервые столкнулся с вопросом меня заинтересовало а понимают ли те кто придумал синтаксис методов класса насколько это отвратительно. И было ощущение, что не понимают. Теперь видно, математики вполне разумные люди, в определённом смысле. Просто, придерживаться единой логики в реальной, предметной области (вне математики) они не хотят. Математика - штука само дисциплинирующая, а предметная деятельность требует создания руководящего документа. Это очень сложная задача в большом проекте. Но если нет приличного тех задания то и тех-условия (стандарт) будет ещё хуже.
Метод класса Class, это обычная функция но со скрытым параметром типа Class *const. Этот прискорбный факт говорит о том, что объект класса, это в принципе (принципиально) по природе своей - левостороннее значение. Но если с этим согласиться, то нарушается равноправие классов и старых С-структур, а так же фундаментальных типов. Можно было бы оставить за структурами семантику С а классы сделать Типами Lvalue. Но решили этого не делать и спорить с природой (логики).
Беда в том, что если допустимо создание временных объектов на которые нельзя взять адрес, то нельзя сделать указатель this параметром по умолчанию для метода класса. То есть (псевдокод - не компилируется) :
не допустим. Хотя можно было бы это разрешить, не разрешая вызов без объекта и оператора доступа, либо без передачи указателя в явном виде как параметра. Сложности с перегрузкой? Да. Есть немного. Кто-то может захотеть определить свободный метод вне класса с сигнатурой и именем типа
... Ну и что? Мало не однозначностей при перегрузках? Можно завершить компиляцию с сообщением и пусть клиент сам думает. Или более драконовски - запретить так делать и всё. В конце концов функция принимающая указатели или объекты класса - часть его интерфейса и можно бы проявить жесткость в рамках стройной логики. Лучше всего было бы запретить определение функций принимающих указатель на объект последним параметром. Можно затребовать неиспользуемый параметр как это делается с некоторыми операторами, например. Параметр void очень пригодился бы.
Например:
свободная функция принимающая указатель на объект. Имя будет менглировано с гарантированным отличием от имени функции члена.
Однако сделано как сделано. Нельзя написать:
Это избавляет от проблемы вызова на временном объекте тиипа:
Сейчас, такие вызовы возможны, если метод не обращается к адресу объекта.
Но такие проблемы есть у методов возвращающих ссылку на объект, например и ни кто не умер...
В общем, нельзя теперь выбрать вызвать:
или
а жаль. Теперь для связывания объекта и его метода нужны специальные приёмы. И запрещено получение адреса на метод -не статический член класса. Вернее, - создание переменной - указателя, хранящего такой адрес, вне объекта класса невозможно.
Хотя, конечно. Каждый может относиться к данному факту по своему. Я высказал свою точку зрения. Далеко не безгрешную и далеко не полную.

Добавлено через 2 часа 43 минуты

Сообщение от IGPIGP Вернее, - создание переменной - указателя, хранящего такой адрес, вне объекта класса невозможно.

То есть возможно. Но зачем?
Впрочем, это применимо для доступа через объект, объявления параметра шаблона, биндинга конкретного метода к объекту... Но типом это считать нельзя. Хотя приходится.

0

Сообщение от IGPIGP cout<< ptrfoo << endl ;//фейковое значение 1 ))))

Это не фейковое значение. Это результат приведения указателя к bool.

Сообщение от IGPIGP но у этого костыля нет доступных операций.

2

Сообщение от DrOffset Это не фейковое значение. Это результат приведения указателя к bool.

Да, - погорячился. Выходит адрес можно вывести так, например:
Но что с ним делать вне объекта?

Сообщение от DrOffset но у этого костыля нет доступных операций.

Пример который вы привели очевиден, однако это не операция на типе "указатель на метод". Это операция на объекте класса. При чём доступ оператором точка произведен по имени, который в классе отсутствует (в общем случае). То есть, в данном случае работает логика притянутая за уши. Не ваша. Вы говорите о том, что известно и реализовано в языке. Я говорю о логике реализованной в языке.
DrOffset, я не готовлю всемирное восстание. Я говорю о противоречиях, которые плохо разрешимы даже путём притягивания за уши. Уши уже километр, а люди никак не могут понять, почему указателя на функцию не достаточно для доступа к методу класса. Тут же вопрос не на уровне "системного программирования" (как говорил один из участников). Это вопрос о противоречивости абстракций уровня класса и объекта - высших уровней языка.
ps. даже цитата из стандарта пытается спорить с ... языком.

0

Сообщение от IGPIGP однако это не операция на типе "указатель на метод". Это операция на объекте класса.

Немного в сторону пример. Допустим мы сделали такой оператор +
И применяем его так:
Операция на каком типе у нас? Это же бинарная операция? Очевидно, что в ней участвуют оба типа, нет?
Так в чем же разница с предыдущим примером?
Там у нас с одной стороны объект класса, а с другой - указатель. И они оба участвуют в применении операции .*. Нет?

Сообщение от IGPIGP а люди никак не могут понять, почему указателя на функцию не достаточно для доступа к методу класса.

Ну вот в примере выше люди могут понять, что для того, чтобы получить x - нужно и obj и v? В чем же тогда проблема?

0

IGPIGP,

Да, - погорячился. Выходит адрес можно вывести так, например

Нельзя так делать.

0

Сообщение от Croessmah Нельзя так делать.

Croessmah, не о том речь. Можно это не только "дозволено", но и достижимо. Croessmah, этот вопрос в стороне от главного. Хотя, если вспомнить цитату о том что тип - функция (указатель или ссылка не важно) он един и нет специального типа - указатель на метод, то я привёл пример о том, что это абстракции разных уровней (как оно реализовано) и одним типом они быть не могут. Это не зависит от того, захотел кто-то это написать или нет. У обычного метода можно взять адрес, сохранить в указателе (распечатать если надо) и вызвать на нём функцию. А поскольку методы не реализованы как функции ( с возможностью явной передачи указателя или ссылки на объект) то и нельзя считать функции и не статические методы чем-то родственным по типу. Это я хотел сказать.

Сообщение от DrOffset Допустим мы сделали такой оператор +

Сообщение от DrOffset Операция на каком типе у нас?

Если это операция в классе - она вызывается на объекте класса. Безотносительно того, что может иметь второй аргумент. А когда она свободная - это функция а не метод. Бинарные операции типа сложения лучше делать свободными (позволяя автоматические преобразования аргументов), обычно) Но вы же понимаете о чём я говорю? Или нет?

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

Сообщение от IGPIGP Croessmah, не о том речь. Можно это не только "дозволено", но и достижимо.

О том, что размеры могут не совападать я знаю. И получить доступ к данным нужного размера (хакнуть) тоже можно. Но это частности.

0

Сообщение от IGPIGP А поскольку методы не реализованы как функции ( с возможностью явной передачи указателя или ссылки на объект) то и нельзя считать функции и не статические методы чем-то родственным по типу

На самом деле я бы согласился с мыслью о том, что синтаксис, который предлагается для указателей на члены, несколько костыльный. Но мне не нравится ваша манера аргументировать это через отсутствие логики или неумение составлять формальные документы у членов комитета. Я убежден, что в условиях, которые были даны (а они были даны, это не то же самое, что строить язык с нуля), члены комитета сделали все, чтобы это работало максимально логично.

Более того, работа в этом направлении продолжается:
http://www.stroustrup.com/multimethods.pdf
http://www.open-std.org/jtc1/s... /n4174.pdf
http://www.open-std.org/jtc1/s... 0131r0.pdf
http://www.open-std.org/jtc1/s... /n4474.pdf
http://www.open-std.org/jtc1/s... 0079r0.pdf
http://www.open-std.org/jtc1/s... 0131r0.pdf
https://isocpp.org/files/papers/P0251R0.pdf

http://www.open-std.org/jtc1/s... 214r0.html

Сообщение от IGPIGP Если это операция в классе - она вызывается на объекте класса. Безотносительно того, что может иметь второй аргумент.

По-вашему получается, что у типа int тоже нет доступных операций?

2

Сообщение от DrOffset На самом деле я бы согласился с мыслью о том, что синтаксис, который предлагается для указателей на члены, несколько костыльный. Но мне не нравится ваша манера аргументировать это через отсутствие логики или неумение составлять формальные документы у членов комитета.

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

Сообщение от DrOffset По-вашему получается, что у типа int тоже нет доступных операций?

Почему вы так решили?
Мы говорим о типах функций (ссылок или константных указателей - неважно) и указателей на функции.
Для типа int операцией (функцией с операторным синтаксисом вызова) является операция сложения (+) например. Но во-первых это свободная функция (зашитая но по духу). А мы же не о статических методах и свободных функциях говорим. мы говорим о нестатических методах - членах. И сравниваем их со свободными функциями. И мне кажется, чем больше будет утверждений о том что метод (н.ст.чл.) класса - это функция а не нечто особенное, тем больше будет вопросов о том, как жеж его инвокнуть...

0