33-й бит результата сравнения

5 views
Skip to first unread message

Maxim Elkin

unread,
Nov 8, 2005, 1:14:53 PM11/8/05
to
Привет всем.

Можно ли, не опускаясь до ассемблера, в таком фрагменте
if (Key == m_k)
...
if (Key < m_k)
...
как-нибудь избавиться от двух сравнений одних и тех же чисел? Если разрядность
не превышает 31 бит, можно написать что-то вроде
int CmpRes = Key - m_k;
if (!CmpRes)
...
if (CmpRes < 0)
...
А если все 32? Красивого решения не существует?

Maxim

Stanislav Shwartsman

unread,
Nov 8, 2005, 4:44:26 PM11/8/05
to
Hello Maxim!

08 Nov 05 21:14, you wrote to All:

ME> Можно ли, не опускаясь до ассемблера, в таком фрагменте
ME> if (Key == m_k)
ME> ...
ME> if (Key < m_k)
ME> ...
ME> как-нибудь избавиться от двух сравнений одних и тех же чисел? Если
ME> разрядность не превышает 31 бит, можно написать что-то вроде int
ME> CmpRes = Key - m_k; if (!CmpRes)
ME> ...
ME> if (CmpRes < 0)
ME> ...
ME> А если все 32? Красивого решения не существует?

А смысл от него избавляться ?
Во первых, если расстояние между этими сравнениями не большое, то хороший
оптимизирующий компайлер может вообще убрать второе и посчитать
условия "меньше" и "равно" одной командой.

С точки зрения времени выполнения проблема это не сравнение, а лишний
условный переход, а от него можно уйти используя if-else потому как
если

if (Key < m_k)

то уже точно не будет if (Key == m_k) и наоборот.

Ты лучше скажи чего ты добиться пытаешься, может вообще лучше на
эти if'ы внимание обращать и заняться другой частью кода ?

Voice Phones: 972-4-8330554 (home), 972-5-4481073 (cell)

Bye ! [Team Intel Centrino Technology]
Stanislav (AKA Night's Man) [Team Technion]

Maxim Elkin

unread,
Nov 8, 2005, 9:44:31 PM11/8/05
to
Привет, Stanislav

09 Nov 05 00:44, you wrote to me:

ME>> А если все 32? Красивого решения не существует?

SS> А смысл от него избавляться ?
Двойная работа. Hехоpошо, даже если она только "на бумаге" (в исходнике). В
частности, лишний повод ошибиться.

SS> лишний условный переход, а от него можно уйти используя if-else
Я опустил else для повышения читабельности пpимеpа.

SS> Ты лучше скажи чего ты добиться пытаешься, может вообще лучше на
SS> эти if'ы внимание обращать и заняться другой частью кода ?
Да я и не замоpачиваюсь - но мне интеpесен ответ на свой вопpос ввеpху :)

Maxim

Andrew Ezhguroff

unread,
Nov 9, 2005, 5:34:53 AM11/9/05
to
Привет! "Maxim Elkin" <Maxim...@p1.f979.n5020.z2.fidonet.org>
сообщил(а):

ME> Можно ли, не опускаясь до ассемблера, в таком фрагменте
ME> if (Key == m_k)
ME> ...
ME> if (Key < m_k)
ME> ...

ME> как-нибудь избавиться от двух сравнений одних и тех же чисел? Если
ME> разрядность не превышает 31 бит, можно написать что-то вроде
ME> int CmpRes = Key - m_k;
ME> if (!CmpRes)


ME> ...
ME> if (CmpRes < 0)
ME> ...

ME> А если все 32? Красивого решения не существует?

#define Compare(Val1, Val2) ((Val1)<(Val2)? -1: (Val1)==(Val2)? 0: 1)

switch(Compare(Key, m_k)){
case 0:
...
case -1:
...
}

С уважением, Андрей.


--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Stanislav Shwartsman

unread,
Nov 9, 2005, 12:22:53 AM11/9/05
to
Hello Maxim!

09 Nov 05 05:44, you wrote to me:

ME>>> А если все 32? Красивого решения не существует?
SS>> А смысл от него избавляться ?

ME> Двойная работа. Hехоpошо, даже если она только "на бумаге" (в
ME> исходнике). В частности, лишний повод ошибиться.

ME> CmpRes = Key - m_k;


ME> if (!CmpRes)
ME> ...
ME> if (CmpRes < 0)
ME> ...

А это не двойная работа ? Что у тебя собственно изменилось ?
Только читабельность кода упала и все.

Stanislav Shwartsman

unread,
Nov 9, 2005, 11:41:02 AM11/9/05
to
Hello Andrew!

09 Nov 05 13:34, you wrote to Maxim Elkin:

ME>> Можно ли, не опускаясь до ассемблера, в таком фрагменте
ME>> if (Key == m_k)
ME>> ...
ME>> if (Key < m_k)
ME>> ...
ME>> как-нибудь избавиться от двух сравнений одних и тех же чисел? Если
ME>> разрядность не превышает 31 бит, можно написать что-то вроде

ME>> int CmpRes = Key - m_k;


ME>> if (!CmpRes)
ME>> ...
ME>> if (CmpRes < 0)
ME>> ...

ME>> А если все 32? Красивого решения не существует?

AE> #define Compare(Val1, Val2) ((Val1)<(Val2)? -1: (Val1)==(Val2)? 0: 1)

AE> switch(Compare(Key, m_k)){
AE> case 0:
AE> ...
AE> case -1:
AE> ...
AE> }

Интересно, а что тут красивого ?
Код получился практически не читабельный (попробуй догадайся связать -1
в case с фактом, что это означает, что key < m_k). И впридачу ни один
компайлер по нормальному это не соптимизирует.

Andrew Ezhguroff

unread,
Nov 9, 2005, 6:02:08 PM11/9/05
to
Привет! "Stanislav Shwartsman"
<Stanislav....@f520.n400.z2.fidonet.org> сообщил(а):

SS> Интересно, а что тут красивого ?
SS> Код получился практически не читабельный (попробуй догадайся связать
SS> -1в case с фактом, что это означает, что key < m_k).

Ф-ция, возвращающая по результатам сравнения (-1), 0, (+1) - это тривиальный
и достаточно часто встречающийся прием программирования.

И я не понимаю, какой квалификацией надо обладать, чтобы столь примитивный
макрос мог вызвать проблемы с читабельностью кода. :)

SS> И впридачу ни один
SS> компайлер по нормальному это не
SS> соптимизирует.

Покажи мне в исходном вопросе хоть одно слово про оптимизацию.

Maxim Elkin

unread,
Nov 9, 2005, 5:57:10 PM11/9/05
to
Пpивет, Stanislav

09 Nov 05 08:22, you wrote to me:

ME>> CmpRes = Key - m_k;
ME>> if (!CmpRes)
ME>> ...
ME>> if (CmpRes < 0)
ME>> ...

SS> А это не двойная работа ? Что у тебя собственно изменилось ?
Исчезло повтоpное вычитание.

Maxim

Stanislav Shwartsman

unread,
Nov 10, 2005, 12:17:01 AM11/10/05
to
Hello Andrew!

10 Nov 05 02:02, you wrote to me:

SS>> Интересно, а что тут красивого ?
SS>> Код получился практически не читабельный (попробуй догадайся

SS>> связать -1в case с фактом, что это означает, что key < m_k).

AE> Ф-ция, возвращающая по результатам сравнения (-1), 0, (+1) - это
AE> тривиальный и достаточно часто встречающийся прием программирования.

Если для того, чтобы это увидеть у меня потребуется хотя бы на секунду
больше времени - код стал менее читабельным. В данном случае мне
потребовалось больше секунд на 5.

AE> И я не понимаю, какой квалификацией надо обладать, чтобы столь
AE> примитивный макрос мог вызвать проблемы с читабельностью кода. :)

SS>> И впридачу ни один компайлер по нормальному это не
SS>> соптимизирует.

AE> Покажи мне в исходном вопросе хоть одно слово про оптимизацию.

А ну конечно, задача написать как можно более медленный и нечитаемый код :)
Тогда я пас !

ob

unread,
Nov 10, 2005, 1:37:52 PM11/10/05
to
Жму руку тебе, Maxim!

10 Nov 05 01:57 --> 10 Nov 05 21:37
Maxim Elkin (2:5020/979.1) --> Stanislav Shwartsman

ME>>> CmpRes = Key - m_k;
ME>>> if (!CmpRes)
ME>>> ...
ME>>> if (CmpRes < 0)
ME>>> ...
SS>> А это не двойная работа ? Что у тебя собственно изменилось ?

*ME*> Исчезло повтоpное вычитание.

Ну да, если сравнение это вычитание... А это далеко не всегда так... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]
... Мёртвые ожить не хотят ...

ob

unread,
Nov 10, 2005, 1:38:30 PM11/10/05
to
Жму руку тебе, Andrew!

10 Nov 05 02:02 --> 10 Nov 05 21:38
Andrew Ezhguroff (2:5020/400) --> Stanislav Shwartsman

SS>> Интересно, а что тут красивого ?
SS>> Код получился практически не читабельный (попробуй догадайся
SS>> связать -1в case с фактом, что это означает, что key < m_k).

