Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, Kernan, Вы писали:

K>>Здравствуйте, _hum_, Вы писали:

__>>>Разработчики языка вообще в эту сторону смотрят?
K>>Просто дроби на либы и компилируй по частям.

__>так в том-т и дело, что логически не разбивается. вот есть у меня модель данных, и есть GUI с главным окном, в котором куча закладок, каждая из которых отображает какую-то сторону модели и позволяет ее редактировать. и получается эдакая "звезда", которую непонятно, как можно разбить на отдельные модули.

1. А что отвечает за работу закладки?
2. Сущность, которая реализует редактирование конкретной view модели, она в каждый момент Икс одна? Или их несколько? Т.е. если закладку сменили, то сущность отвечающая за редактирование предыдущей "закладки" она остается или нет?

Если сущность одна, то нужно копать куда-нить в сторону стратегий, и общего чисто виртуального базового класса, который отвечает за редактирование модели.

Тогда это как-то эдак будет.
1. Есть указатель на IModelerEditor — это абстрактный класс, который отвечает за редактирование какой-то стороны модели. И живет этот указатель на IModelerEditor где-то в районе GUI-логики, через которую гуй с редакторами и общается.

2. При выборе закладки создаем новый класс, наследник от абстрактного IModelerEditor, который уже отвечает за редактирование конкретной "стороны" модели именно под выбранной закладкой.

3. Старый указатель IModelerEditor удаляем, на его место кладем новый из пункта 2.

Тогда все сведется к некоторой фабрике, которая конструирует конкретный наследников от IModelerEditor в зависимости от выбранной закладки, и возвращает указатель. Который уже и юзает GUI.

И только методу-фабрике будут нужны все H-файлы для всех редакторов модели. Если этот метод-фабрику вынести в отдельный модуль, то и вовсе h-файлы всех редакторов в GUI не понадобятся. Т.к. GUI и конкретный класс-редактор модели будут общаться через указатель на базовый абстрактный файл IModelerEditor.

Как-то так. Нечто подобное делал, но обошелся без отдельного модуля для "фабрики", т.к. у меня подобных "конкретных редакторов конкретной стороны модели" всего было штуки 4-5.

Здравствуйте, _hum_, Вы писали:

T>>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.

__>а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.

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

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

Здравствуйте, _hum_, Вы писали:

__>если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

Есть, например, паттерн Dependency injection. Он, помимо всяких плюсов вроде облегчения unit-тестирования, вполне способен порезать и «логически связанные» части программы. Конечно, в include останется какая-то часть, отвечающая за общий интерфейс. Но в контексте этой темы это не так важно: объявление абстрактного базового класса не сильно замедляет компиляцию. Но зато реализация может уже собираться независимо от вызывающего кода. И перекомпилироваться будут всегда лишь какие-то малые части библиотек. Разумеется пока интерфейс не поменяется — но он как бы и не должен часто меняться.

Здравствуйте, _hum_, Вы писали:

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

Гы. Я застал времена, когда программа выдавалась оператору ЭВМ на бумаге, там набивалась на перфокарты (нередко с ошибками), прогонялась через ЭВМ в порядке общей очереди, а результат можно было получить в виде распечатки на следующий день.

Большое время прогонов заставляет нас больше думать, и меньше тыкать кнопки.

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, _hum_, Вы писали:

T>>>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.

__>>а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.

L>За использование отладчика в процессе разработки нужно сразу разжаловать в младшие черпальщики ассенизаторных обозов.

ничего не понял. дебаггинг уже устарел?

L>В процессе разработки должны писаться тесты, которые должны автоматически выполняться при сборке проекта.

а тесты пишутся без ошибок?

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

слова правильные, только как это реально следать

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, _hum_, Вы писали:

__>>Здравствуйте, Kernan, Вы писали:

K>>>Здравствуйте, _hum_, Вы писали:

__>>>>Разработчики языка вообще в эту сторону смотрят?
K>>>Просто дроби на либы и компилируй по частям.

__>>так в том-т и дело, что логически не разбивается. вот есть у меня модель данных, и есть GUI с главным окном, в котором куча закладок, каждая из которых отображает какую-то сторону модели и позволяет ее редактировать. и получается эдакая "звезда", которую непонятно, как можно разбить на отдельные модули.

