C++ – CMake: when to use add_definitions instead of set_target_properties(target PROPERTIES COMPILE_DEFINITIONS definitions)

ccmake

In CMake documentation, we can read:

add_definitions

Adds flags to the compiler command line for sources in the current directory and below.

COMPILE_DEFINITIONS property on directories

COMPILE_DEFINITIONS: Preprocessor definitions for compiling a directory's sources.

COMPILE_DEFINITIONS property on targets

COMPILE_DEFINITIONS: Preprocessor definitions for compiling a target's sources.

COMPILE_DEFINITIONS property on source files

COMPILE_DEFINITIONS: Preprocessor definitions for compiling a source file.

COMPILE_DEFINITIONS and add_definitions functionality seems to overlap. COMPILE_DEFINITIONS property seems more flexible.

So it seems that COMPILE_DEFINITIONS property does everything add_definitions does, and even more.

So, in which cases must we call add_definitions because COMPILE_DEFINITIONS property cannot be used?

Best Answer

add_definitions has existed in CMake since the very first build of CMake came online more than a decade ago.

COMPILE_DEFINITIONS is simply the newer, more flexible and fine-grained way to do it.

They will always both be around: since 99%+ of the existing CMakeLists.txt files in the world use add_definitions, it simply would not be wise to remove it. The CMake devs work very hard to maintain backwards compatibility... sometimes to the detriment of clarity and simplicity. And sometimes doing essentially the same thing in multiple differing ways.

So: add_definitions is primarily useful to configure pre-existing CMakeLists files -- for those projects that have been around since before COMPILE_DEFINITIONS was introduced. And, since those projects use it, any newer projects that are based on what people learn from reading those CMakeLists files are also quite likely to use add_definitions.

But if using COMPILE_DEFINITIONS alone is sufficient for your needs, there's certainly nothing wrong with that.

Related Solutions

C++ – When should you use a class vs a struct in C++

The differences between a class and a struct in C++ is:

struct members and base classes/structs are public by default.
class members and base classes/struts are private by default.

Both classes and structs can have a mixture of public, protected and private members, can use inheritance and can have member functions.

I would recommend you:

use struct for plain-old-data structures without any class-like features;
use class when you make use of features such as private or protected members, non-default constructors and operators, etc.

C++ – Why use static_cast(x) instead of (int)x

The main reason is that classic C casts make no distinction between what we call static_cast<>(), reinterpret_cast<>(), const_cast<>(), and dynamic_cast<>(). These four things are completely different.

A static_cast<>() is usually safe. There is a valid conversion in the language, or an appropriate constructor that makes it possible. The only time it's a bit risky is when you cast down to an inherited class; you must make sure that the object is actually the descendant that you claim it is, by means external to the language (like a flag in the object). A dynamic_cast<>() is safe as long as the result is checked (pointer) or a possible exception is taken into account (reference).

A reinterpret_cast<>() (or a const_cast<>()) on the other hand is always dangerous. You tell the compiler: "trust me: I know this doesn't look like a foo (this looks as if it isn't mutable), but it is".

The first problem is that it's almost impossible to tell which one will occur in a C-style cast without looking at large and disperse pieces of code and knowing all the rules.

Let's assume these:

class CDerivedClass : public CMyBase {...};
class CMyOtherStuff {...} ;

CMyBase  *pSomething; // filled somewhere

Now, these two are compiled the same way:

CDerivedClass *pMyObject;
pMyObject = static_cast<CDerivedClass*>(pSomething); // Safe; as long as we checked

pMyObject = (CDerivedClass*)(pSomething); // Same as static_cast<>
                                     // Safe; as long as we checked
                                     // but harder to read

However, let's see this almost identical code:

CMyOtherStuff *pOther;
pOther = static_cast<CMyOtherStuff*>(pSomething); // Compiler error: Can't convert

pOther = (CMyOtherStuff*)(pSomething);            // No compiler error.
                                                  // Same as reinterpret_cast<>
                                                  // and it's wrong!!!

As you can see, there is no easy way to distinguish between the two situations without knowing a lot about all the classes involved.

The second problem is that the C-style casts are too hard to locate. In complex expressions it can be very hard to see C-style casts. It is virtually impossible to write an automated tool that needs to locate C-style casts (for example a search tool) without a full blown C++ compiler front-end. On the other hand, it's easy to search for "static_cast<" or "reinterpret_cast<".

pOther = reinterpret_cast<CMyOtherStuff*>(pSomething);
      // No compiler error.
      // but the presence of a reinterpret_cast<> is 
      // like a Siren with Red Flashing Lights in your code.
      // The mere typing of it should cause you to feel VERY uncomfortable.

That means that, not only are C-style casts more dangerous, but it's a lot harder to find them all to make sure that they are correct.

Best Answer

Related Solutions

C++ – When should you use a class vs a struct in C++

C++ – Why use static_cast(x) instead of (int)x

Related Topic