Страниц: [1]
  Печать  
Автор Тема: ошибки в template  (Прочитано 8020 раз)
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« : Апреля 27, 2006, 04:24:22 pm »

как можно обойти такое http://pastebin.com/684724

PS самый, казалось бы, подходящий вариант не работает:
1: template<class C, class T, T (C::*fun) ()> class G
2:  { ..
3: ..
// [T: int]
..  class B { public: int fun () {return 0;} ..

wpp:

test.cpp(1): Error! E241: (col 28) 'class C' has not been declared
test.cpp(4): Error! E562: (col 14) cannot take address of non-static member function
test.cpp(4): Note! N630: (col 14) source conversion type is "void (B::* )( void )"
test.cpp(4): Note! N631: (col 14) target conversion type is "void (* )( void )"
Записан
Wlad
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #1 : Апреля 27, 2006, 10:13:27 pm »

яков
как можно обойти такое

::* указатели - не есть ссылка в память. Это - просто некий "индекс метода". Без описания всего класса компилятор не может, ессно, определить к чему же вы всё-таки "потом" попытаетесь обратиться.

У меня, в libao, для того, что бы метод (не статический!) стал носителем активности объекта (аналог функции потока), я ввёл следующие описания:

typedef struct AO_t { } AO_t;
typedef void ( AO_t::*AO_func_t ) ();


Более это нигде никак не используется, кроме, как в запускающем активность методе класса Activity_t:
...
void Start( AO_t*, AO_func_t, const char*, const char*, ...  );
...


В свою очередь, вызов метода Start в нужном месте активного объекта (практически всегда – в конструкторе), выполняется через макрос, в котром, как раз и происходит "приведение типов":

#define ACTIVITY_START(C, A, OwnerName) 
  A.Start(  (AO_t*)this,  (AO_func_t)&C::A##_func,  #A,  OwnerName, ... )


где:  C – имя класса, куда вводится активность
      A – имя переменной активности в этом классе
      OwnerName – имя "объекта-владельца" данной активности
           
(для особых "ценителей-извращенцев" от Си++, можно использовать reinterpret или static(?) -приведение, но, в данном случае, особого смысла в этом нет)

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

#define DECL_ACTIVITY(A)  Activity_t A;void A##_func()
#define ACTIVITY(C,A)     void C::A##_func()


первый вариант, используется так:

class AAA
{
    ....
    DECL_ACTIVITY(MyActivity)
    {
         тут ваш код, как и для нормальной функции
    }
    ...
};


второй

class AAA
{
    ....
    DECL_ACTIVITY(MyActivity); // просто объявление, определение ниже, вне описания класса
    ...
};
...
ACTIVITY( AAA, MyActivity)
{
    ...
}


Всё, класс готов выполнять свои методы в отдельных потоках...

Я немного отвлёкся "на свою волну", но, только лишь с целью иллюстрации... :о)

Короче говоря, аргументом указателя на метод может быть совершенно "левый тип" указателя на метод "совершенно левого" класса. Главное, что бы было приведение к нужному обобщённому типу в том месте, где вы вызываете метод + определён экземпляр объекта, для которого вы вызываете этот метод...

Не пытайтесь приводить к void* и обратно – компилятор не пропустит. void* - не "чистый" ООП тип. Или вообще к "нормальному указательному типу". Просто запомните, что ::* - по смыслу, индекс, а не указатель.

К вопросу о множественном наследовании – всё будет зависеть от реализации компилятора и организации способа хранения ссылок на методы. Может и не сработать или вызваться, "не то" (смотря, от vtbl какого предка вы будете "плясать".

Вообще, всего этого головняка в языке не было бы, если бы предусмотрели делегаты. А так -  "маемо, те що маемо"... :о)
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #2 : Апреля 28, 2006, 10:42:43 am »

спасибо за развернутый ответ


Wlad
::* указатели - не есть ссылка в память. Это - просто некий "индекс метода". Без описания всего класса компилятор не может, ессно, определить к чему же вы всё-таки "потом" попытаетесь обратиться


должно быть так, что компилятор выводит всю информацию из параметров шаблона (как я показывал):
template<class C, void (C::*foo)..

Wlad
typedef struct AO_t { } AO_t;
typedef void ( AO_t::*AO_func_t ) ();


надо бы попробовать с этой заглушкой..
btw, не помните watcom10.6 позволяет иметь нечто такое

class A {
public: template<class C> A () {} };   ??

10x!
Записан
Wlad
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #3 : Апреля 28, 2006, 06:22:06 pm »

яков
должно быть так, что компилятор выводит всю информацию из параметров шаблона

Должно быть так, что компилятор попытается это сделать там, где сможет... :о)
яков
не помните watcom10.6 позволяет иметь нечто такое

class A {
public: template<class C> A () {} };

Честно - не помню. Сейчас нет времени и желания в стандарт и в александресковские бредни лазить за аналогиями и пояснениями... :о)
Насколько я понимаю, вы страстно желаете "привить" классу А некую функциональность, описанную "общими словами" в классе С, с частичной реализацией её с помощью некоторых методов самого же класса А? Рекурсивность в объявлениях не смущает? Если у вас получится такое "разгрести", сообщите подробности. Меня подобные случаю интересант.
Может пусть лучше сердце успокоится простым перекрытием виртуальных методов из С в А? Или очень хоцца с шаблонами поиграться? Тогда полезней будет сразу на Лисп переходить... :о) Там хотя бы всё по уму изначально... Да и по-мощнее Си++-потуг будет...
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #4 : Апреля 30, 2006, 08:29:08 pm »

