Как я могу частично выставить содержимое объекта в библиотеке объектов?

Question

Я собираю некоторый код C ++ в библиотеку. Предположим, мои исходные файлы mylib.cpp и util.cpp. Код в util.cpp используется в реализации библиотеки, но не является частью библиотеки в том смысле, что код, использующий библиотеку, не может вызвать его (он не находится в заголовках publi c) и не должен знать о его существовании ; но my_lib.cpp включает util.hpp и полагается на скомпилированный объектный код util.cpp.

Теперь, если я скомпилирую mylib.o и util.o, выполните:

ar qc libmylib.a mylib.o util.o

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

Как я могу гарантировать, что только объектный код в mylib.o (и в util.o) "видит" символы из util.o, в то время как внешний код не имеет?

Примечание: я полагаю, что этот вопрос относится также к C и, возможно, к другим скомпилированным языкам.

Answer 1

^{Передача комментариев в ответ.}

Если ваша библиотека C ++ имеет собственное пространство имен, то использование этого или подпространства имен является номинально правильным способом контролировать доступ к внутренним утилитам. Звучит так, как будто ваш код не предоставляет шаблонные классы - ограничения для них должны быть продуманы отдельно.

Если конфиденциальность является серьезной проблемой, я, вероятно, рассмотрю возможность включения util.cpp (а также util.hpp) в исходный код для mylib.cpp (имеется в виду #include "util.cpp") с соответствующими элементами управления пространством имен, чтобы код из util.cpp был доступен внутри mylib.cpp, но не снаружи (с использованием анонимного пространства имен, или namespace mylib::Private, или некоторых других схема). Это не очень удобно, но, вероятно, эффективно (после того, как вы отработали необходимые настройки). Скорее всего, комбинация TU (единица перевода) не настолько велика, чтобы вызвать серьезные проблемы у вашего компилятора. Это не зависит от расширений компилятора.

Answer 2

Вот мое запасное «решение», которое на самом деле является обходным путем:

Я поддерживаю видимость publi c, но я обременяю весь код в util.cpp некоторым элементом именования, который будет сделать его по-настоящему уникальным. Например, я могу заключить эти функции в namespace mylib. Не все (расколотые) символы mylib::foo() (или mylib::util::foo()). Их будут искать, но разумно предположить, что они не будут совпадать с чем-либо, кроме кода mylib.

В дополнение к хлопотам, это по-прежнему позволяет разрешить внешнему коду зависеть от этого внутреннего служебного кода - если он делает это намеренно.