define и единици трансляции

[stima]

Хочу сделать что-то наподобии такого:

Код:

----A.h-----
#ifndef A
#define A

#include <Debug>

class A {
    public:
        static void foo(const QString& str);
}

#endif
-------------
------A.cpp-------

void A::foo(const QString& str)
{
   bool empty = str.IsEmpty();

#ifdef PPRINT
    if ( empty ) qDebug() << "Warning: empty";
#else
    Q_ASSERT_X(!empty, "A", "empty str");
#endif

    //....some logic....
}
---------
--------main.cpp--------

#define PRINT
#include "A.h"

int main()
{
    A::foo("");

    return 0;
}
-------

Но постоянно срабатывает ассерт, то есть моего дефайна не видно. Как сделать правильно?

[kambala]

в .pro файле дописать QMAKE_CXX_FLAGS += -DPRINT

ну и в коде использовать не PPRINT а PRINT

[mutineer]

Ты надеешься на то, что препроцессор сначала пройдет по main.cpp, а затем по A.cpp
А где гарантия что он так сделает?

[twp]

в .pro файле дописать QMAKE_CXX_FLAGS += -DPRINT

ну и в коде использовать не PPRINT а PRINT

есть же DEFINES

[kambala]

в .pro файле дописать QMAKE_CXX_FLAGS += -DPRINT

ну и в коде использовать не PPRINT а PRINT

есть же DEFINES

буду знать, спасибо

[Disa]

Взято с гугл стайл гайда по опенсурсным проектам:

Be very cautious with macros. Prefer inline functions, enums, and
const variables to macros:

Macros mean that the code you see is not the same as the code the compiler sees.
This can introduce unexpected behavior, especially since macros have global scope.

Luckily, macros are not nearly as necessary in C++ as they are in C.
Instead of using a macro to inline performance-critical code, use an
inline function. Instead of using a macro to store a constant, use a
const variable. Instead of using a macro to "abbreviate" a long variable
name, use a reference. Instead of using a macro to conditionally compile code ...
well, don't do that at all (except, of course, for the #define guards to
prevent double inclusion of header files). It makes testing much more difficult.

Macros can do things these other techniques cannot, and you
do see them in the codebase, especially in the lower-level libraries.
And some of their special features (like stringifying, concatenation, and so forth)
are not available through the language proper. But before using a macro,
consider carefully whether there's a non-macro way to achieve the same result.

The following usage pattern will avoid many problems with macros;
if you use macros, follow it whenever possible:

Don't define macros in a .h file.
#define macros right before you use them, and #undef
them right after.
Do not just #undef an existing macro before replacing
it with your own; instead, pick a name that's likely to be
unique.
Try not to use macros that expand to unbalanced C++ constructs,
or at least document that behavior well.
Prefer not using ## to generate function/class/variable names.

И еще:

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

Пруфлинк

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

[stima]

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

[kambala]

а что такое "единица трансляции"?

по поводу задания макросов тебе уже ответили выше - используй DEFINES (ну или QMAKE_CXX_FLAGS).

[Disa]

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

[lit-uriy]

>>а что такое "единица трансляции"?
это то, что кушает компилятор, обычно - cpp-файл и всё что в него включается (include).