Здравствуйте, Sinclair, Вы писали:
V>>Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:
V>>V>>то ей будет ничуть не сложнее вычитать эти же символы из модулей
S>Ну так это так и есть. Вы зачем-то предположили, что структура модулей будет совпадать со структурой .LIB, а не со структурой .h.
Сам себе противоречишь. ))
Экономию времени и памяти будет давать только совпадение со структурой LIB.
S>Бесполезное бла-бла-бла — это "если бы в С++ были модули, то в начале 2000х ему для работы не хватало бы памяти".
В реальной жизни для компиляции на линухах порой имеющихся двух стандартных метров на борту не хватало.
С модулями вообще не взлетело бы.
S>Совершенно верно. ЕМНИП, поправили это ближе к концу 2000х, но я уже не застал — к моменту, когда VC научился более-менее прилично работать с pch, я с С++ уже ушёл. Я свой последний проект на плюсах доделывал аккурат под прямой эфир из NYC, 9/11.
9/11 — это 2001-й, а не конец 2000х.
Который тогда был VC — он вышел в 1998-м, следующие плюсы вышли уже не отдельным продуктом, а в составе студии 2002, т.е. речь может быть о компиляторе из 98-го.
Следующий от 2002-го жутко глючил в течении года, что народ (в т.ч. и я) подключал туда VC от предыдущего VC, а уже в Студии 2003 компилятору полегчало.
Плюс случилось главное — стало можно писать кроссплатформенный код не только на Си, но и на С++, т.к. компиляторы покрыли официальным стандартом С++03 и теперь они стали воспринимать плюсы плюс-минус одинаково.
До этого писать на плюсах кроссплатформенный код было мукой, бо каждый компилятор имел своё видение, т.е. приходилось обыгрывать не только разночтение даже в POSIX-подмножестве АПИ осей (тогда в ходу было много плохосовместимых *никсов, не только Linux), но и разночтения компиляторов.
Уверен, тут полно коллег, которым в конце 90-х и почти все нулевые приходилось, как и мне, писать в т.ч. под спарки/солярис.
S>В лучшем случае требуется меньше памяти
Да не меньше никак.
Потому что вообще всё, что видно из h-файла, должно быть видно из модуля.
И пусть тебя не обманывают обещания, что ты не увидишь символы, которые не помечены для экспорта.
Ты, программист, их не увидишь, верно (т.е. не сможешь к ним обратиться), но компилятор, тобой запущенный, обязан все их видеть со всеми их телами для продолжения поддержки шаблонов, макросов и инлайных ф-ий.
S>В худшем — столько же, т.к. "расположение в модулях" занимает плюс-минус столько же места, сколько информация о расположении в .h файлах. Ну, то есть меньше — т.к. нам не нужно вплоть до строчки и колонки.
Инфы на каждый символ будет чуть больше, теперь еще признаки модуля, видимости из модуля и т.д.
V>>Неразрешимой проблему никто не называл (очередной тебе минус за враньё), я пояснял, почему технология не обязательно вызовет экономию ресурсов и ускорение процессов.
S>Ещё раз: если у вас технология модулей не вызывает экономию ресурсов и ускорение процессов, то что-то очень сильно не так с проектированием и реализацией технологии модулей.
Это потому что ты вырос на паскалевских TPU.
Но где Паскаль и где С++?
Ключевое там "не обязательно вызовет экономию ресурсов".
Для современных template-only библиотек скорее всего не вызовет или экономия будет незначительной (единицы процентов прибавки к скорости компиляции в сравнении с прошлыми ср-вами, типа stdafx.h).
V>>Чаще будет ровно наоборот, бо зачитка текстового кода происходит не сильно медленней и текстовый код может быть порой компактней бинарного описания, а скорость компиляции сейчас часто зависит от скорости чтения с диска, т.е. от размеров исходников.
S>В среднем бинарное описание значительно компактнее текстового.
Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
А это примерно оно и есть.
Еще навскидку — с 7-мибитным кодированием целых типов обычно не заморачиваются, бо это тоже некоторые тормоза при кодировании/раскодировании.
А при фиксированной их ширине, как оно есть в большинстве бинарных форматов файлов, — никакой экономии.
Где в тексте 1-2 символа, там в бинарнике честные 4.
Где в тексте операция использует окружающий контекст, сопровождающирй операцию различными признаками, там в бинарнике к каждой операции привязывают уже вычисленные аттрибуты/признаки.
Где в исходнике при вызове шаблонного метода используется автовыводимый тип аргумента, который явно нигде не упоминается, там в бинарнике многоэтажное декорированное имя типа выражения присутствует явно. А в теле шаблонов это имя будет еще и параметризировано.
S>Если у вас не так — вам нельзя писать компилятор, найдите кого-то, кто умеет.
Это ты сейчас с кем разговаривал?
S>Вы, похоже, путаете бинарное описание с бинарным кодом.
Я сейчас нон-стоп зеваю, если по-чеснаку.
Плохо, Синклер.
Очень плохо.
Принципы трасляции С++ кода весьма просты, я бы даже сказал — примитивнейшие.
Как там можно умудряться плавать?
И даже если ты эти принципы не знал, за 10 мин более-менее грамотный разработчик насосёт из пальца свои, точно такие же.
Но у тебя всё мимо каждый божий раз...
В общем, я еще не уверен, но скорее всего отваливаюсь, бо это беспросветно...
