Re: Конфликт макроопределения и метода класса
От: CyberDemon Россия  
Дата: 01.09.03 13:16
Оценка: -3 :)
Здравствуйте, tousled, Вы писали:

T> Доброго времени суток, уважаемые!

T>Есть макроопределение (в заголовках компилятора):
T>
T>#ifdef UNICODE
T>    #define GetObject  GetObjectW
T>#else
T>    #define GetObject  GetObjectA
T>#endif // !UNICODE
T>


T>и есть класс:
T>
T>clacc CTemp
T>{
T>    CTemp(){GetObject()}
T>    void GetObject();
T>};
T>


T>Так вот использование метода класса становится затруднительным.
T>Посоветуйте чего нибудь, пожалуйста. Разум возмущенный мой кипит, но удовлетворительного ответа не находит.
T>Не удовлетворительные варианты таковы (по ряду причин не подходят):
T>1. Переставить местами включение заголовков.
T>2. Воспользоваться 
#undef
.
T>3. Заменить макроопределение функцией.
T>4. Поменять имя метода.

T>Может у кого найдутся еще варианты?

Если не ошибаюсь, можно перед GetObject ставить "::", тогда будет вызываться глобальный метод (в данном случае — макро, как я понял), если не ставить, то, ясное дело, локальный.
А еще, если так не прокатит, можно просто рисовать "this->GetObject()"
Re[2]: Конфликт макроопределения и метода класса
От: LaptevVV Россия  
Дата: 01.09.03 13:19
Оценка: +1
Здравствуйте, CyberDemon, Вы писали:

CD>Если не ошибаюсь, можно перед GetObject ставить "::", тогда будет вызываться глобальный метод (в данном случае — макро, как я понял), если не ставить, то, ясное дело, локальный.
CD>А еще, если так не прокатит, можно просто рисовать "this->GetObject()"
Не, макросу до лампочки — заменит, и все.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Конфликт макроопределения и метода класса
От: Ed.ward Россия  
Дата: 03.09.03 09:32
Оценка: :)
Здравствуйте, tousled, Вы писали:

T> Доброго времени суток, уважаемые!

T>Есть макроопределение (в заголовках компилятора):
T>
T>#ifdef UNICODE
T>    #define GetObject  GetObjectW
T>#else
T>    #define GetObject  GetObjectA
T>#endif // !UNICODE
T>


T>и есть класс:
T>
T>clacc CTemp
T>{
T>    CTemp(){GetObject()}
T>    void GetObject();
T>};
T>


#ifdef GetObject
#pragma push_macro( "GetObject" )
#undef GetObject
clacc CTemp
{
    CTemp(){GetObject()}
    void GetObject();
};
#pragma pop_macro( "GetObject" )


И волки сыты, и овцы, то есть макросы, целы.

Ed.ward
... << RSDN@Home 1.0 beta 7a >>
Конфликт макроопределения и метода класса
От: tousled  
Дата: 01.09.03 13:12
Оценка:
Доброго времени суток, уважаемые!

Есть макроопределение (в заголовках компилятора):
#ifdef UNICODE
    #define GetObject  GetObjectW
#else
    #define GetObject  GetObjectA
#endif // !UNICODE


и есть класс:
clacc CTemp
{
    CTemp(){GetObject()}
    void GetObject();
};


Так вот использование метода класса становится затруднительным.
Посоветуйте чего нибудь, пожалуйста. Разум возмущенный мой кипит, но удовлетворительного ответа не находит.
Не удовлетворительные варианты таковы (по ряду причин не подходят):
1. Переставить местами включение заголовков.
2. Воспользоваться 
#undef
.
3. Заменить макроопределение функцией.
4. Поменять имя метода.

Может у кого найдутся еще варианты?
... << RSDN@Home 1.1 beta 1 >>
Re[3]: Конфликт макроопределения и метода класса
От: tousled  
Дата: 01.09.03 15:59
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Не, макросу до лампочки — заменит, и все.
Эх в том-то вся и проблема
... << RSDN@Home 1.1 beta 1 >>
Re: Конфликт макроопределения и метода класса
От: jazzer Россия Skype: enerjazzer
Дата: 02.09.03 06:32
Оценка:
Здравствуйте, tousled, Вы писали:

T> Доброго времени суток, уважаемые!

T>Есть макроопределение (в заголовках компилятора):
T>
T>#ifdef UNICODE
T>    #define GetObject  GetObjectW
T>#else
T>    #define GetObject  GetObjectA
T>#endif // !UNICODE
T>


включить файл с этим макроопределением в stdafx.h, поскольку он подключается всегда первым, насколько я помню.
тогда препроцессор тебе переименует все и везде, и все будет работать.

P.S. Макросы — зло :))
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Конфликт макроопределения и метода класса
От: Vamp Россия  
Дата: 02.09.03 07:25
Оценка:
ИМХО, никак. Из общих рассуждений:
Макросы думать не умеют. Он заменит все, где только найдет. Раз undef не подходит — отключить ты его не сможешь. Я только не пойму, почему undef не подходит. Отчего бы не 

#undef GetObject
int GetObject(HGDIOBJ hgdiobj, int cbBuffer, LPVOID lpvObject) {
  #ifdef UNICODE
    return GetObjectW(hgdiobj, cbBuffer, lpvObject);
  #else
    return GetObjectA(hgdiobj, cbBuffer, lpvObject);
  #endif // !UNICODE
}
Да здравствует мыло душистое и веревка пушистая.
Re: Конфликт макроопределения и метода класса
От: centurn Россия  
Дата: 02.09.03 07:36
Оценка:
Здравствуйте, tousled, Вы писали:

Я бы в своем классе просто метод переименовал, если это возможно, конечно.

ЗЫЖ А вообще, Микрософт — ... известно кто...
Re[2]: Конфликт макроопределения и метода класса
От: tousled  
Дата: 03.09.03 08:59
Оценка:
Здравствуйте, centurn, Вы писали:

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

C>Я бы в своем классе просто метод переименовал, если это возможно, конечно.
Для этого надо перелапатить пару десятков мегабайт кода

C>ЗЫЖ А вообще, Микрософт — ... известно кто...
В контексте этого топика я присоеденю к этой компании Borland, Sun и Intel, поскольку в своих библиотеках они тоже подобные макросы используют...
... << RSDN@Home 1.1 beta 1 >>
Re[2]: Конфликт макроопределения и метода класса
От: tousled  
Дата: 03.09.03 09:29
Оценка:
Здравствуйте, Vamp, Вы писали:


V>Я только не пойму, почему undef не подходит. Отчего бы не
V>
V>#undef GetObject
V>int GetObject(HGDIOBJ hgdiobj, int cbBuffer, LPVOID lpvObject) {
V>  #ifdef UNICODE
V>    return GetObjectW(hgdiobj, cbBuffer, lpvObject);
V>  #else
V>    return GetObjectA(hgdiobj, cbBuffer, lpvObject);
V>  #endif // !UNICODE
V>}
V>

Это решение надо предложить Мелкомягким. Если я напишу это в своем заголовке, локально проблема конечно решится, но я не смогу гарантировать (группа разработки 54 чела), что раньше моего заголовка не включится другой заголовок использующий GetObject. Тогда-то все и отвалится...
... << RSDN@Home 1.1 beta 1 >>
Re[2]: Конфликт макроопределения и метода класса
От: tousled  
Дата: 03.09.03 09:29
Оценка:
Здравствуйте, jazzer, Вы писали:

J>включить файл с этим макроопределением в stdafx.h, поскольку он подключается всегда первым, насколько я помню.
J>тогда препроцессор тебе переименует все и везде, и все будет работать.
1. Проект мультиплатформенный, потому для сборки используются mak-файлы. Ни о каком stdafx.h не может быть и речи (это приблуда MS, а кроме MSVC есть еще много компиляторов). Даже если выделить один общий заголовок, то сделать это можно только в пределах одного модуля, а модулей этих ~70.
2. Идея сама по себе порочна. Юзверь класса смотрит заголовок (там написано GetObject), а компилятор ему и говорит: Нефига мол "Is not member!"

J>P.S. Макросы — зло
С большой буквы!
... << RSDN@Home 1.1 beta 1 >>
Re[3]: Конфликт макроопределения и метода класса
От: jazzer Россия Skype: enerjazzer
Дата: 03.09.03 11:00
Оценка:
Здравствуйте, tousled, Вы писали:

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

J>>включить файл с этим макроопределением в stdafx.h, поскольку он подключается всегда первым, насколько я помню.
J>>тогда препроцессор тебе переименует все и везде, и все будет работать.
T>1. Проект мультиплатформенный, потому для сборки используются mak-файлы. Ни о каком stdafx.h не может быть и речи (это приблуда MS, а кроме MSVC есть еще много компиляторов). Даже если выделить один общий заголовок, то сделать это можно только в пределах одного модуля, а модулей этих ~70.
1. Согласись, логично, увидев кусок виндовского хедера, предположить, что разработка ведется на MSVC, не говоря уже о том, что она одноплатформенная :)
2. Precompiled headers — приблуда не только MS.
3. Рассмотри вариант с явным инклудом виндовского хедера с этим макросом в хедер твоего класса.

T>2. Идея сама по себе порочна. Юзверь класса смотрит заголовок (там написано GetObject), а компилятор ему и говорит: Нефига мол "Is not member!"

4. Если юзверь не только смотрит, а еще и компилит, то этот макрос должен быть в этом файле включен. см. п.3
Тогда компилятор ему слова не скажет.

J>>P.S. Макросы — зло :))
T>С большой буквы! :-\

5. Переименуй вообще этот метод нафиг в какой-нть _get_object_ и не связывайся. :)
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: Конфликт макроопределения и метода класса
От: LaptevVV Россия  
Дата: 03.09.03 11:46
Оценка:
Здравствуйте, tousled, Вы писали:


J>>P.S. Макросы — зло
T>С большой буквы!
Толлько в С++
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Конфликт макроопределения и метода класса
От: jazzer Россия Skype: enerjazzer
Дата: 03.09.03 12:43
Оценка:
Здравствуйте, Ed.ward, Вы писали:

а разве #pragma push_macro — кроссплатформенная штука?

да и все равно это проблемы не решит, потому что в клиентском коде GetObject'ы переделаются в А или W в соответствии с виндовскими макросами.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: Конфликт макроопределения и метода класса
От: tousled  
Дата: 04.09.03 07:28
Оценка:
Здравствуйте, Ed.ward, Вы писали:


EW>И волки сыты, и овцы, то есть макросы, целы.

EW>Ed.ward

Большой мерси вам, этого и хотелось.
... << RSDN@Home 1.1 beta 1 >>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.