Здравствуйте, 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 мин более-менее грамотный разработчик насосёт из пальца свои, точно такие же.
Но у тебя всё мимо каждый божий раз...

В общем, я еще не уверен, но скорее всего отваливаюсь, бо это беспросветно...

Здравствуйте, 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 мин более-менее грамотный разработчик насосёт из пальца свои, точно такие же.
Но у тебя всё мимо каждый божий раз...

В общем, я еще не уверен, но скорее всего отваливаюсь, бо это беспросветно...