Такое же имя класса в разных файлах на C++

Question

Если два файла C++ имеют разные определения классов с тем же именем, тогда, когда они компилируются и связаны, что-то выкидывается даже без предупреждения. Например,

// a.cc 
class Student { 
public: 
    std::string foo() { return "A"; } 
}; 
void foo_a() 
{ 
    Student stu; 
    std::cout << stu.foo() << std::endl; 
} 

// b.cc 
class Student { 
public: 
    std::string foo() { return "B"; } 
}; 
void foo_b() 
{ 
    Student stu; 
    std::cout << stu.foo() << std::endl; 
} 

После компиляции и связаны друг с другом с помощью G ++, как будет выводить «А» (если a.cc предшествует b.cc в порядке командной строки).

Аналогичная тема here. Я вижу, что пространство имен решит эту проблему, но я не знаю, почему компоновщик даже не снимает предупреждение. И если одно определение класса имеет дополнительную функцию, которая не определена в другой, скажем, если b.cc обновляется:

// b.cc 
class Student { 
public: 
    std::string foo() { return "B"; } 
    std::string bar() { return "K"; } 
}; 
void foo_b() 
{ 
    Student stu; 
    std::cout << stu.foo() << stu.bar() << std::endl; 
} 

Тогда stu.bar() работает хорошо. Спасибо всем, кто может рассказать мне, как работает компилятор и компоновщик в такой ситуации.

В качестве дополнительного вопроса, если классы определены в заголовочных файлах, должны ли они всегда быть обернуты безымянным пространством имен, чтобы избежать такой ситуации? Есть ли побочные эффекты?

Answer 1

Это нарушение одно правило определения (C++ 03, «правило одно определение» 3.2/5) в, который говорит (среди прочего):

Там может быть больше, чем одно определение типа (9), ... в программе, при условии, что каждое определение отображается в другой блок перевода и при условии, что определения удовлетворяют следующим требованиям . С учетом такой объект с именем D определены в более чем одной единице перевода, то

• каждое определение D состоит из одной и той же последовательности маркеров;

Если вы нарушили правила на одно определение, его поведение не определено (что означает, что могут происходить странные вещи).

Компилятор видит несколько определений Student::foo() - один в объектном файле и один в b. Однако он не жалуется на это; он просто выбирает один из двух (как это бывает, первый из них встречается). Эта «мягкая» обработка повторяющихся функций, по-видимому, происходит только для встроенных функций. Для не-встроенных функций компоновщик будет жалуется на несколько определений и откажется создать исполняемый файл (могут быть варианты, которые ослабляют это ограничение). И GNU ld, и компоновщик MSVC ведут себя таким образом.

Поведение имеет некоторый смысл; встроенные функции должны быть доступны в каждой единицы перевода, в которой они используются. И в общем случае они должны иметь доступ к не-встроенным версиям (в случае, если вызов не встроен или если адрес функции занят). inline - это просто бесплатный проход вокруг правила единого определения, но для его работы все встроенные определения должны быть одинаковыми.

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

Что касается вашего второго вопроса:

В качестве дополнительного вопроса, если классы определены в заголовочных файлах, должны они всегда будут обернуты с безымянного пространства имен, чтобы избежать такой ситуации? Есть ли побочные эффекты?

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

Поместите их в разные пространства имен с именами.

Answer 2

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

Answer 3

Я думаю, что ваш «лишний» вопрос является ключом к основному вопросу.

Если я понимаю ваш дополнительный вопрос, то я думаю, что вы делаете не хотите обернуть их в пространство имен, так как если вы # включите один и тот же класс в несколько файлов .cc, то вы, вероятно, захотите использовать только одну копию каждого метода, даже если они определены внутри класса.

Этот (тип) объясняет, почему вы только получаете одну версию каждой функции в своем основном примере. Я ожидаю, что компоновщик просто предполагает, что две функции идентичны - генерируются из одного и того же #include источника. Было бы неплохо, если бы линкер обнаруживал, когда они были разными, и выдавал предупреждение, но я думаю, что это сложно.

Как указывает Марк Б, практический ответ: «Просто не ходи туда».

Answer 4

Помимо нарушения одного правила определения, вы не видите компилятор жалуясь из Name mangling in C++

Edit: Как отметил Konrad Rudolph: исковерканные имена в этом случае было бы то же самое.

Answer 5

но я не знаю, почему линкер даже не снимает предупреждение.

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

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

Как следствие, линкер просто признает, что то, что вы бросаете на него, не нарушает ODR. Не идеальная ситуация, но хорошо.