C>1. А что отвечает за работу закладки?
C>2. Сущность, которая реализует редактирование конкретной view модели, она в каждый момент Икс одна? Или их несколько? Т.е. если закладку сменили, то сущность отвечающая за редактирование предыдущей "закладки" она остается или нет?

C>Если сущность одна, то нужно копать куда-нить в сторону стратегий, и общего чисто виртуального базового класса, который отвечает за редактирование модели.

ну, то есть, менять архитектуру. понятно.

Здравствуйте, Temnikov, Вы писали:

T>Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причине держит.

+ SSD ещё очень хорошо ускоряет процесс.

Здравствуйте, Temnikov, Вы писали:

T>Еще, с чего бы стоило начать, посмотреть на что время тратиться при сборке.

а есть какие-нибудь бесплатные анализаторы? а то у меня в vs2013 не показывает, на что время тратится — просто comiling xxxxx.cpp и три минуты, потом следующий, а по каким она там модулям лазит и на чем стопорится — непонятно.

а еще , может, есть какие анализаторы, которые позволяют просмотреть существующие зависимости, и выделить из них нужные (просто самому лазить по куче фалов и выполнять этот анализ довольно утомительно)?

Здравствуйте, _hum_, Вы писали:

L>>За использование отладчика в процессе разработки нужно сразу разжаловать в младшие черпальщики ассенизаторных обозов.
__>ничего не понял. дебаггинг уже устарел?

При разработке? Уже лет 20 как как устарел. Если не больше.

L>>В процессе разработки должны писаться тесты, которые должны автоматически выполняться при сборке проекта.
__>а тесты пишутся без ошибок?

Тесты обычно тривиальны, а ошибки в тестах обычно ортогональны ошибкам в тестируемом коде, и их влияние легко нивелировать написанием обратных тестов.

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

Ээээ, начать с малого. Потом станет понятнее, что именно и как лучше всего сделать в вашем конкретном случае.

Очень часто именно практика написания тестов спасает от многих эпизодов боли пониже спины. То, что тесты помогают писать наименее связанный код, к делу пока не относится, но их наличие заставляет натурально организовывать проект в отдельные минимально связанные единицы.
Ну а потом можно применять тяжелую артиллерию — precompiled headers, системы распеределнной компиляции и прочее шаманство.

Здравствуйте, Temnikov, Вы писали:


T>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?

2Mb чистого текста в rar-формате
библиотеки — boost::signal2
qt — обычный гуи
cereal (вот после начала его использования, субъективно, все и начало тормозиться)

Здравствуйте, watchmaker, Вы писали:

W>Здравствуйте, _hum_, Вы писали:

__>>если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

W>Есть, например, паттерн Dependency injection. Он, помимо всяких плюсов вроде облегчения unit-тестирования, вполне способен порезать и «логически связанные» части программы.

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

Здравствуйте, Dair, Вы писали:

D>Здравствуйте, Temnikov, Вы писали:

T>>Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причине держит.

D>+ SSD ещё очень хорошо ускоряет процесс.

