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

V>Исторически набор h-файлов обычно шёл уникальный и минимально-необходимый для конкретного С++ файла.
V>В случае модулей на практике всегда будет максимальный набор символов, а не минимально-необходимый.
Опять-таки, вы всё трактуете задом наперёд. Практика в случае модулей такая не потому, что единственно возможная, а потому, что так удобнее.
Были бы проблемы с расходом памяти — резали бы модули по более мелким границам, 1 .h файл = 1 модуль.
V>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
Всё зависит от того, как именно модули реализовывать.

V>В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.
Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.
V>Разумеется, можно считывать модули и в lazy-режиме, т.е. изначально читать просто список символов, а определения конкретных шаблонов, инлайн-функций и макросов — лишь по мере их задействования в компиляции.
V>Но не об этом ведь шла речь, бо, разумеется, это всё не проблема для современных размеров памяти.
Ну, вот видите. А только что это была неразрешимая проблема.

V>Мол, "в нормальных технологиях так давно".
V>Это значит, что ты никогда не писал достаточно больших проектов на том же Турбо-Паскале, т.е. не в курсе проблематики.
Этой проблематики не существует. Повторюсь: Турбо-Паскаль прекрасно работал на объёмах памяти, в тысячу раз меньше тех, которые вы считаете маленькими.

V>>>В итоге, на этапе бурного кодирования мне приходится разбивать целевой проект на десятки их, потом склеивая обратно, когда нужный функционал более-менее отлажен, т.е. перетекает в стадию использования и поддержки.
S>>Вы просто не умеете пользоваться C#.
V>Эээ, простите, "склеивать"? ))
У вас потеря кратковременной памяти? Это же ваша цитата про "склеивать" — поднимите глазки на две строчки выше.
V>Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
Повторю вопрос: зачем вы это делаете? Вы утверждаете, что вам приходится пилить проект на десятки разных, а потом склеивать.
Я вам говорю, что такой нужды нет.
V>И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
Да можно как угодно — хоть студией, хоть руками. Речь о том, что C# вас ни к чему не принуждает.

V>За одно это утверждение тебя уже можно смело увольнять.
Как хорошо, что такие решения принимаете не вы.

V>Это в таких категориях ПО разрабатываешь?
А то.

S>>А вот это вот напиливание избыточного количества проектов — зачем оно?

V>Почему "избыточного"? ))
Ну, потому что потом вы вынуждены обратно их склеивать.

V>Цель каждого отдельного проекта — быть независимой единицей компиляции.
V>Поэтому, такой проект может и включает обычно одну некую функциональность.
V>Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.

Отлично. В чём тогда ваша проблема?

V>Заодно такой подход развязывает руки в экспериментировании, т.е. не надо создавать ветки в гите — это банально лишее, удобней все варианты/эксперименты держать перед глазами одновременно.
V>В общем, отдельные проекты позволяют такие шалости, не ругая за конфликты имен.

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

V>Я ведь могу сделать проект лишь частично разобранным за нулевую трудоёмкость.

V>Опиши себе один мета-проект, ссылающийся на другие проекты, через один коммент включай-отключай запчасти, комбинируй, пробуй варианты и т.д. и т.п.
V>Для сравнения, "выключить" в исходнике класс — это нужно бегать, выключать все зависимости от него.
V>Разбил по проектам (которые на деле всегда подпроекты) — получил изоляцию и управляемость.
Отлично. Пока что всё, что вы рассказываете, вполне укладывается в нормальную практику. Откуда тогда страдания про то, что C# вас вынуждает делить проект на мелкие части?
V>В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
Ну и отлично. Зачем тогда их потом "склеивать"?

V>>>Уверен, тебе бы и в голову такого не пришло, т.к. тебе не с чем сравнить.
S>>Что с чем вы предлагаете сравнить?

V>Наличие всей описанной возни с её отсутствием, ес-но.
Продолжаю не понимать. Вы только что превозносили эту возню как что-то прекрасное, и обвиняли меня в том, что мне оно недоступно. И тут вдруг опять — надо сравнивать описанную возню с её отсутствием. Так вот эти ваши десятки проектов — это хорошо или плохо?

В общем, вы очень путано объясняете. Ложка огурцы банка майонез 500мб DDD склеивать резать предкомпиляция включение.

V>Это самая низкая производительность программиста из всех возможных.
Производительность измеряется результатами, а не строчками.

V>Когда итерация разработки-проверки колеблется на уровне единиц строк (как во всех твоих "примерах в развитии", что ты давал от своего имени) — это примерно нулевая производительность.

V>Потому что ты не планируешь довести текущую итерацию до конца?
Неверно.
V>Т.е. раздать роли и ответственности сущностям дизайна, прописать и обкатать основные сценарии на каждом слое системы?
V>Даже не любопытно хотя бы просто посмотреть, как это примерно будет выглядеть? ))
Если я хочу прописать и обкатать основные сценарии, то у меня проект собирается, проходит тесты и бенчмарки.
А у вас что?

V>>>На плюсах более устоялся чуть другой подход — сначала достаточно "вольное" описание домена/доменов на текущем слое или куче слоёв (смотря, насколько "вглубину" задача), затем решение задач в терминах домена.
S>>Точно также всё работает в C#. Вот ровно также.

V>Достаточно посмотреть на дизай станартных либ и систему "рекомендаций" от MS (половину из которых уже выкинули нафик к сегодняшнему дню, слава богу).
Недостаточно.
V>Мне мешает то, что это несъедобно.
Что именно "несъедобно"?
V>Ты как раз описываешь одну из причин, почему Джава и C#-программисты позволяют себе злоупотреблять интерфейсами.
Давайте в студию пример злоупотребления интерфейсами.
V>По-сути, в Джава и C# интерфейсы выродились более в инструмент развязки зависимостей, чем в инструмент описания абстрактной модели происходящего.
V>Т.е. я высмеивал то де-факто положение вещей, где задача развязки зависимостей зачастую не диктуется причинами технического плана, но диктуется причинами организационного, сугубо для целей совместной разработки.
По-моему, это у вас какие-то фобии. Если у вас модуль А таки зависит от конкретного типа в модуле Б, то есть как минимум два способа временно разрешить эту зависимость, не дописывая до конца реализацию модуля Б, и не переходя к интерфейсу.
Оба стоят чуть меньше, чем ничего, в терминах дополнительных затрат.

V>Причём, русским.
V>Причём, обычно после прибегания тобой к чему-то как к якобы доказательству. ))
Да ну. Вы постоянно приводите какие-то смехотворные затруднения в качестве неразрешимых проблем; зато то, что реально требует больших затрат вам кажется чем-то несущественным.

V>Одна из последних твоих отсылок к примеру с порождением кучи независимых потоков vs тасков дотнета, и всё это в привычной менторской манере.
V>А по ссылке тихий бред от какого-то то ли MS MVP, то ли с должности на MS, что я валяюсь с вашего непуганного заповедника...
V>Исправленную версию примера я там же в обсуждении приводил, но такое ощущение, что ты участвуешь в обсуждениях не для выяснения истины...
Это тот тред, где вы обещали привести легендарную версию локов, которая на треть быстрее стоковых? Или какой-то другой. Ссылка была бы уместна.

V>Фанаты DDD пишут крупнейшие современные проекты.
V>Я занят не в крупнейших, но в которых, наверно, сильнейшие во всей отрасли технические требования.
А то. Как же без вас-то.

V>Ну вот за это и уволить, как и за вопрос выше, где я тоже рекомендовал.
V>Твой очередной косяк тут:
V>

V>Вам так хочется, чтобы модуль А зависел от конкретного типа, определённого в модуле Б?

V>По-форме в любом случае требует письменного публичного извинения и клятвенного обещания больше так не делать.
V>В любом случае, в такой форме и с таким содержанием вопрос заведомо провокационный, а посему заведомо бестолковый.
Вот прямо любо-дорого посмотреть, как вы начинаете вилять ужом по сковородке, чтобы не отвечать на вопрос.
V>Автору подобных манер обычно пару раз делают замечание, если не доходит — тупо увольняют.
V>Это нормальная, обычная практика.

V>И если тебя не уволили до сих пор, это означает, что ты, на самом деле, знаешь как необходимо себя вести.
В жизни я значительно более резкий
V>Получается, именно сюда ты ходишь отвести душу, бо общепринятое тебе противоестественно, давит и утомляет. ))
V>А здесь можно безнаказанно гадить, можно не стараться думать, можно даже строить из себя домохозяйку со стажем.
Здесь я пишу преувеличенно вежливо и аккуратно.

V>Что позволяло компиллировать большие программы на маленьких машинах.
V>В 94-м году довольно большое приложение на Паскале и Turbo Vision достигло у нас c товарищами почти полумегабайта (IDE для разработки на различных ассемблерах) и было неспособно компиллироваться в обычном DOS-режиме.

V>Портировали на Си (многое автоматом через глобальную замену, а многое и так было на Си — целевые парсеры/лексеры ассемблеров) — и всё прекрасно компиллировалось еще долго.
Отож. Каким компилятором компилировали?

V>Синклер, у вас опять обнаруживаются вопиющие провалы, не соответствующие объему надувания боковых поверхностей лица...
Да я вообще не программист. Это вы тут светоч знаний и опора системной архитектуры.

V>(не, я помню твои круглые глаза когда ты узнал о кеше браузеров и кодах ответов веб-серваков, но это было не на уровне "овладел", это было наполнение эрудиции, там инфы примерно на три первых дня работы современного фронтендера)
Как интересно. Напомните мне мои круглые глаза? А то я сам уже не помню, когда узнал о кэше браузера и кодах ответов.