*AE*> Ф-ция, возвращающая по результатам сравнения (-1), 0, (+1) - это
*AE*> тривиальный и достаточно часто встречающийся прием программирования.
Функция?.. Вполне может быть... Но за придумывание функции там, где её нет я
бы руки отрывал... ;-}

*AE*> И я не понимаю, какой квалификацией надо обладать, чтобы столь
*AE*> примитивный макрос мог вызвать проблемы с читабельностью кода. :)
Читабельность не зависит от квалификации... ;-}

SS>> И впридачу ни один компайлер по нормальному это не соптимизирует.
*AE*> Покажи мне в исходном вопросе хоть одно слово про оптимизацию.
Раньше оптимизация была самой главной целью изменения кода... Теперь это
тоже достаточно важно... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёpтвые не чувствуют боли ...

Maxim Elkin

unread,
Nov 10, 2005, 5:11:27 PM11/10/05
to
Пpивет, ob

10 Nov 05 21:37, you wrote to me:

o> Hу да, если сравнение это вычитание... А это далеко не всегда
o> так... ;-}
А как еще можно сpавнить?

Maxim

Andrew Ezhguroff

unread,
Nov 10, 2005, 6:37:15 PM11/10/05
to
Привет! "ob" <o...@p1368.f1368.n5030.z2.fidonet.org> сообщил(а):

o> Функция?.. Вполне может быть... Но за придумывание функции там, где
o> её нет я бы руки отрывал... ;-}

inline ф-ция (или макрос - как в моем примере) не уменьшает скорости работы
программы. :)

o> Читабельность не зависит от квалификации... ;-}

Но восприятие кода зависит. :)

o> Раньше оптимизация была самой главной целью изменения кода... Теперь
o> это тоже достаточно важно... ;-}

Оптимизация ради оптимизации - это бред. Оптимизировать имеет смысл только
несколько процентов кода. Еще раз - в исходном вопросе не было "как сделать
так, чтобы работало быстрее?", а было "имеется-ли красивое решение?".

ob

unread,
Nov 10, 2005, 11:01:38 PM11/10/05
to
Жму руку тебе, Andrew!

11 Nov 05 02:37 --> 11 Nov 05 07:01
Andrew Ezhguroff (2:5020/400) --> ob

o>> Функция?.. Вполне может быть... Hо за придумывание функции там, где


o>> её нет я бы руки отрывал... ;-}

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

o>> Читабельность не зависит от квалификации... ;-}

*AE*> Hо восприятие кода зависит. :)
Это как?.. Этот код люблю, от друго смеюсь, а третий тоску нагоняет?.. Ну
да, зависит... ;-}

o>> Раньше оптимизация была самой главной целью изменения кода... Теперь
o>> это тоже достаточно важно... ;-}

*AE*> Оптимизация ради оптимизации - это бред.
Молодец, согласен... ;-}

*AE*> Оптимизировать имеет смысл только несколько процентов кода.
Оптимизация это не только уменьшение времени выполнения, но зачастую и
просто упрощение кода... ;-}

*AE*> Еще раз - в исходном вопросе не было "как сделать так, чтобы
*AE*> работало быстрее?", а было "имеется-ли красивое решение?".
Значит макросы это украшения?.. ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые слушают меня ...

ob

unread,
Nov 10, 2005, 11:00:16 PM11/10/05
to
Жму руку тебе, Maxim!

11 Nov 05 01:11 --> 11 Nov 05 07:00
Maxim Elkin (2:5020/979.1) --> ob

o>> Hу да, если сравнение это вычитание... А это далеко не всегда
o>> так... ;-}

*ME*> А как еще можно сpавнить?

С помощью команды сравнения... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые ожить не хотят ...

Valentin Konovalov

unread,
Nov 10, 2005, 10:38:07 PM11/10/05
to
Hello ob.

10 Hоя 05 21:38, you wrote to Andrew Ezhguroff:


SS>>> И впридачу ни один компайлер по нормальному это не

SS>>> соптимизирует.


*AE*>> Покажи мне в исходном вопросе хоть одно слово про оптимизацию.

o> Раньше оптимизация была самой главной целью изменения кода...
o> Теперь это тоже достаточно важно... ;-}
Это не оптимизация, а, извиняюсь, хренотень. Оптимизация - это когда серьезно
повышается быстродействие юнита; а тут любой процессор, выпущенный после 1995
года разницы нифига не заметит.

... _/*CU, Valentin.*/_

Andrew Ezhguroff

unread,
Nov 11, 2005, 5:58:43 AM11/11/05
to
Привет! "ob" <o...@p1368.f1368.n5030.z2.fidonet.org> сообщил(а):

o>>> Функция?.. Вполне может быть... Hо за придумывание функции там, где
o>>> её нет я бы руки отрывал... ;-}

o> *AE*> inline ф-ция (или макрос - как в моем примере) не уменьшает
o> скорости *AE*> работы программы. :)
o> А, так ты из этих, из гонщиков?.. А ниже пишешь, что оптимизировать
o> мол надо только несколько процентов кода... Ты бы определился с
o> ориентацией... ;-} На самом деле читабельность в подавляющем большинстве
o> случаев важнее... ;-}

В таком случае, чем тебе дополнительные ф-ции не нравятся? Программа,
ЛОГИЧНО разбитая на множество небольших ф-ций, читабельнее программы,
состоящей из малого кол-ва громадных ф-ций. И выход из 3-х вложенных циклов
по return читабельнее, чем goto, или пачка дополнительных флагов в условии
цикла.

И вообще, читабельность куда больше зависит совсем от других факторов - от
форматирования исходников, от выбора "говорящих" имен идентификаторов
(венгерская нотация - это диверсия противников читабельности), от наличия
продуманных комментариев...

o>>> Читабельность не зависит от квалификации... ;-}

o> *AE*> Hо
o> восприятие кода зависит. :)
o> Это как?.. Этот код люблю, от друго
o> смеюсь, а третий тоску
o> нагоняет?.. Ну да, зависит... ;-}

Например, существует множество стилей форматирования исходников. И очевидно,
что незнакомый стиль вызовет у начинающего программиста трудности с чтением.

o> *AE*> Оптимизировать имеет смысл
o> только несколько процентов кода.
o> Оптимизация это не только
o> уменьшение времени выполнения, но зачастую
o> и просто упрощение кода...
o> ;-}

С точностью до наоборот. Обычно "быстрые" алгоритмы куда сложнее реализации
"в лоб". Например, "быстрый" вариант сортировки простым выбором - это
пирамидальная сортировка. Сравни сложность кода и время работы этих
алгоритмов.

o> *AE*> Еще раз - в исходном вопросе не было "как сделать так,
o> чтобы
o> *AE*> работало быстрее?", а было "имеется-ли красивое
o> решение?".
o> Значит макросы это украшения?.. ;-}

Макросы - удобный способ создания многоплатформенных исходников. И еще
способ компенсировать недостатки синтаксиса "классического" Си. А в
остальном - действительно украшения.

ob

unread,
Nov 12, 2005, 3:29:12 AM11/12/05
to
Жму руку тебе, Valentin!

11 Nov 05 06:38 --> 12 Nov 05 11:29
Valentin Konovalov (2:5060/90.3@fidonet) --> ob

SS>>>> И впридачу ни один компайлер по нормальному это не
SS>>>> соптимизирует.
*AE*>>> Покажи мне в исходном вопросе хоть одно слово про оптимизацию.
o>> Раньше оптимизация была самой главной целью изменения кода...
o>> Теперь это тоже достаточно важно... ;-}

*VK*> Это не оптимизация, а, извиняюсь, хренотень. Оптимизация - это когда
*VK*> серьезно повышается быстродействие юнита; а тут любой процессор,
*VK*> выпущенный после 1995 года разницы нифига не заметит.

С этим не ко мне, я никакую оптимизацию не предлагал... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые за углом стоят ...

ob

unread,
Nov 12, 2005, 3:29:52 AM11/12/05
to
Жму руку тебе, Dmitry!

11 Nov 05 11:37 --> 12 Nov 05 11:29
Dmitry Grebeniuk (2:469/105) --> ob

*AE*>>> Ф-ция, возвращающая по результатам сравнения (-1), 0, (+1) -

*AE*>>> это тривиальный и достаточно часто встречающийся
*AE*>>> прием программирования.


o>> Функция?.. Вполне может быть... Hо за придумывание функции там,

o>> где её нет я бы руки отрывал... ;-}
*DG*> Да! Внатури! В реальности нет функций, кроме main -- и в коде не
*DG*> должно быть! Даёшь сплошной поток инструкций! Даёшь пятилетку за
*DG*> четыре года!

Очень смешно... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые мало говорят ...

ob

unread,
Nov 12, 2005, 3:30:16 AM11/12/05
to
Жму руку тебе, Andrew!

11 Nov 05 13:58 --> 12 Nov 05 11:30


Andrew Ezhguroff (2:5020/400) --> ob

o>>>> Функция?.. Вполне может быть... Hо за придумывание функции
o>>>> там, где её нет я бы руки отрывал... ;-}


o> *AE*>> inline ф-ция (или макрос - как в моем примере) не уменьшает
o>> скорости *AE*> работы программы. :)
o>> А, так ты из этих, из гонщиков?.. А ниже пишешь, что

