RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Может я не прав, но..


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Alexander Conon
To : Игорь Козин
Subj : Может я не прав, но..
>>угу. этот цэ - чума натуральная.
>А ты не подумал, что объяснение может быть более естественное,
>чем массонский заговор любителей C?
что может быть более естественным чем массонский заговор? :)
так или иначе даже если никто напрямую и не договаривался
все-равно "заговор" имеет место быть

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

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

>знаешь ли ты какой реальный оверхед при реализации вызова метода объекта
>в так охаеваемом тобой дельфи-паскале? Так вот, это всего один
>дополнительный указатель (self) передаваемый как первый параметр
>при вызове метода. На фоне всего остального это такая мелочь.
вот только не надо тут "легенды и мифы агропрома" рассказывать.
самолично изучал эти объектные методы в виртуал паскале.
вызываешь голое окошко - экзешник метр. вешаешь кнопку - еще метр.
при повторных вызовах таких рывков нет но все равно
экзешник так разбухает - мама не горюй.
без этого оо и с тем же вп - нормальный размер.

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

>>речь идет не о том как ее затормозить а о том как ее ускорить
>Не-е. Мы говорим о том, что написать медленную программу можно
>на чем угодно. И компилятор тут не спасет. Поэтому когда ты говоришь,
>что программы на C становятся медленнее, это не корректно.
>Ширпотребные программы вообще становятся медленнее независимо
>от того на чем написаны из-за низкой квалификации программистов.
>Еще раз повторяю, даже твой любимый фортран от дурака не спасет.
еще как спасет. я ж на нем несколько месяцев програмил! :)
и принимая во внимание что програмер я никакой
так прям на глюки можно сказать сам нарывался. ни разу не удалось! :)
везде где надо и про ошибки расскажет и предупреждения сделает...
вобщем неизменный результат - быстро и безглючно.

>>>А вот что там последние тесты говорят? Какой выигрыш у Фортрана
>>>по сравнению с последними C++ компиляторами? В конкретных цифрах?
>>ну не помню я конкретные цифры... застрелиться мне теперь?
>А тогда о чем спор? О сферическом коне?
повторяю - был обзор компилеров и по коду на выходе фортран лидирует.
не веришь - проверь. причем тут сферический конь?

>>>>а с чего это goto вдруг стали непрозрачными?
>>>"C":
>>>else { // - вот тут скобочку закрыть забыли...
>>>"F" (прошу прощения если не совсем точно, лет д-цать Фортраном
>>>GOTO 40 - представьте себе тут GOTO потерялось.
>>>30 FOO2
>>>Так вот не надо наверное объяснять, что любой самый убогий C-шный
>>>компилятор завопит, что вы скобочку забыли закрыть. А вот с точки
>>>зрения Фортрана (по крайней мере FORTRAN-IV, в котором конструкции
>>>IF THEN ELSE не поддерживаются) отсутствие "GOTO 40" ошибкой не является...
>>зашибись. для цэ привел пример грамматической ошибки
>>а для фортрана "потерялся" целый оператор.
>Вот в том-то и идея. Незакрытая скобка для С грамматическая ошибка
>отлавливаемая на этапе компиляции, а для фортрана прямая головная боль
>программиста, поскольку перед TRUE секцией ДОЛЖЕН быть GOTO.
агапрямщаз! идея в том что в цэ это ошибка а в фортране это алгоритм.
если програмер не ставит goto это значит что ему _нужно_
чтобы при истинности выполнялось TRUE а при ложности
сначала FALSE а потом TRUE.

>>тебе фортран-компилер кофе в постель должен подавать?
>>на це в "<=" потерять "<" можно куда проще и результат будет
>>таким же интересным и компилер тоже ничего не скажет.
>Вот. Наконец-то, хоть один реальный пример...
это реальный пример того что действительно легко потерять.
однако если ты можешь потерять _целый_оператор_ "goto" на фотране
то ты точно так же можешь потерять какой-нить "x++" на цэ.
никакой компилер не может и не должен "проверять" алгоритм.

>>пааазвольте. в 4 тоже есть динамическое распределение памяти.
>НЕТУ в IV явного динамического распределения памяти. Почитайте стандарт.
вот именно что "почитайте стандарт".
только что LightElf ссылку постил:
"Variable-dimension array arguments in subroutines"
а вот из фортран-ес:"порция 85. массивы с регулируемыми размерами."
куда еще динамичнее-то? а тут еще и common вдобавок.
цэ глотает пыль однозначно.

>Вот напишите-ка мне древовидную структуру произвольного размера
>на Фортране IV.
не врубился.

>>>И, кстати, а чем по-Вашему "С" таки идеологически хуже Фортрана?
>>>Конкретные примеры, можно "в студию"?
>>дык как бы уже. апликухи все жирнее и тормознее
>>и их хистори - непрерывный и нескончаемый бугфикс.
>>оно конечно и на фортране можно написать тормозную прогу
>>и ошибку можно сделать но на нем это будут исключения
>>а на цэ - это правило. это просто вдобавок к тому
>>что все-таки язык - это и стиль мышления тоже :)
>Так все-таки какие особенности С (только КОНКРЕТНО) приводят
>к его непрозрачности? Если не будет конкретики, обсуждать будет нечего.
дык он жыш _в_принципе_ конкретно непрозрачный.
если сами авторы говорят что без поллитры фиг разбирают
что намедни написали так куда еще конкретнее?

>И кстати, никто не мешает использовать goto в С :(
>Вот уж действительно уродство получается...
похоже на то что _единственной_ задачей цэ - являются исходники без goto.


Sat 14 Jul 2007 13:51 XZ/77.0 (WARP; i386)



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.