Как трактовать определение в двух разных модулях классов с одинаковым именем?

Question

[dendibakh]

Всем добрый день!
Подскажите, пожалуйста, как трактовать с точки зрения стандарта С++ код, представленный ниже? Он компилируется и компонуется без ошибок и предупреждений, однако работает непредсказуемо. Проверял на gcc 4.8.1 и msvc 2013.

$ cat a.cpp
#include <stdio.h>

struct A
{
   void foo() { printf("a.cpp: A::foo()\n");}
};

void fooA()
{
   A a;
   a.foo();
}

$ cat b.cpp
#include <stdio.h>

struct A
{
   void foo() { printf("b.cpp: A::foo()\n");}
};

void fooB()
{
   A a;
   a.foo();
}

$ cat main.cpp 
void fooA();
void fooB();

int main()
{
      fooA();
      fooB();
      return 0;
}

$ g++ main.cpp a.cpp b.cpp 

$ ./a.out
a.cpp: A::foo()
a.cpp: A::foo()

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

Comments

[DISaccount]

В main.cpp никаких инклудов!? Фантастика.

[Станислав Макаров]

DISaccount а чего им быть если вручную задекларены fooA и fooB в начале файла :). По теме: такие определения (которые внутри cpp и не должны быть видны за его пределами) надо оборачивать в анонимный неймспейс. Этот неймспейс будет свой для каждого из файлов, и коллизий не будет, сколько классов с одинаковыми именами не создавай. А так лично я проблемы не вижу в двух одинаково названных утилитарных классах, если их использование ограничено одним cpp

[dendibakh]

Nipheris: Да, неймспейсы это конечно. Это сразу говорит, что компоновка внутренняя (internal linkage). Тут без вопросов.
Но как быть если не обернул. Сам дурак?
Добавлю, что предварительно я задавал вопрос про компоновку имени класса здесь. И вроде как выяснили, что в примере выше она все-таки внешняя.

[DISaccount]

Nipheris: не не не. "Фантастика" - декларировать все функции, вместо инклуда хэдеров.
dendibakh: а что тут можно сделать, кроме как расхлебывать? Самое быстрое уже порекомендовали - безымянные неймспейсы втыкать.

Answer 1

[Евгений]

В общем немного покопавшись нарисовалась вполне ожидаемая ситуация:
В получившемся исполняемом файле вызывается одна и та же версия метода A::foo()

objdump -d a.exe
  00401600 <__Z4fooBv>:
  call   402890 <__ZN1A3fooEv>
  
0040161c <__Z4fooAv>:
  call   402890 <__ZN1A3fooEv>
 
00401638 <_main>:
  401643:       e8 d4 ff ff ff          call   40161c <__Z4fooAv>
  401648:       e8 b3 ff ff ff          call   401600 <__Z4fooBv>

После компиляции в объектных файлах используется одно и тоже имя для метода A::foo()

objdump -t b.o

b.o:     file format pe-i386

SYMBOL TABLE:
[  0](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x00000000 b.cpp
File
[  2](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .text$_ZN1A3fooEv
AUX scnlen 0x17 nreloc 2 nlnno 0 checksum 0x0 assoc 0 comdat 2
[  4](sec  5)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00000000 __ZN1A3fooEv
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[  6](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000000 __Z4fooBv

objdump -t a.o

a.o:     file format pe-i386

SYMBOL TABLE:
[  0](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x00000000 a.cpp
File
[  2](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .text$_ZN1A3fooEv
AUX scnlen 0x17 nreloc 2 nlnno 0 checksum 0x0 assoc 0 comdat 2
[  4](sec  5)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00000000 __ZN1A3fooEv
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[  6](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000000 __Z4fooAv

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

Comments

[dendibakh]

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

[dendibakh]

Вот вопрос на SO: https://stackoverflow.com/questions/28749179/why-t...

Answer 2

[Евгений Шатунов]

Именно такую ситуацию имел в команде пару месяцев назад. Человек использовал небольшой вспомогательный класс внутри реализации (.cpp) юнит-тестов. И оба раза назвал этот впосогательный класс одинаково. Код в этом случае прекрасно компилируется, только работает как граната.

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

Обычный линковщик ожидает что на вход к нему будут поданы уже готовые к линейной линковке блоки. Обычный линковщик, если его не попросить, связывает только уже используемые участки кода, начиная с точки входа или точек экспорта. Сортировка блоков (библиотек и модулей) обычно топологическая, но с сохранением алфавитного порядка между модулями в рамках одного ранга. Вот и получается, что "ликовщик увязывает этот код как получится".
Линковщик в очередном модуле встречает еще не связанное, но уже используемое где-то имя типа и генерирует для этого типа код. Далее, в другом модуле линковщик снова встречает имя этого же уже связанного типа и просто отбрасывает его. Но отбрасывается не весь тип, а только уже связанные его части. Если во втором рассматриваемом типе будет находиться иной набор функций, они будут подвязаны к набору функций уже встроенного типа. И вот с этого места начинается дорога в ад, т.к. у двух таких типов может быть разный размер, разные поля в состоянии, разное выравнивание, разная реализация одинаково названных функций.

Выход из ситуации:

• использовать Forward declaration для таких локальных классов (добиться ошибки 'class redefinition' в таких случаях);
  
• обертывать описания в локальные неименованные namespace (добиться уникальности пространства для таких классов);
  
• описывать такие локальные классы как nested-классы от глобальных (делать хотяб Forward declaration в пространстве глобального класса - тоже упор на уникальность пространства);
  

Comments

[Евгений]

У меня все равно не много не укладывается в голове поведение линковщика. После компиляции у нас есть a.obj, в котором есть реализация функции fooA(), в которой должен быть подставлен адрес метода A::foo() из этой же единицы трансляции. Аналогично в b.obj должна быть реализация функции fooB() и адресом метода A::foo() из текущей единицы трансляции. Почему при линковке он начинает подставлять как попало?

[dendibakh]

Евгений: Ну все-таки наверное не как попало. Определенный алгоритм работы у линковщика должен быть. Например, который описан здесь. То есть, например, он может обрабатывать obj файлы в определенной последовательности. Но вот почему он не ругается на это, как например со свободными функциями?

Answer 3

[jackroll]

Пользуюсь MSVS 2013. Вылезает ошибка C2011.
Используйте namespaceы или #ifdef-#ifndefы

Answer 4

[AxisPod]

Опции линкера надо ковырять, может что и есть в этом плане.