Я так понял, что это относится к экспортируемым включениям других модулей. Как по мне, смотрится куда более логично.
Если мне нужен приватный «инклюд»
я пишу просто
import Blank;
А если мне его еще и наружу надо отдать тем, кто будет мной пользоваться:
export import Blank;
ИМХО интуитивнее.
Пользователи скачивают дистрибутив программы с сайта, 50% дается оригинальный инсталлятор, 50%- модифицированный. Ну или 1%, в зависимости от требований.
Самое ключевое что бесит в этой схеме «я перезагружусь» — если бы как в линуксе, перезагрузка не нужна была (ну разве что обновляется kernel32.dll), к установке обновлений гораздо большее число людей спокойно относилось бы.
У интеграции непосредственно с системой сборки есть свои преимущества — можно более точно планировать remote-задачи в отдельном цикле. Судя по замерам, такой подход дает ускорение примерно на 40% по сравнению с подходом — разделяем каждый запрос к компилятору.
Ну а в плане велосипедостроения — да, я просто «неосилил» distcc, статья начинается с упоминания именно его.
Ерунду говорите, базы данных давно работают с 64-битными метками и 128-битными значениями даже на 32-битных архитектурах. Ну и что, что значение за один так не посчитается.
Если мне нужен приватный «инклюд»
я пишу просто
import Blank;
А если мне его еще и наружу надо отдать тем, кто будет мной пользоваться:
export import Blank;
ИМХО интуитивнее.
Что, простите? Данные о паролях? Моих сохраненных паролях?
Если бы был подробный ченджлог, что в каждой дллчке было изменено, и что конкретно я выкачиваю — было намного лучше.
Ну а в плане велосипедостроения — да, я просто «неосилил» distcc, статья начинается с упоминания именно его.