Я тут разбирался с аттрибутами и натолкнулся на упоминание attribute provider
Как я понял это некоторое расширение компилятора, которое работает ДО препроцессора и позволяет внедрять свой код в классы на основе аттрибутов.
Такая запись
[serializable, metainfo]
class A
{
public:
int x;
float y;
}
будет, например, преобразована (ну если написать соответсвующий attribute provider) в
Номера строк для отладки при этом не сбиваются. Можно так же генерировать статические функции.
Знаю так же, что Vc7\bin\atlprov.dll это есть провайдер для ATL, а больше ничего не знаю. Документации по написанию Attribute Provider я не откопал.
Вот и думаю — браться ли за это?
A>Документации по написанию Attribute Provider я не откопал. A>Вот и думаю — браться ли за это?
имхо не стоит. MS не предоставляет возможностей для написания собственного attribute provider'a, т.к. текущие провайдеры плотно привязаны ко внутренностям компилятора. они уже много лет обещают переписать всю эту систему нормально, чтобы провайдер можно было написать не обладая исходниками компилятора, но судя по всему так никогда и не возьмутся (если я не ошибаюсь они еще в 2002 году говорили что мол "в следующем релизе, или через один")...
хотя возможно в VS2005 ситуация изменилась, не знаю, возможности посмотреть на неё нет
Здравствуйте, adontz, Вы писали:
A>Я тут разбирался с аттрибутами и натолкнулся на упоминание attribute provider A>Как я понял это некоторое расширение компилятора, которое работает ДО препроцессора и позволяет внедрять свой код в классы на основе аттрибутов.
A>Такая запись A>
A>[serializable, metainfo]
A>class A
A> {
A> public:
A> int x;
A> float y;
A> }
A>
будет, например, преобразована (ну если написать соответсвующий attribute provider) в A>Вот и думаю — браться ли за это?
Имхо Microsoft Specific C++ is evil. Все расширения языка которые они намутили изза своей кривизны
конеченостей делают код непортабельным.
Недавно прочуствовал на себе __try __catch так и не реализован в mingw GCC
Все то же самое можно получить еще 3мя путями так что я предпочту любой из них.
может все дело в том что я и ATL не люблю ?
wbr
Здравствуйте, adontz, Вы писали:
A>Я тут разбирался с аттрибутами и натолкнулся на упоминание attribute provider A>Как я понял это некоторое расширение компилятора, которое работает ДО препроцессора и позволяет внедрять свой код в классы на основе аттрибутов.
Не стоит, имхо, с атрибутами заморачиваться. Просто по тому, что эта технология еще не доделана, то есть не для публичного использования.
Здравствуйте, SleepyDrago, Вы писали:
SD>Имхо Microsoft Specific C++ is evil. Все расширения языка которые они намутили изза своей кривизны SD>конеченостей делают код непортабельным.
А я себе и не представляю портабельный Code Injection Тем более, что под винду mainstream компилятор всё таки MSVC и дело не представляется совсем уж бесполезным. А embedded IDL как ни крути удобнее отдельного файла.
SD>Все то же самое можно получить еще 3мя путями так что я предпочту любой из них.
Перечислишь хоть какие-то? А то число 3 вызывает у меня впечатление необразованности.
SD>может все дело в том что я и ATL не люблю ?
А кто любит? Хотя аттрибуты предоставляемые именно ATLProvider ИМХО вполне можно заменить на другие конструкции с аналогичной функциональностью.
Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, SleepyDrago, Вы писали:
SD>>что я и ATL не люблю ?
ssm>я сам не люблю, пишу и плачу ssm>но что делать, альтернативы то нет
Есть, по крайней мере именно так позиционируется — http://www.lambdasoft.dk/comet/index.htm
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, SleepyDrago, Вы писали:
SD>>Имхо Microsoft Specific C++ is evil. Все расширения языка которые они намутили изза своей кривизны SD>>конеченостей делают код непортабельным.
A>А я себе и не представляю портабельный Code Injection Тем более, что под винду mainstream компилятор всё таки MSVC и дело не представляется совсем уж бесполезным. А embedded IDL как ни крути удобнее отдельного файла.
SD>>Все то же самое можно получить еще 3мя путями так что я предпочту любой из них.
A>Перечислишь хоть какие-то? А то число 3 вызывает у меня впечатление необразованности.
Имхо я и не надеюсь на magic tool который сам догадается как надо сериализовать мои данные
Мне нужно чтобы он :
а) работал надежно
б) не был тормозом всей системы
в) допускал ручное управление в аварийном режиме
вот
а насчет code injection и прочей "красоты" мое имхо все это от лукавого
самый простой способ из 3х это написать ручками.
После того как я пришел к выводу,
что время набора текста программы это копейки по сравнению со всем остальным
я нашел триальный вижуал ассист и перестал напрягаться на эту тему.
Если есть текстуальные повторы то тут рулят локальные макросы.
А на самый интересный случай можно попробовать замутить предка с typelist'ом в качестве аргумента ...
{ кстати стало интересно замутить — а то еще для typelist не видел практической пользы }
В общем there are many ways to skin a cat
Кстати раз номера строк в отладчике не съезжают то какие номера имеют строки в теле injected кода и как там брякнуться?
Здравствуйте, SleepyDrago, Вы писали:
SD>а) работал надежно
+1 SD>б) не был тормозом всей системы
+1 SD>в) допускал ручное управление в аварийном режиме
+1
SD>а насчет code injection и прочей "красоты" мое имхо все это от лукавого SD>самый простой способ из 3х это написать ручками. SD>После того как я пришел к выводу, что время набора текста программы это копейки по сравнению со всем остальным я нашел триальный вижуал ассист и перестал напрягаться на эту тему.
Если есть текстуальные повторы то тут рулят локальные макросы.
А на самый интересный случай можно попробовать замутить предка с typelist'ом в качестве аргумента ... SD>{ кстати стало интересно замутить — а то еще для typelist не видел практической пользы }
А это кстати было бы круто генерировать QueryInterface на основе TypeList'а...
SD>Кстати раз номера строк в отладчике не съезжают то какие номера имеют строки в теле injected кода и как там брякнуться?
Они видны только в окне Diassembly и отлаживать их кроме как оттуда никак не выйдет.
Но если очень хочеться, то указав компилятору опцию /Fx можно получить файл после применения аттрибутов (генерируется в отдельный файл, в отличие от показа preprocessed source нормальной компиляции не мешает).
Здравствуйте, adontz, Вы писали:
SD>>а) работал надежно A>+1 SD>>б) не был тормозом всей системы A>+1 SD>>в) допускал ручное управление в аварийном режиме A>+1
A>Они видны только в окне Diassembly и отлаживать их кроме как оттуда никак не выйдет. A>Но если очень хочеться, то указав компилятору опцию /Fx можно получить файл после применения аттрибутов (генерируется в отдельный файл, в отличие от показа preprocessed source нормальной компиляции не мешает).
Имхо я за явный и наглядный способ. Чтобы глядя на класс не надо было долго вспоминать откуда там функции serialize_in и тп и почему оно там падает А то через пару лет и среди ночи ...
?
