Здравствуйте, valker, Вы писали:

V>При прочтеннии этой ветки пришла такая мысль, почему бы не трактовать функции-члены, как обычные функции, но с дополнительным параметром в начале списка — аналогом this, передающимся неявно.

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

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, shank, Вы писали:

NB>>>и в этом плане он не отличается от указателя на мембер.
S>>Я о другом, указатель на функцию является "просто" указателем (pointer), как и указатели на объекты, тогда как указатель на функцию-член — это pointer-to-member, совершенно другая группа типов.

NB>"просто" указатель -- низкоуровневая абстракция.
NB>вот лично ты видишь логические основания не считать pointer-to-member указателем?
Скажем так:
"просто указатель" — это смещение в некотором хранилище, по которому находится некоторый объект.
pointer-to-member — это смещение члена от смещения в некотором хранилище, по которому находится некоторый объект.

Код ф-ии члена хранится только в одном месте, делая похожей ф-ию-член на обычную. Следовательно можно было бы использовать "просто указатель" на ф-ию-член. Однако это абсолютно не работает по отношению к членам-данным (см.определения выше). Поэтому создали универсальную сущность pointer-to-member...

Личное мнение — неудобств это не вызывает, а четко отделенное понятие упрощает понимание.

Здравствуйте, Аноним, Вы писали:

А>Код ф-ии члена хранится только в одном месте, делая похожей ф-ию-член на обычную. Следовательно можно было бы использовать "просто указатель" на ф-ию-член. Однако это абсолютно не работает по отношению к членам-данным (см.определения выше). Поэтому создали универсальную сущность pointer-to-member...

Я не против того что это отдельная сущьность. Мне не удобно что у этой сущьности поведение отличается от поведения
похожих сущьностей.

А>Личное мнение — неудобств это не вызывает, а четко отделенное понятие упрощает понимание.

Не вызавает когда пользуешься не часто.
http://www.rsdn.ru/Forum/Message.aspx?mid=2051884&only=1

Автор: night beast
Дата: 10.08.06

.

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, shank, Вы писали:

S>>Указатели (на объекты, функции, void) и указатели на нестатические члены класса относятся к разным группам типов, с т.з. стандарта, ничего здесь не поделаешь. Причина этому, наверное, тот факт, что указатели, обычно, представляют собой адрес, тогда как указатели на члены — не совсем.

NB>дело в том, что указатель на функцию в общем случае не может быть преобразован к указателю на void (что справедливо для обычных объектов).
NB>и в этом плане он не отличается от указателя на мембер.

Гляньте пример в Detours.

//////////////////////////////////////////////////////////////////////////////
//
// Test a detour of a member function (member.cpp of member.exe)
//
// Microsoft Research Detours Package, Version 2.1.
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
// By default, C++ member functions use the __thiscall calling convention.
// In order to Detour a member function, both the trampoline and the detour
// must have exactly the same calling convention as the target function.
// Unfortunately, the VC compiler does not support a __thiscall, so the only
// way to create legal detour and trampoline functions is by making them
// class members of a "detour" class.
//
// In addition, C++ does not support converting a pointer to a member
// function to an arbitrary pointer. To get a raw pointer, the address of
// the member function must be moved into a temporrary member-function
// pointer, then passed by taking it's address, then de-referencing it.
// Fortunately, the compiler will optimize the code to remove the extra
// pointer operations.
//
// If X::Target is a virtual function, the following code will *NOT* work
// because &X::Target is the address of a thunk that does a virtual call,
// not the real address of the X::Target. You can get the real address
// of X::Target by looking directly in the VTBL for class X, but there
// is no legal way to 1) get the address of X's VTBL or 2) get the offset
// of ::Target within that VTBL. You can of course, figure these out for
// a particular class and function, but there is no general way to do so.

Там преобразование идет через & (PVOID &)

Здравствуйте, Аноним, Вы писали:

А>Код ф-ии члена хранится только в одном месте, делая похожей ф-ию-член на обычную. Следовательно можно было бы использовать "просто указатель" на ф-ию-член.

Нельзя, чтоб позвать функцию-член нужно иметь this, а this-ы бывают разные при множественном наследовании ЕМНИП где-то преобразования this делают специальные прокладки в пару команд, так что и код в одном месте не хранится.

Здравствуйте, Bell, Вы писали:

B>Здравствуйте, night beast, Вы писали:

NB>>Недавно столкнулся с такой непонятной штукой.

NB>>Указатель на мембер-функцию не является указателем.
B>Да, это более сложная сущность.

NB>>Какие причины такого решения?
B>Ну хотя бы то, что размеры указателя и указателя на член в общем случае не совпадают.

Cам разок на это натыкался и выяснил, что в .Net ++'ом компиляторе размеры совпадают, а в gcc (на тот момент под рукой был 2.9.x) нет.
2-варианты, либо реализация зависит от компилятора, либо один из них не"до"поддерживает стандарт, по части указателей на мембер классы

Здравствуйте, night beast, Вы писали:

NB>Недавно столкнулся с такой непонятной штукой.
NB>Указатель на мембер-функцию не является указателем.
NB>Какие причины такого решения?

Он им и не является. Когда мы говорим "указатель на функцию", мы имеем в виду нечто сложное, учитывающее сигнатуру конкретной функции. Когда мы говорим просто "указатель", мы мгновенно получаем кучу бенефитов: дуализм с массивами, создание по указателю, адресную арифметику... всего этого мы лишаемся при "указателе на функцию". Именно поэтому специализация к T* считает, что вам нужно нечто, что является честным указателем со всей его обвязкой, чем указатель на функцию на является. Попробуйте например на вкус вот такой код:

template<typename T>
struct is_pointer<T*> {  
  int test_pointer_properties(T* arg){
    T* next = arg++;
    next += 10;
    T* newobj = new T();
    delete newobj;
    T someobj = arg[0];
    arg = &someobj;
    return 0;
  }
};

Как вы там представляете указатель на функцию?

Здравствуйте, Tilir, Вы писали:

T>Как вы там представляете указатель на функцию?

на обычную функцию указатель приводим к (void *) и обратно. Он указатель, просто сам обьект не копируем и не имеет характеристики длинны. А дуализм массив-указатель ИМХО не всегда нужен, нужен дополнительный тип мутабельная_ссылка, чтоб к типу с адресной арифметикой в явную приводилась.

Здравствуйте, shank, Вы писали:

S>>>Размеры указателей на int и на double тоже "в общем случае" не совпадают.

B>>Неужели?

S>Угу.
S>Единственное, что гарантируется касательно размеров указателей, это то, что размер void* достаточен для того, чтобы "вместить" указатель на объект любого типа, а также то что sizeof(void*) == sizeof(char*). Больше никаких гарантий. (Это объяснялось где-то Steve'ом Clamage'ом, если мне склероз не изменяет).

Чисто гипотетически, это может пригодиться для машин со слишком широким словом данных (БЭСМ-6, IBM-360, какие-нибудь современные DSP). Одно слово — один double.
Машинный адрес — только пословно. Чтобы адресоваться посимвольно, нужно тащить ещё и сдвиг символа в слове.
Тогда указатели на числа и на выравненные структуры данных — это адреса, а указатели на символы — это уже пара (адрес,сдвиг).
Можно, конечно, пойти паскалевской дорогой, ввести тип упакованной строки... Типа, диалект для экзотической платформы.

Чуть-чуть пендатизма.

S>...а также то что sizeof(void*) == sizeof(char*). ...
В приведенной строчке надо либо убрать один знак =, либо видоизменить ее так:
(sizeof(void*) == sizeof(char*)) = true

Здравствуйте, Programador, Вы писали:

P>на обычную функцию указатель приводим к (void *) и обратно. Он указатель, просто сам обьект не копируем и не имеет характеристики длинны. А дуализм массив-указатель ИМХО не всегда нужен, нужен дополнительный тип мутабельная_ссылка, чтоб к типу с адресной арифметикой в явную приводилась.

Пока такого типа нет (и вряд ли будет), программист, особенно с опытом на C, волен ожидать от специализированного на "указатель" типа всё, что традиционно можно вытворять с указателем. Включая и то, что вам лично кажется не нужным