Надеюсь, что ни у кого не возникает вопроса, нужно ли выносить законченный по логике код в отдельный модуль.
Вопрос в следующем - как оформлять этот модуль - в виде *.h + *.cpp или *.h + некий бинарник.
У "исходников" есть плюс - при изменении интерфейса компилятор заботится о соответствии версий.
Минус - необходимость перекомпилировать (при чём обязательная) всего проекта.
Плюс у "dll-ек" - легко подменять  реализацию без "уведомления" основной программы.
Минус - при изменении интерфейса бинарника может случиться ситуация - несоответствия h-ников dll-кам...
В общем, надеюсь, вы поняли дилемму...
Вопрос как вы решаете эту дилемму 

По мне так динамическая загрузка dll довольно удобная штука.

Мысль едва уловима. Или логика. А может, обе...

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

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

Проголосовала за src, потому что это единственный вменяемый вариант из предложенных.

Гм. Непонятно, почему "всего проекта". Если в коде что-то изменилось, чего хватает на изменение одной dll, то и перекомпилироваться будет область исходников, как бы соответствующая этой dll...
Кроме того, писать целый проект так, как будто его подчасти можно выделить в отдельные dll - хороший стиль программирования ;)

feodorv, я думаю 
borisbn, имел ввиду что при изменении участка кода , нужно будет перекомпилировать весь код, который от него зависит. (фактически весь проект)
При изменении длл, ничего перекомпилировать (кроме самой этой длл) не нужно. (при условии конечно, что ничего не поменялось в интерфейсе)

borisbn, для полноты картины, нужно бы еще добавить было статические библотеки.
Для себя, исходники, и статические либы. 
DLL практически для себя не использую. толко если одавать кому-то. (это не плод каких-то умных расчетов, просто так получается, не знаю почему   )
Проголосовал за исходники

это и имелось ввиду  

Добавлено через 1 минуту и 54 секунды


чем не вариант

Гм. Если проект небольшой, то разбивать на dll его смысла нет. Если большой, то то всё равно разработчик разобьёт его на логические части, в противном случае его сопровождать и поддерживать будет трудной задачей. Изменение в одной логической части не затронет другие (интерфейс по условию не меняется), соответственно, перекомпилироваться должна бы именно эта логическая часть, а не весь проект. Мне так кажется...

feodorv, пересобрать (скажем так), нужно будет весь проект, даже если поменялась одна запятая, во второстепенной строке, самого второстепенного файла.
при изменении Dll ничего пересобирать не нужно, кроме одной этой DLL.

это все равно что сравнивать жопу с пальцем

Ты не поверишь


ага. именно это и имел в виду.

Поясню более конкретно. Есть проект, который делают 3 человека. Вернее сборкой воедино занимается один, а остальные делают для него модули (модуль сетевого взаимодействия, модуль записи в БД и т.п.). Есть два варианта как передавать "сборщику" свои модули - в виде исходников или в виде бинарников. У обоих вариантов есть и плюсы и минусы. Хотелось бы услышать ваше мнение, как бы вы поступали бы.


Ооооооч. полезное замечание. Как я раньше без Вашего мнения обходился ?

borisbn, при разработке проекта предавать надо исходники.
А чтобы проблем с интерфейсами не было используется PIMPL (см. все нешаблонные классы Qt). В итоге, если ты заменишь интерфейс, но не будешь использовать новые функции, то перекомпиляция dll не потребуется (именно таким образом сохраняется обратная совместимость версий Qt).

Ну, да, пересобирать придётся))))

Всё же ответ не однозначен. При наличии второго (третьего etc) программиста и хорошо определённого, проработанного и оговоренного интерфейса, dll удобнее. Удобнее и в плане разделения ответственности тоже. Я так прикинул, что в моей практике всё, что касалось обмена данных с БД (если это не главная задача программы), выделялось в dll... Иногда соразработчик сам требовал от меня dll. Впрочем, был и случай, когда я сильно пожалел, что разделил программу на модули (хотя по-началу идея казалась здравой)))

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


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


Вот точь-в-точь та же фигня  Что касается других модулей - было по-разному, а вот БД (почему-то) - всегда в dll )))

Добавлено через 2 минуты и 52 секунды

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

Стадия разработки заканчивается, когда ты выпускаешь ПО. Дальше в этой версии ты можешь делать только багфиксы и дополнения. Если тебе нужно кардинально что-то изменить, то изволь подготовить другую версию.
Обычно, все часто обновляемые продукты имеют следующий вид версий (может немного меняться): x.y.z, x - версия (серьезные изменения без обратной совместимости), y - подверсия (изменения с обратной совместимостью), z - номер сборки (без изменений интерфейсов вообще - только исправление ошибок). Так вот, когда ты выпустил 1.0.0 - ты закончил разработку версии 1. Но можешь продолжать разработку 2.0.0...

Это не то. Но уже чуть-чуть теплее.

Dynamic linking

Ну, и чтобы подытожить выскажу своё мнение: я (в последнее время) за исходники. Мне довольно часто приходилось делать не кроссплатформенные, а кросскомпиляторные dll-ки. Вот список проблем, с которыми приходится сталкиваться:

•  Нельзя передавать stl-ные классы из одного компилятора в другой (ни указатели на них, ни ссылки), т.к. реализация данных классов может отличаться. Приходится передавать "сырые" указатели и размер
•  Приходится явно прописывать размер выравнивания для классов и структур (#pragma pack( push, 4 ) / #pragma pack( pop ))? т.к. размер выравнивания, указанный в проекте для dll может отличаться от размера, указанного в проекте для exe
•  Приходится явно прописывать тип вызова для каждой функции (__stdcall или __cdecl) по той же причине
•  В дебилдере и в студии отличаются типы вызовов __fastcall, так что такой тип вообще нельзя указывать
•  В дебилдере и в студии отличаются выравнивание __v_ptr, если указывать выравнивание на 8
•  В дебилдере и в студии отличается порядок функций в виртуальной таблице, если есть перегруженные функции (при наличии в классе 2-х виртуальных ф-ций foo() и foo( int ) студия меняет их местами в виртуальной таблице)
•  Нельзя импортировать/экспортировать шаблонные функции (по понятным причинам)
•  Нельзя выделять память в dll-ке, а освобождать в exe и наоборот, т.к. менеджеры памяти разных компиляторов несовместимы

может и забыл чего-нибудь, но, ИМХО, список и так достаточно большой

ага. забыл.
во всех enum'ах нужно дописывать один элемент, равный 0x7FFFFFFF, потому что в разных проектах по-умолчанию размер enum'ов может быть либо 1 либо 4 байта.
enum Some {
    Some_one,
    Some_two,
    Some_FORCE_DWORD = 0x7FFFFFFF
};