информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft прикрывает Visual Studio... 
 Умер Кевин Митник 
 Массовое внедрение вредоносного... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Задело за живое?... 03.09.03 17:13  Число просмотров: 1130
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 03.09.03 17:25  Количество правок: 4
<"чистая" ссылка> <обсуждение закрыто>
> Ага, темплейтную функцию можно сделать inline-овой, кроме
> отстутствия оверхеда на вызов, компилер еще может и
> соптимизировать данный конкретный вызов, в том контексте
> куда вставлена функция. Раньше меня пугало то, что будет
> инстанцироваться сильно много шаблонов и это невероятно
> раздует код. Теперь я этого не боюсь :-)

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

> Эти правила в частности разрешают использовать goto для
> выхода из вложенных циклов (использование флага и проверка
> на каждой итерации не кажется мне слишком изящной). В
> perl-е для этого вообще введена отдельная конструкция
> (метки циклов и break по метке). Кроме того лично я
> использую goto для обработки ошибок (вложенные if-ы тоже не
> кажутся мне слишком читаемыми), а метка fail: только
> добавляет читаемости и выносит обработку ошибок отдельно от
> основного потока исполнения. В том же C++ для этих целей
> есть exception-ы.

Пишу очень мало (хобби такое, а не работа), но давно. Не припомню, чтобы "goto" где-то воспользовался. Сначала тяжело было (после бэйсика с фортраном №4), потом привык, сейчас забыл и оператор такой ("пошел на...").

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

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

> Гы. Эт точно :-) Мне нет 30-ти, но я это помню

Ну да, и двадцати достаточно - конец эры БК, ДВК, Поиск, Спектрум, Атари.... начало эры 1ВМ/РС-ХТ.

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

"Жаль, только жить в эту пору прекрасную, уж не придется ни мне, ни тебе". (Некрасов)
Пока закон Мура выполняется, и в ближайшие десятки лет будет выполнятся тоже (ученые-разработчики обещают).
Конечно не следует неделю оптимизировать алгоритм, и добиться счета программы один час, как и не следует писать час, если программа потом неделю считать будет. Важно время (а время - деньги, З.П. программиста + оборотная прибыль). Оптимально будет день писать, день считать. Т. е. совокупное время счета до устаревания программы должно быть адекватно человекочасам, потраченным на написание программы. Если программа будет эксплуатироваться год по пять минут чистого счета в день - потратьте часок другой, если есть возможность добиться одной секунды счета в день вместо пяти минут. Да еще предлагать обновить год назад купленный компьютер, поскольку он морально устарел и слаб для таких задач, хотя грамотно написанная (в которой применен оптимальный алгоритм) та же программа будет и на 286 летать. Разве не так?
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2023 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach