не могу жить без #define :)

[Алексей++]

много раз встречал на форуме мнение, что определение своих дефайнов в программе - зло. Но лично я ими пользуюсь и иногда просто невозможно без них (не теряя при этом в удобстве)

вопрос к противникам этого чуда - какой посоветуете использовать аналог дефайна, против которого Вы не, но который полностью заменит дефайн ?

[nikedeforest]

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

[Алексей++]

nikedeforest, смотря что ты понимаешь под порядком компиляции...

давай пойдём от обратного - что не стоит делать через дефайн ? (пример приведи)
я потом сравню - если я делаю что то "недопустимое, тогда уточню вопрос

[nikedeforest]

ИМХО, не стоит делать макросы и объявлять константы (или как там они называются), т.е.
#define MaxValue 100

Но в принципе не сильно возбраняется делать так
#define bugVersion
#define HomeEdition

#ifdef bugVersion
printf (" ");
...

#ifdef HomeEdition
....



Смысл надеюсь понятен?

[Алексей++]

вот как раз макросов типа
#define MaxValue 100
 - навалом . Но в последнее время стараюсь объявить через enum

а почему так не стоит делать ?

[nikedeforest]

Потому что это по сути ничем не лучше глобальных переменных. Ты же пишешь на С++, создай закрытую переменную внутри класса, в котором ты используешь это значение (для выделения массива или еще чего), инкапсулируй ее. Как выразился Макконнелл - "Скрывайте секреты". Есть глава такая в его книге "Совершенный код", где он призывает скрывать подобные (и не подобные ) детали реализации.

[Алексей++]

да вот не всегда так получается

[nikedeforest]

А в каких случаях не получается?

[Джон]

Лёш, на самом деле никто не сможет тебе ответить на вопрос "почему?". Это всё-равно что спросить почему один любит арбуз, а другой свинной хрящик.

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

Абсолютно неверно! define (в данном случае) не имеет никакого отношения к переменным. Они не находятся в таблице перепенных они ВОБЩЕ нигде не находятся к моменту компиляции. Об этом позаботится прекомпилятор.

Насчёт того, что define - зло. Бред! С таким же успехом можно утверждать, что столовые приборы - зло, поскольку без них можно обойтись, и кушать например руками.

Данному утверждению нет ни одного доказательства , а вот опровергнуть его можно легко:

В программе, в мат. расчётах во многих местах (чтобы быть совсем точным - в 17ти файлах, 48 классов, всего 397 вхождений) необходимо использовать некую эмпирическую константу, которая равна 423.566783. Через 48 недель, эта константа изменяется и становится равной 273.982647.
И что? Мне надо перелопатить 17 файлов и в каждом поменять значение? Каким образом я должен определить переменную(ые) внутри класса? Или сделать глобальную константу?

А как же быть с системозависимыми? Например MAX_PATH?

define (в данном случае) не имеет также никакого отношения к ООП парадигме. Это просто дополнительная возможность, удобно, читабельно, наконец красиво  оформить код. И С++ здесь совершенно не при чём.

Теперь про макросы.

Нормальная цветовая модель в GDI (COLORREF) для набора кодируется как BGR, что очень неудобно для ввода инфы полученной от дизайнеров, которые все экранные цвета представляют в RGB
Те чтобы видеть в коде "нормальную" цветовую модель, цвета надо преобразовать:

Код:

#define RGB(r,g,b) ((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16)))

Таким образом они позоволяют сделать код компактным, а, соответственно, удобочитаемым (легко просматриваемым) в ключевых местах, не загромождая его повторяющимися сложными выражениями.

А вот какой вред от них?

[nikedeforest]

Сравнение с глобальными переменными здесь образное, а не буквальное. Ну а если это по-вашему лучший способ оформить код, то мне просто нечего сказать.

[Антон (LogRus)]

ИМХО макросы полезны, когда они действительно полезны, т.е. когда использование другого подхода или невозможно или крайне не удобно, что для меня равносильно невозможно

Джон, что касается констант занесённых в макроопределение, так это решается простыми константными переменными, они на этапе компиляции имеют привычку подставлятся в код значением, а не переменной.
опять же есть менанизм enum
макрос могут переопределить в другом хередере и ты это увидишь только в виде предупреждения в большом проекте собираемого системой автосборки ты можешь никогда не обратить внимание на это сообщение или забить на него со словами: " А макрос, да фиг с ним", этого не случится при использовании енумов и константных переменных, потому, что компилятор не соберёт проект и ты будешь вынужден обратить внимание на проблему.
по поводу RGB это прекрасно заменяется шаблонную на inline функцию
+ под отладной не всегда можно увидеть чему всёже был равен макрос в точке отладки.

Впрочем приведённые тобой примеры мне кажутся вполне безобидными. Лично мне не нравятся макросы которые разварачиваются в здоровенную функцию или класс(видел я много таких), тяжелова-то в них отлаживаться

Есть у нас в коде пара мест, где такие страшные макросы вполне оправданны по соображениям производительности, но их всего ничего.

[Алексей++]