o>> оптимизировать мол надо только несколько процентов кода... Ты бы
o>> определился с ориентацией... ;-} Hа самом деле читабельность в
o>> подавляющем большинстве случаев важнее... ;-}
*AE*> В таком случае, чем тебе дополнительные ф-ции не нравятся?
*AE*> Программа, ЛОГИЧHО разбитая на множество небольших ф-ций,
*AE*> читабельнее программы, состоящей из малого кол-ва громадных ф-ций.
Ну сейчас... Часть кода выносится в отдельную функция не исходя из числа
строчек, а исходя из логики работы программы и закончености этой части кода как
функции... И если у меня функция init_hw() будет на несколько экранов, но
вызывается один раз при инициализации и действительно инициализирует аппаратную
часть, то я скорее всего разбивать её на составные функции не стану... ;-}

*AE*> И выход из 3-х вложенных циклов по return читабельнее, чем goto, или
*AE*> пачка дополнительных флагов в условии цикла.
Наивный... Я про goto... Если ты выйдешь по return, то часть функции по
обработке каких-то ошибок, например, вынесешь в другую функцию... ;-}

*AE*> И вообще, читабельность куда больше зависит совсем от других факторов
*AE*> - от форматирования исходников,
Не от форматирования, а от стиля и его наличия... Я могу замечательно всё
отформатировать, но каждую функцию в своём стиле... ;-}

*AE*> от выбора "говорящих" имен идентификаторов (венгерская нотация - это
*AE*> диверсия противников читабельности),
По поводу венгерской нотации согласен... ;-}

*AE*> от наличия продуманных комментариев...
Заканчиваешь правильно... ;-}

o>>>> Читабельность не зависит от квалификации... ;-}
o> *AE*>> Hо
o>> восприятие кода зависит. :)
o>> Это как?.. Этот код люблю, от друго
o>> смеюсь, а третий тоску

o>> нагоняет?.. Hу да, зависит... ;-}
*AE*> Hапример, существует множество стилей форматирования исходников. И
*AE*> очевидно, что незнакомый стиль вызовет у начинающего программиста
*AE*> трудности с чтением.
Это трудности начинающего программиста, пусть набирается опыта... Существет
ещё такое понятие как корпоративный стиль... И придерживаться его обязан любой
сотрудник данной организации, даже если он начинающий программист... Или ты
опенсорсник?.. А может вообще ориентироваться на школьников и студентов, чтобы
у них не возникало трудностей?.. ;-}

o> *AE*>> Оптимизировать имеет смысл
o>> только несколько процентов кода.
o>> Оптимизация это не только
o>> уменьшение времени выполнения, но зачастую
o>> и просто упрощение кода...
o>> ;-}

*AE*> С точностью до наоборот. Обычно "быстрые" алгоритмы куда сложнее
*AE*> реализации "в лоб". Hапример, "быстрый" вариант сортировки простым
*AE*> выбором - это пирамидальная сортировка. Сравни сложность кода и время
*AE*> работы этих алгоритмов.
Сравни сложность сопровождения программы со стандартными библиотечными
функциями и с самописными реализациями "быстрых" алгоритмов... А если эти
"быстрые" алгоритмы сортировки сортируют массив из десяти элементов, то точно
надо брать молоток... ;-}

o> *AE*>> Еще раз - в исходном вопросе не было "как сделать так,
o>> чтобы
o> *AE*>> работало быстрее?", а было "имеется-ли красивое
o>> решение?".
o>> Значит макросы это украшения?.. ;-}

*AE*> Макросы - удобный способ создания многоплатформенных исходников. И
*AE*> еще способ компенсировать недостатки синтаксиса "классического" Си.
*AE*> А в остальном - действительно украшения.
Так вот, многоплатформенность можно реализовать далеко не только при помощи
макросов, а макросы можно использовать далеко не только для создания
многоплатформенных исходников... И недостатки какие-то припутал... Прямо
детский лепет... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые ожить не хотят ...

Andrew Aksyonoff

unread,
Nov 11, 2005, 12:50:48 PM11/11/05
to
ehlo.

[ 11 Nov 05, 07:01 ] ob -> Andrew Ezhguroff:
o> Жму руку тебе, Andrew!
o> 11 Nov 05 02:37 --> 11 Nov 05 07:01
o> Andrew Ezhguroff (2:5020/400) --> ob
[skip]
o> LPS: Hе стоит принимать близко к сердцу мой бред...
o> Руку отпускаю, пока. ob.
o> [*Соседи спят спокойно*]
o> [_/Necromant's Voice team/_] [*451 F*] [/_Death after Life team_/]
o> ... Мёртвые слушают меня ...
o> --- GoldED+/W32 1.1.4.7
o> * Origin: Moderator of live-n-loud.mp3 [punk/oi/hc/ska]
o> (2:5030/1368.1368)

тебе сколько лет?

--
shodan

ob

unread,
Nov 12, 2005, 10:58:34 AM11/12/05
to
Жму руку тебе, Andrew!

11 Nov 05 20:50 --> 12 Nov 05 18:58
Andrew Aksyonoff (2:5025/3.286) --> ob

*AA*> тебе сколько лет?

Хочешь меня совратить?.. Иди подрочи... ;-}

*AA*> shodan

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]

[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

Andrew Ezhguroff

unread,
Nov 12, 2005, 8:30:38 PM11/12/05
to
Привет! "ob" <o...@p1368.f1368.n5030.z2.fidonet.org> сообщил(а):

o> *AE*> В таком случае, чем тебе дополнительные ф-ции не нравятся?
o> *AE*> Программа, ЛОГИЧHО разбитая на множество небольших ф-ций,
o> *AE*> читабельнее программы, состоящей из малого кол-ва громадных ф-ций.
o> Ну сейчас... Часть кода выносится в отдельную функция не исходя из
o> числа строчек, а исходя из логики работы программы и закончености этой
o> части кода как функции...

Именно это я и сказал - "ЛОГИЧHО разбитая".

o> И если у меня функция init_hw() будет на
o> несколько экранов, но
o> вызывается один раз при инициализации и
o> действительно инициализирует
o> аппаратную часть, то я скорее всего
o> разбивать её на составные функции
o> не стану... ;-}

Еще раз - "ЛОГИЧHО разбитая". И с чего ты взял, что говоря о небольшой ф-ции
я имел в виду именно 1 экран?

Огромная (и единая) секция инициализации характерна для Фортрана-4. Но если
мы продолжаем говорить о Си, то нетривиальный инициализатор удобнее разбить
на секции-подпрограммы. Если же это просто присвоение значений
полям/переменным, то огромная ф-ция такого назначения в Си-программе - это
очевидный показатель неквалифицированности программиста и/или идеолога
проекта.

И уж совершенно бредово это выглядит на С++, где вся нетривиальная
инициализация выносится в конструкторы классов.

o> *AE*> И выход из 3-х вложенных циклов по return
o> читабельнее, чем goto,
o> или *AE*> пачка дополнительных флагов в условии
o> цикла.
o> Наивный... Я про goto... Если ты выйдешь по return, то часть
o> функции
o> по обработке каких-то ошибок, например, вынесешь в другую
o> функцию... ;-}

Следовательно, ты не знаешь, как программировать подобные конструкции. В
этих подпрограммах return'ов всего ДВА - один в самом вложенном цикле,
второй - после всех циклов. Соответственно, один return (и расположенный
перед ним код) выполняется в случае удачного исхода, второй - в случае
неудачного. Никаких проблем с обработками ошибок не возникает.

Если же взять C++, то там для обработки ошибок есть специальные операторы.
:)

o> *AE*> И вообще, читабельность куда больше зависит
o> совсем от других
o> факторов *AE*> - от форматирования исходников,
o> Не
o> от форматирования, а от стиля и его наличия... Я могу замечательно
o> всё
o> отформатировать, но каждую функцию в своём стиле... ;-}

Я же говорю о психически нормальных программистах, а не о клинических
случаях. :)

o> *AE*> Hапример, существует множество
o> стилей форматирования исходников. И
o> *AE*> очевидно, что незнакомый
o> стиль вызовет у начинающего программиста
o> *AE*> трудности с чтением.
o> Это трудности начинающего программиста, пусть набирается опыта...

Что такое "однострочник" на APL, ты представляешь? Но и на Си можно написать
в таком стиле, что самый опытный программист несколько часов в коротенькой
программе разбираться будет.

o> Существет ещё такое понятие как корпоративный стиль... И придерживаться
o> его обязан любой сотрудник данной организации, даже если он
o> начинающий
o> программист... Или ты опенсорсник?.. А может вообще
o> ориентироваться на
o> школьников и студентов, чтобы у них не возникало
o> трудностей?.. ;-}

А что, кроме крупных корпораций и OpenSource, ты других моделей организации
работы программистов ты не знаешь?

o> Сравни сложность
o> сопровождения программы со стандартными
o> библиотечными функциями и с
o> самописными реализациями "быстрых"
o> алгоритмов... А если эти "быстрые"
o> алгоритмы сортировки сортируют массив
o> из десяти элементов, то точно
o> надо брать молоток... ;-}

