B>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
Если Microsoft случайно выберет в качестве имени для функции или класса то, которое вы используете для
каких-то других целей, угадайте, кому из вас придется его сменить?
Так что, на самом деле, правильный выход — обеспечить, чтобы винапишный заголовок всегда включался раньше. Даже если он тебе и не нужен в каком-то конкретном месте.
Чтобы снизить нагрузку на компилятор, помести #include<windows.h> в прекомпилированный заголовок (stdafx.h и т.п.)
Да, в итоге у тебя вместо Foo::MessageBox будет Foo::MessageBoxW (или -A, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
Здравствуйте, Caracrist, Вы писали:
C>Здравствуйте, buka123, Вы писали:
B>>Здравствуйте, Bell, Вы писали:
B>>>Здравствуйте, buka123, Вы писали:
B>>>>>Начать можно с того, что получить файл после обработки препроцессором.
B>>>>Получил многомегабайтные файлы, а дальше что?
B>>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
C>можешь наставить #undef где нужно
Можно, но как-то не круто
Здравствуйте, buka123, Вы писали:
B>>Я что-то теряю мысль — в чем собственно проблема? В том, что у твоего класса есть функции, имена которых совпадают с API-шными? Если да — ты знаешь эти имена? B>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
ИМХО единственный выход — изменить эти имена. Иначе ты не сможешь защитить пользователей своего класса — любой новый #include может все сломать.
Здравствуйте, buka123, Вы писали:
B>В проекте есть класс, который страдает от дефайна WinApi , который прибавляет к именам функций "A" или "W". Как можно отследить его и убить?
А данные формата анси
W это юникод, так и должно быть, если не подходит укажи руками, где A, где W
Здравствуйте, 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>Да,некоторые методы совпадают в винапишными. Да, я знаю эти имена.
Здравствуйте, 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, в зависимости от юникодности). Но это будет повсеместно и согласованно, и волновать тебя не очень должно.
Ага, пока с библиотекой какой не пересечется Ну а потом начнутся вопросы в форум, типа "а чё у меня линкер конструктор 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
Здравствуйте, 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? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Угу, и как же предлагается обеспечивать присутствие windows.h в сторонних библиотеках? В бусте там или тем паче в wxWidgets с её winundef.h? Да, и почему такие полумеры — только windows.h? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде
Ну или пользоваться исключительно стерильной средой для компиляции под сфероконическую ось.
Но что-то я не верю в её существование, поэтому лично я бы попробовал выхватить напильник и три раза вотще по всем используемым мной библиотекам, которые порождают конфликты.
Здравствуйте, Кодт, Вы писали:
S>>Угу, и как же предлагается обеспечивать присутствие windows.h в сторонних библиотеках? В бусте там или тем паче в wxWidgets с её winundef.h? Да, и почему такие полумеры — только windows.h? Для полноты концепции надо все хедеры, содержащие дефайны, включать везде
К>Ну или пользоваться исключительно стерильной средой для компиляции под сфероконическую ось. К>Но что-то я не верю в её существование, поэтому лично я бы попробовал выхватить напильник и три раза вотще по всем используемым мной библиотекам, которые порождают конфликты.
Ну а мне проще и на счет windows.h не парится, пока конфликты не вылезут.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
46. Не пользуйтесь именами из стандарта ANSI Cи.
Идентификаторы, начинающиеся с символа подчеркивания, и имена типов, оканчивающиеся на _t, были зарезервированы стандартом ANSI Cи для использования разработчиками компиляторов.
Не используйте эти символы.
Я как-то привык уже выделять некоторые типы этим суффиксом. Слава пуху, Си не пользую, но может кто просветит, это действительно запрет или перемудрили просто?
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).