Тип указателя на функцию-член.

[Сионист]

Как его правильно декларировать? И как её по нему вызывать?

[Romeo]

Код: Выделить всё

class Class
{
public:
	int Method1(float f)
	{
		return int(f + 10);
	}

	int Method2(float f)
	{
		return int(f + 20);
	}
};

int main()
{
	Class object;

	typedef int (Class::*MethodType)(float);
	MethodType mpMethod = NULL;
	int nRet = -1;

	mpMethod = &Class::Method1;	
	nRet = (object.*mpMethod)(3.14f);

	mpMethod = &Class::Method2;	
	nRet = (object.*mpMethod)(3.14f);

	return 0;
}

[Сионист]

А без & ни как? Вроде ж функция - и так указатель и присваивается без взятия адреса.

[Romeo]

Без & компилятор будет думать, что ты хочешь сделать вызов метода. Так что этот синтаксис обязателен так же, как и для обычной внешней функции.

[Сионист]

Скрин проекта с обычной функцией http://hkar.ru/Dhk6. Без &, хватило отсутствия скобок.

[Romeo]

Вообще-то о необходимости указывать амперсанд для получения адреса функции/метода оговорено в стандарте. Видимо это упрощает труд разработчиков компиляторов. Тем не менее некоторые компиляторы поддерживают упрощённый синтаксис для обычных функций. Проверил на студии, она, как и CodeBlocks, для обычной функции тоже кушает всё без &. На самом деле рекомендую делать именно по стандарту, так как легко можно напороться на компилятор, который упрощённый синтаксис не поддерживает и получить проблемы с портированием. Хотя портируемость кода тоже не всем нужна...

[Сионист]

Кодоблоки есть и для LINUX.

[Romeo]

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

К тому же даже один и тот же компилятор может вести себя по разному в разных платформенных имплементациях. Вот тебе пример, с которым я лично столкнулся месяц назад. Вроде бы всем известный линусковый gcc. Как бы нам его поиметь на Win? А без проблем, есть официальный порт gcc под Win, который называется MinGW. Написал я простенький пример с несколькими потоками, которые синхронизируются через самописный RW-mutex. Радостно заюзал 11-ый стандарт, так как gcc его поддерживает полностью. На линуксе откомпилил gcc - всё работает, как часы. Компилируем MinGW на Win, а он спрашивает: "Хозяин, а что это у тебя за класс такой std::mutex? Я его первый раз вижу!". После путешествия по штатовским программерским форумам, на которых сидят бородатые линуксоиды в заляпанных кетчупом футболках, нахожу подтверждение того, что мьютексы и кондишн вариэйблы действительно не поддерживаются в MinGW. Вот тебе и хвалёный официальный порт!

[Сионист]

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

Энто зачем же? Я ещё понимаю переехать с Win32 на Win64 и в связи с этим поменять компилятор. Но это тоже нифига не одна платформа. А просто так в пределах одной? Не понятно.

К тому же даже один и тот же компилятор может вести себя по разному в разных платформенных имплементациях. Вот тебе пример, с которым я лично столкнулся месяц назад. Вроде бы всем известный линусковый gcc. Как бы нам его поиметь на Win? А без проблем, есть официальный порт gcc под Win, который называется MinGW. Написал я простенький пример с несколькими потоками, которые синхронизируются через самописный RW-mutex. Радостно заюзал 11-ый стандарт, так как gcc его поддерживает полностью. На линуксе откомпилил gcc - всё работает, как часы. Компилируем MinGW на Win, а он спрашивает: "Хозяин, а что это у тебя за класс такой std::mutex? Я его первый раз вижу!". После путешествия по штатовским программерским форумам, на которых сидят бородатые линуксоиды в заляпанных кетчупом футболках, нахожу подтверждение того, что мьютексы и кондишн вариэйблы действительно не поддерживаются в MinGW. Вот тебе и хвалёный официальный порт!

Не знал, учту.

[Romeo]

Энто зачем же? Я ещё понимаю переехать с Win32 на Win64 и в связи с этим поменять компилятор. Но это тоже нифига не одна платформа. А просто так в пределах одной? Не понятно.

Самый простой пример, с которым сам сталкивался. Переход со студийного компилятора на IBM-овский, так как последний намного лучше оптимизирует код и может разогнать определённые участки в сотни раз, по сравнению с той же студией. Например, умеет работу с STL-евским вектором разворачивать в вызовы MMX команд процессора.