Во первых, "стандартные библиотечные функции" не имеют никакого отношения к
твоей фразе, что "оптимизация это <...> зачастую и просто упрощение кода". Я
тебе привел элементарное опровержение, а ты зачем-то полез в "сложность
сопровождения программы". Один раз отлаженный алгоритм сортировки вообще не
требует сопровождения.

Во вторых, если ты всегда используешь именно "стандартную библиотечную
функцию", то это именно ты будешь сортировать 10 элементов QuickSort'ом. :)

В третьих, попробуй воспользоваться "стандартной библиотечной функцией" в
реализации алгоритма BWT. А потом расскажешь, сколько часов твой архиватор
сжимал "Войну и Мир". :)

o> *AE*> Макросы - удобный способ создания
o> многоплатформенных исходников. И
o> *AE*> еще способ компенсировать
o> недостатки синтаксиса "классического"
o> Си. *AE*> А в остальном -
o> действительно украшения.
o> Так вот, многоплатформенность можно
o> реализовать далеко не только при
o> помощи макросов, а макросы можно
o> использовать далеко не только для
o> создания многоплатформенных
o> исходников... И недостатки какие-то
o> припутал... Прямо детский лепет...
o> ;-}

Конкретнее, плиз. А то у тебя только общие фразы и ни одного примера.

Забудем о многоплатформенности и рассмотрим, для чего еще используются
макросы:

1. Макросы приходится использовать из-за того, что в Си нет нормальных
констант (не надо про квалификатор const - это только внешнее подобие
констант).

2. Макросы приходится использовать из-за отсутствия в Си параметризированных
ф-ций. Из-за чего приходится либо плодить кучу ф-ций для разных типов
аргументов, либо пользоваться "#define Max(a, b) ((a)>=(b)? (a): (b))" с
очевидными проблемами в вызовах вида Max(x++, y--).

3. Макросы приходится использовать из-за отсутствия в Си inline-функций.

Все 3 случая - это именно очевидные недостатки языка Си (частично
исправленные в C++), которые приходится "обходить" с помощью макросов.

ob

unread,
Nov 13, 2005, 4:39:34 AM11/13/05
to
Жму руку тебе, Andrew!

13 Nov 05 04:30 --> 13 Nov 05 12:12


Andrew Ezhguroff (2:5020/400) --> ob

o> *AE*>> В таком случае, чем тебе дополнительные ф-ции не нравятся?


o> *AE*>> Программа, ЛОГИЧHО разбитая на множество небольших ф-ций,
o> *AE*>> читабельнее программы, состоящей из малого кол-ва громадных

o> *AE*>> ф-ций.
o>> Hу сейчас... Часть кода выносится в отдельную функция не исходя
o>> из числа строчек, а исходя из логики работы программы и
o>> закончености этой части кода как функции...
*AE*> Именно это я и сказал - "ЛОГИЧHО разбитая".
Да видел я как ты на функции разбиваешь, два if'а -- это уже функция...
Очень логично... ;-}

o>> И если у меня функция init_hw() будет на несколько экранов, но
o>> вызывается один раз при инициализации и действительно инициализирует
o>> аппаратную часть, то я скорее всего разбивать её на составные функции
o>> не стану... ;-}
*AE*> Еще раз - "ЛОГИЧHО разбитая". И с чего ты взял, что говоря о
*AE*> небольшой ф-ции я имел в виду именно 1 экран?
Читай выше... ;-}

[тут паслись слоники]

o> *AE*>> И выход из 3-х вложенных циклов по return
o>> читабельнее, чем goto,
o> или *AE*>> пачка дополнительных флагов в условии
o>> цикла.

o>> Hаивный... Я про goto... Если ты выйдешь по return, то часть


o>> функции
o>> по обработке каких-то ошибок, например, вынесешь в другую
o>> функцию... ;-}

*AE*> Следовательно, ты не знаешь, как программировать подобные
*AE*> конструкции.
Конечно, не знаю, о великий, преклоняюсь пред тобою... ;-}

[тут паслись слоники]

o> *AE*>> И вообще, читабельность куда больше зависит
o>> совсем от других
o>> факторов *AE*> - от форматирования исходников,

o>> Hе


o>> от форматирования, а от стиля и его наличия... Я могу замечательно
o>> всё
o>> отформатировать, но каждую функцию в своём стиле... ;-}

*AE*> Я же говорю о психически нормальных программистах, а не о
*AE*> клинических случаях. :)
Если судить по тебе, то о психически нормальных программистах ты можешь
только говорить... ;-}

o> *AE*>> Hапример, существует множество
o>> стилей форматирования исходников. И
o> *AE*>> очевидно, что незнакомый
o>> стиль вызовет у начинающего программиста
o> *AE*>> трудности с чтением.
o>> Это трудности начинающего программиста, пусть набирается опыта...

*AE*> Что такое "однострочник" на APL, ты представляешь?
О гуру, как давишь ты меня сирого своим могучим интеллектом... ;-}

[тут паслись слоники]

o>> Существет ещё такое понятие как корпоративный стиль... И

o>> придерживаться его обязан любой сотрудник данной организации, даже
o>> если он начинающий программист... Или ты опенсорсник?.. А может
o>> вообще ориентироваться на школьников и студентов, чтобы у них не
o>> возникало трудностей?.. ;-}
*AE*> А что, кроме крупных корпораций и OpenSource, ты других моделей
*AE*> организации работы программистов ты не знаешь?
Про крупные корпорации я не говорил... Даже в команде из 2-3 программистов
следует придерживаться корпоративного стиля... А конченых опенсорсников я с
детства не люблю... ;-}

o>> Сравни сложность сопровождения программы со стандартными
o>> библиотечными функциями и с самописными реализациями "быстрых"
o>> алгоритмов... А если эти "быстрые" алгоритмы сортировки сортируют
o>> массив из десяти элементов, то точно надо брать молоток... ;-}
*AE*> Во первых, "стандартные библиотечные функции" не имеют никакого
*AE*> отношения к твоей фразе, что "оптимизация это <...> зачастую и
*AE*> просто упрощение кода".
Зачастую... ;-}

*AE*> Я тебе привел элементарное опровержение, а ты зачем-то полез в
*AE*> "сложность сопровождения программы".
Знаешь, если выбирать между лёгким сопровождением и крутой оптимизацией, то
любой, как ты его называешь, психически нормальный программист выбирает
первое... Вот об этом я тебе и говорю... ;-}

*AE*> Один раз отлаженный алгоритм сортировки вообще не требует
*AE*> сопровождения.
Фантазёр-теоретик?.. ;-}

[тут паслись слоники]

o> *AE*>> Макросы - удобный способ создания
o>> многоплатформенных исходников. И
o> *AE*>> еще способ компенсировать
o>> недостатки синтаксиса "классического"
o> Си. *AE*>> А в остальном -
o>> действительно украшения.

o>> Так вот, многоплатформенность можно реализовать далеко не только
o>> при помощи макросов, а макросы можно использовать далеко не только для
o>> создания многоплатформенных исходников... И недостатки какие-то
o>> припутал... Прямо детский лепет... ;-}
*AE*> Конкретнее, плиз. А то у тебя только общие фразы и ни одного
*AE*> примера.
Условная компиляция на разных уровнях... Я вообще люблю, когда
платформо-зависимый код разнесён по разным директориям... ;-}

[тут паслись слоники]

PS1: Извини, поскипал твою ахинею, некогда мне в твоём бреде копаться...
Изначально разговор вёлся в первом абзаце... ;-} PS2: Играющих тренеров я
вообще не люблю, особенно тех, что не играют... Я, конечно, понимаю, что и они
нужны, раз уж их создала природа, но не люблю... ;-}

PS3: А то, что ты си++ начал припутывать так вообще занятно... ;-}

Andrew Aksyonoff

unread,
Nov 13, 2005, 8:57:41 AM11/13/05
to
ehlo.

[ 13 Nov 05, 04:30 ] Andrew Ezhguroff -> ob:
AE> Еще раз - "ЛОГИЧHО разбитая". И с чего ты взял, что говоря о небольшой
AE> ф-ции я имел в виду именно 1 экран?

зачем ты с этим чудом споришь?

--
shodan

Andrew Aksyonoff

unread,
Nov 13, 2005, 8:57:25 AM11/13/05
to
ehlo.

[ 12 Nov 05, 18:58 ] ob -> Andrew Aksyonoff:
AA>> тебе сколько лет?
o> Хочешь меня совратить?.. Иди подрочи... ;-}

с возрастом все понятно, спасибо.

--
shodan

Andrew Ezhguroff

unread,
Nov 13, 2005, 12:40:38 PM11/13/05
to
Привет! "ob" <o...@p1368.f1368.n5030.z2.fidonet.org> сообщил(а):

o> *AE*> Именно это я и сказал - "ЛОГИЧHО разбитая".
o> Да видел я как ты на функции разбиваешь, два if'а -- это уже
o> функция... Очень логично... ;-}

Н-да... Как реализовать выход из вложенных циклов через return, ты не
знаешь... Зачем нужны ф-ции из 2-х операторов, ты не понимаешь... Не одного
конкретного возражения привести не можешь (только поток демагогии и
хамства)... Свой возраст назвать боишься...

Хочешь спорить - приводи конкретные аргументы. Но для этого, мальчик, тебе
необходимо немного подучиться (и программированию и умению вести дискуссии).

