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