Участник:Yulya3102/Плюсы2сем

one definition rule (ODR)

Вкратце, положения ODR выглядят так:

1. В пределах любой единицы трансляции шаблон, тип данных, функция, или объект не могут иметь более одного определения. Некоторые могут иметь неограниченное число объявлений. Определение порождает сущность.
2. В пределах программы (совокупности всех единиц трансляции) объект или не-inline функция не могут иметь больше одного определения; если объект или функция используются, у каждого из них должно быть строго по единственному определению. Можно объявить объект или функцию, которые не будут использованы в программе, в этом случае не потребуется и их определения. Ни в коем случае не должно быть более одного определения.
3. Некоторые сущности, например, типы, шаблоны или внешние inline функции, могут определяться в более чем одной единице трансляции. Для данной сущности, каждое определение должно быть одним и тем же. Объекты или функции, не являющиеся внешними, в разных единицах трансляции имеют разные сущности, даже если их имена и типы совпадают.

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

Например:

 // file1.c:
     int a = 1;
     int b = 1;
     extern int c;

 // file2.c:
     int a;
     extern double b;
     extern int c;

В данном примере 3 ошибки: a определено дважды (int a; является определением, которое означает int a=0;), b описано дважды с разными типами, а c описано дважды, но не определено. Эти виды ошибок (ошибки компоновки) не могут быть обнаружены компилятором, который за один раз видит только один файл. Компоновщик, однако, их обнаруживает.

type_traits'ы

This header defines a series of classes to obtain type information on compile-time.

The header contains: Helper classes: Standard classes to assist in creating compile-time constants. Type traits: Classes to obtain characteristics of types in the form of compile-time constant values. Type transformations: Classes to obtain new types by applying specific transformations to existing types.

anonymous namespaces

You can declare an unnamed namespace as a superior alternative to the use of global static variable declarations.

namespace { namespace-body }

An unnamed-namespace-definition having the syntax shown above behaves as if it were replaced by:

namespace unique { namespace-body }
using namespace unique;

Each unnamed namespace has an identifier, assigned and maintained by the program and represented here by unique, that differs from all other identifiers in the entire program. For example:

// unnamed_namespaces.cpp
// C2872 expected
namespace { int i; }          // unique::i
void f() { i++; }             // unique::i++

namespace A {
   namespace {
       int i;      // A::unique::i
       int j;      // A::unique::j
   }
}

using namespace A;

void h()
{
   i++;            // C2872: unique::i or A::unique::i
   A::i++;         // C2872: A::i undefined
   j++;            // A::unique::j++
}

Unnamed namespaces are a superior replacement for the static declaration of variables. They allow variables and functions to be visible within an entire translation unit, yet not visible externally. Although entities in an unnamed namespace might have external linkage, they are effectively qualified by a name unique to their translation unit and therefore can never be seen from any other translation unit.