возврат из подпрограмм

Jurgis, ты ещё здесь сидишь?

Вторник Июнь 06 2006 12:42, Jurgis Armanavichius wrote to Alex Mogilnikov:

JA> Да ну их, эти табуляции... Я в редакторе задал заменять табы на два JA> пробела :-)

Это грамотное, универсальное решение.

Георгий

Aleksandr, ты ещё здесь сидишь?

Вторник Июнь 06 2006 14:50, Aleksandr Konosevich wrote to Michael Belousoff:

AK> Вот только без закатывания глаз к потолку и театрального же AK> заламывания рук, pls ! Кому надо - берёт нечто вроде NASM'а

Вот только не этот невменяемый хлам!

AK> и делает удовлетворяющие его слух и нюх ;-) макро ...

Угу.

Георгий

Kirill, ты ещё здесь сидишь?

Вторник Июнь 06 2006 21:09, Kirill Frolov wrote to Igor Havtorin:

Хэлловорлд, вестимо ;)

Георгий

Kirill, ты ещё здесь сидишь?

Вторник Июнь 06 2006 22:03, Kirill Frolov wrote to Michael Belousoff:

Что есть экран?

Георгий

Kirill, ты ещё здесь сидишь?

Вторник Июнь 06 2006 22:08, Kirill Frolov wrote to Michael Belousoff:

Далеко не факт. Существуют процессоры, работающие с данными в стеке без команд POP, существуют компиляторы, выкидывающие "мусор" из стека просто модифицируя указатель стека.

К примеру можно поглядеть паскалевский код для x86...

Георгий

Hello Jurgis.

06 Jun 06 00:37, Jurgis Armanavichius wrote to Pasha Popov:

JA> Это точно. А вообще я уже много лет борюсь с собой и никак не могу JA> решить (прошу не смеяться!): использовать табуляцию, или нет :-) JA> В смысле:

JA> int MyProg(int param) JA> { JA> if(DeviceActive) { JA> if(input_data_flag) { JA> if(InputData[0] == INIT_COMMAND) { JA> if(InputData[1] == GET_PARAM_SUBCOMMAND) { JA> if(OldParam != param) { JA> <и так довольно глубоко ;-)>

JA> } JA> } JA> } JA> } JA> } JA> }

JA> Если использовать табуляцию, то после трех-четырех уровней вложения JA> текст перестает помещаться в экран :-) Поэтому я частенько применяю JA> отступ в два пробела. Hо есть другое неудобство: если нужно вставить JA> или убрать уровень, то еще та работенка...

JA> В общем, сложный это вопрос. В нем хорошо помогает грамотный редактор.

В общем случае помогает грамотная голова. if(DeviceActive && input_data_flag && InputData[0] == INIT_COMMAND && InputData[1] == GET_PARAM_SUBCOMMAND && OldParam != param) { ... }

Еще существуют некие эмпирические правила, которые говорят, что если у аффтара возникают 20-ти вложенные циклы и if-ы, и если длина функции превышает пару экранов, то что-то здесь не то, и надо править в консерватории. Также существуют отработанные правила синтеза конечных автоматов, без тридцативло женных ифов.

Dmitry

Vladimir, ты ещё здесь сидишь?

Вторник Июнь 06 2006 22:26, Vladimir Vassilevsky wrote to Michael Belousoff:

VV> A вы до сих пор топчете лапки в качестве программиста? Понятно. VV> Это проклятие. Примерно как вечный студент или как Шепелев.

Гражданин Вассилевский, вам не надоело заниматься "персональными наездами"? Или Вы просто ни на что более конструктивное не способны?

Георгий

Hello Alex.

06 Jun 06 15:11, you wrote to Vladimir Vassilevsky:

VV>> P.S. Очевидно что while(i--) эффективнее чем for(i=0;i<255;i++)

AM> Hеочевидно. Если проверка на 0 в целевой архитектуре эффективнее, AM> хороший компилятор сам реверсирует цикл.

Кроме того, в Ц++ i может быть вовсе итератором, и код ++i может быть существенно эффективнее, чем i++

Dmitry

Hello Pasha.

06 Jun 06 19:51, you wrote to Michael Belousoff: PP> Кстати, ЕМHИП, это входит с стандарт ANSI С. Да и дело тут скорее в PP> безопастности - если, к примеру, сделать вот так: if( !Array[i] && i PP> < ArraySize ) ... то вот под Линуксом в конце массива можно получить PP> Segmentation fault. Если переставить условия, то это гарантирует, что PP> не входящую в массив ячейку смотреть не будем.

Причем здесь линукс ? В том же стандарте записано, что выход запределы массива

- это undefined behaviour. Во что это конкретно выльется, никто не знает и поэтому обсуждать последствия смысла не имеет.

Dmitry

Привет Jurgis!

07 Jun 06 15:34, Jurgis Armanavichius писал Alex Kocharin:

AM>>>> if(counter_started && ++counter == MAX_COUNTER) AM>>>> do_smthng();

В чем криминал?

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Слепой Пью, Глухой Ем...

Wed Jun 07 2006 07:53, Ruslan Mohniuc wrote to Vladimir Vassilevsky:

MB>>> Hееее, я yж лyчше по-стаpинке, MB>>> на Си...

VV>> Успехов вам в разрешении конфликтов имен, в изобретении всяких VV>> глобальных ERROR-ов, в борьбе с утечкой памяти и пр. мелкими VV>> техническими трудностями...

RM> Это ты за C++ агитируешь? Или за что-то другое, но главное чтобы это не C RM> был?

Си, как и все остальное, имеет свою область применимости. Причем эта область ограничена как сверху, так и снизу.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Привет Alex!

07 Июн 06 года (а было тогда 15:33) Alex Mogilnikov в своем письме к Ruslan Mohniuc писал:

RM>> и никакой компилятор не поручится, что у меня порядок RM>> обхода зависящих от i значений некритичен.

AM> Конкретный пример:

AM> ========= test.c ========== AM> void foo(int);

AM> void bar(void) AM> { AM> for(int i=5; i < 10; i++) AM> foo('G'); AM> } AM> ===========================

AM> Что мешает компилятору поручится в незавуисимости результата от AM> параметра цикла?

Может быть прерывание ?

AM> Здесь результат выполнения bar() зависит только от AM> количества проходов цикла. Вот какой код генерит gcc3:

------ кусь -----

AM> Мне тут прокомментировать нечего.

Это справетдливо если i не объявлено как volatile.

С уважением, Andrey 07 Июн 06 года

... E-Mail:a_biv<саба>list,ru Jabber:Andrey_B@jabber,ru |СQ:226793191

Привет!

Wed Jun 07 2006 15:33, Alexandr Torres wrote to Jurgis Armanavichius:

JA>> С пиками я не работал. Если для пиков не существует хорошего JA>> компилятора, то можешь это семейство микроконтроллеров вычеркнуть JA>> из списка программируемых на C/C++. Все же остальные - только ЯВУ! AT> Да откуда ему знать? Он Си не знает. AT> Прекрасный Хайтечевский Си для пиков, программировать что пик12 что AT> пик16 кроме как в исключительных случаях - на чистом асме - жорин AT> мазохизм.

Да, я подозревал, что компилятор должен быть.

JA>> Я хоть с пиками и не работал никогда, но сильно подозревал, что не JA>> должна фирма, создавшая микроконтроллерное семейство, гробить JA>> собственное будущее. AT> Что будетв будущем - посморим, а пока что Микрочип около десяти лет AT> занимает второе место в мире (после Моторолы) по выпуску 8-битных AT> микроконтроллеров....

Хм... Заинтриговал ты меня... Hужно будет взглянуть на эти пики.

JA>> Слышь, Георгий, ты меня не обманывай! Я ведь человек доверчивый :-) AT> Hашел кому верить...

;-)

Юргис

Привет!

Wed Jun 07 2006 19:47, Alex Mogilnikov wrote to Jurgis Armanavichius:

AM>>>>> if(counter_started && ++counter == MAX_COUNTER) AM>>>>> do_smthng(); AM> В чем криминал?

Hе люблю я такие конструкции... Эта еще ничего (хотя я проверку на равенство взял бы в скобки), а иногда встречаются такие выражения! :-)

Юргис

Привет!

Wed Jun 07 2006 19:29, Dmitry Lyokhin wrote to Jurgis Armanavichius:

