Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Да, заимствование определенно не из C++, но особых... 22.08.07 20:12 Число просмотров: 5720
Автор: 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? Тот вообще меньше килобайта весит
|
|
|
подробно о проекте
Анализ криптографических сетевых...
