А в каком виде ты себе представляешь такие «подсовывания»? Если я правильно понял, ты хочешь связывания (binding) на этапе компиляции. Но для связывания требуется объект, содержимое которого на этапе компиляции не известно. Т.е. получается, что компилятору придётся на ходу генерировать некую вспомогательную функцию, объект посылать как полуявный (заданный внутри <>, а не () ) параметр шаблонной функции и потом связывать его со сгенерированной вспомогательной функцией. Полагаю, для разработчиков компиляторов реализация такого – геморрой ещё тот... А в случае передачи cdecl вместо thiscall я вообще не представляю, что должно происходить (что будет делать cdecl-функция – игнорировать this-параметр? или параметров у неё должно быть на один больше, и один из них будет выступать в роли this?)

Цитата(archimed7592 @  13.11.2006,  21:26 )

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

Что-то идей пока нету, с чего б беседу начать. Вот коли появится какая мысл́я – подниму...

Это сообщение отредактировал(а) UnrealMan - 14.11.2006, 11:58

я представляю себе это так: семантически, ф-ция - это набор аргументов + возвращаемое значение. т. е. семантически разницы между f() и obj.f() и pobj->f() нету. чтобы работало следующее:т. е. чтобы в шаблоне описывалась только семантика, а реализация подставляется во время компиляции. как в #define...все равно компилятор генерит по экземпляру на каждую специализацию. собственно и все чего я хочу.

угу. во время компиляции. т. е. продвинутого препроцессинга 

что значит неизвестно? когда ты пишешь f () - все известно. когда пишешь obj.f () - тоже. в шаблоне же, на этапе специализации тоже все известно.

ну вот генерит компилятор конкретную специализацию. он все знает про эту ф-цию. зачем ему нужны какие-то вспомогательные вещи? точнее говоря может и нужны, но только для своего внутреннего представления структуры кода, но в итоговом бинаренике - как будто препроцессор поработал и наделал много copy-paste 

ну препроцессор же написали 

зы. а кто-нить располагает информацией, когда выйдет новый станадарт? 2007? 2008? 2009? как быстро появятся компиляторы для этого стандарта? в прошлый раз (в 2003 году) как быстро появились?

obj (или *pobj) – это один из аргументов функции, и от этого никуда не денешься.


Ну ты сравнил :-) Директивы препроцессора и шаблоны – это почти совсем разные вещи. Общее у них только то, что с помощью них можно создавать абстракции (а при их объединении можно получить более мощные абстракции).


Дело в том, что количество параметров, передаваемых в функцию в данных вариантах

temp_func<f> (...);
temp_func<obj.f> (...);

разное.


Ну, смотри:


Что будет при вызове функции pf в шаблонной функции Func? Очевидно, для корректного отрабатывания такого вызова нужен объект a. Откуда он возьмётся? Как ни крути, его придётся передавать в качестве отдельного параметра Func (подобно тому, как в вызове a.f() он в качестве отдельного параметра (this) передаётся в функцию f). Реализация шаблона сама должна везде подставлять неявный аргумент a при всяком вызове pf. Сигнатура у pf теперь не соотвествует её действительному статусу: да, используется она как void (pf)(), но в сущности это будет прежняя void (A:f)(), переданная как шаблонный аргумент. Это в общем-то серьёзный минус. Что, например, будет, если кто-то вдруг захочет присвоить pf некоторому указателю:



Ну, про вспомогательную функцию эт я загнул, конечно...


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

без сомнений. но я же сказал: семантически. ты же конкретно, ручками не передаешь этот аргумент? вот представь, как объясняют это начинающим в школе (или где ещё там)? что мол ф-ция просто исполняется в контексте конкретного объекта. или про ссылки. что это просто "синоним" переменной. так ведь? вот с точки зрения начинающего разницы между вызовом этих двух ф-ций нет:если он конечно не передает константу вместо переменной (но тогда он получает ошибку компиляции - то же самое можно выдать, когда не получается использовать данную ф-ции в этом шаблоне)...
ну как откуда. естественно не с потолка 
значит ещё раз как я себе это представляю: вот есть у наc зашаблоненный qsort. берем и пишем
что я хочу, чтобы из этого получилось: 3 ф-циит. е. обычный копи-пэйст. что же касается контекста thiscall, т. е. того заветного лишнего аргумента - ну как-то он должен передаваться в ф-цию (если она не inline - иначе вопросов вообще никаких не должно быть) средствами компилятора - это уже его проблемы - через стек или через регистры...не суть важно, главное, что проблемы в этом никакой нет.

зы. кстати, насчет передачи this...вот взять какой-нить шаблончик из нэймспейса std и передать ему в качестве аргумента ф-цию из другого нэймспэйса? компилятор же допетривает, что так и так и что это имя из другого нэймспэйса. т. е. как-то он эту ситуацию разруливает. не лучший пример, конечно, но, тем не менее, если задуматься, то семантически разницы между этими вещами большой нету. ну объект, ну нэймспэйс...у нэймспэйса адреса, правда, нету, но это так, мелочи... 
я отлично понимаю, что звучит все это как-то неубедительно...может даже глупо, но если именно с "глупой" точки зрения на это посмотреть, забыв про тот низкий уровень, где есть разница между stdcall и thiscall, между byval и byref, то идея вполне имеет право на жизнь...

Имеет. Только толку будет не много. В том варианте, что ты предлагаешь буду куча кодогенирации. Ещё проблема - это контроль времени жизни obj.
Для С++ существует много различных релизаций обобщенных обратных вызовов и делигатов. Поэтому насущей необходимости в добавлении чего-то на подобие это в язык, мне кажется, нет.