ну функции я никогда не засовывал в макросы, только исключительно константы или повторяемые много раз кусаки (во время поиска глюка они ещё не макрос, а потом переделываю в макрос после отладки)

ещё делаю такую вещь (где то упоминал)

Код:

#define num      133
#define num_txt "133"

 - где надо, вставляю число, где надо - предопределённую строку

Ну и константы и несложные выражения-формулы

[Антон (LogRus)]

Алексей1153++, ну ведь можно написать функцию что бы небыло повторяющегося(шаблонунную, если лень в типах разбираться), зачем макрос? зачем? найдут у тебя тестеры ошибку, из макроса данные обратно в код будешь вставлять, во все места, где он используется? в нём же даже брейкпоинт не поставить.

что касается

Код:

#define num      133
#define num_txt "133"

то у нас делают так

Код:

const int num = 133;
const char * num_txt = "133";
enum { ENum = 133, Enum2 = 266};

[Алексей++]

LogRus,
const char * num_txt = "133";
- это глобальная переменная. Не есть хорошо совсем...

>> ну ведь можно написать функцию 
Можно... с кучей передаваемых параметров. Обычно макросы описываю уже внутри функции (там, где много повторяющихся кусков). Иногда действительно пепеделываю в функторы, но иногда это не удобно, так и остаются макросы

[RXL]

Если кто забыл, есть статьи Михалыча на эту тему - там хорошо объяснено, когда и почему define - вред.

Совсем отказываться от define также не следует.

[Антон (LogRus)]

LogRus,
const char * num_txt = "133";
- это глобальная переменная. Не есть хорошо совсем...

>> ну ведь можно написать функцию 
Можно... с кучей передаваемых параметров. Обычно макросы описываю уже внутри функции (там, где много повторяющихся кусков). Иногда действительно пепеделываю в функторы, но иногда это не удобно, так и остаются макросы

Сделай переменную статиком ИМХО лучше чем макрос.
Повторяющихся кусков кода, то стараемся его всегда выносить в функции даже, если функция маленькая.

что касается статьи от Михалыча, то там импользование макроопределений рассматривается в основном, как некая замена typedef

Согласен, от макроопределений полностью отказаться нельзя(особенно, если тебе нужен страж хедера ), как известно всё лекарство и всё яд

Когда я смело использую макросы:
1. Стражи заголовочных файлов(про #pragma once умолчим platform specific)
2. Условная компиляция(для разных платформ или отладка/релиз)
3. Передача в функцию переменной и символьного представления имени переменной/класса
4. Нет дрого пути кроме, как использовать макрос
к пукту 4 пример

Код:

#define LOG_DATA(Name, Condition, OutData) \
            if(Condition) \
            { \
                  std::cout << Name << " Data: " << OutData << "\n"; \
            }

используем это дело:

Код:

int func(string& s, int i, long l, bool dump)
{
        LOG_DATA("FUNC", dump, << s << " " << i << " "<< l);
        ...
}

почему этот код не вынести в функцию? потому, что: тогда всегда буду вынужден выполнять формирование строки OutData
не зависимо от условия, а формирование строки может быть очень дорогой операцией
Но и этот код можно заменить при желании на такой, что строка формироваться не будет без использования, если написть класс обёртку с шаблонным оператором <<
примерно, так

Код:

class Logger
{
    bool dump_;
public:
    Logger(const string& name, bool dump):dump_(dump)
    {
        if (dump)
           std::cout << name << ":"
    }

     template<T>
     Logger& operator<<(const T)
     {
          if(dump_)
          {
                  std::cout << T;
          }
          return *this;
     }
}

теперь испольуем его:

Код:

int func(string& s, int i, long l, bool dump)
{
        {
           Logger log("FUNC", dump);
           log << s << " " << i << " "<< l << "\n";
        }
        ...
}

но у нас появляются дополнительные расходы: конструирование/разрушение объекта, дополнительные вызовы << и проверки условия

[Алексей++]

примерно понятно )

зы кстати, никогда ещё не доводилось пользоваться cout

[Vlaor]

О чем может идти речь, если сама Microsoft в своих include файлах использует эти define направо и налево. Зачем например обьявлять переменную, тратить место в памяти (пусть и мелочи) когда есть стандартный выход. Осторожней просто надо быть. О .

[Антон (LogRus)]

Vlaor, константны переменные не расходуют память, а экономят. Если подумаешь, то поймёшь почему.
Что касается MS, так это их личное дело.

[nikedeforest]

Мое не авторитетное мнение хочу заменить следующим:
Бьерн Страуструп 1997г.

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

Макконнелл "Соверешенный код" 2изд. стр 180

Современные языки вроде С++ поддерживают много альтернатив макросам:
-ключевое слово const для объявления констант;
-ключевое слово inline для определения функций, которые будут компилироваться как встраиваемый код
-шаблоны для безопасного в плане типов определения стандартных операций, таких как min, max и т.д.
-ключевое слово enum для определения перечислений;
-директиву typedef для простых замен одного типа другим

[Алексей++]

