| |
|
|
| | Купил недавно книгу по С/С++, как сказано, "для начинающих". Ну, так это или нет, не знаю, но вопрос у меня возник.
Везде в примерах используются конструкции типа
int i=5;
char c=getch();
while((c=getch()) != eof)
|
и все такое прочее, то есть автор идет по пути максимальной вложенности операторов. Имхо, это некрасиво.
Но это только имхо, а хотелось бы узнать поточнее: правильно ли так писать как с точки зрения "хорошего тона", как и с точки зрения эффективности (быстродействия в первую очередь - ведь на С++ от Hello, world недалеко и до DOOM4:) )
PS И еще, в догонку. Там же, в книге, упомянут атрибут __fastcall для функции, ускоряющий ее работу. А в чем подвох? почему бы всем функциям его не приписать? | |
| |
|
|
| |
|
|
| |
для: Киналь
(31.03.2006 в 23:28)
| | | Большая степень вложености - это наследоство от C - страшного ничего нет, но злоупотреблять этим не стоит...
PS Я так понимаю речь идёт о Builder? __fastcall позволяет аргументы вызываемой функции разместить непосредственно в регистрах, а не в памяти, что ускоряет вызов функции. Но если параметры в регистры не влазят (например, это строка) толку от неё не будет. Более того, компилятор у Builder достаточно умный и сам может сообразить имеется возможность засунуть параметры в регистры или нет. В общем для совместимости лучше избегать __fastcall, её наверное удобно применять, одновременно с дизасемблером, когда видно, что компилятор не догодался поместить параметры в регистры, а сделать это можно... | |
| |
|
|
| |
|
|
| |
для: cheops
(01.04.2006 в 13:17)
| | | Понятно, спасибо!
Но все же, про вложенность - сильно ли это влияет быстродействие? И как? Сам пока измерить не могу - функций для времени не знаю=)
Насчет __fastcall - это мне пока слишком круто=) но буду иметь в виду. | |
| |
|
|
| |
|
|
| |
для: Киналь
(01.04.2006 в 13:21)
| | | На скорость это не влияет, это влияет на количество используемой памяти, просто при выносе из вложенного блока функции - её результат вам придётся хранить в отдельной переменной, если вам не жалко пары байт (а жалеть их не следует), можно именно так и поступать. | |
| |
|
|
| |
|
|
| |
для: cheops
(01.04.2006 в 13:43)
| | | Понятно... Тогда еще вопрос (уж простите за назойливость:) )
Если программа сводится к вычислительным задачам (расчет поля, к примеру, или там колебаний конструкций), то помешает ли эта самые "пара байт"? Должны же они, байты. на что-то влиять?
Я почему так выспрашиваю - напугали тут меня, что расчет картины поля среднего электродвигателя займет у опять-таки среднего по мощности ПК несколько суток. Вот я и думаю, что к мелочам надо отнестись внимательно, пока они не вошли в привычку=) | |
| |
|
|
| |
|
|
| |
для: Киналь
(01.04.2006 в 13:52)
| | | Тут тогда на скорость следует обращать внимание, поинтересуйтесь сколько памяти жрёт такой расчёт, сдаётся мне что байты экономить придётся (только не усердствуйте - проще оптимизировать рабочую программу, чем заставить правильно работать оптимизированную). Я в своё время возился примерно с такими же задачами (кванты), но мне было проще у меня были программные комплексы на Fortran, которые начали разрабатываться мировым сообществом ещё до моего рождения на свет (и кстати, до GPL тоже, от туда у меня любовь к BSD-лицензиям). Так как эти комплексы пережили не один десяток архитектур, в них была очень хорошая масштабируемость - память прекрасно конвертировалась во время: если у вас мало памяти - считаться будет дольше, если много - быстрее. Поэтому памятью сильно не разбрасывайтесь, если особенно с многомерными пространствами работаете... | |
| |
|
|
| |
|
|
| |
для: cheops
(01.04.2006 в 14:13)
| | | Большое спасибо, все понятно. | |
| |
|
|
