Здравствуйте, buka123, Вы писали:
B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
Кого именно? Класс или дефайн?
Начать можно с того, что получить файл после обработки препроцессором.
Здравствуйте, K13, Вы писали:
B>>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
K13>Не использовать имена методов, которые совпадают с функциями WinAPI
Такое не катит, слишком много на него завязанно.
Здравствуйте, Bell, Вы писали:
B>Здравствуйте, buka123, Вы писали:
B>>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить? B>Кого именно? Класс или дефайн?
B>Начать можно с того, что получить файл после обработки препроцессором.
Здравствуйте, buka123, Вы писали:
B>Здравствуйте, K13, Вы писали:
B>>>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
K13>>Не использовать имена методов, которые совпадают с функциями WinAPI B>Такое не катит, слишком много на него завязанно.
Если проблема в самих функциях API тогда, кто-то там у вас не прав. Либо используйте названия без A и W с расчётом на те самые дефаины. Либо используйте сразу с A и W, и тогда все эти дефайны не для вас...
Здравствуйте, buka123, Вы писали:
B>>Начать можно с того, что получить файл после обработки препроцессором.
B>Получил многомегабайтные файлы, а дальше что?
Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена?
Здравствуйте, Bell, Вы писали:
B>Здравствуйте, buka123, Вы писали:
B>>>Начать можно с того, что получить файл после обработки препроцессором.
B>>Получил многомегабайтные файлы, а дальше что?
B>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена?
Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
Здравствуйте, buka123, Вы писали:
B>Здравствуйте, Bell, Вы писали:
B>>Здравствуйте, buka123, Вы писали:
B>>>>Начать можно с того, что получить файл после обработки препроцессором.
B>>>Получил многомегабайтные файлы, а дальше что?
B>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
Здравствуйте, Caracrist, Вы писали:
C>Здравствуйте, buka123, Вы писали:
B>>Здравствуйте, Bell, Вы писали:
B>>>Здравствуйте, buka123, Вы писали:
B>>>>>Начать можно с того, что получить файл после обработки препроцессором.
B>>>>Получил многомегабайтные файлы, а дальше что?
B>>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
C>можешь наставить #undef где нужно
Можно, но как-то не круто
Здравствуйте, buka123, Вы писали:
B>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
ИМХО единственный выход — изменить эти имена. Иначе ты не сможешь защитить пользователей своего класса — любой новый #include может все сломать.
Здравствуйте, buka123, Вы писали:
B>Здравствуйте, K13, Вы писали:
B>>>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
K13>>Не использовать имена методов, которые совпадают с функциями WinAPI B>Такое не катит, слишком много на него завязанно.
А вариантов на самом деле только два:
— Переименовать ваши методы
— не инклудить windows.h там, где есть конфликт.
B>>Такое не катит, слишком много на него завязанно.
B>А вариантов на самом деле только два: B>- Переименовать ваши методы B>- не инклудить windows.h там, где есть конфликт.
B>Что проще — тебе виднее.
Есть еще третий вариант — там где используется "конфликтный класс" обрамлять имя класса в скобки. Это предотвратит макроподстановку. Но это, конечно, уж очень экзотический вариант. Что мешает переименовать класс, если исходники все под рукой?
Здравствуйте, buka123, Вы писали:
B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
Можно воспользоваться #undef или #pragma push_macro/pop_macro, но лучше все-же переименовать методы.
Здравствуйте, Анатолий Широков, Вы писали:
B>>Что проще — тебе виднее.
АШ>Есть еще третий вариант — там где используется "конфликтный класс" обрамлять имя класса в скобки. Это предотвратит макроподстановку. Но это, конечно, уж очень экзотический вариант.
Да, к тому же проблема с именами методов, коих много, и нет гарантии, что во вновь создаваемом коде не забудут про обрамление.
А еще веселее получиться, если сначала код с оригинальными именами будет компилится, а потом кто-то где-то подключит новый хедер, и все сломается
АШ>Что мешает переименовать класс, если исходники все под рукой?
ИМХО это единственный приемлемы вариант.
Здравствуйте, _Paul, Вы писали:
_P>Здравствуйте, buka123, Вы писали:
B>>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
_P>Можно воспользоваться #undef или #pragma push_macro/pop_macro, но лучше все-же переименовать методы.
Но ведь можно сделать так, чтоб винапишный заголовок инклюдился позже.
Приветствую, buka123, вы писали:
b> В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
Так что, на самом деле, правильный выход — обеспечить, чтобы винапишный заголовок всегда включался раньше. Даже если он тебе и не нужен в каком-то конкретном месте.
Чтобы снизить нагрузку на компилятор, помести #include<windows.h> в прекомпилированный заголовок (stdafx.h и т.п.)
Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
Здравствуйте, Кодт, Вы писали:
К>Так что, на самом деле, правильный выход — обеспечить, чтобы винапишный заголовок всегда включался раньше. Даже если он тебе и не нужен в каком-то конкретном месте. К>Чтобы снизить нагрузку на компилятор, помести #include<windows.h> в прекомпилированный заголовок (stdafx.h и т.п.)
К>Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
Ага, пока с библиотекой какой не пересечется Ну а потом начнутся вопросы в форум, типа "а чё у меня линкер конструктор boost::archive::archive_exception не видит?"
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, buka123, Вы писали:
B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
Кстати, хочу заметить: этот злодейский дефайн — это UNICODE, и он ничего никуда не добавляет.
Просто винапишные хедеры содержат примерно такие строки
int WINAPI MessageBoxA(HWND,LPCSTR,LPCSTR,UINT);
int WINAPI MessageBoxW(HWND,LPCWSTR,LPCWSTR,UINT);
#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif