Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Именно в данном случае 10.03.05 15:37 Число просмотров: 2078
Автор: 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 указывает, не важен.
> Просто указатель на ноль. Если для вас и Страуструп не
> стандарт, то я уж и не знаю :-)
Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего лишь мануал :-)
|
|
|
подробно о проекте
Анализ криптографических сетевых... 