а ещё хотелось бы, чтоб у макросов была область видимости )

[Антон (LogRus)]

Алексей1153++, направь заявку в комитет по C++
nikedeforest, поддерживаю.

[Алексей++]

LogRus,

[Vlaor]

nikedeforest, Я конечно согласен, вот только не пойму насчет экономии памяти. Может тормоз. Ведь при использовании const выделяется место в секции .rdata, но ведь выделяется же. При define происходит прямая подстановка в код.

Например VC6 скомпилил подобный код.

Код:

1:    void func(int);
2:
3:    #define A 10
4:    const int a = 10;
5:
6:    void main()
7:    {

//инициализация

8:    func(A);
0040B468   push        0Ah
0040B46A   call        @ILT+5(func) (0040100a)
0040B46F   add         esp,4
9:    func(a);
0040B472   push        0Ah
0040B474   call        @ILT+5(func) (0040100a)
0040B479   add         esp,4
10:
11:   }

Замечательно, а что мне делать если я хочу использовать нечто вроде:

Код:

#define B (A + 10)

[npak]

> а ещё хотелось бы, чтоб у макросов была область видимости )

#define BLA-BLa-BLA

#undef BLA-BLA-BLA

Ситуация с #define похожа на ситуацию с goto - это было универсальное средство переключения потока управления. Умные люди посидели, подумали, и выделили основные идиомы использования goto в отдельные конструкции - более понятные и безопасные: циклы, прерывания циклов (break, continue), вызовы функций и return. Затем подумали и победили экстремальную форму goto - longjump - ввели исключения.

Также и define - универсальное средство управления кодом. Разработчики С++ приложили массу усилий по созданию заменителей define. Во-первых, замена литералов вида
#define MY_MAGIC_NUMBER 123
на константы
const int my_magic_number = 123
которые можно использовать всюду, где в Си разрешаются только литералы (например, задать размер массива - константы enum в Си для этого недопустимы).
Во-вторых, "маленькие" и "быстрые" функции поддержаны функциями inline.
В-третьих, переиспользование кода для разных типов решено введением шаблонов.

Пожалуй, в Си++ не нашли заменителя для одного сценария использования #define - условной компиляции. Более того, такой сценарий использования макросов перекочевал в С# почти в неизменном виде.

[npak]

Vlaor, при использовании const компилятор С++ имеет полное право подставить в точку использования константы её фактическое значение, что полностью эквивалентно константам #define. Если константа статическая (то есть не может использоваться за пределами модуля), то оптимизатор может ее выкинуть из секции данных, расставив во всех местах использования фактическое значение.

[Алексей++]

npak, про undef я в курсе. Пользуюсь )
Но стоит поменять имя макроса и забыть поменять его в ундефе - приехали

[npak]

препроцессор по стандарту не парсит текст программы, он только совершает замены и подстановки, и это правильно. С++ сам по себе черезмерно навороченный язык, если к этому добавить семантически подкованный препроцессор - это будет совсем труба. Нужно будет определить понятия границ видимости, определить правила обработки макросов за пределами этих границ, потом может возникнуть желание ввести динамически определенные макросы - проблем будет гораздо больше, чем обретенных возможностей.

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

[nikedeforest]

аминь

[Scorp__)]

Да, вот еще особенность макросов съевшая минут 15 времени. Пишу интерфейс под .NET, нужно зарегистрировать горячую клавишу, в этом случае можно воспользоваться только API-шной RegisterHotKey. Отлично, подключаем windows.h. В случае неудачи хочу вывести MessageBox и пользуюсь классом MessageBox для этого, вроде все правильно, пространство имен указал. А компилятор говорит, неа, MessageBoxA() не член этого пространства имен и все тут.

Казалось бы причем тут вообще MessageBoxA(), я его даже не трогаю. Оказывается, в windows.h есть макрос
#define MessageBox MessageBoxA
препроцессор все правильно заменяет, а я сижу и смотрю тупо в монитор пытаясь понять в чем же дело. Решение-то простое:
#undef MessageBox
но все равно неприятно.

[Алексей++]

Scorp__), примени MessageBoxEx

[Scorp__)]

Алексей1153++, да решение-то я нашел и описал в своем посте Но вот странное предложение для того чтобы отвязаться от применения одной АПИ функции применить другую?

Дело в том, что в .NET MessageBox - это класс такой, а всякий кто хочет показать окошечко с сообщением вызывает статический метод этого класса, Show, с нужным набором параметров. Так вот макрос обитающий в windows.h перекрыл название этого класса в namespace System::Windows::Forms.

API функции применять, когда находишься в управляемом (managed) контексте, - довольно недешевое удовольствие и делать это надо только в случае, если другого выхода нет

[LifeMaker]

вот как раз макросов типа
#define MaxValue 100
 - навалом . Но в последнее время стараюсь объявить через enum

а почему так не стоит делать ?

пакость от такого использования:

Код:

// объявил
#define MaxValue 100

int m[MaxValue]; //использовал

//забыл

... //500 строк кода

void func(int MaxValue) //компилятор нас обматюкает, и придётся долго разбираться почему.
{
  //ещё хуже, если этот MaxValue был объявлен в каком-нибудь библиотечном хидере, а создатель функции случайно выбрал такое же имя
}

правильная альтернатива:

Код:

const int MaxValue = 100;

эффект - тот же, безопасность - выше.

[RXL]

Потому и принято в именах макросов и констант использовать только прописные буквы, чтобы не путать с именами переменных.

Кстати, имена переменных тоже не следует начинать с прописной буквы - так принято начинать имена типов (классов).

Все становится просто и ясно:
MAXVALUE - макрос
MaxValue - класс
maxValue - переменная или ф-ия

[Алексей++]

LifeMaker,

1) первое. "//забыл" - так не будет , скорее всего, потому что стараюсь не забывать и делать ундефайны
2) //компилятор нас обматюкает, и придётся долго разбираться почему. - компилятор напишет что нибудь вроде "повторный идентификатор" или "неправильное использование константы". А поскольку я помню, что за константа (имена обычно говорящие даю, да начинаются с def_) - жмём F12 (для студии) и летим к определению. Или по памяти находим.
3) const - не всегда можно применить так гибко, как макрос, к сожалению. А так бы я давно отказался от дефайнов

[LifeMaker]

А как же быть с системозависимыми? Например MAX_PATH?

по хоршему можно было объявить const int MAX_PATH = <чего-то там>;
и был бы тот же эффект, только немного безопаснее. можно было в другой области видимости использовать MAX_PATH по другому.
а почему этого не сделали - дык эта константа писалась на языке С ещё в те времена, когда стандарта C++ не было. только и всего.
и использование #define в хидерах микрософта для констант объясняется только желанием сохранить совместимость со старыми C компиляторами. зачем программисту, который пишет программу, которая будет компилиться только одним современным хорошим С++ компилятором поступать также?
вообще, перед тем как подражать тому стилю, что используют в Microsoft, Borland и т.д., стоит трижды подумать почему они так сделали и подходит ли такая стратегия вам...

Теперь про макросы...

...они позоволяют сделать код компактным, а, соответственно, удобочитаемым (легко просматриваемым) в ключевых местах, не загромождая его повторяющимися сложными выражениями.

А вот какой вред от них?

а как насчет такого макроса?

Код:

#define sq(val) ((val)*(val)) //возведение в квадрат

int a = sq(3);    //всё замечательно, раскроется в "int a = ((3)*(3))"
int b = sq(sin(a)); //плохо: "int a = ((sin(a))*(sin(a)))" два вызова sin вместо  одного, а могла быть очень сложная конструкция
int c = sq(db->query("<сложный долгоий запрос>").IntValue()); //думаю понятно, почему плохо
int d = sq(object.getValue()); // а если getValue() модифицирует состояние объекта. будет две модификации вместо одной

все проблемы отпадут, если использовать правильную безопасную альтернативу:

Код:

template<class T>
inline T sq(const T& a)
{
   return a*a;
}

да, такая запись чуть длиннее, но она безопасна и кроме того, появляется возможность сделать разную реализацию для разных типов.
например:

Код:

template<class T>
inline T min(const T& a, const T& b)
{
   return a<b;
}

template<const char*>
inline const char* min(const char* a, const char* b)
{
   return (strcmp(a,b)<0) ? a : b;
}

а вот сможешь ли ты написать макросом такой min, который работает и для строк, и для int, float и т.п.?
причем вред от макроса в том, что стоит перед этими шаблонами кому-то написать (в хидере например) макрос #define min(a,b) (a<b?a:b)
и весь мой код будет убит. это я о вреде макросов...

[LifeMaker]

RXL, Алексей1153++, не спорю, хороший стиль может решать некоторые проблемы, но вы боретесь с искуственными проблемами, зачем?
и приведи пример обяъявления константы, где гибкисти const не хватает...

[Алексей++]

>>два вызова sin вместо  одного

это сразу надо учитывать в макросах, это не есть минус. Шаблоны тож не приплетай, речь не о создании универсальных классов

примеры, когда константа не катит, не могу сразу вспомнить, просто помню, что были такие ситауции

[LifeMaker]

>>два вызова sin вместо  одного
это сразу надо учитывать в макросах, это не есть минус. Шаблоны тож не приплетай, речь не о создании универсальных классов

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

[Алексей++]

LifeMaker, я ничего не имею против шаблонов Открою страшную тайну: я никогда не пользовалься шаблонами

[lapulya]

LifeMaker,
Есть ряд очень специфичных случаев которые не одойти без макросров (я не смог), один из таких на форуме когда-то обсуждался (мной точно и помоему пушистый с зайцем участвовали), если очень надо ))) могу поискать.

во всем остальном, полностью согласен

Алексей1153++ и RXL, по поводу того, что могут быть проблемы при использовании дефайнов и их объявлении - так это может быть в сторонней библиотеке или этот код содержится в дорабатываемом уже написанном приложении или его просто напишет ваш коллега (допустим стиль написания кода в компании не утвержден)

