В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?

Здравствуйте, buka123, Вы писали:

B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
Кого именно? Класс или дефайн?

Начать можно с того, что получить файл после обработки препроцессором.

B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?

Не использовать имена методов, которые совпадают с функциями WinAPI

Здравствуйте, 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>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.

можешь наставить #undef где нужно

Здравствуйте, 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". Как можно отследить его и убить?

IDE какое?

Здравствуйте, buka123, Вы писали:

B>Но ведь можно сделать так, чтоб винапишный заголовок инклюдился позже.

У тебя тогда будет редкая каша из имён.

struct Foo
{
    void MessageBox();
};

#include <windows.h>

int main()
{
    Foo f; f.MessageBox();
}

/// превратится в

struct Foo
{
    void MessageBox();
};

.....

int main()
{
    Foo f; f.MessageBoxW();
}

Так что, на самом деле, правильный выход — обеспечить, чтобы винапишный заголовок всегда включался раньше. Даже если он тебе и не нужен в каком-то конкретном месте.
Чтобы снизить нагрузку на компилятор, помести #include<windows.h> в прекомпилированный заголовок (stdafx.h и т.п.)

Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.

Здравствуйте, Кодт, Вы писали:

К>Так что, на самом деле, правильный выход — обеспечить, чтобы винапишный заголовок всегда включался раньше. Даже если он тебе и не нужен в каком-то конкретном месте.
К>Чтобы снизить нагрузку на компилятор, помести #include<windows.h> в прекомпилированный заголовок (stdafx.h и т.п.)

К>Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.

Ага, пока с библиотекой какой не пересечется Ну а потом начнутся вопросы в форум, типа "а чё у меня линкер конструктор boost::archive::archive_exception не видит?"

Здравствуйте, 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