Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Прошу прощения - сказал не проверив. Мне почему то... 22.08.07 16:47 Число просмотров: 5563
Автор: amirul <Serge> Статус: The Elderman
|
> > Во-первых, приличия ради стоит отметить, что
> > int avg(int a, int b) { return (a + b) / 2; }
> > будет правильно работать для любых a и b (с точностью
> до
> > 0.5 естественно), помещающихся в int.
>
> Если a и b близки к INT_MAX, то результат получится
> отрциательный - это правильно?
Прошу прощения - сказал не проверив. Мне почему то показалось, что перенос, появившийся от сложения пропадет при делении (он то уйдет, и все биты, кроме знакового будет правильными, но вот со знаковым - действительно проблема).
> > Во-вторых смешно слышать о модульности паскаля (в
> котором
> > изначально вся программа должна была помещаться в одну
> > единицу трансляции)
> Я имел ввиду Turbo Pascal и Delphi, в которых есть
> раздельная компиляция, к тому же еще и оптимальная
Ну так она в паскале и появилась из плюсов. Все более менее хорошие вещи в паскале (и производных) появились из C++. Так зачем брать подражателей (зачастую неудачных), если можно сразу взять изначально "правильный" язык?
> перекомпиляция, которй в принципе нет в C++.
Что такое оптимальная перекомпиляция? Ни гугль ни яндекс не знают о таком.
> > В частности "create, write,
> > read, delete" никак не хватит для работы. Навскидку
> нужны
> > еще как минимум enum, stat, chmod, chown, chgrp и др..
> И
> > вот уже интерфейс, сопоставимый по "жирности" с Reg
> > интерфейсом винды.
>
> Даже если добавить enum (верно, это было упущением), итд,
> по жирности этот интерфейс никогда не догонит WinRegistry -
> напомню, там 41 функция. Плюс, в UNIX-е будут
Ну а в *NIX получится штук 20. Это не считая бэкапа/рестора, подключения дополнительных хайвов, использования удаленного реестра и пр.. Они появились не по прихоти - кому то это понадобилось.
> использоваться стандартные функции open, read, write, итд,
Не уверен, что это плюс. Если выбирать между чрезмерной перегрузкой семантики одних и тех же функций и "ожирением" интерфейса, я, пожалуй, выберу "ожирение". Вы же сами и описывали проблему с write-ом из-за его перегруженной семантики. "Золотые молотки" никому не нужны
> и не надо будет изучать никаких новых интерфейсов с тоннами
> документации - вот в чем разница. Не говоря уже, что в в
Надо будет. Названия вызовов не поменяются, поменяется их семантика.
> UNIX Registry будут работать все стандартные cmdline
В описанном виде - не будут. Ибо тоже нужно делить на "ключи" и "значения". Все cmdline утилиты ожидают, что файл окажется либо директорией либо файлом (пока не будем принимать в расчет наличие девайсов, пайпов и пр.). И вот интерфейс UR раздувается еще на несколько вызовов. Вопреки общепринятому мнению, в майкрософте сидят СОВСЕМ не дураки и я уверен они обдумывают несколько возможных путей перед тем как принять то или иное архитектурное решение.
> утилиты, а в Windows они не работают. Впрочем, я уже
В Windows не проблема написать файловую систему, предоставляющую ВТОРОЙ интерфейс к реестру. С ней будут работать все cmdline тулзы. В чем проблема? Другое дело, что это не особо надо.
> повторяюсь - пойдите перечитайте статью.
> > Да, забыл упомянуть: рекомендации - вообще песТня.
> Даже
> > комментировать не хочется и так все понятно.
>
> Что понятно? :)
Ну возьмем сначала: используйте "интернет-технологии" (а если проект вообще не связан с сетью?), но не используйте XML (а как же Asynchronous JavaScript + XML - в миру AJAX, от которого сейчас не продыхнуть). Я совершенно согласен, что XML - не серебрянная пуля и не стоит его тыкать куда не следует, но структурированный и расширяемый XML ГОРАЗДО лучше *NIX-like текстовок. Что же до языка и библиотек, позволяющих сосредоточиться на главном - это правильно, но при чем здесь отказ от метапрограммирования и шаблонов? Я так понимаю, от них следует отказаться только потому, что в "правильном" Delphi их нет? И почему следует АПРИОРИ отказываться от COM/DCOM? Что в них такого ужасного, что их нельзя использовать вообще?
Ну а цитата про "Large systems" - вообще ни к селу ни к городу. Все современный операционные системы и компиляторы - охренительно большие системы, так что же теперь отказаться от них, только потому, что некто из гугля считает это плохим?
|
|
|
подробно о проекте
Анализ криптографических сетевых...
