coolste Makros

Sone

Hmm, nicht schlecht.

#define true false // happy debugging suckers

nurf

Da das Niveau ja immer weiter absinkt ...

#define false '-'-'-'
#define true  '/'/'/'

nurf schrieb:

Da das Niveau ja immer weiter absinkt ...
#define false '-'-'-'
#define true  '/'/'/'

das kompiliert sogar, ich staune

Für den GCC:

#define DO_PRAGMA(x) _Pragma(#x)
#define TODO(x) DO_PRAGMA(message("TODO: " #x ))

TODO(test); // => note: #pragma message: TODO: test

otze

und so läufts auch auf dem MSVC.

#define DO_PRAGMA(x) __pragma(#x)

krümelkacker

krümelkacker schrieb:

Ich finde das hier ganz nett:

#define REQUIRES(...) ,class=typename std::enable_if<(__VA_ARGS__)>::type

U.a. so zu verwenden in C++11:

template<class T, class U
  REQUIRES( std::is_scalar<T>::value &&
            std::is_scalar<U>::value &&
            sizeof(T)==sizeot(U) )
>
inline T reinterpret_value(U x)
{
  T y;
  std::memcpy(&y,&x,sizeof y);
  return y;
}

also für constrained templates.

Apropos constrained templates...

hustbaer

otze schrieb:

und so läufts auch auf dem MSVC.
#define DO_PRAGMA(x) __pragma(#x)

Waaaaaaaaaaah, MS wiedermal.
Die Deppen.
Weisst du ab welcher Version das geht?

Ethon

2 eher unspekakuläre Makros, die aber den Code bei mir echt verschönern:

#define SYNTHETIC_CURRENT_FUNCTION &__PRETTY_FUNCTION__[0]
#define SYNTHETIC_THROW(ErrorClass, ...) \
    throw ErrorClass(SYNTHETIC_CURRENT_FUNCTION, __VA_ARGS__)

(Wobei meine Exceptionklassen alle den Funktionsnamen als ersten Konstruktorparameter nehmen)

und

#define REQUIRE_FILE(path, errorMsg)                    \
    do {                                                \
    if(!boost::filesystem::is_regular_file(path))       \
        SYNTHETIC_THROW(Synthetic::InvalidPathError,    \
            errorMsg, path);                            \
    } while(0)

#define REQUIRE_DIRECTORY(path, errorMsg)               \
    do {                                                \
    if(!boost::filesystem::is_directory(path))          \
        SYNTHETIC_THROW(Synthetic::InvalidPathError,    \
            errorMsg, path);                            \
    } while(0)

Auch recht häufig benutzt:

#define UNUSED(x) (void)x

krümelkacker schrieb:

krümelkacker schrieb:
Ich finde das hier ganz nett:
#define REQUIRES(...) ,class=typename std::enable_if<(__VA_ARGS__)>::type
U.a. so zu verwenden in C++11:
template<class T, class U
  REQUIRES( std::is_scalar<T>::value &&
            std::is_scalar<U>::value &&
            sizeof(T)==sizeot(U) )
>
inline T reinterpret_value(U x)
{
  return T(reinterpret_cast<T&>(x));
}
also für constrained templates.
Apropos constrained templates...

Ich finde das ohne Makro etwas lesbarer

template <bool B, class = typename std::enable_if<B>::type> struct requires;

template<class T, class U,
         class=requires<std::is_trivially_copyable<T>::value &&
                        std::is_trivially_copyable<U>::value &&
                        sizeof(T)==sizeof(U)>>
inline T reinterpret_value(U x)
{
  T y;
  std::memcpy(&y,&x,sizeof y);
  return y;
}

oder sogar

template <bool B, class = typename std::enable_if<B>::type> struct requires;
template <class T, template<typename...>class C>
constexpr bool that() { return C<T>::value; }

template<class T, class U,
         class=requires<that<T, std::is_trivially_copyable>() &&
                        that<U, std::is_trivially_copyable>() &&
                        sizeof(T)==sizeof(U)>>
inline T reinterpret_value(U x)
{
  return T(reinterpret_cast<T&>(x));
}

(Btw, weshalb ist

requires

ein Keyword?)

Ethon

allescalar schrieb:

(Btw, weshalb ist
requires
ein Keyword?)

Laut dem Link oben wird es vermutlich Keyword in C++17 .

Kellerautomat

Das koennen nun aber wirklich Funktionen sein, Ethon...

hustbaer

@Kellerautomat
Ich gehe davon aus dass er es als Makro ausgeführt hat, damit er die File-/Zeilen-Info der Funktion bekommt die das Makro erweitert, anstatt immer die Info über die "RequiresFile" Funktion.

Mit genau der selben Motivation hab' ich mir sowas gebastelt

#define GLAZE_LOCATION_INFO() \
	::Glaze::Log::LocationInfo( \
		GLAZE_WIDEN(__FILE__), \
		__LINE__, \
		GLAZE_WIDEN(__FUNCTION__))

#define GLAZE_LOCATION_INFO_N(locationName_) \
	::Glaze::Log::LocationInfo( \
		GLAZE_WIDEN(__FILE__), \
		__LINE__, \
		GLAZE_WIDEN(__FUNCTION__), \
		(locationName_))

Dann kann man eine RequiresFile Funktion machen, die einfach ein ::Glaze::Log::LocationInfo als Parameter nimmt.

Kellerautomat

Ah, das ergibt natuerlich Sinn.

hustbaer

Ethon schrieb:

#define UNUSED(x) (void)x

void Fun(istream& is)
{
    UNUSED(is).get();
}

->

#define UNUSED(x) ((void)x)

volkard

hustbaer schrieb:

Ethon schrieb:

#define UNUSED(x) (void)x

void Fun(istream& is)
{
    UNUSED(is).get();
}

->

#define UNUSED(x) ((void)x)

->

UNUSED(in.get());

->

UNUSED(((void(*)())0)());

Es kömmt so selten vor, daß ich bei Bedarf roh (void) davor in den Code schreibe. Aber als Makro vielleicht

->

#define UNUSED(x) ((void)sizeof(x))

Sone

Komisch, requires wird bei mir in CodeBlocks ebenfalls gehilighted.

hustbaer

volkard schrieb:

->

UNUSED(in.get());

Was vollkommen korrekt ist, wo soll das Problem sein?

Ich verstehe auch nicht warum man sich darüber aufregen bzw. lustig machen muss, wenn jemand vorschlägt etwas zu fixen was ganz easy zu fixen ist - nach dem Motto "zahlt sich net aus, kommt ja so selten vor".

BTW: ich verwende solche UNUSED Makros nicht, weil wir die entsprechende Warning einfach abgedreht haben.

Das UNUSED Macro gibt es so ähnlich für den MSVC (ich glaube in der Windows.h) als

#define UNREFERENCED_PARAMETER(P) (P)

um beispielsweise Warnungen auf Level 4 für hPrevInstance in der WinMain abzustellen.