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

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

"Трактуешь" и вообще выкручиваешься тут ты, я говорю как оно есть и как непременно будет.
Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:

то ей будет ничуть не сложнее вычитать эти же символы из модулей

V>>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
S>Всё зависит от того, как именно модули реализовывать.

Если уж ты решил именно спорить (хотя я ХЗ зачем было именно спорить, а не спрашивать подробности), то надо уметь не косячить в рассуждениях, особенно в очевидном.
А вот это бесполезное бла-бла-бла...
Зачем оно?


V>>В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.

А из-за сваливания в кучу всего и вся.
И из-за глючной одно время технологии инкрементной компиляции, но это поправили ближе к концу 90-х.


S>Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.

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


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

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

Удобство модулей — это уменьшение вероятности потенциальных конфликтов имён промежуточных сущностей, фигурирующих сейчас в открытом виде в h-файлах.
Т.е. сами те сущности из модулей никуда не денутся, ес-но, но теперь их имена не будут вызывать конфликтов.

Но основное ожидаемое удобство — легкость разворачивания, поддержка версионности.
Зависимости м/у модулями можно описывать в явном виде, это перекликается с задачами пакетных менеджеров, поэтому в подветке про пакетные менеджеры я их и упомянул.


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

Я же говорю — ты не писал больших проектов на Турбо Паскале.


V>>Эээ, простите, "склеивать"? ))
S>У вас потеря кратковременной памяти? Это же ваша цитата про "склеивать" — поднимите глазки на две строчки выше.

Пфф, я и повторялся в сообщении, на которое отвечаешь, насчёт переписывания описания проекта с 0-ля по окончании работ, но ты высказывался про сам процесс, как мне показалось.
Иначе бы откуда было про "боль", когда речь об однократных операциях, выполняемых раз в несколько недель или даже единиц месяцев?

Использование тех же слов не обязательно означает тот же смысл.


V>>Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
S>Повторю вопрос: зачем вы это делаете?

Потому что будучи окончательно сгруппированным по конечным единицам деплоймента, описание проекта в виде единого файла будет минимальным по объёму.
(но при этом наименее управляемым, ес-но)


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

Уметь говорить мало, надо уметь говорить аргументировать.
И хотя бы понимать, о чём вообще речь.


V>>И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Да можно как угодно — хоть студией, хоть руками. Речь о том, что C# вас ни к чему не принуждает.

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

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


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

Да пофик кто принимает решения, хосподя, речь всё-равно не обо мне.
За злоупотребление такими вещами, которые ты себе позволяешь, увольняют откуда угодно.


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

То, что ревью делать некому, походу. ))

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


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

(утомляешь уже упоротостью...)
См. определение "избыточность" в IT.
Способ группировки информации обычно не влияет на степень её избыточности.


V>>Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
S>Отлично. В чём тогда ваша проблема?

Такие вещи обычно называются не "проблемами", а "задачами".
Проблемой задача становится, когда плохо понятно как её решать или её решение слишком дорогое.

Забавный у нас вышел обмен мнениями — я тебе рассказываю как решать те задачи, которые ты не в состоянии даже просто сформулировать. ))
Че-та ржу уже...

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


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

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

Альтернативой идёт дублирование уникальных описаний проектов и всё это в плохо управляемом на уровне исходников виде.

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


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

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

Например, посмотри на Авалонию.
И посмотри на исходники своих MSBuild-описаний.


S>Откуда тогда страдания про то, что C# вас вынуждает делить проект на мелкие части?

Декомпозиция — это вроде как стандартный способ борьбы со сложностью. ))

У меня сотни библиотечных типов одновременно было в разработке/портировании с С++, без оперативного оперирования зависимостями там можно было бы застрять надолго, т.е. выполнять работы "пошагово" можно было бы бесконечно.

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

Коллеги с тех пор заметно подросли, в подобных советах не нуждаются.
Но по-интернету уникальные кадры еще пробегают и даже преднамеренно привлекают к своей необычности внимание! ))


V>>В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
S>Ну и отлично. Зачем тогда их потом "склеивать"?

Чтобы убрать явную декомпозицию времени разработки.


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

Да там вышло два непонимания с твоей стороны — это непонимание самой задачи и доступных способов её решения для C# с использованием трюков MSBuild.
А это уже третье непонимание того, что непониманий в прошлый раз у тебя было два. ))


S>И тут вдруг опять — надо сравнивать описанную возню с её отсутствием. Так вот эти ваши десятки проектов — это хорошо или плохо?

Да я уже понял, что ты совсем запутался.

Медленно еще раз:
— в плюсах у меня единицы компиляции независимы, т.е. каждый cpp-файл;
— поэтому я могу работать над конкретным cpp-файлом независимо от компилябельности других cpp-файлов, т.е. хотя бы проверять на компиллябельность;
— если мне компиляции недостаточно, я могу линковаться от каждого отдельного obj-файла, который получается из каждого отдельного cpp-файла.
— или могу сложить те obj-файла, которые считаются рабочими, в одну либу одной командой и добавлять очередные obj-файлы в эту либу по мере готовности и т.д. и т.п.

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

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


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

Наверное, это побочный эффект вашего регулярного надувания.
Мне всё-время кажется, что вы обладаете достаточной эрудицией, что мне нет надобности с 0-ля всё разжёвывать.

Но дело не только в этом, ХЗ.
Я совершенно уверен в том, что ты хорошо в курсе про описанные в пред. абзаце подробности относительно декомпозиции единиц трансляции в С++.

Ты всё это знал, но тебе это не помогло.
А вот это уже необъяснимо.

Т.е., я хорошо понимаю что происходит, я не понимаю — почему.
Когда-то, когда ты познавал новое, проявлял любопытство, лично мне было интересно тебя читать.
Свежий, нестандартный взгляд от непрофессионала IT на всю эту скукатень, которой мы занимаемся...
Ты познавал новое и делился впечатлениями в интересной манере.
Умение заинтересовать — это уважаемый мною талант.
Несомненно, это приносило пользу более молодым коллегам, пополнять эрудицию в виде нескучного чтива.

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

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

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

"Трактуешь" и вообще выкручиваешься тут ты, я говорю как оно есть и как непременно будет.
Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:

то ей будет ничуть не сложнее вычитать эти же символы из модулей

V>>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
S>Всё зависит от того, как именно модули реализовывать.

Если уж ты решил именно спорить (хотя я ХЗ зачем было именно спорить, а не спрашивать подробности), то надо уметь не косячить в рассуждениях, особенно в очевидном.
А вот это бесполезное бла-бла-бла...
Зачем оно?


V>>В общем, у самого много раз компиляция под линухами молча подвисала при нехватке памяти в те года, если злоупотреблял предкомпляцией.
S>Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.

А из-за сваливания в кучу всего и вся.
И из-за глючной одно время технологии инкрементной компиляции, но это поправили ближе к концу 90-х.


S>Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.

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


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

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

Удобство модулей — это уменьшение вероятности потенциальных конфликтов имён промежуточных сущностей, фигурирующих сейчас в открытом виде в h-файлах.
Т.е. сами те сущности из модулей никуда не денутся, ес-но, но теперь их имена не будут вызывать конфликтов.

Но основное ожидаемое удобство — легкость разворачивания, поддержка версионности.
Зависимости м/у модулями можно описывать в явном виде, это перекликается с задачами пакетных менеджеров, поэтому в подветке про пакетные менеджеры я их и упомянул.


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

Я же говорю — ты не писал больших проектов на Турбо Паскале.


V>>Эээ, простите, "склеивать"? ))
S>У вас потеря кратковременной памяти? Это же ваша цитата про "склеивать" — поднимите глазки на две строчки выше.

Пфф, я и повторялся в сообщении, на которое отвечаешь, насчёт переписывания описания проекта с 0-ля по окончании работ, но ты высказывался про сам процесс, как мне показалось.
Иначе бы откуда было про "боль", когда речь об однократных операциях, выполняемых раз в несколько недель или даже единиц месяцев?

Использование тех же слов не обязательно означает тот же смысл.


V>>Но да, в самом конце "быстрой" первоначальной итерации разработки все-равно придётся код описания проектов переписать начисто, увы.
S>Повторю вопрос: зачем вы это делаете?

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


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

Уметь говорить мало, надо уметь говорить аргументировать.
И хотя бы понимать, о чём вообще речь.


