Здравствуйте, vdimas, Вы писали:
V>Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:
V>

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

Ну так это так и есть. Вы зачем-то предположили, что структура модулей будет совпадать со структурой .LIB, а не со структурой .h.
С чего вы это взяли — решительно непонятно. Сами себе придумали проблему; сами же придумали ей решение (хоть и не сразу), а вот догадаться, что если бы С++ был с модулями, то вся картина реализации стандартной библиотеки была бы другой, вы не можете.

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

V>Зачем оно?
Бесполезное бла-бла-бла — это "если бы в С++ были модули, то в начале 2000х ему для работы не хватало бы памяти".

S>>Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.
V>И из-за глючной одно время технологии инкрементной компиляции, но это поправили ближе к концу 90-х.
Совершенно верно. ЕМНИП, поправили это ближе к концу 2000х, но я уже не застал — к моменту, когда VC научился более-менее прилично работать с pch, я с С++ уже ушёл. Я свой последний проект на плюсах доделывал аккурат под прямой эфир из NYC, 9/11.

S>>Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.
V>Дык, готовое бинарное описание ничего не экономит в сравнении с исходным текстовым после зачитки тех и тех, там в лучшем случае требуется та же память, в худшем чуть большая — ввиду дополнительного мета-описания символов с т.з. расположения тех в модулях.
В лучшем случае требуется меньше памяти, т.к. можно хранить результат анализа, а не AST в ожидании окончания компиляции. В худшем — столько же, т.к. "расположение в модулях" занимает плюс-минус столько же места, сколько информация о расположении в .h файлах. Ну, то есть меньше — т.к. нам не нужно вплоть до строчки и колонки.
V>Неразрешимой проблему никто не называл (очередной тебе минус за враньё), я пояснял, почему технология не обязательно вызовет экономию ресурсов и ускорение процессов.
Ещё раз: если у вас технология модулей не вызывает экономию ресурсов и ускорение процессов, то что-то очень сильно не так с проектированием и реализацией технологии модулей.
V>Чаще будет ровно наоборот, бо зачитка текстового кода происходит не сильно медленней и текстовый код может быть порой компактней бинарного описания, а скорость компиляции сейчас часто зависит от скорости чтения с диска, т.е. от размеров исходников.
В среднем бинарное описание значительно компактнее текстового. Если у вас не так — вам нельзя писать компилятор, найдите кого-то, кто умеет. Вы, похоже, путаете бинарное описание с бинарным кодом. Вот код на целевой архитектуре может запросто раздуться сильнее, чем текстовый исходник. А вот описание символов — не должно. Посмотрите, для примера, на устройство метаданных того же дотнета.
Я знаю, вы предпочитаете аргументированные утверждения — так вот, в исходнике у вас какой-нибудь bool Generate(const std::string& filepath, const std::string& configpath);, который вы разворачиваете в дерево с текстовыми узлами. А в бинаре у вас вместо строк — ссылки на готовые метаданные. При подъёме в память эти токены превращаются в банальные указатели, и тратят в разы меньше места по сравнению с AST-узлами.
Про зависимость скорости компиляции от скорости чтения исходников — это вы хорошо пошутили. Попробуйте-ка скомпилять какой-нибудь chromium, потом вместе посмеёмся. Сколько там у него, полгига исходников? Надо полагать, за пару минут соберётся.

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

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

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

V>У меня сотни библиотечных типов одновременно было в разработке/портировании с С++, без оперативного оперирования зависимостями там можно было бы застрять надолго, т.е. выполнять работы "пошагово" можно было бы бесконечно.
Ну так это вырожденный случай — кстати, самый комфортный и удобный. Портирование — это же тупая механическая работа. Если бы исходным языком был не С++, то её вообще можно было бы автоматизировать. И, кстати, там всё очень легко делать инкрементально.

Я просто почему-то представлял себе обычный процесс разработки, который идёт с нуля. Или, наоборот, есть какой-то проект с предысторией, в котором "бурное кодирование" закончилось годы назад.
Мне такое счастье, как портирование, в последний раз доставалось году эдак в девятом. И то так — рядом постоять. Поправить мелкие косяки автоматизированного перевода.
А в предпоследний раз — в 2002 году. Мечта была, а не проект. Попадание в предварительные оценки с точностью до 1%; test code coverage = 100.0%. Заказчик на радостях премию выплатил.

С учётом подробностей — ок, я впечатлён вашей способностью эмулировать поведение плюсов в C# и msbuild. Толково придумано, я бы не допёр.

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

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