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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> >>угу. этот цэ - чума натуральная.
> >А ты не подумал, что объяснение может быть более естественное, 
> >чем массонский заговор любителей 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.
>

__, _,_ _, __, ___, \|_) \| \| \| \|_ ` / \| \ \| \| \| , \| / ~ ~ `~' ~~~ ~~~ ~~~