информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыПортрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Простое пробивание рабочего/провайдерского... 
 400 уязвимостей в процессорах Snapdragon 
 Яндекс неуклюже оправдался за установку... 
главная обзор 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
регистрация





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

Пф-ф-ф-ф...
<programming> Поиск 








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


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach