C++: каждый класс в своём модуле. В чём прикол? (6 стр)

одна роль
одна сущность
один класс
один файл (с поправкой на с++ иногда два, тут уж так исторически сложилось)

Оба способа нормальные, и так и так удобно (за счет современных ИДЕ) - просто в одном случае не надо тратить клик на переход в другой файл, зато в другом маленькие отдельные файлы приятно читать.
Если какой-то из способов вызывает технические проблемы типа медленной компиляции или зависания visual assist, это уже личные крестопроблемы пользователей этих ИДЕ.

Для статистики: я за разделение классов по файлам. И да, в с++ нет модулей.

Dimich
> И да, в с++ нет модулей.
а что есть ?

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

Pushkoff
> любителям писать все в одном файле рекомендую посмотреть на
> http://www.sqlite.org/src/artifact?ci=trunk&filename=tool/lemon.c
Надо сказать sqlite - одна из немногих, на мой взгляд, Ъ-библиотек с точки зрения именно использования, как библиотеки. Версия, где всё слито в один файл - отличная штука. Тыц-тыц, добавил файл в проект, всё билдится и работает. А что до того, что оно внутри "трудноредактируемо" - у меня библиотеки в проект добавляются для того, чтобы они работали, а не для того, чтоб их редактировать.

Библиотека на россыпь мелких файлов - показатель низкой культуры библиотечной разработки. А если она ещё и обвешана билд-конфигураторными скриптами и костылями - это откровенная недоделка.

Pushkoff
> любителям писать все в одном файле рекомендую посмотреть на

не во всём соглашусь с предыдущим оратором...
но всё же

если я правильно понял - все классы и функции там имеют "общее направление"
соответственно логически друг с другом связаны
что мешает их редактировать в одном файле ?
возможности IDE ?

DevilDevil
> что мешает их редактировать в одном файле ?

Это в том же посте, который ты процитировал:

> те кто пользуются системами контроля версий понимают зачем нужна куча файлов,
> ибо чем меньше затрагивается файлов при правке тем меньше геморроя при слиянии

Sbtrn. Devil
DevilDevil
попробуйте хоть разобраться как оно работает
это к стати генератор LALR(1) парсеров, говорят быстрейший из существующих
документации по нему мало, хотелось бы немного доработать чтоб он был больше совместим с C++, типа enum вместо дефайнов, классы и неймспейсы и тп.

Sbtrn. Devil
> Тыц-тыц, добавил файл в проект, всё билдится и работает
это преимущество, хотя никто не мешает затулить в один lib и это даже билдить не надо, только прилинковывать.

тред не читай@сразу отвечай

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

К вопросу о времени компиляции из соседней темы, которую подобный подход, вроде бы, ухудшает. Если каждая папочка будет торчать наружу несколькими заголовочными файлами (один высокоуровневая обертка над содержимым папки, прячущая реализацию за pimpl и сколько понадобится интерфейсов для DI), то время компиляции значительно уменьшится по причине уменьшения связности, что само по себе плюс.

// Geometry.h

#include "vector2.h"
#include "vector3.h"
#include "vector4.h"
#include "matrix.h"

И потом

#include <Geometry.h>

В чем проблема-то?

Sergio
> #include <Geometry.h>
>
> В чем проблема-то?

Нет никакой проблемы, - в Qt 4.x именно так и сделано, - допустим мы пишем

#include <QtGui>

а в нём, в свою очередь

...
#include "qwidget.h"
#include "qwidgetaction.h"
#include "qwindowdefs.h"
#include "qgenericmatrix.h"
#include "qmatrix4x4.h"
#include "qquaternion.h"
#include "qvector2d.h"
#include "qvector3d.h"
#include "qvector4d.h"
#include "qbrush.h"
#include "qcolor.h"
#include "qcolormap.h"
#include "qdrawutil.h"
#include "qmatrix.h"
#include "qpaintdevice.h"
#include "qpaintengine.h"
#include "qpainter.h"
#include "qpainterpath.h"
...

Pushkoff
> попробуйте хоть разобраться как оно работает
С конкретно этим я тоже разбирался. Неглубоко, правда, ибо Ц и чем-то не устроили возможности. Но по документации мне сильно понравилось, что там подфрагменты не нумеруются порядковыми цифрами (норовящими поплыть при модификации грамматики), как в 99% поделок соответствующего назначения (включая пцре и стадо якобизонов), а по-человечески именуются человекозадаваемыми идентификаторами.
И это было ещё одно свидетельство как высокой культуры библиотекоразработки sqliteчиков, так и прискорбной редкости оной высокой культуры в мире программирования.

Sbtrn. Devil
> С конкретно этим я тоже разбирался. Неглубоко, правда, ибо Ц и чем-то не
> устроили возможности.
я переименовываю файл из c в срр и пользуюсь

Каждый класс в отдельном файле, при условии, что в названии заголовка .h и реализации .cpp фигурирует название класса является правилом хорошего тона программирования.
DevilDevil
В большинстве книг по совершенствованию навыков программирования (я имею ввиду книги типа "Совершенный код", "Архитектура ПО", "97 советов для архитектора ПО") описываются суть, плюсы и минусы данного стиля. Хотя это и элементарно.