[LifeMaker]

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

Не спорю, что есть случаи. Первый - строковый литерал, насколько я знаю, константой не объявишь без лишней переменной. придётся писать

Код:

#define MY_STR "Hello, world!"

и это будет эффективнее чем

Код:

const char* MY_STR = "Hello, world!";

но проблема эффективности тут немного надуманная, на практике я предпочту второй вариант.

Ещё случай. Совсем недавно я на работе писал функцию WRITE_LOG и сделал её макросом по двум причинам.
Во-первых, чтобы в RELEASE-версии была возможность #idef-ом отключить логгирование, во вторых,
потому что gcc компилятор (мы и его на работе используем) умеет распознавать ошибки типа fprintf(f,"%d","string") и только при подстановке макросом не теряется связь <форматная строка>+<передаваемые параметры>.

Случаи действительно специфичные... я собственно почему тут критикую... Алексей1153++ и Джон и другие сторонники дефайна ратуют за типичное использование, именно там где его легко избежать. ни  одного действительно необходимого случая они не привели....

[lapulya]

LifeMaker,

Случаи действительно специфичные... я собственно почему тут критикую... Алексей1153++ и Джон и другие сторонники дефайна ратуют за типичное использование, именно там где его легко избежать. ни  одного действительно необходимого случая они не привели....

Если надо могу привести

но проблема эффективности тут немного надуманная, на практике я предпочту второй вариант.

Я безусловно предпочту второй вариант, однако повторяю есть случаи когда вариант без дефайна серьезно грамоздкий и не решает задачу в общем виде. Ща найду... ну вот тут, что-то на тему...
https://forum.shelek.ru/index.php/topic,4744.msg87889.html#msg87889

А вот пример с WRITE_LOG эээ нууу противоречит твоим высказываниям... тут как раз макрос обходится на раз два... причем с возможностью отключением функционала #ifdef

[Алексей++]

LifeMaker, умеешь обходиться без дефайна - плюс тебе, я не умею Например те же строки.

#define MY_STR "Hello, world!"

const char* p="text1"MY_STR"text2";

[McZim]

а как быть например с:

Код:

#ifndef SOME_H_INCLUDED
#define SOME_H_INCLUDED
...
...
...
#endif

[LifeMaker]

А вот пример с WRITE_LOG эээ нууу противоречит твоим высказываниям... тут как раз макрос обходится на раз два... причем с возможностью отключением функционала #ifdef

так что бы не было даже вызова пустой функции + вычисление кучи параметров?


тут, опять же, немножко надуманная проблема производительности.
и воспользовался я макросом не из-за отключабельности, а из-за того, что не хотел терять warning'ов, ибо реально полезная вещь. несколько раз уберегала от ошибок...

[LifeMaker]

а как быть например с:

Код:

#ifndef SOME_H_INCLUDED
#define SOME_H_INCLUDED
...
...
...
#endif

#pragma once

и не надо говорить о нестандартности и непортируемости. msvc понимает, с++builder, gcc понимает...
меня удивляет, когда люди упорно отказываются от #pragma once предпочитаю эту конструкцию из-за стандартности, да;t tckb точно знают, что программа завязана на текущий компилятор и никогда не будет собираться другим компилятором.

я когда то тоже так делал. теперь мне за это стыдно

[lapulya]

LifeMaker,
а мне не стыдно, не вижу почему надо использовать прагму... Где хоть один плюс? А минус пусть и надуманный (хотя это очень спорно, но флеймить не хочу) на лицо!

так что бы не было даже вызова пустой функции + вычисление кучи параметров?

Конечно, вообще ничего вызываться не будет. Запихай вызов между ifdef и endif и все в шоколаде. Если лениво каждый раз писать так много ))) но готов пожертвовать созданием объекта (без мемберов) на стеке, то заказтай в структуру типа так

Код:

struct LoggerWrapper
{
	LoggerWrapper ()
	{
		#ifdef DEBUG
		theLogger.write("nmabssfnmsb nms");
		#endif
	}
};

ну или что-то вроде того

[LifeMaker]

LifeMaker,
а мне не стыдно, не вижу почему надо использовать прагму... Где хоть один плюс? А минус пусть и надуманный (хотя это очень спорно, но флеймить не хочу) на лицо!

прагма удобнее. простой способ сделать простую вещь. одна строка вместо трёх.
не болтается сбивающий с толку #endif в конце файла который сильно оторван от других строк, с которыми он неразрывно связан.

и кстати как раз сегодня мне эта конструкция немного нервы попортила. мне понадобилось модифицировать h-файл, написанный не мной. загнал туда определение своего класса. компилятор начал меня материть. посмотрел на #ifndef-#define вроде всё как надо.
попробавл и так и эдак. потратил минут 15 (файл входил в precompiled header, каждая попытка скомпилить длилась довольно долго).
выяснилось что структура файла такова

#ifndef __HEADER_SUPER_MACROS
#define __HEADER_SUPER_MACROS
//много всяких объявлений
#endif

#idef _MEGA_PARAMETER1
//много объявлений
#else
//много объявлений
#endif

