Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
back to the user! 26.12.03 11:04 Число просмотров: 2000
Автор: jammer <alex naumov> Статус: Elderman
Отредактировано 26.12.03 11:04 Количество правок: 1
|
> > какие могут быть еще новые условия существования -
> обновление вирусной
> > базы или смена сервиспака в W2k/XP ? не смеши.
> Или смена ОС или платформы.
а зачем все время сменять? есть монитор под OS1 и... скажем, OS2 ;) и под платформы. надо что-то дописать - дописывается. переносить смысла не вижу.
> Скажи, ты дествительно не видел AVP под линух?
именно. да я вообще с линуксом дел не имею и стараюсь не иметь... мне компромиссы не по душе. ;) (личная точка зрения)
> Только не надо мне говорить про врапперы и
> абстрагирующий layer. Это попытка создать из асма
> высокоуровневую среду программирования. Это гораздо лучше
> сделано в том же C (хотя и тоже не без косяков).
я и не собирался об этом говорить, я не настолько повернут на девелоперстве. слова твои понятны поодиночке, а в сочетаниях я просто даже не знаю о чем конкретно ты говоришь (только догадываюсь, вспоминая высшую школу и теорию).
> > а вообще-то сабж. :) как честно заплативший. убытки от
> > лишних тормозов можно посчитать хоть в блоках rc5, хоть в
> > нервах юзеров в моменты сильной нагрузки. на выбор.
> У меня уже сейчас есть несколько проектов по ~10000 строк
> (которые я тяну в одиночку). При этом статическая типизация
> ой как помогает избавиться от лишних ошибок.
когда во время компиляции и даже выполнения контролируются допустимые значения для переменных? да кто ж с этим поспорит, только до стандартного стародоброобучающего паскаля си все равно не дотягивает в этом контроле - во всяком случае ощущение правильности исходника у меня отсутствует. си, т.о. не изящен и нечитабелен. объявить int x и присвоить ему 'a' - ну где еще такое проканает, кроме сей. также радует и логический тип задавать целочисленным, опупенный расклад, особенно если вспомнить о разнице выполнения операций NOT, AND, OR, XOR etc над логическими и цифровыми величинами.
> Четвертая беда - чрезмерная избыточность кода, не
я думаю именно на выходе твоего компилятора получается чрезмерная избыточность кода, когда 100 байт инструкций обрамляются 100 килобайтами MFC и прочей срани.
> приводящая однако к его ошибкоустойчивости. Для реализации
> цикла надо вводить с десяток инструкций, причем цикл так и
> останется неявным (инкремент-проверка-условный переход ни
> одно из этих явлений не говорит о непосредственно цикле).
и комментариям ты тоже не обучен? ;)
> Для вызова функции - еще пара десятков. Код растет - его
а, мышление функциями, одна из убогостей сишного взгляда на программирование, в ассемблере нет функций вообще. хотя скорее тут расхождение во мнениях терминологическое, если не думать о том что скорее всего ты забываешь, что результат функции - одна величина некоторого типа, результатом процедуры может быть от нуля до множества величин.
> понимаемость снижается -> количество ошибок растет
> (особенно если учесть предыдущую проблему) - простой юзер
> недоволен (если до него вообще когда нибудь дойдет проект
> из хотя бы десятков-сотен тысяч строк, который
> принципиально пишут на асме).
кстати, про принципиальность написания я ничего не говорил. такие вещи как открытие файла или сообщение об ошибке я не вижу смысла писать на языке низкого уровня. pure asm скорее фетиш и на деле действительно - на мой взгляд - оправдывается только если приносит удовольствие автору.
> Повторю для непонятливых: в ПОДАВЛЯЮЩЕМ БОЛЬШИНСТВЕ случаев
> оптимизирующий компилятор генерирует код не хуже (а
всегда хуже - как минимум из-за обрамления ненужными кусками двоичного кода в объектных и исполняемых файлах, ненужной масштабируемостью, и прочей фигней, которую даже днем с огнем всю не выключишь. я сейчас говорю на примере борландовского и мелкософтовского компилятора, про другие тонкостей не помню.
> зачастую и лучше) человека. В самых крайних случаях есть
ну если настолько неграмотен человек - место ему в вебмастерах, а не в программерах.
> inline-ассемблер.
об этом и речь. про тот же монитор можно уверенно сказать что наиболее популярные проверяющие циклы он крутит не эффективно из-за пренебрежения такой возможностью, лени, а возможно и простой неграмотности разработчиков.
> на марафонных дистанциях (>1000 строк) компилятор всегда побеждает.
в скорости и комфорте разработки, но не в результате.
типичная беда нашего времени - сделать все впопыхах. сграбить фильм с DVD, неэффективно пожать его в divx, криво перевести название на русский язык и записать его траснлитом в имя файла - утверждая что компилятор всегда побеждает. смешно.
настолько же нелепо делать гуй из монитора, которому сервисом положено было бы работать, а темы XP лепить в виде сервиса.
имхо.
PS. ну и опять же повторюсь - мы только о проблемах девелоперов рассуждаем, а проблема юзера в том что он зазря гоняет байтики в памяти по причине ленивой криворукости девелопера. я в своих попытках что-то сдевелопить поражаюсь быстродействию таких машин на которых AVP Monitor будет прорисывывать свои FUCKING иконки минут несколько при разворачивании гуевого окна. мне иконки не нужны, и регедит тоже, я бы с большим удовольвием отредактировал конфиг фаром - по образу и подобию того как я редактирую фаром конфиги freebsd.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
