один .cpp один .h VS все в .h

Потому что в с/с++ нет нормальной модульности.
/thread

RTFM

Почему плохо скажем все в .cpp или в .h писать

Чего это плохо? Вон, почти все в boost/stl написано в одних hpp/h, и все это в каждый подключающий эти headers translation unit попадает.

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

Выше правильно RTFM о компиляции шаблонов, библиотеках (а так же о том, как компилятор называет функции и что делает extern «C»).

а ты попробуй.

Объявления можно включать куда угодно, а если включить сам код, то при сложной структуре (исходник включает библиотеку и другой исходник, в котором включена та же самая библиотека) будет ерор.

Предлагаю забанить ОПа. Ради его же пользы, может хоть гуглить научится.

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

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

Ну и соответственно, при сборке, если в Makefile верно указаны зависимости, изменение пары-тройки исходников из большого проекта сэкономит чуток времени

ТС либо лентяй, либо толсто троллит. Мог бы и попробовать.

Сам иногда люблю какую-нибудь ерунду написать на си и смотреть в отладчике.

Это единственный (известный мне) способ иметь раздельную компиляцию каждого .cpp программы.

Встречал я конечно людей, делающих #include «filename.c», но это были аппаратчики-электронщики, им простительно. А из-за того, что их программы как правило простые и небольшие, такие финты ушами проходят на ура. Но при хоть сколько-нибудь росте сложности (а следовательно и модульности) у тебя все развалится. Как верно было сказано выше, в C и C++ отсутствует понятие модуля. Все эти заголовочные файлы лишь исторически сложившееся недоразумение, с выработанным набором костылей (например include guard) и правил на тему их использования. Но приходится все это использовать именно таким отработанным способом, иначе просто будет каша.

Разделение есть очень хорошо визуально. Мне нравится.
Всегда видишь функционал посмотрев только хедер, не продираясь через реализацию.
Все остальное от лукавого.

Гм, а я тоже самое вижу в IDEA для Java классов, только мне для этого не нужны там заголовочные файлы, а только поддержка IDE :)

Java, IDE... нельзя так грешить, Тут все таки кресты. :)

Я это к тому, что воспринимать хедер, как удобную конструкцию аннотации кода - неправильно, т.к. это костыль возникший из-за дизайна C и перекочевавший в C++. А Java были приведена для того, чтобы показать, что в других ЯП и их инфраструктурах хедеры могут быть просто не нужны в принципе.

воспринимать хедер, как удобную конструкцию аннотации кода - неправильно

То есть воспринимать и мучиться от неправильности этого? :)
Ну не, если есть, то надо радоваться...

В хедеры можно писать только то, что представляет собой контракт, но не прямое обьявление переменных, тела, функций и методов, вообщем нельзя ничего что генерирует символ. Если нарушить это правило и включить хедер в разные файлы С++, то один и тот же символ и произойдет конфликт при linking

В силу «особенностей» С++, шаблоны не генерирует символы сами по себе, только при использовании, и использование не вызывает конфликтов. Библиотеки шаблонов написаны полностью в хедерах, потому что только там их можно написать.

Всегда видишь функционал посмотрев только хедер, не продираясь через реализацию.

Только в случае с C++ хедеры засорены деталями реализации (protected и private), встроенными функциями или вообще шаблонами. Как ни отделяй интерфейс от реализации, а все равно винегрет.

Пиши всё всегда только в хидер. А пока оно компеляется, играй в кваку.

Я тебе так отвечу: программирование - набор компромиссов. Можно сделать маленькую программу неюзабельной разбив на кучу лишних модулей, а можно сделать жуткий монолит. Тебе надо найти золотую середину.

Неправда. Интерфейсы бывают лишними только тогда, когда в них упирается производительность. Во всех остальных случаях они улучшают читаемость кода на порядок.

Я написал про модульность вообще. Из этого нетрудно сделать выводя для своего случая.

да, согласен. если про модульность то ты прав.

Разделение на исходник и заголовок сделано не для красоты или удобства (никакого удобства, как видишь и нет). Условно говоря, Си++, как и Си, при компиляции теряет информацию об объектах в объектном файле. Например, если ты написал функцию int myfunc(double, const char *), то в объектном файле она будет видна как просто «myfunc» — без намека на типы аргументов или возвращаемого значения. Разумеется, очень хороший программист всегда держит все типы в голове, но что если ты не очень хорош? На помощь приходит заголовочный файл, в котором в виде forward-declaration описано то, что ты потерял при компиляции. Теперь компилятор может проверять соответствие типов между модулями, если каждый из них включит forward-declarations другого. Это можно сделать через #include.

Тем не менее, содержимое заголовочного файла может не соответствовать версии объектного файла или библиотеки оных (они никак не связаны), и компилятор не в состоянии тебя об этом предупредить. Отсюда всякий dll-hell. Теоретически, эту «проблему» можно победить созданием нового, более прогрессивного формата объектных файлов, которые даже в скомпилированном виде будут хранить всю метаинформацию, которая когда-то была в оригинальном исходнике.

Так и сделали, но не для Сей, а для Жав, Шарпов, Делфей и прочих новомодных типизированных языков. Си++ компиляторы до сих пор часами пережевывают свои многомегабайтные заголовки.