Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Нет, в TP была своя схема объектных модулей (юнитов). Фокус... 22.08.07 17:38 Число просмотров: 5646
Автор: crontab Статус: Незарегистрированный пользователь
|
> Ну так она в паскале и появилась из плюсов. Все более менее
> хорошие вещи в паскале (и производных) появились из C++.
Нет, в TP была своя схема объектных модулей (юнитов). Фокус был в том, что интерфейс и реализация объявлялись в одном исходном файле, а не в двух отдельных как в Си. Исходный файл состоял из двух секций - interface и implementation, и это было очень удобно. Из-за этого, правда, формат объектного модуля был специфичным, а не стандартным ".obj". Наверное в Инете можно что-то найти по этой теме.
> Что такое оптимальная перекомпиляция? Ни гугль ни яндекс не
> знают о таком.
В Си любое изменение в .h файле приводит к перекомпиляции всех модулей, которые включили этот .h. Turbo Pascal же (и Delphi) проводил минимальную необходимую перекомпиляцию - это опять же упирается в его двичные форматы. Сейчас подобные фокусы могут делать какие-то очень крутые Си-компиляторы, но в мейнстрим такая практика так и не вошла.
>
> Ну а в *NIX получится штук 20. Это не считая
> бэкапа/рестора, подключения дополнительных хайвов,
> использования удаленного реестра и пр.. Они появились не по
> прихоти - кому то это понадобилось.
>
В UNIX не получится 20, потому что они там уже есть. Бэкапы и удаленный доступ тоже получаются автоматически как с обычными файлами (tar, NFS), а в Windows для обеих функций пишутся специфичные сервисы и специфичные GUI - еще один прекрасный пример раздувания задачи из ничего.
> > использоваться стандартные функции open, read, write,
> итд,
>
> Не уверен, что это плюс. Если выбирать между чрезмерной
> перегрузкой семантики одних и тех же функций и "ожирением"
> интерфейса, я, пожалуй, выберу "ожирение". Вы же сами и
> описывали проблему с write-ом из-за его перегруженной
> семантики.
Но я уже хорошо знаком с write(), и мне не надо перечитывать документацию. В Windows же, мало того что надо помнить или же всякий раз заглядывать в документацию, плюс к этому семантика этих функций тоже нетривиальна, что тоже абсурд. Мне бы очень не хотелось загружать мозг такими пустяковыми вещами - у мозга ресурсы ограничены.
> > UNIX Registry будут работать все стандартные cmdline
>
> В описанном виде - не будут. Ибо тоже нужно делить на
> "ключи" и "значения". Все cmdline утилиты ожидают, что файл
> окажется либо директорией либо файлом. И вот
> интерфейс UR раздувается еще на несколько вызовов.
Я не понял почему нужны еще вызовы и почему утилиты не будут работать. Для утилит - это файлы, и им нет дела до того, что драйвер на самом деле отводит каждому файлу не полкило на диске, а гораздо меньше.
В статье я, правда, упустил enum, который в терминах FS на UNIX - это функции <dirent.h>, тоже знакомые. Ничего страшного.
> Вопреки
> общепринятому мнению, в майкрософте сидят СОВСЕМ не дураки
> и я уверен они обдумывают несколько возможных путей перед
> тем как принять то или иное архитектурное решение.
>
В Майкрософте сидят не дураки - это самый плохой аргумент в защиту Майкрософта. А за раздуванием API кстати, стоит маркетинговый трюк, который заставляет людей посвятить себя целиком ихним технологиям, потому что ресурсов и времени на изучения "чужих" у программиста уже не остается. Этот прием, кстати, изобрели в IBM еще до появления Windows.
>
> Ну возьмем сначала: используйте "интернет-технологии" (а
> если проект вообще не связан с сетью?), но не используйте
> XML (а как же Asynchronous JavaScript + XML - в миру AJAX,
> от которого сейчас не продыхнуть). Я совершенно согласен,
> что XML - не серебрянная пуля и не стоит его тыкать куда не
> следует, но структурированный и расширяемый XML ГОРАЗДО
> лучше *NIX-like текстовок. Что же до языка и библиотек,
> позволяющих сосредоточиться на главном - это правильно, но
> при чем здесь отказ от метапрограммирования и шаблонов? Я
> так понимаю, от них следует отказаться только потому, что в
> "правильном" Delphi их нет? И почему следует АПРИОРИ
> отказываться от COM/DCOM? Что в них такого ужасного, что их
> нельзя использовать вообще?
>
AJAX - это способ посылать HTTP запросы прямо из браузера, и XML тут вообще не при чем.
XML по сути - это формат для записи древовидных структур данных. Во-первых в нем нет необходимости когда нет дерева, и во-вторых его синтаксис избыточен. Например лиспоподобный синтаксис уже выглядел бы лучше и компактнее, его легче было бы парсить и легче редактировать вручную.
Шаблоны Си++ ухудшают читабельность, потому что их сложно понимать. Ими можно делать очень крутые фокусы, но в продакшн надо использовать в очень сдержанном количестве. Вобщем, это мнение не ново и не оригинально.
DCOM - это надстройка над RPC. Все бы ничего, но он слишком привязан к Access Rights в Windows, из-за чего возникает много мороки. Плюс его очень трудно или почти невозможно файерволить - вместо этого приходится открывать чуть ли не все порты. Нет возможности "общаться" через прокси, как в HTTP.
Майкрософт сам уже постепенно сворачивает COM/DCOM и предлагает переходить на .NET-овские технологии, которые, однако, страдают схожими недостатками.
О преимуществах HTTP: длинная история, для этого и правда нужна отдельная статья.
> Ну а цитата про "Large systems" - вообще ни к селу ни к
> городу. Все современный операционные системы и компиляторы
> - охренительно большие системы, так что же теперь
> отказаться от них, только потому, что некто из гугля
> считает это плохим?
Эта цитата о том, что большие системы должны быть разбиты на небольшие куски - вот и все. Из современных компиляторов только Си++ очень большой - так это говорит не в пользу языка. Turbo Pascal 5-ой версии занимал 70 килобайт (!), когда как сишные компиляторы - это мегабайты и даже десятки МБ.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
