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