Надеюсь, что ни у кого не возникает вопроса, нужно ли выносить законченный по логике код в отдельный модуль.
Вопрос в следующем - как оформлять этот модуль - в виде *.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...

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