V>>И стараться не править его из GUI Студии, а то там каша получается, а не исходник.
S>Да можно как угодно — хоть студией, хоть руками. Речь о том, что C# вас ни к чему не принуждает.

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

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


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

Да пофик кто принимает решения, хосподя, речь всё-равно не обо мне.
За злоупотребление такими вещами, которые ты себе позволяешь, увольняют откуда угодно.


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

То, что ревью делать некому, походу. ))

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


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

(утомляешь уже упоротостью...)
См. определение "избыточность" в IT.
Способ группировки информации обычно не влияет на степень её избыточности.


V>>Низкая связанность/высокое зацепление — это общий принцип, в основе DDD лежит в том числе одним из первых.
S>Отлично. В чём тогда ваша проблема?

Такие вещи обычно называются не "проблемами", а "задачами".
Проблемой задача становится, когда плохо понятно как её решать или её решение слишком дорогое.

Забавный у нас вышел обмен мнениями — я тебе рассказываю как решать те задачи, которые ты не в состоянии даже просто сформулировать. ))
Че-та ржу уже...

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


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

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

Альтернативой идёт дублирование уникальных описаний проектов и всё это в плохо управляемом на уровне исходников виде.

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


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

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

Например, посмотри на Авалонию.
И посмотри на исходники своих MSBuild-описаний.


S>Откуда тогда страдания про то, что C# вас вынуждает делить проект на мелкие части?

Декомпозиция — это вроде как стандартный способ борьбы со сложностью. ))

У меня сотни библиотечных типов одновременно было в разработке/портировании с С++, без оперативного оперирования зависимостями там можно было бы застрять надолго, т.е. выполнять работы "пошагово" можно было бы бесконечно.

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

Коллеги с тех пор заметно подросли, в подобных советах не нуждаются.
Но по-интернету уникальные кадры еще пробегают и даже преднамеренно привлекают к своей необычности внимание! ))


V>>В общем, границы проектов в конце стадии "быстрого роста" дизайна зависят от границ предметных областей и слоёв иерархии доменной модели, и ни от чего более.
S>Ну и отлично. Зачем тогда их потом "склеивать"?

Чтобы убрать явную декомпозицию времени разработки.


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

Да там вышло два непонимания с твоей стороны — это непонимание самой задачи и доступных способов её решения для C# с использованием трюков MSBuild.
А это уже третье непонимание того, что непониманий в прошлый раз у тебя было два. ))


S>И тут вдруг опять — надо сравнивать описанную возню с её отсутствием. Так вот эти ваши десятки проектов — это хорошо или плохо?

Да я уже понял, что ты совсем запутался.

Медленно еще раз:
— в плюсах у меня единицы компиляции независимы, т.е. каждый cpp-файл;
— поэтому я могу работать над конкретным cpp-файлом независимо от компилябельности других cpp-файлов, т.е. хотя бы проверять на компиллябельность;
— если мне компиляции недостаточно, я могу линковаться от каждого отдельного obj-файла, который получается из каждого отдельного cpp-файла.
— или могу сложить те obj-файла, которые считаются рабочими, в одну либу одной командой и добавлять очередные obj-файлы в эту либу по мере готовности и т.д. и т.п.

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

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


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

Наверное, это побочный эффект вашего регулярного надувания.
Мне всё-время кажется, что вы обладаете достаточной эрудицией, что мне нет надобности с 0-ля всё разжёвывать.

Но дело не только в этом, ХЗ.
Я совершенно уверен в том, что ты хорошо в курсе про описанные в пред. абзаце подробности относительно декомпозиции единиц трансляции в С++.

Ты всё это знал, но тебе это не помогло.
А вот это уже необъяснимо.

Т.е., я хорошо понимаю что происходит, я не понимаю — почему.
Когда-то, когда ты познавал новое, проявлял любопытство, лично мне было интересно тебя читать.
Свежий, нестандартный взгляд от непрофессионала IT на всю эту скукатень, которой мы занимаемся...
Ты познавал новое и делился впечатлениями в интересной манере.
Умение заинтересовать — это уважаемый мною талант.
Несомненно, это приносило пользу более молодым коллегам, пополнять эрудицию в виде нескучного чтива.

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