2012-01-23 3 views
1

У меня есть библиотека (a.so) с базовыми классами (MyClassA). Другая библиотека (b.so) имеет класс MyClassB, который наследуется от MyClassA (в a.so). Я компилирую MyClassA.h и MyClassA.cpp, изолированные в a.so. MyClassB.h и MyClassB.cpp скомпилированы отдельно (со ссылкой на MyClassA.h, но без добавления MyClassA.h в b.so). Затем я связываю b.so с a.so.Общие библиотеки C++ с наследованием

Подводя итог:

  1. a.so содержит MyClassA.h и MyClassA.cpp
  2. b.so содержит MyClassB.h и MyClassB.cpp
  3. b.so связана с a.so

Когда я пытаюсь скомпилировать, я получаю несколько ссылочных ошибок для MyClassA, вызванных b.so.

Когда я компилирую b.so и добавляю MyClass.h к нему, библиотека компилируется и запускается без каких-либо ошибок. Следовательно:

  1. a.so содержит MyClassA.h и MyClassA.cpp
  2. b.so содержит MyClassB.h, MyClassB.cpp И MyClassA.h
  3. b.so связана с a.so

Возможно ли, чтобы на C++ использовался мой первый вариант, или он всегда должен включать базовые заголовки в библиотеку подкласса?

+0

Как первый вариант должен работать, нам нужно увидеть больше ошибок и кода, особенно заголовков, и то, что они включают в себя – Mark

ответ

0

Все производные классы должны #include объявления базового класса во время компиляции. Реализация базового класса должна быть известна при связывании времени.

В вашем случае:

  1. a.so содержит MyClassA.h и MyClassA.cpp
  2. b.so содержит MyClassB.h и MyClassB.cpp но MyClassB.h `#include«MyClassA.h "
  3. b.so ссылки a.so с помощью:

г ++ -o b.so -la

+0

именно то, что я сделал. #Include "MyClassA.h "находится в заголовке MyClassB. Это не проблема. Проблема в том, что я действительно должен включать MyClassA.h внутри b.so. Это значительно увеличивает размер библиотеки. Я думал, что компоновщик (компилятор) будет смотреть на файл заголовка при создании, но мне не нужно фактически добавлять MyClassA.h в b.so. Когда я это сделаю, я получаю ссылки на ошибки. – goocreations

+0

Действительно, вам не нужно включать MyClassA.h внутри b.so. Показать нас , как MyclassA.h и MyClassB.h, так и команды компиляции и компоновки. –

+0

Я не включаю его, COMPILER делает. Я проверил: если я добавлю некоторые строки в заголовки MyClassA и скомпилирую MyClassB (b.so) , тогда размер b.so увеличивается. Таким образом, компилятор автоматически вытягивает MyClassA.h в b.so. В настоящее время я использую CMake, занятый, создающий простой пример с нормальным g ++ компилятором – goocreations

3

Если вы черпаете ClassB от ClassA, вы должны указать ClassA, при получении не только (ссылка). Вот почему вы должны включить заголовочный файл ClassA.

Но если вы реализовали ClassA функции в cpp файле, а не в заголовке, фактический код из ClassA будет a.so, поэтому, includeing ClassA заголовочный файл на самом деле не является проблемой.

+0

Проблема только в том, что существует много заголовки в a.so, которые я использую в b.so. И когда я добавляю заголовки в b.so, размер b.so резко возрастает (хотя включены только заголовки, а не файлы cpp). Мне было интересно, есть ли способ обойти это, чтобы я мог держать b.so очень маленьким. В конце концов, заголовки уже находятся в a.so – goocreations

+0

Проверьте, содержат ли ваши заголовки _code_, например function _defenitions_ (not _declarations_), или могут быть некоторые шаблоны, вы можете попытаться уменьшить размер публичных заголовков с помощью 'pimpl' или' facade' шаблоны – Lol4t0

+0

У моих заголовков базового класса есть много виртуальных замеров виртуальной функции в них, без реализации. Вот что делает заголовки такими большими. Если у меня есть 50 подбиблиотец, наследующих от классов в a.so, тогда данные заголовка из классов в a.so (скажем, 100kb) дублируются в каждой из 50 подбиблиотек. Thats 50x100kb = почти 5mb дублированных заголовков, которые на самом деле уже находятся в a.so – goocreations

0

Если class B является производным от class A, тогда должен быть включен заголовочный файл class A.

Смежные вопросы