LINUX.ORG.RU

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

madcore ★★★★★
()

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

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

kamre ★★★
()
Ответ на: комментарий от kamre

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

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

Norgat ★★★★★
()

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

Stil ★★★★★
()

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

prischeyadro ★★★☆☆
()

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

dmfd
()

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

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

schizoid ★★★
()
Ответ на: комментарий от schizoid

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

minakov ★★★★★
()

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

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

cryptohedge
()

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

jeuta ★★★★
()

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

m0rph ★★★★★
()

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

zJes ★★
()
Ответ на: комментарий от zJes

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

Norgat ★★★★★
()
Ответ на: комментарий от zJes

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

Norgat ★★★★★
()
Ответ на: комментарий от Norgat

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

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

zJes ★★
()

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

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

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от zJes

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

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

m0rph ★★★★★
()

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

nanoolinux ★★★★
()

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

flareguner
()
Ответ на: комментарий от flareguner

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

nanoolinux ★★★★
()

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.