Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Сори, парни... Что-то я не совсем догоняю суть проблемы. В чем сопсна?... 10.03.05 21:32 Число просмотров: 2846
Автор: Den <Denis> Статус: The Elderman
|
> > > А ты уверен, что это не поменятеся в будущем? Чем > > ближе ты > > > находишься к существующему стандарту, тем меньше > > > вероятность, что комитет по стандартизации в > будущем > > > поломает твою программу. > > > > Уверен. Генерация кода вещь хотя и хрупкая, но не в > данном > > конкретном случае. Я не вижу более оптимальных > вариантов
Уверен на 100%, что пересматривать стандарт Си в отношении значения NULL никто не будет, хотябы по соображениям обратной совместимости с уже имеющимися реализациями готовых компиляторов под существующие платформы.
> Я специально уточнил, что кодогенератор не меняет СМЫСЛ > сгенерированного кода, а может поменять сам код. И сказал я > это к тому, что > > > cmp [ptr], 0
> jne is_not_null
>
> или
>
> cmp [ptr], 0
> je is_null
> ---
> > не имеет разницы и в данном обсуждении совершенно > несущественно. Мне совершенно по фигу, в КАКОЙ КОД это > скомпилируется. Гораздо важнее ИСХОДНЫЙ КОД на C++. И я это > уже подчеркнул. Разрушить твою программу может не > кодогенератор, а комитет по стандартизации
Если бы комитет по стандартизации мог разрушить чей-то код, тогда MS VC и Borland C++ Builder были бы братья близнецы со всеми вытекающими...
> > для построения кода (хотя при сравнении float'а с > нулём > > компилятор и строит хрень какую-то - cmp или test были > бы и > > проще и эффективнее - но это я уже склонен списывать > на > > баги Майкрософта). > > А ты уверен, что включил опцию оптимизации? :-) > Я неоднократно убеждался, что оптимизатору можно доверять.
Если ты про оптимизатор от WatCom, то доверять можно. ;)
> > > > отличаются только иструкцией je вместо jne.
Ну дык... Все зависит от дальности перехода по условию.
> При > > этом > Открою секрет: ОДНО И ТО ЖЕ сравнение из-за хрупкости > кодогенератора может выливаться в совершенно разные > инструкции. Повторюсь, ЭТО НЕСУЩЕСТВЕННО. Считай, что C++ > код вообще не компилируется, а исполняется на специальной > C++ машине, которая понимает его напрямую и обрабатывает > полностью в соответствии со стандартом
А это как? Ты про .NET?
> > > В теории. На практике всегда можно предугадать какой > именно > > код построит компилятор. Естесственно, что он > использует > > Ню-ню. > > > умные методы оптимизации, однако в таких вещах как я > > показал оптимизировать физически нечего. > > Немного оффтоп, хотя и в тему, но вот вы писали в > топике > > про ООП, что, мол, компилятор строит эффективный код, > > который часто не по силам человеку. > > Надо внимательнее читать (в части про бутылочные горлышки). > Человеку по силам оптимизировать 10-100 строк кода так, > чтобы они были эффективнее того, что даст компилятор. Но > проект в 1000-100000 строк кода совершенно невозможно не то > что написать на ассемблере эффективно, а невозможно ВООБЩЕ.
Ты ошибаешься. Есть люди, которые подсознательно помнят все правила оптимизации кода начиная с i386 и пишут на ассемблере оптимизируя налету, причем даже не задумываясь.
> > > 115940 - уже было подобное обсуждение. Да и то что я > привёл > > с float'ом при сравнении с нулём опять же не тянет на > "не > > по силам человекам". Я бы такое сравнение писал проще > и > > лучше. Мелочь, но однако. > > Интересно посмотреть. Хотя не зря бутылочные горлышки > расширяются именно при помощи ручной оптимизации на > ассемблере. И не зря они имеют мизерные размеры. Я Вам > скажу почему: оптимальное распределение ограниченного > набора регистров - NP-полная задача номер раз, оптимальная > кодогенерация - NP-полная задача номер два. NP полные > задачи решаются за экспоненциальное время от из размера. > КАЖДАЯ дополнительная строка умножает сложность на > определенную константу (пусть это будет 2). Оптимально > написать 10 строк в 2 раза легче, чем 11. Написать 20 строк > в 1024 раз сложнее, чем 10. Человек не способен справиться > с этой сложностью.
Да не... Обычно оптимизируются соседние 3 - 7 мнемоник, поэтому, сложность ручной оптимизации не вырастает в разы, а скорее переходит в константу для одтельно взятой "версии" проца.
> > > Почему оно так называется понятно. Но что касается Си, > то > > он уж через чур "статический". Хоть убейте, но я не > понимаю > > зачем вообще разделять указатели. Какая разница, > указывает > > Ну дык пиши на бейсике. Или наоборот на ассемблере. А еще > рекомендую почитать про корректирующие коды и зачем нужна > избыточность информации. Тебя не смущает что ЛЮБОЙ русский > текст сжимается примерно на 60%. Это значит, что полезную > нагрузку несет только 40% русской речи. Советую задуматься, > а на фига остальные 60% (в английском эта цифра вообще > около 75%).
Если бы существовал платформонезависимый ассемблер, мы бы им пользовались.
> > > он на int, char или вообще на другой указатель? Только > что > > бы программист сам при программировании не запутался? > > Как-то это сомнительно.
Для проверки типа при компиляции и уменьшения ошибок кодирования.
> > Ага, сомнительно. А ты подумай, подумай на хрена в русском > языке 60% мусора. > > > Думаю, теперь все вопросы прояснились. NULL - нулевой > Все вопросы прояснились еще раньше. Когда Ktirf дал ссылку > на 18-й параграф СТАНДАРТА (ага того, который ISO/IEC > 14882) > > > указатель. Тип, на что именно NULL указывает, не > важен. > > Просто указатель на ноль. Если для вас и Страуструп не > > стандарт, то я уж и не знаю :-) > Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего > лишь мануал :-)
Пф-ф-ф-ф...
|
|
|