информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRыАтака на Internet
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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да, заимствование определенно не из C++, но особых... 22.08.07 20:12  Число просмотров: 4178
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Нет, в TP была своя схема объектных модулей (юнитов). Фокус
> был в том, что интерфейс и реализация объявлялись в одном

Да, заимствование определенно не из C++, но особых преиуществ (как и недостатков) такой системы не вижу. В C/C++ интерфейс физически вынесен в отдельный файл, здесь он просто логически отделен внутри одного файла. Во всяком случае этого недостаточно для того, чтобы говорить о том, что паскаль в отличие от плюсов - модульный.

> > Что такое оптимальная перекомпиляция? Ни гугль ни
> яндекс не
> > знают о таком.
>
> В Си любое изменение в .h файле приводит к перекомпиляции
> всех модулей, которые включили этот .h. Turbo Pascal же (и
> Delphi) проводил минимальную необходимую перекомпиляцию -
> это опять же упирается в его двичные форматы. Сейчас

Если меняется интерфейсная часть юнита в паскале, приходится ли перекомпилировать все файлы, использующие этот юнит? Скорее всего да. Это всего лишь говорит о том, что не стоит пихать все свои интерфейсы в один h-файл.

> подобные фокусы могут делать какие-то очень крутые
> Си-компиляторы, но в мейнстрим такая практика так и не
> вошла.

Да нет. Это не фокус. Один h-файл считается интерфейсом ОДНОГО модуля. Если меняется интерфейс, то все исходники, использующие (в т.ч. и реализующие) данный интерфейс необходимо перекомпилировать. Просто не стоит складывать все яйца в одну корзину и все.

> > Ну а в *NIX получится штук 20. Это не считая
> > бэкапа/рестора, подключения дополнительных хайвов,
> > использования удаленного реестра и пр.. Они появились
> не по
> > прихоти - кому то это понадобилось.

> В UNIX не получится 20, потому что они там уже есть. Бэкапы

Не совсем так. По аналогии с перегрузкой функций, даже если у функции одно и то же имя, но различные входные аргументы, физически они все равно остаются разными. Иногда такая перегруженность помогает, но все равно нужно помнить тонкости семантики при работе с разными типами "файлов".

> и удаленный доступ тоже получаются автоматически как с
> обычными файлами (tar, NFS), а в Windows для обеих функций

Ах да, в *NIX толком нет блокировок (flock-и это не блокировки - а ХЗ что), поэтому можно изменять, удалять и пр. совершенно не заботясь о тех, кто в данный момент читает или даже тоже изменяет тот же файл. Не знаю, может это и хорошо, но я видел слишком много race-ов чтобы так легкомысленно подходить к проблемам синхронизации.

> пишутся специфичные сервисы и специфичные GUI - еще один
> прекрасный пример раздувания задачи из ничего.

Да нет, backup/restore - это такой способ обхода блокировок. И я бы не сказал, что блокировки - это блажь.

> Но я уже хорошо знаком с write(), и мне не надо
> перечитывать документацию. В Windows же, мало того что надо

Да нет же. Вы помните семантику write-а при работе с plain файлом. Нигде не гарантируется, что она будет одинаковая для всех файлов, реализующих этот интерфейс. Более того, желание запихнуть в файлы совершенно все - это как раз и есть тот самый "golden hammer"

> помнить или же всякий раз заглядывать в документацию, плюс

Лично мне всегда хватает IntelliSense-а из IDE.

> к этому семантика этих функций тоже нетривиальна, что тоже

Она тривиальна, так же как и для write-а, но в случае с write-ом на одном названии висит целая куча (пусть и тривиальных) семантик. Не факт, что это вызовет проблемы, но не вижу чем раздувание семантики одного слова лучше раздувания количества слов.

> абсурд. Мне бы очень не хотелось загружать мозг такими
> пустяковыми вещами - у мозга ресурсы ограничены.

Вы загружаете мозг другими пустяковыми вещами :-)

> Я не понял почему нужны еще вызовы и почему утилиты не

Создание файла и создание каталога - разные вызовы.

> будут работать. Для утилит - это файлы, и им нет дела до
> того, что драйвер на самом деле отводит каждому файлу не
> полкило на диске, а гораздо меньше.

Я не о том сколько места. Я о том, что Вы посчитали неразмным хранение ключей и значений (директорий и файлов) и предложили обойтись одними директориями, которые могут иметь значение. Ни одна cmdline утилита не ожидает от директории такой подлости, и следовательно работать не будет.

> В статье я, правда, упустил enum, который в терминах FS на
> UNIX - это функции <dirent.h>, тоже знакомые. Ничего
> страшного.

Согласен, ничего. Но в конце концов интерфейс работы с UR будет не меньше 20 функций. Не так уж и меньше, чем в Windows варианте.

> В Майкрософте сидят не дураки - это самый плохой аргумент в
> защиту Майкрософта. А за раздуванием API кстати, стоит

Это не аргумент в защиту, это констатация факта, о котором почему то принято забывать (или более того, считать истинным противоположное утверждение). Жирный интерфейс никто не заставляет знать полностью, можно использовать его подмножество и реализовывать велосипеды самому. А вот если интерфейс неполный, то никакого выбора уже не остается: чего то не хватает - пиши сам.

> маркетинговый трюк, который заставляет людей посвятить себя
> целиком ихним технологиям, потому что ресурсов и времени на
> изучения "чужих" у программиста уже не остается. Этот

Мягко говоря необоснованное утверждение. Точно так же можно утверждать, что неполный *NIX интерфейсы - это способ привязки программистов, заставляющий их все свое время посвящать реализации необходимых велосипедов, а не учить что то другое, или не дай бог программировать.

> AJAX - это способ посылать HTTP запросы прямо из браузера,
> и XML тут вообще не при чем.

Строго говоря способ посылать запросы это XML-HTTP, а AJAX это JavaScript + XML-HTTP, но дело не этом. А в том, что XML стал интернет стандартом и первая рекомендация противоречит второй.

> XML по сути - это формат для записи древовидных структур
> данных. Во-первых в нем нет необходимости когда нет дерева,

Не дерева, а структуры. Есть только один неструктурированный текстовы тип данных - raw text. Для всего остального XML пригоден.

> и во-вторых его синтаксис избыточен. Например лиспоподобный
> синтаксис уже выглядел бы лучше и компактнее, его легче
> было бы парсить и легче редактировать вручную.

Не факт

> Шаблоны Си++ ухудшают читабельность, потому что их сложно
> понимать. Ими можно делать очень крутые фокусы, но в
> продакшн надо использовать в очень сдержанном количестве.
> Вобщем, это мнение не ново и не оригинально.

В целом согласен, но согласитесь, это немного более сдержанная формулировка, чем "никаких шаблонов и метапрограммирования".

> DCOM - это надстройка над RPC. Все бы ничего, но он слишком
> привязан к Access Rights в Windows, из-за чего возникает
> много мороки. Плюс его очень трудно или почти невозможно

Если не предполагается кросплатформенность, то никаких проблем с виндовыми правами нет.

> файерволить - вместо этого приходится открывать чуть ли не
> все порты. Нет возможности "общаться" через прокси, как в
> HTTP.

Уже ответили.

> О преимуществах HTTP: длинная история, для этого и правда
> нужна отдельная статья.

Мне этого говорить не надо :-) Я с этим и не спорю.

> Эта цитата о том, что большие системы должны быть разбиты
> на небольшие куски - вот и все. Из современных компиляторов
> только Си++ очень большой - так это говорит не в пользу
> языка. Turbo Pascal 5-ой версии занимал 70 килобайт (!),
> когда как сишные компиляторы - это мегабайты и даже десятки
> МБ.

Самый крутой язык - brainfuck? Тот вообще меньше килобайта весит
<site updates> Поиск 








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


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