Как распознать тип переменной, переданной в макрос в качестве аргумента?

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

V>Как распознать тип переменной, переданной в макрос в качестве аргумента?

Что значит "распознать" ?

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

V>Как распознать тип переменной, переданной в макрос в качестве аргумента?

Никак, обработка макросов идет на уровне препроцессора, до сбора информации о синтаксической и семантической структуры программы.

Можно попытаться как-то привязать перегруженные функции или темплейтные классы, но это не для всех макросов пройдет.

Напиши подробнее, что тебе хочется.

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

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

V>>Как распознать тип переменной, переданной в макрос в качестве аргумента?

DG>Никак, обработка макросов идет на уровне препроцессора, до сбора информации о синтаксической и семантической структуры программы.

DG>Можно попытаться как-то привязать перегруженные функции или темплейтные классы, но это не для всех макросов пройдет.

DG>Напиши подробнее, что тебе хочется.

Спасибо за то, что откликнулись. Я пишу макрос, действия которого должны зависеть от типа передаваемого аргумента. Вот и хочу узнать, что за переменная ему передана. Если это невозможно, то воспользуюсь Вашим советом привязать перегруженные функции.

V>>>Как распознать тип переменной, переданной в макрос в качестве аргумента?

DG>>Никак, обработка макросов идет на уровне препроцессора, до сбора информации о синтаксической и семантической структуры программы.

DG>>Можно попытаться как-то привязать перегруженные функции или темплейтные классы, но это не для всех макросов пройдет.

DG>>Напиши подробнее, что тебе хочется.

А>Спасибо за то, что откликнулись. Я пишу макрос, действия которого должны зависеть от типа передаваемого аргумента. Вот и хочу узнать, что за переменная ему передана. Если это невозможно, то воспользуюсь Вашим советом привязать перегруженные функции.

Я и говорю, напиши подробнее о смысле макроса, одно дело когда это что-то типа функции max, другое — это какие-нибудь "извратные" мапы.

Одно время я занимался интересными макросами, один из самых навороченных был типа:
[ccode]
struct Q
{
BEGIN_FIELDS(Q)
FIELD(int, i, 0)
FIELD(double, d, 0.5)
END_FIELDS()
};
[ccode]

В итоге такая вещь разворачивалась в обычную структуру + начальная инициализация полей + operator < + функции Load/Save + еще много чего.

Поэтому если напишешь подробнее, помогу дельным советом.

Здравствуйте DarkGray, Вы писали:
DG>Поэтому если напишешь подробнее, помогу дельным советом.

Ну что ж, напишу, хотя это потребует некоторого отступления от темы :)
Дело в том, что мне что-то не понравилась среда VC++ 6.0 — ни редактор кода, ни отладчик, ни редактор ресурсов. Я решил писать в своем любимом :) редакторе Фара с установленным плагином Colorer для подсветки синтаксиса, а в качестве отладчика использовать свой любимый :) SoftICE. Однако SoftICE — средство тяжелой артиллерии, иногда требуется просто выводить куда-то отладочные сообщения, лучше не на консоль, а в какое-нибудь текстовое окошко. В свое время для отладки программ на асме я написал утилиту DbgWin, которая входит в состав пакета MASM32 v7.0. Утилита состоит из текстового окошка и нескольких макросов для вывода зачений переменных в это окошко. Теперь я решил сделать нечто подобное для С++. Макрос (а это должен быть именно макрос, потому что должны использоваться макродирективы __FILE__ и __LINE__) в качестве параметров должен принимать различные типы переменных — целочисленные, вещественные, строки и т.д. Естественно, внутри макроса переводить значения переменных в удобочитаемый вид надо по-разному, в зависимости от типа: int переводить в ASCIIZ-строку функцией _itoa, double — функцией _fcvt... Вопрос в том, как в макросе распознать типы. Впрочем, эту задачу я уже решил с помощью перегруженных функций, воспользовавшись Вашим советом. Если интересно, могу выслать программку.

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

DG>>Поэтому если напишешь подробнее, помогу дельным советом.

А>Ну что ж, напишу, хотя это потребует некоторого отступления от темы :)
А>Дело в том, что мне что-то не понравилась среда VC++ 6.0 — ни редактор кода, ни отладчик, ни редактор ресурсов. Я решил писать в своем любимом :) редакторе Фара с установленным плагином Colorer для подсветки синтаксиса, а в качестве отладчика использовать свой любимый :) SoftICE. Однако SoftICE — средство тяжелой артиллерии, иногда требуется просто выводить куда-то отладочные сообщения, лучше не на консоль, а в какое-нибудь текстовое окошко. В свое время для отладки программ на асме я написал утилиту DbgWin, которая входит в состав пакета MASM32 v7.0. Утилита состоит из текстового окошка и нескольких макросов для вывода зачений переменных в это окошко. Теперь я решил сделать нечто подобное для С++. Макрос (а это должен быть именно макрос, потому что должны использоваться макродирективы __FILE__ и __LINE__) в качестве параметров должен принимать различные типы переменных — целочисленные, вещественные, строки и т.д. Естественно, внутри макроса переводить значения переменных в удобочитаемый вид надо по-разному, в зависимости от типа: int переводить в ASCIIZ-строку функцией _itoa, double — функцией _fcvt... Вопрос в том, как в макросе распознать типы. Впрочем, эту задачу я уже решил с помощью перегруженных функций, воспользовавшись Вашим советом. Если интересно, могу выслать программку.

Когда я решал похожую задачу был примерно следующий код:

#define DBG(i) Debug::Dbg(i)

#define DBGX(i) Debug::Dbg(__FILE__, __LINE__), DBG(i)

namespace Debug
{

struct CDebug:
public std::ostream
{
//здесь код специфичный от способа вывода отладочной информации
//реализуется аналогично ostringstream & ofstream
};
extern CDebug debug;


inline void Dbg(const char * file_name, int line)
{
debug << file_name << "( " << line << "): ";
}

template<class T>
inline void Dbg(const T&t)
{
debug << t;
}

};

При таком подходе у нас остаются гибкие возможности форматирования вывода, уже имеющиеся у ostream'а
Встроенная поддержка основных типов
При необходимости вывести новый тип данных надо только перегрузить оператор:
std::ostream & operator << (std::ostream &os, const T&t);

Минус, что надо тащить за собой stl, но так как большая часть нашей библиотеки завязана на stl, то для нас это было не критично