В проекте есть класс, который страдает от дефайна 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

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

К>>Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
S>Ага, пока с библиотекой какой не пересечется Ну а потом начнутся вопросы в форум, типа "а чё у меня линкер конструктор boost::archive::archive_exception не видит?"

Как бы, дефайны — зло, это давно известно.
Но чтобы не было нарушений ODR и т.п. расхождений — надо все свои библиотеки компилировать в единой среде — например, в присутствии windows.h и в известном окружении дефайнов.

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

К>>>Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
S>>Ага, пока с библиотекой какой не пересечется Ну а потом начнутся вопросы в форум, типа "а чё у меня линкер конструктор boost::archive::archive_exception не видит?"

К>Как бы, дефайны — зло, это давно известно.
К>Но чтобы не было нарушений ODR и т.п. расхождений — надо все свои библиотеки компилировать в единой среде — например, в присутствии windows.h и в известном окружении дефайнов.

Угу, и как же предлагается обеспечивать присутствие windows.h в сторонних библиотеках? В бусте там или тем паче в wxWidgets с её winundef.h? Да, и почему такие полумеры — только windows.h? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде

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

S>Угу, и как же предлагается обеспечивать присутствие windows.h в сторонних библиотеках? В бусте там или тем паче в wxWidgets с её winundef.h? Да, и почему такие полумеры — только windows.h? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде

Ну или пользоваться исключительно стерильной средой для компиляции под сфероконическую ось.
Но что-то я не верю в её существование, поэтому лично я бы попробовал выхватить напильник и три раза вотще по всем используемым мной библиотекам, которые порождают конфликты.

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

S>>Угу, и как же предлагается обеспечивать присутствие windows.h в сторонних библиотеках? В бусте там или тем паче в wxWidgets с её winundef.h? Да, и почему такие полумеры — только windows.h? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде

К>Ну или пользоваться исключительно стерильной средой для компиляции под сфероконическую ось.
К>Но что-то я не верю в её существование, поэтому лично я бы попробовал выхватить напильник и три раза вотще по всем используемым мной библиотекам, которые порождают конфликты.

Ну а мне проще и на счет windows.h не парится, пока конфликты не вылезут.

B>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена?
B>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.

http://lib.co.ua/teacher/golub-a1/Golub-a1.txt

47. Не пользуйтесь именами Microsoft

Если Microsoft случайно выберет в качестве имени для функции или класса то, которое вы используете для
каких-то других целей, угадайте, кому из вас придется его сменить?

46. Не пользуйтесь именами из стандарта ANSI Cи.
Идентификаторы, начинающиеся с символа подчеркивания, и имена типов, оканчивающиеся на _t, были зарезервированы стандартом ANSI Cи для использования разработчиками компиляторов.
Не используйте эти символы.

Я как-то привык уже выделять некоторые типы этим суффиксом. Слава пуху, Си не пользую, но может кто просветит, это действительно запрет или перемудрили просто?

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

B>

46. Не пользуйтесь именами из стандарта ANSI Cи.
B>Идентификаторы, начинающиеся с символа подчеркивания, и имена типов, оканчивающиеся на _t, были зарезервированы стандартом ANSI Cи для использования разработчиками компиляторов.
B>Не используйте эти символы.

B>
B>Я как-то привык уже выделять некоторые типы этим суффиксом. Слава пуху, Си не пользую, но может кто просветит, это действительно запрет или перемудрили просто?

Стандарт резервирует имена, начинающиеся на __ или _Капс

17.4.3.1.2 Global names

1 Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.°

°) Such names are also reserved in namespace ::std (17.4.3.1).

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

К>Стандарт резервирует имена, начинающиеся на __ или _Капс
Нет, я о выделенном (суффикс _t в типах) и стандарте С.

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

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

А данные формата анси
W это юникод, так и должно быть, если не подходит укажи руками, где A, где W