N.B. Для справки - я программированием занимаюсь 20 лет, из них на Си -
около 16.

Ivan Kuvshinov

unread,
Nov 13, 2005, 1:41:36 PM11/13/05
to
AE> Оптимизация ради оптимизации - это бред. Оптимизировать имеет смысл
AE> только несколько процентов кода.
Человек очень быстро самообучается и набив руку на оптимизации всего и вся (в
частности просто интуитивно интерсных моментов (важных для его стиля)) - он
становится намного умней и опытней, а стиль его _естественного_ и
непринуждённого кода становится таким, как если бы новичёк думал над
оптимизацией каждой конструкции весь день и при этом не прилагается никаких
дополнительных усилий. Это всё равно что в технике покупать разные наборы
инструмента, хотя всё можно сделать кувалдой, пассатижами, одной отвёрткой и
такой-то матери. ;-)
Hу а спорить о том, что более быстрый в среднем код, никому не нужен, потому
что просто быстрее никому не нужно - это уж точно бред.

КИА

Andrew Ezhguroff

unread,
Nov 13, 2005, 2:39:44 PM11/13/05
to
Привет! "Andrew Aksyonoff" <Andrew.A...@p286.f3.n5025.z2.fidonet.org>
сообщил(а):

AA> зачем ты с этим чудом споришь?

Ты прав. Но я надеялся, что он будет все же более адекватен.

ob

unread,
Nov 13, 2005, 2:28:26 PM11/13/05
to
Жму руку тебе, Andrew!

13 Nov 05 20:40 --> 13 Nov 05 21:25


Andrew Ezhguroff (2:5020/400) --> ob

o> *AE*>> Именно это я и сказал - "ЛОГИЧHО разбитая".


o>> Да видел я как ты на функции разбиваешь, два if'а -- это уже
o>> функция... Очень логично... ;-}

*AE*> H-да... Как реализовать выход из вложенных циклов через return, ты
*AE*> не знаешь...
Я этого не говорил... Я только сказал, что если обработка ошибок в функции
будет произведена в конце, (а в функции может быть и не один вложенный цикл, а
значит и ошибок, требущих обработки; только вот обработка может быть
одинаковая), то это будет более правильно... ;-}

*AE*> Зачем нужны ф-ции из 2-х операторов, ты не понимаешь...
Я то понимаю, но если отталкиваться от исходного вопроса, то нет смыла
городить неочевидный макрос... Если исходник большой, то макрос надо будет
искать, может быть даже в другом файле... А если этот макрос будет
использоваться один раз, то он вообще не имеет право на существование... ;-}

*AE*> Hе одного конкретного возражения привести не можешь (только поток
*AE*> демагогии и хамства)...
Не не могу, а не хочу... Ты же программист авторитетный, сам разберёшься...
;-}

*AE*> Свой возраст назвать боишься...
Не имею желания... ;-}

*AE*> Хочешь спорить - приводи конкретные аргументы.
Начни с себя... Кроме голословных утверждений и обвинения меня в
некомпетентности ты ничего сказать не можешь... ;-}

*AE*> Hо для этого, мальчик, тебе необходимо немного подучиться (и
*AE*> программированию и умению вести дискуссии).
;-}

*AE*> N.B. Для справки - я программированием занимаюсь 20 лет, из них на Си
*AE*> - около 16.
Ну ладно, давай пиписьками меряться... ;-} Я программированием занимаюсь 15
лет, из них профессионально и на Си (если тебе так Си важен) -- примерно 10...
Это ничего что короче, в этом деле толщина важнее... ;-}

PS1: Погуглил я твоё имя, поулыбался... ;-} Меня, кстати, тоже в гугле можно
найти на первой странице, хотя моя фамилия гораздо более распространённая и не
люблю я афишироваться... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые ходят не спеша ...

Andrew Ezhguroff

unread,
Nov 13, 2005, 4:27:12 PM11/13/05
to
Привет! "Ivan Kuvshinov" <Ivan.Ku...@p10110.f830.n5020.z2.fidonet.org>
сообщил(а):

AE>> Оптимизация ради оптимизации - это бред. Оптимизировать имеет смысл
AE>> только несколько процентов кода.

IK> Человек очень быстро самообучается и набив руку на оптимизации всего и
IK> вся (в частности просто интуитивно интерсных моментов (важных для его
IK> стиля)) - он становится намного умней и опытней, а стиль его
IK> _естественного_ и непринуждённого кода становится таким, как если бы
IK> новичёк думал над оптимизацией каждой конструкции весь день и при этом
IK> не прилагается никаких дополнительных усилий.

Разумеется, в большинстве случаев опытный программист "с ходу" напишет более
эффективный код, чем новичок. Но я имел в виду другое -оптимизацию
используемых в программе алгоритмов.

IK> Это всё равно что в
IK> технике покупать разные наборы инструмента, хотя
IK> всё можно сделать
IK> кувалдой, пассатижами, одной отвёрткой и такой-то
IK> матери. ;-)

В таком случае, надо начинать с выбора языка программирования под конкретную
задачу. Базовый набор инструментов - это именно язык программирования.

IK> Hу а спорить о том, что более быстрый в среднем код,
IK> никому не нужен,
IK> потому что просто быстрее никому не нужно - это уж
IK> точно бред.

Предположим, при оптимизации программы изменение 5% кода приводит к
уменьшению времени работы программы в 4 раза, оптимизация остальных 95% кода
приводит к уменьшению времени работы программы на 2%. Вопрос - имеет-ли
смысл тратить силы и деньги на оптимизацию этих самых 95%?

Кроме того, есть класс задач, для которых "быстрее" действительно никому не
нужно - это программы, интерактивно взаимодействующие с пользователем. Ну
какая разница, среагирует она на нажатие Enter через 1, или через 2 ms?
Главное, чтобы время реакции было психологически комфортным.

Stanislav Shwartsman

unread,
Nov 13, 2005, 3:38:53 PM11/13/05
to
Hello ob!

13 Nov 05 22:28, you wrote to Andrew Ezhguroff:

o> PS1: Погуглил я твоё имя, поулыбался... ;-}

А что, между прочим примерно в 15 раз больше линков, чем на твое имя ...

o> Меня, кстати, тоже в гугле можно найти на первой странице, хотя моя
o> фамилия гораздо более распространённая и не люблю я афишироваться...
o> ;-}

Да не такая уж и распространенная ...

Кстати, из принципа проверил в google и по имени "Oleg Bolshakov" ничего
выдающегося не обнаружил. Преимущественно FIDO RU.ASM.CHANINIK,
в котором наверно твои знания никак не проявляются :(

Из всех серьезных форумов увидел только QNX.ORG.RU, но и там ты
тоже отличился. Цитирую:

"В связи с хамским поведением пользователю ob1 доступ к форуму
заблокирован.

Причиной послужили его хамские выпады в адрес участников сайта. Ради
развлечения таких пользователей держать можно, но всему есть предел."

o> LPS: Hе стоит принимать близко к сердцу мой бред...

А я и не принимаю ...

P.S. А ведь так хорошо начал разговор ... и так быстро скатился на
элементраное хамство. У тебя это всегда так или просто тебе
в этот раз действительно сказать нечего ?

Andrew Aksyonoff

unread,
Nov 13, 2005, 11:07:29 PM11/13/05
to
ehlo.

[ 13 Nov 05, 23:38 ] Stanislav Shwartsman -> ob:
SS> P.S. А ведь так хорошо начал разговор ...

не заметил.

может у меня какие-то письма порезались?

--
shodan

ob

unread,
Nov 14, 2005, 12:08:58 AM11/14/05
to
Жму руку тебе, Stanislav!

13 Nov 05 23:38 --> 14 Nov 05 08:08
Stanislav Shwartsman (2:400/520) --> ob

o>> PS1: Погуглил я твоё имя, поулыбался... ;-}

*SS*> А что, между прочим примерно в 15 раз больше линков, чем на твое
*SS*> имя ...
Две трети из них -- как установить винду 95 на ega, и примерно треть -- как
это сделать более простым способом (от другого автора, естественно)... ;-}

o>> Меня, кстати, тоже в гугле можно найти на первой странице, хотя моя
o>> фамилия гораздо более распространённая и не люблю я афишироваться...
o>> ;-}

*SS*> Да не такая уж и распространенная ...
Да ну?.. ;-}

*SS*> Кстати, из принципа проверил в google и по имени "Oleg Bolshakov"
*SS*> ничего выдающегося не обнаружил. Преимущественно FIDO
*SS*> RU.ASM.CHANINIK, в котором наверно твои знания никак не проявляются
*SS*> :(
Ой, наверно... ;-}

*SS*> Из всех серьезных форумов увидел только QNX.ORG.RU, но и там ты
*SS*> тоже отличился. Цитирую:
Там у них свои проблемы... ;-}

[тут паслись слоники]

*SS*> P.S. А ведь так хорошо начал разговор ... и так быстро скатился на
*SS*> элементраное хамство. У тебя это всегда так или просто тебе
*SS*> в этот раз действительно сказать нечего ?
Это от собеседника зависит... ;-}

LPS: Не стоит принимать близко к сердцу мой бред...

Руку отпускаю, пока. ob.
[*Соседи спят спокойно*]
[_/Necromant's Voice team/_] [*451°F*] [/_Death after Life team_/]

... Мёртвые с кошками стоят ...

Igor Krassikov

unread,
Nov 17, 2005, 12:24:00 AM11/17/05
to
Hello Andrew!
20:40 13 Nov 05, Andrew Ezhguroff -> ob:
AE> N.B. Для справки - я программированием занимаюсь 20 лет, из них на Си
AE> - около 16.

... а пиписьками меряешься, как в первом классе :( ...

Как хорошо сказано в Coding Standards Саттера-Александреску - не мелочитесь
при стандартизации. Выносить 3 строки в виде функции или нет - это вопрос явно
не принципиальный...

Что до стажа :), то интересно смотреть, как считавшиеся еще лет 5 назад
истины в последней инстанции сегодня оказываются... ну, скажем так, под очень
большим сомнением... Причем зачастую все возвращается на круги своя :)

Best regards.
Igor

Ivan Kuvshinov

unread,
Nov 18, 2005, 4:02:10 PM11/18/05
to
IK>> стиль его _естественного_ и непринуждённого кода становится таким,
IK>> как если бы новичёк думал над оптимизацией каждой конструкции весь
IK>> день и при этом не прилагается никаких дополнительных усилий.
AE> Разумеется, в большинстве случаев опытный программист "с ходу" напишет
AE> более эффективный код, чем новичок. Hо я имел в виду другое
AE> -оптимизацию используемых в программе алгоритмов.
Я тоже имел ввиду не только "фишки", это как в физике и математике: формулы
одни с точностью до литер, а видя схожесть формул - знаешь куда "копать" в
каждом конкретном случае. Hу и потом, программы строятся из "кирпичиков" -
типовых кирпичиков, которые нарабатывает каждый сам для себя. Фактически из
процедур и функций строится новый метаязык в каждой программе, это может
происходить разными путями, но безусловно для одного индивидуума такой путь
"восхождения" - это протоптанная дорожка проходящая по подобным ступенькам и
то, что это за ступеньки: напрямую зависит от предъидущего опыта программиста.
Там где опытный программист будет автоматически делать циклы не содержащие
ничего ненужного, новичёк будет лепить циклы, за пределы которых не мешало бы
кое-чего вынести. И это, как ни странно экономит время, потому что человек,
набивший руку на оптимизации, заранее предчувствует какое построение программы
может дать трудности в будущем, а переделывать придётся полностью всё с нуля, и
выбирает более безопасный вариант, а вот новичёк, скорее всего реализует самый
прямой вариант и столкнётся с фундаментальными трудностями на этапе когда уже
ничего изменить не переписав по новой - нельзя.

IK>> кувалдой, пассатижами, одной отвёрткой и такой-то
IK>> матери. ;-)

AE> В таком случае, надо начинать с выбора языка программирования под
AE> конкретную задачу. Базовый набор инструментов - это именно язык
AE> программирования.
Безусловно. Hо.. - все мы люди со своими заскоками и иррациональными: "не
хочу, потому что - не хочу" :-) И на самом деле - это логично, потому что,
возможность творить и причастность к искуству притягательны сами по себе, а
лабать что-нибудь тупое и примитивное на высокоразвитом передовом языке - никто
не хочет, вот и создают себе любимчиков - эдакая любимая дырявая тряпочка для
протирки полотна, без которой процесс не заладиться сразу. Вот и получаем -
украшение финтифлюшками любимого болота. Вот только - стоит ли на этом
заострять внимание, если получен положительный результат? Пусть будут и
пряники, пока человек ещё занимает центральное место в программировании.

IK>> потому что просто быстрее никому не нужно - это уж
IK>> точно бред.

AE> Предположим, при оптимизации программы изменение 5% кода приводит к
AE> уменьшению времени работы программы в 4 раза, оптимизация остальных
AE> 95% кода приводит к уменьшению времени работы программы на 2%.
Вопрос: на какой машине 2 процента и в 4 раза? А на вдвое более слабой, ты
уверен, что будут те же 2 процента и 4 раза? Hе стоит забывать, что разные
блоки программы непропорционально будут отъедать время при варьировании
производительности компов.
Вот у меня есть программка для просмотра lbx ресурсов, так она анимацию
показывает "бегущей волной" на Pentium 233МГц MMX, каково же было моё
удивление, когда ситуация ни чуть не изменилась и на 2.4ГГц с хорошей AGP
карточкой. :-) Это уже пример на "другую оптимизацию" - на вопрос: "а стОит
ли"? А если его поставить по другому: "а кто будет решать - что именно стОит"?

AE> Вопрос
AE> - имеет-ли смысл тратить силы и деньги на оптимизацию этих самых 95%?
Речь шла о том, что код уже получается оптимизированным (в среднем - доводка
всё равно будет нужна) при изначальном создании - без дополнительных усилий.

AE> пользователем. Hу какая разница, среагирует она на нажатие Enter через
AE> 1, или через 2 ms? Главное, чтобы время реакции было психологически
AE> комфортным.
Вот именно, до поры до времени можно и файлы по одному из папки в папку
таскать, не испоьзуя выделения. Hо только до поры.. - комфортно.
Я объясню свою позицию так: есть очень широкий ряд програм, которые
балансировали на грани фола по комфортности от производительности, но - им
прощали, потому, что все знали - будет новое железо и будет с ними всё по
другому. Когда стало новое железо - стали и новые программы, а старые - всё так
же тормозили и уже на новом железе, потому что дело было не в нём, а в "какой
разнице" съигравшей на самих алгоритмах. Мораль, думаю - ясна.

КИА

Andrey Tarasevich

unread,
Nov 18, 2005, 7:48:41 PM11/18/05
to
Tue Nov 08 2005 20:14, Maxim Elkin wrote to All:

ME> Можно ли, не опускаясь до ассемблера, в таком фрагменте
ME> if (Key == m_k)
ME> ...
ME> if (Key < m_k)
ME> ...
ME> как-нибудь избавиться от двух сравнений одних и тех же чисел? Если
ME> разрядность не превышает 31 бит, можно написать что-то вроде int CmpRes =
ME> Key - m_k;
ME> if (!CmpRes)
ME> ...
ME> if (CmpRes < 0)
ME> ...
ME> А если все 32? Красивого решения не существует?

Hе совсем понимаю задачу. Сравнений-то в твоем последнем примере (в if-ах) все
равно осталось 2. Что же имеется в виду под сравнениями?

if в С/С++ осуществляет бинарное ветвление, поэтому как ни крути, чтобы
организовать ветвление на 3 ветки понадобятся 2 if-а и, соответственно, 2
условия, а как ты будешь собственно сравнивать числа - явно или вычитанием -
роли не играет.

Избавиться от двух if-ов можно, например, путем использования ветвления по
switch, а для этого, в свою очередь, надо уметь представлять результат
сравнения в каком-то нормализованном виде. Hапример - целыми значениями -1, 0,
+1.

i_comp = <...>;
switch (i_comp)
{
case -1: <...>;
case 0: <...>;
case +1: <...>;
}

Перевести результат сравнения в такой нормализованный вид можно "в лоб"

int i_comp = Key < m_k ? -1 : (Key > m_k ? +1 : 0);

(скобки, кажется, даже и не нужны) или чуть более хитро

int i_comp = (Key > m_k) - (Key < m_k);

В этих выраженияъ явно присутствуют два сравнения, но при этом ясно, что во
многих современных аппаратных арихитектурах для вычисления
этих выражений достаточно _одного_ машинного сравнения. Будет ли оно
действительно одно в маштнном коде зависит от качества реализации конкретного
компилятора. Может оба варианта странслируются через одно сравнение, может -
только один (причем еще неизвестно какой). А может, как ни верти, все равно
компилятор захочет сравнивать 2 раза. В общем, надо пробовать.

Best regards, Андрей

Stanislav Shwartsman

unread,
Nov 19, 2005, 2:16:22 AM11/19/05
to
Hello Andrey!

19 Nov 05 03:48, you wrote to Maxim Elkin:

AT> Hе совсем понимаю задачу. Сравнений-то в твоем последнем примере (в
AT> if-ах) все равно осталось 2. Что же имеется в виду под сравнениями?

AT> if в С/С++ осуществляет бинарное ветвление, поэтому как ни крути,
AT> чтобы организовать ветвление на 3 ветки понадобятся 2 if-а и,
AT> соответственно, 2 условия, а как ты будешь собственно сравнивать числа
AT> - явно или вычитанием - роли не играет.

Или не выпендриваться и оставить все компилятору, который достаточно
натаскан, чтобы код типа:

if (a<b) do_smth1
else if(a==b) do_smth2
else do_smth3

отранслировать в что типа:

cmp a, b
jb do_smth1
je do_smth2
do_smth3
jmp next

do_smth1:
...
jmp next

do_smth2:
...

next:
...

Как видишь и сравнение получилось всего одно и код соптимизирован
по параметру уменьшения условных переходов, которые как раз проблемы
и делают.

AT> Избавиться от двух if-ов можно, например, путем использования
AT> ветвления по switch, а для этого, в свою очередь, надо уметь
AT> представлять результат сравнения в каком-то нормализованном виде.
AT> Hапример - целыми значениями -1, 0, +1.

AT> i_comp = <...>;
AT> switch (i_comp)
AT> {
AT> case -1: <...>;
AT> case 0: <...>;
AT> case +1: <...>;
AT> }

В отличие от switch, для реализации которого понадобятся не только
условные переходы, но и сравнения. Единственная альтернатива -
воспользоваться таблицей при реализации switch, нечто типа

jmp [ebx+i_comp]

что является indirect jump и всвязи с устройством современных модулей
предсказания переходов гарантированно будет выполняться медленнее
предыдущего раза в 2-3. Собственно поэтому нормальный компайлер реализует
switch через таблицу, только при наличии > 16 или даже >32 вариантов
case, иначе просто не имеет смысла.

AT> Перевести результат сравнения в такой нормализованный вид можно "в
AT> лоб"

AT> int i_comp = Key < m_k ? -1 : (Key > m_k ? +1 : 0);

AT> (скобки, кажется, даже и не нужны) или чуть более хитро

AT> int i_comp = (Key > m_k) - (Key < m_k);

AT> В этих выраженияъ явно присутствуют два сравнения, но при этом ясно,
AT> что во многих современных аппаратных арихитектурах для вычисления этих
AT> выражений достаточно _одного_ машинного сравнения. Будет ли
AT> оно действительно одно в маштнном коде зависит от качества реализации
AT> конкретного компилятора. Может оба варианта странслируются через одно
AT> сравнение, может - только один (причем еще неизвестно какой). А может,
AT> как ни верти, все равно компилятор захочет сравнивать 2 раза. В общем,
AT> надо пробовать.

А ты, если тебе действительно интересно, напиши этот код в маленькой
тест-программе, отомпилируй и посмотри что получилось. Hапример
using gcc, icc или даже MSDV со всеми оптимизациями. Думаю глаза
немного откроются :)

Maxim Elkin

unread,
Nov 19, 2005, 4:12:02 PM11/19/05
to
Привет, Stanislav

19 Nov 05 10:16, you wrote to Andrey Tarasevich:

SS> if (a<b) do_smth1
SS> else if(a==b) do_smth2
SS> else do_smth3
Вернулись к печке :). Все бы ничего, но do_smthx иногда раздуваются на
страницы, a и b постепенно превращаются в d(b) и c(a), а программист чешет
репку над неожиданным поведением тривиального, как он помнит, кода.

Maxim

Maxim Elkin

unread,
Nov 19, 2005, 12:14:24 PM11/19/05
to
Пpивет, Andrey

19 Nov 05 03:48, you wrote to me:

ME>> int CmpRes = Key - m_k; if (!CmpRes) ... if (CmpRes < 0) ...


ME>> А если все 32? Красивого решения не существует?

AT> Hе совсем понимаю задачу. Сравнений-то в твоем последнем примере (в
AT> if-ах) все равно осталось 2. Что же имеется в виду под сравнениями?
Под сpавнением имеется ввиду вычитание одного числа из дpугого - пpи этом
pазpядность pезультата увеличивается на флаг пеpеноса, не влезающий в сишный
синтаксис, но доступный компилятоpу. Сpавнивать с нулем (вычитая нуль)
совpеменные компилятоpы избегают, так что я бы сказал, что в моем пpимеpе
осталось не два сpавнения, а два условия (ветвления). Hо от них избавиться,
очевидно, нельзя. Разве что стоит посмотpеть генеpиpуемый компилятоpом код для
AT> int i_comp = (Key > m_k) - (Key < m_k);
и последующего свича. Возможно, это именно то "кpасивое pешение", котоpого я
хотел - thanx.

[Чеpез час или два]
AT> как ни верти, все равно компилятор захочет сравнивать 2 раза. В
AT> общем, надо пробовать.
Gcc 2.95 сpавнивает дважды в обоих случаях - да еще и вставляет одно-два
ветвления, что уж совсем никуда не годится :(. Код v3.21 для "хитрого"
(оставленного в квоте) ваpианта чуть лучше - то же лишнее сравнение и
ветвистость:
cmp esi, ebx
setnle al
cmp esi, ebx
jge short loc_10062
dec eax
loc_10062: ...

Как ни стpанно, неплохой код сотвоpил для "хитрого" ваpианта BC/2 2.0:
cmp eax, edx
setnle bl
and ebx, 0FFh
cmp edx, eax
setnle al
and eax, 0FFh
sub ebx, eax

А если я не ошибаюсь, наилучшим кодом было бы что-то вpоде:
cmp eax, edx
setg al
setl ah
sub al, ah
Интересно, есть ли компиляторы, порождающие такое?

Maxim

Nickita A Startcev

unread,
Nov 21, 2005, 3:39:14 AM11/21/05
to
Привет, Andrew !


13 Nov 05 , 04:30 Andrew Ezhguroff писал к ob:

AE> 2. Макросы приходится использовать из-за отсутствия в Си
AE> параметризированных ф-ций. Из-за чего приходится либо плодить кучу
AE> ф-ций для разных типов аргументов, либо пользоваться "#define Max(a,


b) ((a)>> =(b)? (a): (b))" с очевидными проблемами в вызовах вида

AE> Max(x++, y--).

хех. А вот, кстати, интересный вопрос, какие побочные эффекты будут в
конструкции и что об этом говорит стандарт?

#define Max(a,b) ((a)>=(b)? (a): (b))
...
int a, b, c;
...
a=Max(b++,c--);
...

. С уважением, Hикита.
... Пpед кpыльцом pычит и бьет копытом тpактоp.

Dmitry Grebeniuk

unread,
Nov 21, 2005, 12:04:00 AM11/21/05
to
hi, Ivan

IK> потому что человек, набивший руку на оптимизации, заранее
IK> предчувствует какое построение программы может дать трудности в
IK> будущем, а переделывать придётся полностью всё с нуля, и выбирает
IK> более безопасный вариант, а вот новичёк, скорее всего реализует самый
IK> прямой вариант и столкнётся с фундаментальными трудностями на этапе
IK> когда уже ничего изменить не переписав по новой - нельзя.

Я сначала всегда пишу самый прямой вариант. В 90% кода ничего переписывать
не приходится (бОльшая часть кода получаются и так лучшими, в остальном
различия непринципиальные). А если и надо переписывать -- то всё
переписывается настолько просто, что никаких проблем с этим не возникает.

AE>> В таком случае, надо начинать с выбора языка программирования под
AE>> конкретную задачу. Базовый набор инструментов - это именно язык
AE>> программирования.

IK> Безусловно. Hо.. - все мы люди со своими заскоками и иррациональными:
IK> "не хочу, потому что - не хочу" :-)

Во дебилы.

IK> И на самом деле - это логично, потому что, возможность творить и
IK> причастность к искуству притягательны сами по себе, а лабать
IK> что-нибудь тупое и примитивное на высокоразвитом передовом языке -
IK> никто не хочет,

Как связано "тупое и примитивное" с "высокоразвитым передовым языком"?

IK> Это уже пример на "другую оптимизацию" - на вопрос: "а стОит ли"? А
IK> если его поставить по другому: "а кто будет решать - что именно
IK> стОит"?

Вот тот самый программист, который "занимает центральное место" и должен "и
пряники".

AE>> Вопрос - имеет-ли смысл тратить силы и деньги на оптимизацию этих
AE>> самых 95%?
IK> Речь шла о том, что код уже получается оптимизированным (в среднем -
IK> доводка всё равно будет нужна) при изначальном создании - без
IK> дополнительных усилий.

Зачастую в изначально-оптимизированном коде (когда в нём куча мелких
непринципиальных оптимизаций) гораздо больше ошибок.

IK> Когда стало новое железо - стали и новые программы, а старые - всё так
IK> же тормозили и уже на новом железе, потому что дело было не в нём, а в
IK> "какой разнице" съигравшей на самих алгоритмах. Мораль, думаю - ясна.

Hадо сделать что-то уж очень криво, чтобы на новом железе были ровно те же
тормоза.

bye

Stanislav Shwartsman

unread,
Nov 21, 2005, 11:37:25 AM11/21/05
to
Hello Nickita!

21 Nov 05 11:39, you wrote to Andrew Ezhguroff:

AE>> 2. Макросы приходится использовать из-за отсутствия в Си
AE>> параметризированных ф-ций. Из-за чего приходится либо плодить

AE>> кучу ф-ций для разных типов аргументов, либо пользоваться
AE>> "#define Max(a,


b) ((a)>>> =(b)? (a): (b))" с очевидными проблемами в вызовах вида
AE>> Max(x++, y--).

NS> хех. А вот, кстати, интересный вопрос, какие побочные эффекты будут в
NS> конструкции и что об этом говорит стандарт?

NS> #define Max(a,b) ((a)>=(b)? (a): (b))
NS> ...
NS> int a, b, c;
NS> ...
NS> a=Max(b++,c--);
NS> ...

Hичего хорошего не будет и по стандарту это undefined behavior.

Andrew Ezhguroff

unread,
Nov 21, 2005, 6:30:12 PM11/21/05
to
Привет! "Nickita A Startcev"
<Nickita.A...@p96.f105.n469.z2.fidonet.org> сообщил(а):

NA> хех. А вот, кстати, интересный вопрос, какие побочные эффекты будут в
NA> конструкции и что об этом говорит стандарт?
NA>
NA> #define Max(a,b) ((a)>=(b)? (a): (b))
NA> ...
NA> int a, b, c;
NA> ...
NA> a=Max(b++,c--);
NA> ...

Стандарт говорит, что это неопределенное поведение. Т.е. стандарту
соотвествует ЛЮБОЙ результат - и то, что ты хочешь получить, и BSOD и погода
на Марсе.

Andrey Tarasevich

unread,
Dec 13, 2005, 2:13:41 PM12/13/05
to
Mon Nov 21 2005 18:37, Stanislav Shwartsman wrote to Nickita A Startcev:

NS>> #define Max(a,b) ((a)>=(b)? (a): (b))
NS>> ...
NS>> int a, b, c;
NS>> ...
NS>> a=Max(b++,c--);
NS>> ...

SS> Hичего хорошего не будет и по стандарту это undefined behavior.

a=Max(b++,c--);

разворачивается в

a=((b++)>=(c--)? (b++): (c--));

Hикакого undefined behavior в этом конкретном примере и в помине нет, т.к.
условный оператор содержит точку следования после вычисления первого
(условного) выражения.

Хорошего, конечно, в этом все равно мало.

Best regards, Андрей

Andrey Tarasevich

unread,
Dec 13, 2005, 2:14:22 PM12/13/05
to
Tue Nov 22 2005 01:30, Andrew Ezhguroff wrote to Nickita A Startcev:

NA>> хех. А вот, кстати, интересный вопрос, какие побочные эффекты будут в
NA>> конструкции и что об этом говорит стандарт?
NA>>
NA>> #define Max(a,b) ((a)>=(b)? (a): (b))
NA>> ...
NA>> int a, b, c;
NA>> ...
NA>> a=Max(b++,c--);
NA>> ...

AE> Стандарт говорит, что это неопределенное поведение. Т.е. стандарту
AE> соотвествует ЛЮБОЙ результат - и то, что ты хочешь получить, и BSOD и
AE> погода на Марсе.

Hичего подобного стандарт в данном случае не говорит.

Best regards, Андрей

Andrey Tarasevich

unread,
Dec 13, 2005, 2:17:57 PM12/13/05
to
Sat Nov 19 2005 09:16, Stanislav Shwartsman wrote to Andrey Tarasevich:

SS> А ты, если тебе действительно интересно, напиши этот код в маленькой
SS> тест-программе, отомпилируй и посмотри что получилось. Hапример
SS> using gcc, icc или даже MSDV со всеми оптимизациями. Думаю глаза
SS> немного откроются :)

Hе понимаю, на что именно должны открыться мои глаза, но простейшие
эксперименты показывают, что мир еще несколько далёк от того
утопически-розового компиляторного соврешенства, в которое ты, похоже,
искренне веришь...

Best regards, Андрей

Andrew Kuksov

unread,
Nov 14, 2006, 5:51:24 PM11/14/06
to
Привет, Maxim!

08 Hоя 05 21:14, Maxim Elkin ---> All:


ME> Можно ли, не опускаясь до ассемблера, в таком фрагменте

[skip]


ME> как-нибудь избавиться от двух сравнений одних и тех же чисел? Если
ME> разрядность не превышает 31 бит, можно написать что-то вроде int

ME> CmpRes = Key - m_k; if (!CmpRes)


ME> ...
ME> if (CmpRes < 0)

ME> ...


ME> А если все 32? Красивого решения не существует?

Дело в том, что все равно остается два сравнения. Самое разумное будет -
полжиться на оптимизатор компилятора. Это, скорее всего, даст лучший результат.
Да и читабельность кода от всех этих ухищрений страдает. В общем, ничего не
выигрывая, теряем в понятности. Оставь как есть.

Я еще вернусь, Maxim... Удачи.

Andrew Kuksov

unread,
Nov 14, 2006, 6:02:22 PM11/14/06
to
Привет, Maxim!

11 Hоя 05 01:11, Maxim Elkin ---> ob:


o>> Hу да, если сравнение это вычитание... А это далеко не всегда
o>> так... ;-}
ME> А как еще можно сpавнить?
Примитивные типы довольно часто сравниваются аппаратными средствами.

Andrew Kuksov

unread,
Nov 14, 2006, 6:03:10 PM11/14/06
to
Привет, Andrew!

11 Hоя 05 02:37, Andrew Ezhguroff ---> ob:


o>> Раньше оптимизация была самой главной целью изменения кода...
o>> Теперь это тоже достаточно важно... ;-}


AE> Оптимизация ради оптимизации - это бред. Оптимизировать имеет смысл

AE> только несколько процентов кода. Еще раз - в исходном вопросе не было
AE> "как сделать так, чтобы работало быстрее?", а было "имеется-ли
AE> красивое решение?".
Ты же согласишься, что твое решение сложно назвать "красивым"? =)

Я еще вернусь, Andrew... Удачи.

Andrew Kuksov

unread,
Nov 14, 2006, 6:05:06 PM11/14/06
to
Привет, Andrew!

11 Hоя 05 13:58, Andrew Ezhguroff ---> ob:


o> *AE*>> Еще раз - в исходном вопросе не было "как сделать так,
o> *AE*>> работало быстрее?", а было "имеется-ли красивое решение?".
o>> Значит макросы это украшения?.. ;-}
AE> Макросы - удобный способ создания многоплатформенных исходников. И еще
AE> способ компенсировать недостатки синтаксиса "классического" Си. А в
AE> остальном - действительно украшения.
Удобный способ создания многоплатформенных исходников - использование
соответствующего инструмента, например, Джава. Кстати, в Java макросов нет, и,
что самое интересное, не хочется их там =)

Andrew Kuksov

unread,
Nov 14, 2006, 6:15:42 PM11/14/06
to
Привет, Andrew!

13 Hоя 05 16:57, Andrew Aksyonoff ---> ob:


AA>>> тебе сколько лет?
o>> Хочешь меня совратить?.. Иди подрочи... ;-}
AA> с возрастом все понятно, спасибо.
Да! За те несколько лет, которые меня не было в Fido, ничего не изменилось!
Супер. Мне этого так не хватало =)

Человек дело говорит. Слушайте его. Пусть и не совсем серьезно, но общая мысль
у него правильная.

Andrew Kuksov

unread,
Nov 14, 2006, 6:28:22 PM11/14/06
to
Привет, Maxim!

20 Hоя 05 00:12, Maxim Elkin ---> Stanislav Shwartsman:


SS>> if (a<b) do_smth1
SS>> else if(a==b) do_smth2
SS>> else do_smth3

ME> Вернулись к печке :). Все бы ничего, но do_smthx иногда раздуваются
ME> на страницы, a и b постепенно превращаются в d(b) и c(a), а
ME> программист чешет репку над неожиданным поведением тривиального, как
ME> он помнит, кода.
Вот как раз для того, чтобы такого не было, и не стоит заниматься
"оптимизацией" этих условий. А если такое все-таки получилось, нужно
(необходимо) переписать так, чтобы такого не было.

Andrew Ezhguroff

unread,
Nov 14, 2006, 8:22:09 PM11/14/06
to
Привет! "Andrew Kuksov" <Andrew...@p71.f1538.n5030.z2.fidonet.org>
сообщил(а):

Эта тема закрыта год назад. Тебе не кажется, что махать кулаками через год
после драки - это несколько странно?

AK> Ты же согласишься, что твое решение сложно назвать "красивым"? =)

Сразу видно, что на Фортране ты не программировал. :-) Это решение ничем не
хуже других. А спорить об эстетике - это абсолютно бессмысленное занятие.

Andrew Ezhguroff

unread,
Nov 14, 2006, 8:45:47 PM11/14/06
to
Привет! "Andrew Kuksov" <Andrew...@p71.f1538.n5030.z2.fidonet.org>
сообщил(а):

AK> Удобный способ создания многоплатформенных исходников - использование
AK> соответствующего инструмента, например, Джава.

Рассмешил. На официальном сайте Java перечислены процессорные архитектуры,
для которых существует Java 5 SE. Ты всерьез считаешь, что это можно назвать
многоплатформенностью?

AK> Кстати, в Java макросов
AK> нет, и, что самое интересное, не хочется их
AK> там =)

Ну и что? Мало-ли где чего нет. Вон в Паскале множества есть - и что?

Лучше попробуй объяснить, как автоматическая сборка мусора совместима с
программированием задач реального времени.

Dmitry Grebeniuk

unread,
Nov 15, 2006, 1:26:20 AM11/15/06
to
hi, Andrew

AE> А спорить об эстетике - это абсолютно бессмысленное занятие.

Hет.

bye

Stas Gritsjuk

unread,
Nov 15, 2006, 3:26:10 AM11/15/06
to
Привет, Dmitry.

Ответ на письмо Dmitry Grebeniuk к Andrew Ezhguroff от Tue Nov 06 1990 09:26

AE>> А спорить об эстетике - это абсолютно бессмысленное занятие.

DG> Hет.

Ответь же мне, большой бpат, что эстетичнее :

switch (n) {
case 2:
bla-bla-bla;
break;
case 5:
bla-bla-bla;
break;