Wlad
Рекурсивность в объявлениях не смущает? Если у вас получится такое "разгрести", сообщите подробности.

nfrj
не буду на вс цитировать. слог у вас самобытный btw такой какойто малость колхозно-крестьянский..

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

Щас мне стало интересно насколько надо переделать подложку template для watcom10.6  Очень нетривиальная задача надо вам сказать

ЗЫ мой вам совет не фамильярничайте так с С++ -- в каждой области есть своя терминология, неплозо бы ее знать.

Wlad
александресковские бредни


меня улыбает подход по типу "а не знаю куда ето надо => в топку и КГ/АМ etc"..  Както по-детски, можно это 8класнику прочтить, но вы вроде не мальчик уже?!
Записан
Wlad
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #5 : Мая 02, 2006, 12:30:47 am »

Щас мне стало интересно насколько надо переделать подложку template для watcom10.6 Очень нетривиальная задача надо вам сказать

В смысле? – в самом компиляторе поддержку? Или использование классов-шаблонов для классов-обёрток над средствами Фотона?
Я сделал уже пару хидеров для своих оберток для фотона. получилось очень модерново: сигналы, свойства, которые можно связывать (bind).

"Модерново" – это как? С полной интеграцией со средой PhAB-а? Через промежуточную работу плагинов Эклипса?
не буду на вс цитировать.

Цитировать из каких мест и по поводу?
слог у вас самобытный btw такой какойто малость колхозно-крестьянский..

Нужно цитирование. Укажите – где такое... Если – взагали, так уж извиняйте, как у Жванецкого: "Наконец, ты начинаешь говорить так, как они понимают..."
ЗЫ мой вам совет не фамильярничайте так с С++ -- в каждой области есть своя терминология, неплозо бы ее знать.

Вот здесь как раз и пригодилось бы цитирование... Именно для того, что бы указать на "фамильярничание". При всём вашем возможном недовольстве, оставляю за собой право именно такого стиля. Во-первых, считаю, что достаточно хорошо знаком с миром ООП-языков, что бы писать на уровне, понятном тому, кто хотя бы десятой частью моего опыта, в данном вопросе, владеет, а, во-вторых, - мы не на ВАКе... :о)
меня улыбает подход по типу "а не знаю куда ето надо => в топку и КГ/АМ etc".. Както по-детски, можно это 8класнику прочтить, но вы вроде не мальчик уже?!

