информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsSpanning Tree Protocol: недокументированное применениеВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft закрыла серьёзную уязвимость,... 
 Прощаемся с Windows 7 
 С наступающим 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Нет, в TP была своя схема объектных модулей (юнитов). Фокус... 22.08.07 17:38  Число просмотров: 4181
Автор: 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 килобайт (!), когда как сишные компиляторы - это мегабайты и даже десятки МБ.
<site updates> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach