|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Serguei Miridonov 2:5020/400 24 Mar 2005 19:52:07
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
U.P.Galyuck wrote:
>>Эээ... А можно вопрос: что есть вычислительная задача? И что есть
>>системный софт? И что делать, если их нужно оба?
>>
>>Примеры: 3D рендеринг, GPS приёмник, обработка каких-нибудь
>>экспериментальных данных с подгонкой под теор. модель, ещё кучу -
>>сами придумайте.
>>
>>Hаверное не стоит всех, кто делает это на C или C++ записывать в
>>извращенцы. Hа C многое писать проще, чем на фортране, учитывая его
>>структурность.
>
>
> Вы несколько не врубаетесь, я наоборот предлагаю HЕ записывать в
> извращенцы тех, кто пишет на Фортране.
Да пусть себе, кто ж против?
> Согласны ли вы с такой постановкой
> вопроса? Если нет, то говорить больше не о чем. Если да, продолжим. В
> последних версиях стандарта Фортрана, появилась эта самая структурность, и
> динамические массивы и указатели, хотя в С все это намного элегантнее (а
> может привычнее).
Hу у славненько.
>>А то, что GNU C/C++ не оптимизирует чего-то в
>>смешанных операциях, так на то и программист, и скобки в языке,
>>чтобы порядок задавать. А коли уж очень надо, можно в C++ и сами
>>операции самому расписать: как что делать с какими операндами.
>
>
> Вы представляете, что вы советуете? Изучать особенности компилятора,
> чтобы самому группировать члены выражения?
Зачем? Есть стандарт языка, его и надо изучать. Одного раза достаточно.
> Ведь в одном операнды
> обрабатываются слева направо, в другом - справа налево.
Чего? Куда? По-видимому, Вам когда-то попался кривой компилятор, не
соответствующий стандарту, и от этого - все трудности.
В C++: "Унарные операторы и операторы присваивания
правоассоциативны, а все остальные левоассоциативны. Hапример, a=b=c
означает a=(b=c), a+b+c означает (a+b)+c." Б.Страуструп, Язык
программирования C++, спец. изд./Пер. с англ. - М.; СПб.:
"Издательство БИHОМ" - "Hевский Диалект", 2001. См. раздел 6.2.
Кроме этого, как уже указано выше, существуют ещё и скобки, про
которые ещё в школе изучают (по крайней мере раньше изучали, не
знаю, как сейчас ;-) )
> И все равно, даже для С++ перегруженность опрераций не позволяет
> перегргуппировывать операции, чтобы сначала сделать вещественную арифметику,
> а только потом комплексную. Транслятор для не встроенных типов данных это
> знать не может, и поэтому не посмеет выражение a*z*b сначала преобразовать к
> виду z*(a*b), а потом его вычислить.
Ещё раз - скобки.
>>Да и вообще - спорить об этом, это как про религию...
>
>
> Конечно, я просто за толерантность к инакомыслящим.
Есть инакомыслие - это когда иная точка зрения имеет серьёзное
основание и более или менее стройную теорию. Hапример, атеизм и
теизмы всякие: каждое направление построено на неком наборе
постулатов, которые проверить нельзя. Можно лишь убедиться в их
непротиворечивости по отношению к наблюдаемой реальности.
А есть ... как бы это ... Hу, неграмотность или невежество, что
ли... Это когда точка зрения оказывается ошибочной из-за незнания
этой самой реальности. Так вот, как мне кажется, тут как раз второй
случай.
>>P.S. Кстати, насчёт порядка в вычислениях: порядок в арифметическом
>>выражении есть закон для компилятора - не ему переопределять то, что
>>задано программистом. Иначе потом можно долго голову ломать, откуда
>>ошибки округления берутся.
>
>
> Hет, это не совсем так. В оптимизирующем компиляторе не надо разбивать
> длинные выражения на короткие, думая, что так будет эффективнее, не надо
> чистить циклы, не надо группировать выражения, не надо расставлять метки
> (это сужает область оптимизации) - надо поручить это компилятору, т.к. он
> это сделает эффективнее.
И/или кривее... Может, всё-таки будем опираться на стандарт, а не на
конкретную реализацию компилятора. А тот, который оптимизирует -
пусть он делает это только когда попросят, т.е. через опции.
--- ifmail v.2.15dev5.3
* Origin: CICESE Research Center, Ensenada, Mexico (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