#idef _MEGA_PARAMETER2
//много объявлений
#else
//много объявлений
#endif

т.е. не весь хидер оказался обрамлён #ifndef-ом. хотя первоначальный взгляд говорит, что вот, всё хорошо. в начале файла #ifndef-#define, а в конце - #endif, а после внимательного чтения всего (!) хидера, оказывается, что не всё так просто...

[Алексей++]

LifeMaker, кстати, в студии есть удобная штука для таких случаев -

#ifndef //{
...километры
...строк
#endif //}

если поставить курсор около фигурной скобки и нажать ctrl+} , то курсор будет перемещён к парной скобке. Если ещё и шифт удержать - всё это выделится

[Scorp__)]

Есть искусственный способ ))

#ifndef __HEADER_SUPER_MACROS
#define __HEADER_SUPER_MACROS
//... код...
#endif // __HEADER_SUPER_MACROS
Сразу видно какой #endif, что закрывает.

Между прочим, Саттер и Александреску рекомендуют использовать именно этот вариант защиты от повторного включения, а не прагмы компиляторов )

[LifeMaker]

так что бы не было даже вызова пустой функции + вычисление кучи параметров?

Конечно, вообще ничего вызываться не будет. Запихай вызов между ifdef и endif и все в шоколаде. Если лениво каждый раз писать так много ))) но готов пожертвовать созданием объекта (без мемберов) на стеке, то заказтай в структуру типа так

Код:

struct LoggerWrapper
{
	LoggerWrapper ()
	{
		#ifdef DEBUG
		theLogger.write("nmabssfnmsb nms");
		#endif
	}
};

ну или что-то вроде того
[/quote]
дык это же сильно неудобно, при каждом вызове функции обрамлять её #idef'ом.
зачем делать 100 раз то, что можно сделать один раз?
и всех коллег заставлять? (я ведь не один программист на проекте) и каждый вечер просматривать весь проект, проверять, чтоб никто не забыл #idef поставить. и всё равно забудут где-нить поставить и я не замечу.

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

[LifeMaker]

Есть искусственный способ ))

#ifndef __HEADER_SUPER_MACROS
#define __HEADER_SUPER_MACROS
//... код...
#endif // __HEADER_SUPER_MACROS
Сразу видно какой #endif, что закрывает.

Между прочим, Саттер и Александреску рекомендуют использовать именно этот вариант защиты от повторного включения, а не прагмы компиляторов )

конечно, Саттер - глава комитета по стандартизации. кому как не ему защищать стандарт. но я то практик...
(прошу заметить, Саттера, лично я, уважаю)

поторюсь - автор хидера - не я. и то, что автор воспользовался менее удачной конструкцией чем я вылезло боком мне
ps. проект поддерживается только под visual studio. аргументы кроссплатформенности тут не катят

[LifeMaker]

более того, если я буду писать кроссплатформенную библиотеку, я вздохну и напишу #ifndef-#define...
или если волею судьбы мне придётся использовать какой-нибудь слишком нестандартный компилятор.
но если я знаю, что проект никогда не потребует такого, это глупо

[Scorp__)]

Ну у меня ситуация такая, что я не могу быть уверен, что мне не скажут завтра: "а давай-ка то же самое, но под QNX". То есть любое приложение и библиотека должны быть как можно более дружествены к другим компиляторам и платформам )

[LifeMaker]

Scorp__),

Ну у меня ситуация такая, что я не могу быть уверен, что мне не скажут завтра: "а давай-ка то же самое, но под QNX". То есть любое приложение и библиотека должны быть как можно более дружествены к другим компиляторам и платформам )

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

а что ты пишешь? (если не секрет...)

[Scorp__)]

Блин, даже не знаю как написать ) В основном, это небольшие программки для тестов различных комплексов, для замеров времени выполнения это работа на оборонку и комплексы там сейчас активно переводятся с встраиваемых версий винды на qnx и linux. Но инерция большая, поэтому пока все же пишем под винду.
Да и другие заказы, которые делаю... не раз звучало, что потом может быть придется сделать такое же под Linux, правда пока еще не приходилось ))

[lapulya]

Scorp__),

Есть искусственный способ ))

Код:

#ifndef __HEADER_SUPER_MACROS
#define __HEADER_SUPER_MACROS
//... код...
#endif // __HEADER_SUPER_MACROS
Сразу видно какой #endif, что закрывает.

Между прочим, Саттер и Александреску рекомендуют использовать именно этот вариант защиты от повторного включения, а не прагмы компиляторов )

Это и имелось ввиду.

