Войти
ПрограммированиеФорумОбщее

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

Страницы: 14 5 6 726 Следующая »
#60
15:03, 12 мар. 2012

DevilDevil
> Исходя из опыта, язык С++ откладывает сильный отпечаток (причём на мой взгляд
> негативный) на среднестатистического разработчика.

Как в одной известной песне "Губит людей не пиво, губит людей вода", следствие выдаётся за причину. Файлы заголовков нужны затем, чтобы описание было отдельно от определения. Некоторые ситуации без forward декларации не разруливаются в принципе. А людей губит не язык, а лень, нежелание развития, излишнее стремление получать деньги вкупе с абсолютно наплевательским отношением к качеству созданного продукта.

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

Практически любая возможность в языке возникла из реальной потребности. И лишь программист решает будет ли он и как использовать эти возможности. Многие вещи в принципе программисты никогда не используют за время разработки, и вполне себе создают отличные решения.


#61
15:07, 12 мар. 2012

Truthfinder

раз уж мне сегодня повезло и я общаюсь с адекватами, спрошу

> Файлы заголовков нужны затем, чтобы описание было отдельно от определения.
> Некоторые ситуации без forward декларации не разруливаются в принципе.

приведи пожалуйста пример ситуации, когда 2 файлова система выигрышнее однофайловой с описанием и реализацией

#62
15:13, 12 мар. 2012

DevilDevil
> приведи пожалуйста пример ситуации, когда 2 файлова система выигрышнее
> однофайловой с описанием и реализацией

Мне это зачем? Я для себя выбрал методу написания кода так, как мне нравится. Пиши хоть одним файлом и одной функцией main. Есть и такие "таланты". Это полностью твой выбор как ты будешь разрабатывать. Я например купил себе мазду. А ты тойоту. И теперь, вместо того чтобы ездить, ты предлагаешь мне заниматься сравнением автомобилей вплоть до царапины. И я вижу на форуме ты занимешься этим давно очень. Только это занятие, в отличие от тебя, далеко не всем интересно. Теперь ещё и SCU технологию выдумали для быстрой сборки. Там вообще несколько иначе организация структуры идёт.

#63
15:17, 12 мар. 2012

Truthfinder
у тебя ник очень похож на моё отношение к жизни
поэтому спрашиваю твоего мнения как у умного человека, может знаешь

#64
15:26, 12 мар. 2012

DevilDevil
> может знаешь

Не знаю. Наверное просто уже не обращаю внимания. У явы как раз однофайловая модель. Что на плюсах, что на яве уже давно не испытываю дискомфорта с этим. Привык к такому положению вещей. Я всего лишь думаю как в установленных рамках сделать так, чтобы было удобно максимально мне или группе разработчиков, с которыми работаю в одной команде. У меня приоритеты скорее в сторону SDK, чтобы было удобнее использовать, например на andoid платформах с java всё удобно и просто, с плюсами и отладкой под них ужасно. Такие вещи мне критичнее. Они существенно замедляют разработку.

#65
15:27, 12 мар. 2012

Truthfinder
ok

#66
15:34, 12 мар. 2012

DevilDevil
> 2 файлова система
1) декларация в .h файле, а тело в .lib файле - тоже двухфайловая система, тот, кто инклюдит заголовок не знает где конкретно линкер найдет ему тела функций
2) один .hpp файл на несколько .cpp файлов - и в нормальном проекте встречается, например, когда есть центральный класс-диспетчер, объявляющий методы-коллбеки, вызываемые из всех концов приложения по разным причинам - удобнее обработку одной группы причин собирать в своем .cpp файле, чем городить .cpp файл на 10к строк
3) несколько .hpp файлов на один .cpp файл - встречается реже, причины различны, иногда оптимизация процесса сборки

#67
15:55, 12 мар. 2012

Вообще надо убрать файлы, и хранить весь код в одном архиве, а в IDE разделять на модули.

#68
16:07, 12 мар. 2012

Жора Монтировка
> Вообще надо убрать файлы, и хранить весь код в одном архиве, а в IDE разделять
> на модули.

Есть такая "прекрасная" IDE для забавного языка RealBasic. Она хранит файлы в плохочитаемом нередактируемом виде. Оченно доставляло в своё время. В NetBeans 6.0 он был читаемым и редактиремым, но нарушалось форматирование. Спросите в чём минус? Минус в контроле версий. Ни тебе CVS, ни тебе SVN. Страшно сейчас вспомнить.

#69
16:18, 12 мар. 2012

любителям писать все в одном файле рекомендую посмотреть на
http://www.sqlite.org/src/artifact?ci=trunk&filename=tool/lemon.c

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

#70
16:20, 12 мар. 2012

DevilDevil
> приведи пожалуйста пример ситуации, когда 2 файлова система выигрышнее однофайловой с описанием и реализацией
+:
1)В .h файле только интерфейс, а реализация скрыта .cpp и не мешается при изучении интерфейса системы классов (удобно).
2)Реализация под несколько платформ в нескольких различных *.cpp, а описание интерфейса класса в одном .h (более легкая портабильность без лишней копипасты).

-:
1)Кому то не удобно читать реализацию с кучей TClass:: и прочими декорациями в .cpp на каждый метод. Ощущение оторванности от контекста, ибо объявления членов класса не видишь.
2)Также реализацию TClass1 от TClass2 можно отделить только форматированием типа закоментированной полоски //========= или выделением каждого класса в отдельный файл. Это кстати одна из причин выделения крестушками каждого класса в отдельную пару файлов (h+cpp).
3)Пункты (1) и (2) из (+) в реальности все равно до конца не работают, ибо часть реализации все равно видна в хедере, а именно приватные члены класса.
4)IDE уже достаточно развиты, чтобы сворачивать реализацию класса для легкости изучения интерфейса при использовании "однофайловой системы".
5)Порочная система включения хедерорв, замедляющая компиляцию в каждый отдельный .cpp (чем больше .cpp в проекте, тем больше повторных перекомпиляций хедеров) (отдельная компиляция хедера под каждый .cpp)
6)На замену (1) из (+) уже есть более удобные interface объявления (до С++ ещё не дошла, хотя эмулируется).

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

#71
16:56, 12 мар. 2012

DevilDevil
> Объясните, чем это обусловлено?
глянь эту тему

#72
17:00, 12 мар. 2012

AndryBlack
кстати речь о твоём проекте )

#73
17:13, 12 мар. 2012

Подход зависит от проекта. В sourceforge встречаются разные реализации, и с разделением заголовков и файлов класса, и с раздельными классами, и с миксами всё-в-одном.

Если проект небольшой, классов на 50-100, визуально более удобно разнести их на отдельные файлы. Сгруппировать в пространства имен по действиям, что-то относится к GUI, что-то к инструментарию, что-то к core service и т.п.
Если проект большой, более резонна схема, когда классы совмещаются в один файл, делясь опять же, по логическим группам. Например, класс item содержит всё, что требуется для реализации и обработки предметов.

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

Разделение может расти из UML, т.к. в диаграммах классы ставятся отдельными блоками.

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

#74
18:23, 12 мар. 2012

DevilDevil
> кстати речь о твоём проекте )
Я понял)

Страницы: 14 5 6 726 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.