JA>> Это точно. А вообще я уже много лет борюсь с собой и никак не могу JA>> решить (прошу не смеяться!): использовать табуляцию, или нет :-) JA>> В смысле: JA>> int MyProg(int param) JA>> { JA>> if(DeviceActive) { JA>> if(input_data_flag) { JA>> if(InputData[0] == INIT_COMMAND) { JA>> if(InputData[1] == GET_PARAM_SUBCOMMAND) { JA>> if(OldParam != param) { JA>> <и так довольно глубоко ;-)>

JA>> } ... JA>> В общем, сложный это вопрос. В нем хорошо помогает грамотный редактор. DL> В общем случае помогает грамотная голова. DL> if(DeviceActive && input_data_flag DL> && InputData[0] == INIT_COMMAND DL> && InputData[1] == GET_PARAM_SUBCOMMAND DL> && OldParam != param) DL> { DL> ... DL> }

А еще больше помогает правильное использование грамотной головы ;-) Я эти if'ы написал кратко, чтобы показать отступ текста программы вправо. И уж, конечно, понятно, что их всех можно объединить в один! Hо все дело в том, что ты абсолютно не следил за дискуссией. (Подозреваю, что ты очень обрадовался, найдя эту "оплошность" и лихое ее решение ;-)

А на самом деле каждый if сложнее и содержит под собой немало операторов до следующего if'а. Вот чтобы не заграмождать экран лишним для понимания вопроса текстом, я и упростил этот текст. Т.к. речь шла о быстром смещении текста программы вправо, а не о ловком умении некоторых круто объединять if'ы в кучку ;-)

Теперь ты ферштейн?

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

О да, конечно, о Великий! Благодаря тебе я наконец-то узнаю, что два и более условий можно объединить в один if... :-)

DL> Также существуют отработанные правила синтеза конечных автоматов, DL> без тридцативло женных ифов.

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

Юргис

Wed Jun 07 2006 19:47, Alex Mogilnikov wrote to Jurgis Armanavichius:

AM>>>>> if(counter_started && ++counter == MAX_COUNTER) AM>>>>> do_smthng();

AM> В чем криминал?

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

,-' Hello, Alex Mogilnikov! How is your connection today?

AM> Почитай что-нибудь о работе оптимизаторов. Конечно же, обсуждаемая AM> оптимизация возможна только в случае, если тело цикла не зависит от AM> его AM> параметра. А рассматриваемом примере оно не зависит. Определить, зависит AM> ли результат от изменения направления счета, компилятор вполне способен.

Не всегда. :-)

int k=0; for (int i=0; i<10; i++) g+=i;

Я думаю, компилятор не оптимизирует это. Хотя надо бы...

`-._ --- Alexander Kocharin ---

Wed Jun 07 2006 19:29, Dmitry Lyokhin wrote to Jurgis Armanavichius:

DL> Еще существуют некие эмпирические правила, которые говорят, что если у DL> аффтара возникают DL> 20-ти вложенные циклы и if-ы, и если длина функции превышает пару DL> экранов, то что-то здесь не то,

Подобные конструкции могут возникать по причине религиозного нежелания использовать goto.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Привет Alex!

08 Jun 06 01:00, Alex Kocharin писал Alex Mogilnikov:

AM>> Определить, зависит ли результат от изменения AM>> направления счета, компилятор вполне способен.

AK> Hе всегда. :-)

Хорошо, уточню мысль: ничто не мешает компилятору выявить независимость результата от направления.

AK> int k=0; AK> for (int i=0; i<10; i++) g+=i;

AK> Я думаю, компилятор не оптимизирует это. Хотя надо бы...

gcc4 оптимизировал:

======== test.c ============= int foo(void) { int k = 0; for(int i = 0; i < 10; i++) k += i;

return k; } =============================

======== test.s ============= .file "test.c" .arch avr2 __SREG__ = 0x3f __SP_H__ = 0x3e __SP_L__ = 0x3d __tmp_reg__ = 0 __zero_reg__ = 1 .global __do_copy_data .global __do_clear_bss .text .global foo .type foo, @function foo: /* prologue: frame size=0 */ /* prologue end (size=0) */ ldi r24,lo8(45) ldi r25,hi8(45) /* epilogue: frame size=0 */ ret /* epilogue end (size=1) */ /* function foo size 3 (2) */ .size foo, .-foo /* File "test.c": code 3 = 0x0003 ( 2), prologues 0, epilogues 1 */ =============================

Hичто не совершенно, и совершенству нет предела. :)

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

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.