"Меня улыбает" – это теперь так выражаться "модерново"? Ну а меня "улыбает" подход, при котором кидаются на "изобрЕтенья", не пытаясь даже элементарно оценить, что куда "притыкается" и какую РЕАЛЬНУЮ пользу от этого иметь можно...
Уверяю вас: и прочитал, и могу вам своего александреску показать, сколько там на полях карандашных пометок и замечаний. Это всё хорошо, пока "пляшет" в чётко очерченном круге задач и идеологии, а как чуть в сторонку шагнёшь – опять головняк. Конкретно у меня к товарищу две главных претензии: по первой главе и по приложению. Собсна, всё, что между – строится та этих двух "кочках". Но в каждой из этих тем, на мой взгляд, есть несколько "вольных допущений", из-за которых я с ОЧЕНЬ большой оглядкой буду его советы применять. По первой главе всё получается кучеряво, если не обращая внимание на элементарные постулаты ООП и ООД делать напрямую, "всё как есть". Выход по коду может быть и улучшится, но по идеологии можно прийти к противоречиям. Не случайно, даже один из знакомых программеров из google, в переписке со мной по поводу libao, по-началу также горячо советовал все активные объекты "образовывать" через параметрическое наследование от класса активности. Я не был согласен. Дискуссия растянулась на несколько писем, но закончилась, когда я напомнил Патрику про два простых волшебных ключика-словосочетания в мире ООП: "IS-A" и "HAS-A"... :о) Подход со стратегиями александреску – не всегда срабатывает адекватно с построенной (или переданной нам кем-то другим) моделью предметной области, а использовать средство только ради "красивости" или "модерновости" – согласитесь, подход, несколько странноватенький. Я не говорю,  что, безоговорочно "фтопкуего!", просто взвешенно надо к оценке предлагаемых средств и инструментов...
И по многозадачности а ля александреску проектировать и использовать не буду – своё написал.
Всё его Loki, по идеологии реализации многозадачности очень перекликается и с ACE и с остальными "библиотеками": ничего кардинально нового, всё та же "обёрточность" + очень узкое трактование семантики и "времени жизни" блокировок. Очень ограниченный подход. Ограниченность обуславливается абсолютным отсутствием средств и подходов к обеспечению безопасного выхода из аварийных ситуаций (точнее – аккуратного возвращения состояний ресурсов и потоков в "нормальное" после удаления потока или объекта). В libao я вообще обхожусь без понятия "поток", "мьютекс" и "условная переменная". Там другие понятия элементов исполнения и синхронизации. Естественно, "внизу" они базируются на POSIX-средствах, но на прикладном уровне эти средства отсутствуют, не "захламляя" тем самым предметную область. А в других библиотеках вы всегда будете иметь очередные обёртки над "потоком", "мьтексом" и остальным низкоуровневым хозяйством. Плюс к этому, вас обяжут обязательным образом связываться (для "эффективности" и "модерновости", канечна!) с "умными указателями", потому, что именно так вам навяжут (переложат на ваши плечи!) "изячный" способ определения времён "залочивания" используемых объектов. Это – 100%! Да только вот беда, иногда законы функционирования систем нашего класса (РВ, если вы не забыли... :о) ), не совсем согласуются с законами, устанавливаемыми такими "модерновыми" библиотеками. Как-то очень не любят ни Шилдт, ни Александреску обращать внимание на то, что у меня залоченный объект может быть аварийно удалён, или, что поток, владеющий, в какой-то момент целой "кучей" залоченных объектов ( например, через "мьютексы" ), может быть "прибит" каким-либо другим потоком... Было гладко на бумаге, в статьях... А вот в жизни несколько всё прозаичнее, трагичнее и грязнее... :о)  И я вот в силу своего стиля ( "крестьянско-колхозного" ), хвала Господу, как-то научился эти "неприятные моментики" "разгребать". Реализация несколько извратно-нестандартная, согласен, но библиотека удовлетворяет цели, поставленной при её проектировании: привить "на почву" Си++ активные объекты (настоящие, в духе Активного Оберона и Зоннона, а не галиматью, типа Шилдта или Александреску). И она применяется для реальной работы в реальных проектах.
Кстати, опыт этой разработки, заставил на очень многие вещи взглянуть по-другому. В том числе и, например, на полезность и правомерность, что ли, "прививания" POSIX-варианта реализации многопотоковости для ОСей, класса QNX.

В заключении, яков, совет вам: не считайте, что обладание каким-либо средством реализации, делает вас уж настолько компетентным за пределами сфер применения этого средства. Если проводить параллели: многие выдающиеся талантливые люди были "со странностями". Но это абсолютно не значит, что подражая им своим поведением или "проявлениями", вы автоматом достигнете их уровня мастерства и таланта. Выбор в качестве языка реализации проекта Си или Си++ никак не прибавляет проекту каких-то очень выдающихся свойств или шансов на качественную реализацию. В большинстве своём, такой выбор обуславливается просто потому, что "взяв с улицы" любого "мальчика", вы на 100% будете уверены, что он вам заявит, что он де "знает Си/Си++"... Эти "мальчики" – просто винтики в четком рыночном механизме производства-скармливания. Качествами языков, конкретно Си/Си++, этот выбор никак не определён. Более того, могу вас заверить, что для выполнения тех же самых проектов, с качеством, несомненно более высоким, существует масса средств, которые просто оказались не в "мэйнстриме"... Скажем, в большинстве случаев, то, что предлагается Си++ в качестве очередной, ещё одной новейшей и эффективной,  революционной "фичи", в том же Лиспе работает уже с лет тридцать... И реализовано оно там более логично и стройно + требует меньше затрат на освоение и применение в проектах. Как сказал один хороший программист из Белоруссии: "я с трудом делаю на Лиспе за месяцы то, что сделал бы не напрягаясь за годы на Си++..." :о)
А Лисп я избрал в качестве контрпримера чисто "навскидку". Просто надо "за деревьями видеть лес".
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #6 : Мая 02, 2006, 10:53:51 am »

Wlad
Уверяю вас:


извините, многоуважаемый многомудрый Wlad, я до этого места дочитал а дальше, как говориться, EFBIG..  я такие огромные романы не читаю FYI

по теме: да, если вам действительно интересно и это не стеб, то с интеграцией с PhAB (какой еще эклипс??)

happy fsckn'
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #7 : Мая 02, 2006, 02:13:00 pm »

Wlad
Тогда полезней будет сразу на Лисп переходить... :о) Там хотя бы всё по уму изначально... Да и по-мощнее Си++-потуг будет...


в морг
Записан
Фдуч
Гость
« Ответ #8 : Мая 03, 2006, 05:41:16 pm »

яков
извините, многоуважаемый многомудрый Wlad, я до этого места дочитал а дальше, как говориться, EFBIG.. я такие огромные романы не читаю FYI

по теме: да, если вам действительно интересно и это не стеб, то с интеграцией с PhAB (какой еще эклипс??)


Яша, Влад дело говорит, это правда. Конечно несколько многословно и с реверансами всторону ему инетересных вещей, но...

Насчет вопроса - ну не вижу смысла в задаче, поэтому и ответа искать влом.

А Александреску Вы переболеете, да WBR
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #9 : Мая 04, 2006, 10:21:25 am »

Фдуч
А Александреску Вы переболеете, да WBR

я тоже нажеюсь что на тех вопросы вы научитесь отвечать техническими ответами или никак.

а то вы уже зае#$$# (c)  

я так и не понял при чем здесь Александреску..
Записан
Фдуч
Гость
« Ответ #10 : Мая 04, 2006, 12:17:02 pm »

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

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

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

За сим откланиваюсь.
Записан
яков
Участник
*
Offline Offline

Сообщений: 3


Просмотр профиля
« Ответ #11 : Мая 04, 2006, 02:17:14 pm »

ладно, последний камень в тебя Фдуч. проблем не возникает/ не возникнет, то что watcom10.6 подкачал, то это пока без надобности -- я посмотрел сколько потенциально надо переделывать/реорганизовывать или сколько н епридется чтоб сделать все это QNX4/QNX6..  

По делу: мне до лампочки какие там десятки, но когда я начинал я обшарил _все_ в поисках С++ над фотон и __ничего__ меня не утроило => я сделал свои. таких нет и мои пока самые правильные.

а то что было в топиках на тему там еще Olej вместе с остальными распинался -- так это просто некомпетентный малотехнический FUD

всиё  Wink
Записан
Страниц: [1]
  Печать  
 
Перейти в: