Я много раз слышал, что объявление функций и статических данных нужно размещать в .cpp файле, иначе будет multiple definition, что и происходит. Но, например, Boost целиком состоит только из hpp файлов, в которых, следовательно, содержаться и определения функций. Как так получается, что при подключении в двух файлов одной библиотеки Boost, не возникает multiple definition? И вообще, какие существуют принципы написания библиотек, если не хочется делать объектных файлов для библиотеки --- их создание усложняет использование и не позволяет делать оптимизацию. 

Всякие конструкции вида 



не помогают.

d06osipov, ты просто не понимаешь, что происходит. У буста, кстати, тоже есть библиотеки, которые надо цеплять (например, program_options, thread и др.). Только некоторые вещи реализованы как встраиваемые (inline), а другие - просто шаблонные. В первом случае компилятор каждый раз вместо вызова функции подставляет ее код, во втором случае он может, как вставить код, так и сделать вызов. Но в любом случае код генерится для каждой реализации шаблона.
Так можно определить встраиваемую функцию:Так можно определить шаблон:Оба этих примера можно размещать в заголовочном файле и подключать в любое количество модулей не опасаясь получить ошибки.

boost почти полностью состоит из шаблонов   

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

Главным отличием inline-функций от нешаблонной не-inline в данном случае является то, что определение inline-функции может и должно дублироваться в каждой единице трансляции, где данная функция используется.

Это сообщение отредактировал(а) UnrealMan - 7.9.2007, 22:46

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



Значит, inline функции всё-таки, вопреки принципу, ставить inline только там, где это действительно необходимо, рекомендуется применять при разработке библиотек.

Интересный момент --- если инлайновость и игнорируется семантически, то не игнорируется синтаксически (не создаёт multiple definition). 

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

Всё это описано в стандарте:


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

Очень просто. Каждый *.cpp файл превращается в объектный файл. У этого объектного файла есть таблица экспортируемых символов - нестатических функции и переменных, определенных в этом *.cpp файле. Когда линковщик начинает объединять все объектные файлы он читает эти таблицы всех файлов и, в случае обнаружения двух одинаковых символов, ругается.
Так что дело тут не столько в inline, сколько в static. Не забывай, компилятор совсем не обязан выполнять директиву inline   

Здесь уже писалось, что компилятор может семантически не воспринимать inline, но дублироваться в каждом модуле такая функция обязана. 


Эксперементально проверено на нескольких компиляторах: разрешаются в разных единицах трансляции классы с одинаковыми именами. Это же подтверждается Стандартом. 

Хочешь сказать эти два модуля можно будет скомпоновать ?

А ты возьми и попробуй собрать проект с полной оптимизацией (когда inline скорее всего встраивается) и без оптимизации вообще (когда не встраивается). И ты поймешь, зачем нужен static.

А здесь определена два раза функция с именем C::f, чего нельзя.

А если не определять функциональность класса, то от него не особо много пользы получается...

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

А если с одним именем класса код получается элегантнее и лаконичнее, то безымянное пространство имён - очень удобно.

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

В принципе да. Но когда код разрастается, приходится его как-то делить - с большими файлами работать неудобно. Кстати, одинаковые имена классов приводят к проблемам, даже если они больше нигде (кроме как в родном cpp-файле) не видны. Безымянные пространства имен автоматически делают имена уникальными. Но, скажем, MFC с его как-бы-рантайм классами и макросами пространства имен до лампочки.
Короче, в больших проектах нельзя имена пускать на самотек: кто как хочет. Нужно определить какую-то политику и всем ее придерживаться. Тогда дублирования имен проще избежать. И код чужой читать будет легче, кстати.

Ну есть у меня некая helper ф-ция, нужная ф-циям f1, f2 и f3. Если она нужно только этим ф-циям и эти ф-ции логически должны быть в одном модуле, то anonymous namespace. Если эта helper ф-ция нужна ф-циям из нескольких модулей, к примеру, какая-нибудь доработаная версия станадртного алгоритма или просто ф-ция "общего назначения"(хоть и использующаяся всего 3-4 ф-циями), то не грех её в своё пространство имён запихать(и в отдельный модуль).

Сейчас archimed7592 посоветует выбросить MFC.   

Недождёшься .
Я MFC не знаю(в частности не знаю о каких макросах тут идёт речь), не использую(и не собираюсь), а людей, умеющих грамотно использовать MFC считаю богами программирования и проектной мысли(это ж надо такое <censored> умудриться грамотно использовать ), так что советовать ничего не буду .

Объясняю зачем. Я пишу библиотеку. Из примера Boost я знаю, что оптимизация лучше работает, если библиотека не содержит объектных файлов, а подаётся целиком в исходниках. Вот и всё. А все имена у меня и есть в namespace, причём не безымянном.