охотно верю. но это временное решение. надо с этой проблемой что-то системно делать (на c#, говорят, вообще не знают, что такое время компиляции)

Здравствуйте, Dair, Вы писали:

D>+ SSD ещё очень хорошо ускоряет процесс.

Кстати, а зачем SSD если 32 гига оперативы?
Сам комп не выключать а засыпать, и я не видел загрузку винта более 1% уже после 30-40 минут после загрузки. Все летает. Особенно после того как поставил самую быструю память.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, _hum_, Вы писали:

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.

Pzz>Гы. Я застал времена, когда программа выдавалась оператору ЭВМ на бумаге, там набивалась на перфокарты (нередко с ошибками), прогонялась через ЭВМ в порядке общей очереди, а результат можно было получить в виде распечатки на следующий день.

Pzz>Большое время прогонов заставляет нас больше думать, и меньше тыкать кнопки.

ой, если б так было. на само деле наукоемкого кода — процентов 10%, остальное — GUI, коды сериализации и прочая мудатень, которая жрет столько времени на разработку, а на деле — просто интерфейс доступа к основному коду

Здравствуйте, Andrew.W Worobow, Вы писали:

D>>+ SSD ещё очень хорошо ускоряет процесс.

AWW>Кстати, а зачем SSD если 32 гига оперативы?
32 прикольно. У меня 16, до конца не загружаются, вроде хватает.

AWW>Сам комп не выключать а засыпать, и я не видел загрузку винта более 1% уже после 30-40 минут после загрузки. Все летает. Особенно после того как поставил самую быструю память.

У меня сейчас порядка 2000 исходных файлов и чуть больше заголовочных файлов.
На каждый — прочитать, пропроцесс/компиляция, результат записать на диск бинарники.
Потом читать с диска бинарники, записать на диск исполняемый файл / библиотеку.


А, я вот подумал, если делать ramdrive, туда скидывать проект и оттуда компилировать, тогда будет ещё быстрее, да.

Здравствуйте, _hum_, Вы писали:

T>>Еще, с чего бы стоило начать, посмотреть на что время тратиться при сборке.
__>а есть какие-нибудь бесплатные анализаторы? а то у меня в vs2013 не показывает, на что время тратится — просто comiling xxxxx.cpp и три минуты, потом следующий, а по каким она там модулям лазит и на чем стопорится — непонятно.
Tools\Options\Projects and Solutions\Buld and Run\MSBuild project build * verbocity выстави в нужное положение и анализируй.

Ну и плюс время компиляции хорошо снижается через precompiled headers(для Release можно отключить чтобы все по честному было), и Multi-processor compilation(включается в настройках проекта).

А, ну еще как вариант перейти на 2015 студию
https://blogs.msdn.microsoft.com/vcblog/2015/11/11/new-improved-and-faster-database-engine/
https://blogs.msdn.microsoft.com/vcblog/2015/10/16/debugfastlink-for-vs2015-update-1/
https://blogs.msdn.microsoft.com/visualstudio/2015/11/30/improving-your-build-times-with-incredibuild-and-visual-studio-2015/

Здравствуйте, _hum_, Вы писали:

__>Здравствуйте, Kernan, Вы писали:

K>>Здравствуйте, _hum_, Вы писали:

__>>>Разработчики языка вообще в эту сторону смотрят?
K>>Просто дроби на либы и компилируй по частям.

__>так в том-т и дело, что логически не разбивается. вот есть у меня модель данных, и есть GUI с главным окном, в котором куча закладок, каждая из которых отображает какую-то сторону модели и позволяет ее редактировать. и получается эдакая "звезда", которую непонятно, как можно разбить на отдельные модули.
Как минимум у тебя есть GUI, модель и рутины обработки данных. Это уже 3 библиотеки.

Здравствуйте, _hum_, Вы писали:

sciter-32/64 dll.

Размер src архива (zip) — 6.3 Mb.

Полная сборка win32/Release — 3 минуты. win32/Debug — 2 минуты.
MS VC 2010

Проект разбит на модули — static libs. Используются активно precompiled headers.

Полная сборка делается редко. В основном local change — build — run — test.
Редко когда эта последовательность занимет больше чем 30 секунд.

Рабочая машина — обычная, c SSD вместо HD.

Здравствуйте, Dair, Вы писали:

D>А, я вот подумал, если делать ramdrive, туда скидывать проект и оттуда компилировать, тогда будет ещё быстрее, да.

Пробовал. Особого ускорения не отметил почему-то

Здравствуйте, _hum_, Вы писали:

__>так в том-т и дело, что логически не разбивается. вот есть у меня модель данных, и есть GUI с главным окном, в котором куча закладок, каждая из которых отображает какую-то сторону модели и позволяет ее редактировать. и получается эдакая "звезда", которую непонятно, как можно разбить на отдельные модули.

Уменьшай связность по хедерам.
Пимплы, предобъявления классов, фабрики.

// main.h

#include "some_view.h" // плохо!
class SomeView; // хорошо!

class MainWindow {
  SomeView* child_;
  ...
};

///////////////////

// main.cpp

#include "main.h"
#include "some_view.h"

MainWindow::Create() {
  child_ = new SomeView(); // неплохо
  child_ = NewSomeView(); // лучше, потому что можно спрятать толстую реализацию за интерфейс и тонкую фабрику
};