LifeMaker твой пример с больши хеадером не совсем корректный с ммм практической точкой зрения, если так можно выразиться. Я могу и одну функцию я на 15 старниц написать, а потом попросить кого-то в этом разобраться. Если грамотно писать (это безусловно идеал, но в одной команде он достижим) то классы будут короткие, закрывающий endif содержит комет к чему он относится (я когда еще писал, так у меня просто макрос в студии был, который получал на вход имя неймспейса + класса, а создавал он примерно следующее

Код:

#ifndef __ИМЯНЕЙМСПЕЙСА_ИМЯКЛАССА_H__
#define __ИМЯНЕЙМСПЕЙСА_ИМЯКЛАССА_H__

namespace ИМЯНЕЙМСПЕЙСА
{
	class ИМЯКЛАССА
	{
	public:
		ИМЯКЛАССА();
		~ИМЯКЛАССА();
	};
};

#endif // __ИМЯНЕЙМСПЕЙСА_ИМЯКЛАССА_H__

и вообще не испытывал проблем со временем объявления нового класса, поскольку макрос отрабатывает менее пол секунды) и внутри черезчур много idef (а зачем они? да еще и в таком количестве?)

[lapulya]

LifeMaker,

дык это же сильно неудобно, при каждом вызове функции обрамлять её #idef'ом.
зачем делать 100 раз то, что можно сделать один раз?
и всех коллег заставлять? (я ведь не один программист на проекте) и каждый вечер просматривать весь проект, проверять, чтоб никто не забыл #idef поставить. и всё равно забудут где-нить поставить и я не замечу.

вот для этого и это все обернуто в функцию (точнее конструктор), да ее вызов и создание объекта на стеке надо будет стерпеть (потеря производительности на лицо, но если это не критично). Ну а параметры вычисляй уже внутри ifdef (если это не возможно, то и макрос тебя не спасет от их вычислений)

В класс лучше оборачивать чем просто в функцию много потенциальных бонусов при минимуме затрат

[LifeMaker]

LifeMaker твой пример с больши хеадером не совсем корректный с ммм практической точкой зрения, если так можно выразиться. Я могу и одну функцию я на 15 старниц написать, а потом попросить кого-то в этом разобраться. Если грамотно писать (это безусловно идеал, но в одной команде он достижим) то классы будут короткие, закрывающий endif содержит комет к чему он относится
...
и внутри черезчур много idef (а зачем они? да еще и в таком количестве?)

ну здесь ситуация такая...
хидер на самом деле писался на в нашей команде, это библиотечный хидер, из игрового движка (PopCap framework). Движок кстати, на мой взгляд очень хороший... и то, что там применялась такая конструкция ещё не значит, это кривой код, что писали его неквалифицированные программисты.
Такая структура хидера там действительно нужна. Выглядит это так...

Код:

#ifndef __HEADER_MACROS__
#define __HEADER_MACROS__
// обяъявление классов, которое должно быть только один раз
#endif

#ifdef USING_FEATURE_FLAG

#define FEATURE_ONE feature_one_call()
#define FEATURE_TWO(params) feature_two_call(params)
//...

#else

#define FEATURE_ONE
#define FEATURE_TWO(params)
//...

#endif

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

хотя я бы реализовал это по другому. вот так...

Код:

//*************************************************************
//header1.h:
//*************************************************************
#pragma once
// обяъявление классов, которое должно быть только один раз



//*************************************************************
//header2.h:
//*************************************************************
#include "header1.h"

#ifdef USING_FEATURE_FLAG

#define FEATURE_ONE feature_one_call()
#define FEATURE_TWO(params) feature_two_call(params)
//...

#else

#define FEATURE_ONE
#define FEATURE_TWO(params)
//...

#endif

и ещё header1.h я бы подкинул в pch. и всё было бы здорово...

[LifeMaker]

LifeMaker,

дык это же сильно неудобно, при каждом вызове функции обрамлять её #idef'ом.
зачем делать 100 раз то, что можно сделать один раз?
и всех коллег заставлять? (я ведь не один программист на проекте) и каждый вечер просматривать весь проект, проверять, чтоб никто не забыл #idef поставить. и всё равно забудут где-нить поставить и я не замечу.

вот для этого и это все обернуто в функцию (точнее конструктор), да ее вызов и создание объекта на стеке надо будет стерпеть (потеря производительности на лицо, но если это не критично). Ну а параметры вычисляй уже внутри ifdef (если это не возможно, то и макрос тебя не спасет от их вычислений)

В класс лучше оборачивать чем просто в функцию много потенциальных бонусов при минимуме затрат

я смотрю мы немного недопонимаем друг друга... давай лучше я приведу свой код и объяню, почему я использую макрос и ничто другое.
задача написать вспомогательное нечто, позволяющее легко, не заморачиваясь выводить в уже открытый стандартный FILE* некую форматную строку, возможно не только в файл, но и в Debug Output Visual Studio, TTY игровую консоль, куда угодно в общем-то...
иметь возможность отключить всё это не имея при этом оверхеда (это игровое приложение), в Release-билде каждый FPS на счету.
я могу поместить WRITE_LOG в цикл рендера, там даже вызов пустой функции или пустой конструир объекта с парой параметров может очень сильно подпортить жизнь...
вот так:

Код:

WRITE_LOG("ptr is NULL");
WRITE_LOG("File '%s' not found.",filename.c_str());
WRITE_LOG("Players scores: '%d'.",mPlayerScores);
WRITE_LOG("Matrix value is: %f %f %f %f - %f %f %f %f - %f %f %f %f - %f %f %f %f",mtx[0][0],mtx[0][1],mtx[0][2],mtx[0][3],
mtx[1][0],mtx[1][1],mtx[1][2],mtx[1][3],mtx[2][0],mtx[2][1],mtx[2][2],mtx[2][3],mtx[3][0],mtx[3][1],mtx[3][2],mtx[3][3],);

WRITE_LOG("Player2 health: %f", gGameDataBase->FindPlayerNode("Player2")->GetHealth());

// реализация примерно так WRITE_LOG

#ifdef NDEBUG

#define WRITE_LOG(...)

#else

#ifdef WIN32

#define WRITE_LOG(...) { \
    fprintf(gLogFile,__VA_ARGS__);fprintf(gLogFile,"\n"); \
    char buf[512]; sprintf(buf,__VA_ARGS__); OutputDebugString("buf"); OutputDebugString("\n"); \
}

#endif

#ifdef PS3

#define WRITE_LOG(...) { \
    fprintf(gLogFile,__VA_ARGS__);fprintf(gLogFile,"\n"); \
    PSSG_PRINTF(__VA_ARGS__); PSSG_PRINTF("\n"); \
}

#endif

#endif

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

отдельный момент, ради которого используется макрос: проверка GCC компилятором корректности форматной строки.
т.е. вот что он говорит на вот таком коде:

Код:

1: // test.cpp
2: #include <stdio.h>
3: int main()
4: {
5: 	float f;
6: 	int i;
7: 	printf("%d %f",f,i);
8: 	return 0;
9: }

test.cpp: In function `int main()':
test.cpp:7: warning: int format, double arg (arg 2)
test.cpp:7: warning: double format, different type arg (arg 3)

полезная подсказка чаще всего программист ошибается вот так

Код:

std::string str;
printf("%s",str); //плохо
printf("%s",str.c_str()); //надо было так, все об этом знают, но часто забывают, а вылазит только в рантайме...

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

Код:

void WRITE_LOG(const char* fmt, ...) 
{
#ifndef NDEBUG
    va_list argList;
    va_start(argList, fmt);
    char buffer[bufSize];
    vsnprintf(buffer, bufSize, fmt, argPtr);
    va_end(argList);
    OutputDebugString(buffer);
    OutputDebugString("\n");
#endif
}

в итоге GCC говорит что-то вроде warning: Format string is not literal. Unable to check parameters.
итого, мы потеряли ценную информацию от компилятора. в случае с макросом вся информация сохраняется, как буд-то мы передали параметры непосредственно в printf (что мы собственно и сделали). и warning уже выручал меня раза три, и коллег уже выручал, хотя WRITE_LOG'у этому всего неделя примерно... и выручит, я думаю, ещё не раз

[Алексей++]

Код:

#define m(a,b,c) a+b+c

int i=m(1,,,,2,,,3,);

это компилируется ))) А почему

[Джон]

Опять олифишь?

warning C4002: too many actual parameters for macro 'm'
error C2105: '++' needs l-value

[Алексей++]

это в VC6 было, вернее не совсем прям так запущено, а двойная запятая была ) Прокатывает

[Джон]

Лёш, что значит двойная запятая? Какая разница?

Ты поставь себя на место компилятора:

из твоего выражения получается так
i = 1++;

остальные параметры значения не имеют, но первые три затребованные должны присутствовать. А так ты и получаешь ошибку: C2105: '++' needs l-value.

Если например ты возьмёшь вот такой вариант:
int i=m(1,2,3,4,5,6,,,,,,7,,,,,,,);

или даже такой

int i=m(1,2,3,4,5,"hallo",new CEdit());

то, кроме предупреждения о превышении числа параметров, всё будет в порядке. Остальные параметры нигде не фигурируют поэтому будут проигнорированы.

Но обязательные должны присутствовать.

[Алексей++]

в том и дело, что в 6-й подряд идущие запятые (даже разделённые переводом строки) в параметрах воспринимаются как одна запятая

[Джон]

Покажи точно, какая у тебя строка компилится в шохе.

[Алексей++]

так я показал

Код:

#define m(a,b,c) a+b+c

int i=m(1,,,,2,,,3,);

и не просто компилится, но ещё и выполняется правильно

[Джон]

Я вот про что:

вернее не совсем прям так запущено, а двойная запятая была

зы В любом случае так лучше не делать, как минимум в 2003 уже не прокатит.

[lapulya]

LifeMaker, хехехе... или гибкость или скорость, от теории к практике путь тернист.

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

Итого, если это не модули ПО, от которых требуется выжать максимум из железки по какому-то показателю,  а "гражданское" приложение, то макросы в утиль. Если это "боевой" слой, то какие нах обертки и т.д. - дефайн (если он оправдан и нужен) рулеззз.

[Алексей++]

lapulya, копил обиду полтора года ? ))  С возвращением, кстати

[lapulya]

Угу, шучу... А где заяц? Синий такой...

[RXL]

Пробегает временами. Чаще по аськам.