Почему внутриклассовая инициализация статических членов нарушает ODR?

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

прототипы.h

class CLASS
{
public:
    static const int global;
};
template <class T>
class TEMPLATE
{
public:
    static const int global;
};

void part1();
void part2();

файл1.cpp

#include <iostream>
#include "template.h"
const int CLASS::global = 11;
template <class T>
const int TEMPLATE<T>::global = 21;
void part1()
{
    std::cout << TEMPLATE<int>::global << std::endl;
    std::cout << CLASS::global << std::endl;
}

файл2.cpp

#include <iostream>
#include "template.h"
const int CLASS::global = 21;
template <class T>
const int TEMPLATE<T>::global = 22;
void part2()
{
    std::cout << TEMPLATE<int>::global << std::endl;
    std::cout << CLASS::global << std::endl;
}

main.cpp

#include <stdio.h>
#include "template.h"
void main()
{
    part1();
    part2();
}

Я согласен, что этот пример полностью надуманный, но, надеюсь, он демонстрирует, почему «Изменение сильных ссылок на слабые компоновщики является критическим изменением».

Будет ли это компилироваться? Нет, потому что в нем есть 2 сильные ссылки на CLASS::global.

Если вы удалите одну из сильных ссылок на CLASS::global, будет ли она скомпилирована? Да

Каково значение TEMPLATE::global?

Какова ценность CLASS::global?

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

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

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

Вы должны помнить, что во время появления C++ 8-битные, 16-битные и 32-битные процессоры все еще были действительными целями, у AMD и Intel были похожие, но разные наборы инструкций, поставщики оборудования предпочитали закрытые частные интерфейсы открытым стандартам. И цикл сборки может занять часы, дни и даже неделю.

Раньше структура сборки C++ была довольно простой.

Компилятор создал объектные файлы, которые обычно содержали одну реализацию класса. Затем компоновщик объединил все объектные файлы в исполняемый файл.

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

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

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

Изменить:

В былые времена компоновщики часто связывали объектные файлы, созданные на разных языках. Было обычным делом связывать ASM и C, и даже после C++ часть этого кода все еще использовалась, и это абсолютно необходимо для ODR. Тот факт, что ваш проект связывает только файлы C++, не означает, что это все, что может сделать компоновщик, и поэтому он не будет изменен, поскольку большинство проектов теперь исключительно C++. Даже сейчас многие драйверы устройств используют компоновщик в соответствии с его более оригинальным намерением.

Ответ:

Однако кажется, что эти «сложные правила компоновщика» существуют и используются в случае шаблона, так почему бы не использовать его и в простом случае?

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

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

Таким образом, шаблоны не влияют на правила компоновщика, но правила компоновщика по-прежнему важны, потому что ODR является требованием ASM и C, которые компоновщик все еще связывает, и люди, кроме вас, все еще фактически используют.