Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Уверен. Генерация кода вещь хотя и хрупкая, но не в данном... 10.03.05 14:22 Число просмотров: 2801
Автор: Heller <Heller> Статус: Elderman
|
> Никто как бы и не удивлен тем, что информация о типах
> теряется при компиляции. Вообще то если кто не заметил, мы
> говорили не о том, что БУДЕТ РАБОТАТЬ (если бы вопрос
> ставился таким образом, достаточно было бы одного теста), а
> о том, что БОЛЬШЕ СООТВЕТСВУЕТ СТАНДАРТУ
> А ты уверен, что это не поменятеся в будущем? Чем ближе ты
> находишься к существующему стандарту, тем меньше
> вероятность, что комитет по стандартизации в будущем
> поломает твою программу.
Уверен. Генерация кода вещь хотя и хрупкая, но не в данном конкретном случае. Я не вижу более оптимальных вариантов для построения кода (хотя при сравнении float'а с нулём компилятор и строит хрень какую-то - cmp или test были бы и проще и эффективнее - но это я уже склонен списывать на баги Майкрософта).
> > отличаются только иструкцией je вместо jne. При этом
>
> А вот тут по фигу - кодогенерация весьма хрупкая штука (не
> в смысле что может сломаться, а в смысле что при малейшем
> телодвижении может давать совершенно другой код). А все
> потому, что оптимальная кодогенерация - NP-полная задача и
> для ее решения используются эвристические итерационные
> методы которые в пределе должны сходиться к оптимальному
> результату.
В теории. На практике всегда можно предугадать какой именно код построит компилятор. Естесственно, что он использует умные методы оптимизации, однако в таких вещах как я показал оптимизировать физически нечего.
Немного оффтоп, хотя и в тему, но вот вы писали в топике про ООП, что, мол, компилятор строит эффективный код, который часто не по силам человеку. http://bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=2&m=115940 - уже было подобное обсуждение. Да и то что я привёл с float'ом при сравнении с нулём опять же не тянет на "не по силам человекам". Я бы такое сравнение писал проще и лучше. Мелочь, но однако.
> > Си'шный тип (указатель/не указатель, char/не char)
> вообще
> > оказывается не существенным.
>
> А почему по твоему она называется статической типизацией (в
> отличие от динамической)?
Почему оно так называется понятно. Но что касается Си, то он уж через чур "статический". Хоть убейте, но я не понимаю зачем вообще разделять указатели. Какая разница, указывает он на int, char или вообще на другой указатель? Только что бы программист сам при программировании не запутался? Как-то это сомнительно.
Ну да про стандарт. Я решил обратиться по вопросу NULL'а к Страуструпу:
----------------
Ноль (0) имеет тип int. Благодаря стандартным преобразованиям (§ В.6.2.3), 0 можно использовать в качестве константы любого интегрального типа (§ 4.1.1), типа с плавающей точкой, указателя или указателя на член класса. Тип нуля определяется по контексту. Ноль, как правило (но не всегда), будет физически представлен в виде последовательности нулевых битов соответствующей длины.
Гарантируется, что нет объектов с нулевым адресом. Следовательно, указатель, равный нулю, можно интерпретировать как указатель, который ни на что не ссылается.
В языке С было очень популярно определять макрос NULL для представления такого нулевого указателя. Так как в С++ типы проверяются более жёстко, использование банального нуля вместо NULL приведёт к меньшим проблемам. Если вы чувствуете, что просто обязаны определить NULL, воспользуйтесь
const int NULL = 0;
Модификатор const (§ 5.4) предотвращает ненамеренное замещение NULL и гарантирует, что NULL можно использовать везде, где требуется константа.
----------------
Думаю, теперь все вопросы прояснились. NULL - нулевой указатель. Тип, на что именно NULL указывает, не важен. Просто указатель на ноль. Если для вас и Страуструп не стандарт, то я уж и не знаю :-)
|
|
<programming>
|
[C++] void* 28.01.05 23:12 [Ktirf, HandleX, amirul, Den, Killer{R}]
Автор: YoungNigga Статус: Незарегистрированный пользователь
|
|
это сообщение стоило бы написать, наверно, в разделе beginners, по я все-таки решил здесь. так вот, я вообще изучаю С++, а с той частью С, которая считается устаревшей в С++, не знаком. а сейчас стал WinApi и DirectX изучать, а там всплывают иногда моменты на С. объясните, пожалуйста, что эт за такой указатель на тип void (void*), потому что в моей 1000-страничной книге по С++ этого нет, и в статьях, которые у меня есть, тоже нет. в общем-то понятно, но хотелось бы как-нить поподробней.
|
|
[C++] Не ответ, а вопрос новичка, т.е. мой вопрос... 02.03.05 05:06
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 02.03.05 05:13 Количество правок: 1
|
... а на сколько хорошо с точки зрения vulnerability использовать такого рода проверки для функций, возвращающих 0 при неудаче:
char * some_copy_buf_function ( const char* src, char * dest, int size_data );
if (some_copy_buf_function( src, dest, size_data * sizeof(char)) == NULL)
{
....
}
имея ввиду, как определено макро NULL.
ПС. поделитесь соображениями про эту проверку и про определение NULL.
ППС. Сорри за вопрос в отношение VOID. Но макро NULL имеет для некоторых компилеров прямое отношение к VOID*
|
| |
Углубился я в дизассемблер 10.03.05 04:30 [Heller]
Автор: Heller <Heller> Статус: Elderman
|
Для начала простой пример. Дано: a - int, проверка условия - if (a) (пример немного не в тему - привожу для дальнейшего сравнения):
cmp dword ptr [a (004225d8)],0
je main+25h (00401035)
Те же условия, но проверка (!a):
cmp dword ptr [a (004225d8)],0
jne main+25h (00401035)
При отрицании единственное что изменилось, это проверка с JE на JNE. В общем, именно так, как я писал уже выше.
Заменив в этих примерах "int a" на "int *a" не зменилось вообще ничего - код остался совершенно таким же. Компилятор при построении экзэшника не сделал разницы между указателем и обычным int'ом.
Вообще для любых целых типов он просто урезает/дополняет значение до dword. Например, для char'а это инструкция movsw.
Для вещественных чисел алгоритм более мудрёный:
fld dword ptr [a (00426968)]
fcomp dword ptr [__real@4@00000000000000000000 (0042301c)]
fnstsw ax
test ah,40h
В этом случае сравнение идёт по регистру SWR (пример дан для float). Всякие doubl'ы и прочие, видимо, работают аналогично, но я не стал разбираться - не то сейчас интересно. Кстати, для сравнений он всегда, не только с вещественными числами, но и с целыми, испольует test. Исключение составляет только тот случай, когда под переменную изначально выделено 4 байта - в этом случае используется cmp. Ну да это я так, к слову.
В общем, как это всё работает, понятно. Теперь про сравнения "==". Начну с простого int'аб сравнивая его с "0":
cmp dword ptr [a (00426968)],0
jne main+25h (00401035)
Для "!=" jne меняется на je. То есть, вообще говоря, компилятору исключительно пофик как именно идёт сравнение. "0" он и есть "0", а сравнение идёт обычным cmp, приводя изначально любое данное к dword.
Для полноты картины упомяну и про вещественные типы. В случае сравнения "==0" или "!=0" код получается такой же, как и приведённый выше (там где сравнивается SWR). А вот если проверка идёт уже с конкретным значением, например "==1", то компилятор уже не заморачивается и использует всё тот же cmp.
Теперь сравнение указателей. Приведу сразу общий случай:
Код на Си:
int *a,*b;
void main() {
if (a==b) {return;}
}
Соответственно на АСМе:
mov eax,[a (00426b94)]
cmp eax,dword ptr [b (00426b98)]
jne main+29h (00401039)
jmp main+2Bh (0040103b)
Теперь изврат:
if (a==((void *)0))
На АСМе. Вы будете смеяться:
cmp dword ptr [a (00426b94)],0
jne main+25h (00401035)
Тот же результат даёт сравнение с NULL. Причём совершенно пофик, что именно я с ним сравниваю, указатель или "обыкновенный" тип. И даже скажу больше: при сравнении с NULL типа float мы получаем всё те же самые fld и fcomp.
Получается, что следующие записи эквивалентны: (a), (a!=0), (a!=NULL). От следующих: (!a), (a==0), (a==NULL) они отличаются только иструкцией je вместо jne. При этом Си'шный тип (указатель/не указатель, char/не char) вообще оказывается не существенным.
|
| | |
А на фига углубляться в дизассемблер? 10.03.05 12:08
Автор: amirul <Serge> Статус: The Elderman
|
> Заменив в этих примерах "int a" на "int *a" не зменилось
> вообще ничего - код остался совершенно таким же. Компилятор
> при построении экзэшника не сделал разницы между указателем
> и обычным int'ом.
Никто как бы и не удивлен тем, что информация о типах теряется при компиляции. Вообще то если кто не заметил, мы говорили не о том, что БУДЕТ РАБОТАТЬ (если бы вопрос ставился таким образом, достаточно было бы одного теста), а о том, что БОЛЬШЕ СООТВЕТСВУЕТ СТАНДАРТУ
> Получается, что следующие записи эквивалентны: (a), (a!=0),
> (a!=NULL). От следующих: (!a), (a==0), (a==NULL) они
А ты уверен, что это не поменятеся в будущем? Чем ближе ты находишься к существующему стандарту, тем меньше вероятность, что комитет по стандартизации в будущем поломает твою программу.
> отличаются только иструкцией je вместо jne. При этом
А вот тут по фигу - кодогенерация весьма хрупкая штука (не в смысле что может сломаться, а в смысле что при малейшем телодвижении может давать совершенно другой код). А все потому, что оптимальная кодогенерация - NP-полная задача и для ее решения используются эвристические итерационные методы которые в пределе должны сходиться к оптимальному результату.
> Си'шный тип (указатель/не указатель, char/не char) вообще
> оказывается не существенным.
А почему по твоему она называется статической типизацией (в отличие от динамической)?
|
| | | |
Уверен. Генерация кода вещь хотя и хрупкая, но не в данном... 10.03.05 14:22
Автор: Heller <Heller> Статус: Elderman
|
> Никто как бы и не удивлен тем, что информация о типах
> теряется при компиляции. Вообще то если кто не заметил, мы
> говорили не о том, что БУДЕТ РАБОТАТЬ (если бы вопрос
> ставился таким образом, достаточно было бы одного теста), а
> о том, что БОЛЬШЕ СООТВЕТСВУЕТ СТАНДАРТУ
> А ты уверен, что это не поменятеся в будущем? Чем ближе ты
> находишься к существующему стандарту, тем меньше
> вероятность, что комитет по стандартизации в будущем
> поломает твою программу.
Уверен. Генерация кода вещь хотя и хрупкая, но не в данном конкретном случае. Я не вижу более оптимальных вариантов для построения кода (хотя при сравнении float'а с нулём компилятор и строит хрень какую-то - cmp или test были бы и проще и эффективнее - но это я уже склонен списывать на баги Майкрософта).
> > отличаются только иструкцией je вместо jne. При этом
>
> А вот тут по фигу - кодогенерация весьма хрупкая штука (не
> в смысле что может сломаться, а в смысле что при малейшем
> телодвижении может давать совершенно другой код). А все
> потому, что оптимальная кодогенерация - NP-полная задача и
> для ее решения используются эвристические итерационные
> методы которые в пределе должны сходиться к оптимальному
> результату.
В теории. На практике всегда можно предугадать какой именно код построит компилятор. Естесственно, что он использует умные методы оптимизации, однако в таких вещах как я показал оптимизировать физически нечего.
Немного оффтоп, хотя и в тему, но вот вы писали в топике про ООП, что, мол, компилятор строит эффективный код, который часто не по силам человеку. http://bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=2&m=115940 - уже было подобное обсуждение. Да и то что я привёл с float'ом при сравнении с нулём опять же не тянет на "не по силам человекам". Я бы такое сравнение писал проще и лучше. Мелочь, но однако.
> > Си'шный тип (указатель/не указатель, char/не char)
> вообще
> > оказывается не существенным.
>
> А почему по твоему она называется статической типизацией (в
> отличие от динамической)?
Почему оно так называется понятно. Но что касается Си, то он уж через чур "статический". Хоть убейте, но я не понимаю зачем вообще разделять указатели. Какая разница, указывает он на int, char или вообще на другой указатель? Только что бы программист сам при программировании не запутался? Как-то это сомнительно.
Ну да про стандарт. Я решил обратиться по вопросу NULL'а к Страуструпу:
----------------
Ноль (0) имеет тип int. Благодаря стандартным преобразованиям (§ В.6.2.3), 0 можно использовать в качестве константы любого интегрального типа (§ 4.1.1), типа с плавающей точкой, указателя или указателя на член класса. Тип нуля определяется по контексту. Ноль, как правило (но не всегда), будет физически представлен в виде последовательности нулевых битов соответствующей длины.
Гарантируется, что нет объектов с нулевым адресом. Следовательно, указатель, равный нулю, можно интерпретировать как указатель, который ни на что не ссылается.
В языке С было очень популярно определять макрос NULL для представления такого нулевого указателя. Так как в С++ типы проверяются более жёстко, использование банального нуля вместо NULL приведёт к меньшим проблемам. Если вы чувствуете, что просто обязаны определить NULL, воспользуйтесь
const int NULL = 0;
Модификатор const (§ 5.4) предотвращает ненамеренное замещение NULL и гарантирует, что NULL можно использовать везде, где требуется константа.
----------------
Думаю, теперь все вопросы прояснились. NULL - нулевой указатель. Тип, на что именно NULL указывает, не важен. Просто указатель на ноль. Если для вас и Страуструп не стандарт, то я уж и не знаю :-)
|
| | | | |
Именно в данном случае 10.03.05 15:37
Автор: 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 указывает, не важен.
> Просто указатель на ноль. Если для вас и Страуструп не
> стандарт, то я уж и не знаю :-)
Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего лишь мануал :-)
|
| | | | | |
Однако и трудоёмкость обоих фрагментов одинакова - к... 10.03.05 22:57
Автор: Heller <Heller> Статус: Elderman
|
> Я специально уточнил, что кодогенератор не меняет СМЫСЛ
> сгенерированного кода, а может поменять сам код. И сказал я
> это к тому, что
>
> > cmp [ptr], 0
> jne is_not_null
>
> или
>
> cmp [ptr], 0
> je is_null
>
---
>
Однако и трудоёмкость обоих фрагментов одинакова - к оптимизации это мало отношения имеет. Если только не приходится jump'иться на большие расстояния, но эта проблема опять же легко решаема без оптимизатора, ручками. А компилятор в свою очередь, насколько я знаю, именно физическим размещением функций в памяти никак не управляет - строит всё в той последовательности, как это было написано на Си. Хотя здесь я не уверен на 100%.
> не имеет разницы и в данном обсуждении совершенно
> несущественно. Мне совершенно по фигу, в КАКОЙ КОД это
> скомпилируется. Гораздо важнее ИСХОДНЫЙ КОД на C++. И я это
> уже подчеркнул. Разрушить твою программу может не
> кодогенератор, а комитет по стандартизации
>
> > для построения кода (хотя при сравнении float'а с
> нулём
> > компилятор и строит хрень какую-то - cmp или test были
> бы и
> > проще и эффективнее - но это я уже склонен списывать
> на
> > баги Майкрософта).
>
> А ты уверен, что включил опцию оптимизации? :-)
> Я неоднократно убеждался, что оптимизатору можно доверять.
Уверен ;-)
> Надо внимательнее читать (в части про бутылочные горлышки).
> Человеку по силам оптимизировать 10-100 строк кода так,
> чтобы они были эффективнее того, что даст компилятор. Но
> проект в 1000-100000 строк кода совершенно невозможно не то
> что написать на ассемблере эффективно, а невозможно ВООБЩЕ.
>
> > 115940 - уже было подобное обсуждение. Да и то что я
> привёл
> > с float'ом при сравнении с нулём опять же не тянет на
> "не
> > по силам человекам". Я бы такое сравнение писал проще
> и
> > лучше. Мелочь, но однако.
>
> Интересно посмотреть. Хотя не зря бутылочные горлышки
> расширяются именно при помощи ручной оптимизации на
> ассемблере. И не зря они имеют мизерные размеры. Я Вам
> скажу почему: оптимальное распределение ограниченного
> набора регистров - NP-полная задача номер раз, оптимальная
> кодогенерация - NP-полная задача номер два. NP полные
> задачи решаются за экспоненциальное время от из размера.
> КАЖДАЯ дополнительная строка умножает сложность на
> определенную константу (пусть это будет 2). Оптимально
> написать 10 строк в 2 раза легче, чем 11. Написать 20 строк
> в 1024 раз сложнее, чем 10. Человек не способен справиться
> с этой сложностью.
Видимо, мы разные обсуждения имеем ввиду. Про бутылочные горлышки не помню. Что касается 1000-100000 строк кода, то, как уже заметил Den, "обычно оптимизируются соседние 3 - 7 мнемоник" - здесь вся сложность исключительно в больших объёмах кода на АСМе против компактности и наглядности Си.
>
> > Почему оно так называется понятно. Но что касается Си,
> то
> > он уж через чур "статический". Хоть убейте, но я не
> понимаю
> > зачем вообще разделять указатели. Какая разница,
> указывает
>
> Ну дык пиши на бейсике. Или наоборот на ассемблере. А еще
> рекомендую почитать про корректирующие коды и зачем нужна
> избыточность информации. Тебя не смущает что ЛЮБОЙ русский
> текст сжимается примерно на 60%. Это значит, что полезную
> нагрузку несет только 40% русской речи. Советую задуматься,
> а на фига остальные 60% (в английском эта цифра вообще
> около 75%).
>
> > он на int, char или вообще на другой указатель? Только
> что
> > бы программист сам при программировании не запутался?
> > Как-то это сомнительно.
>
> Ага, сомнительно. А ты подумай, подумай на хрена в русском
> языке 60% мусора.
Здесь-то как раз таки всё просто. Для записи любого символа на русском языке достаточно 6 бит, однако используется обычно 8. Это уже значит, что четверть можно выкинуть. Так же в русском тексте принято отделять тире пробелами и вообще ставить пробелы после всеми знаками препинания - их можно со спокойной совестью вырезать, но читать уже будет не удобно. Плюс ко всему этому - избыточность текста сама по себе ("а" встречается гораздо чаще "ы", а после "c" гораздо чаще идёт "е", чем "ъ"). Только если убрать всю избыточность - прочитать такой текст (который получится практически случайным) будет невозможно в силу строения человеческих органов речи.
А избыточность английского текста, кстати говоря, меньше, чем избыточность русского. Если он ужимается сильнее, то это происходит только по причине того, что сам алвавит меньше, в то же время для записи символов используются те же 8 бит. И вот за счёт уменьшения избыточности, правила чтения английского текста гораздо сложнее правил чтения русского. Уменьшите избыточность ещё немного и читать такой текст будет вообще невозможно.
Что же касается языков, то вообще-то избыточность АСМа значительно выше, чем избыточность Си, но это не делает АСМ более "прозрачным". Имхо, для нормального чтения, понимания и написания кода вполне достаточно различных скобок, комментариев и возможности вставлять неограниченное (в разумных пределах :-)) количество пробелов/переходов на новую строку. Статическая типизация указателей уже лишняя.
>
> > Думаю, теперь все вопросы прояснились. NULL - нулевой
> Все вопросы прояснились еще раньше. Когда Ktirf дал ссылку
> на 18-й параграф СТАНДАРТА (ага того, который ISO/IEC
> 14882)
>
> > указатель. Тип, на что именно NULL указывает, не
> важен.
> > Просто указатель на ноль. Если для вас и Страуструп не
> > стандарт, то я уж и не знаю :-)
> Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего
> лишь мануал :-)
Однако бОльшая часть людей изучает и программирует в последствии не по Стандарту, а именно по Страуструпу. К тому же, как показывает практика, ведущие разработчики ПО далеко не всегда к стандартам прислушиваются. Ну и как уже заметил Den, если стандарт и будет меняться, то обязательно с оглядкой на прошлые версии.
|
| | | | | | |
Епты, да что ж ты все про оптимизацию да про кодогенерацию 11.03.05 11:57
Автор: amirul <Serge> Статус: The Elderman
|
Диктую БОЛЬШИМИ БУКВАМИ: ЭТО НЕ ИМЕЕТ ОТНОШЕНИЯ К ОБСУЖДАЕМОМУ ВОПРОСУ.
> Однако и трудоёмкость обоих фрагментов одинакова - к
> оптимизации это мало отношения имеет. Если только не
Ты хоть помнишь в каком контексте ты это сказал? Мол, код одинаковый - значит методы сравнения эквивалентны. Я привел встречный пример, когда ОДИН И ТОТ ЖЕ исходник компилится в разные инструкции на асме. И ВСЕ. ВСЕГО ЛИШЬ ДЕМОНТРАЦИЯ ТОГО, ЧТО РЕЗУЛЬТИРУЮЩИЙ КОД НЕСУЩЕСТВЕННЕН.
> А компилятор в свою очередь, насколько я знаю, именно
> физическим размещением функций в памяти никак не управляет
> - строит всё в той последовательности, как это было
> написано на Си. Хотя здесь я не уверен на 100%.
И компилятор и линкер этим и занимаются. В том числе и выравниванием кода по границе кеш-строки и прочим "размещением в памяти". НО ЭТО НЕ ОТНОСИТСЯ К ОБСУЖДАЕМОМУ ВОПРОСУ
> Видимо, мы разные обсуждения имеем ввиду. Про бутылочные
> горлышки не помню. Что касается 1000-100000 строк кода, то,
> как уже заметил Den, "обычно оптимизируются соседние 3 - 7
> мнемоник" - здесь вся сложность исключительно в больших
> объёмах кода на АСМе против компактности и наглядности Си.
Оптимизация 3-7 соседних строк - не оптимизация вообще. Лучшая оптимизация - вообще сквозная по всей программе (но таких оптимизаторов пока нет, вернее есть но методы сквозной оптимизации довольно плохие)
ПОВТОРЮСЬ, ОПТИМИЗАЦИЯ НЕ ОТНОСИТСЯ К СУТИ ВОПРОСА
> Здесь-то как раз таки всё просто. Для записи любого символа
> на русском языке достаточно 6 бит, однако используется
> обычно 8. Это уже значит, что четверть можно выкинуть. Так
Это не 60%
> же в русском тексте принято отделять тире пробелами и
> вообще ставить пробелы после всеми знаками препинания - их
> можно со спокойной совестью вырезать, но читать уже будет
> не удобно. Плюс ко всему этому - избыточность текста сама
Пробелы несут даже меньше т.н. невербальной информации, чем передается при обычном разговоре, так что речь даже более избыточна, чем письмо.
> по себе ("а" встречается гораздо чаще "ы", а после "c"
> гораздо чаще идёт "е", чем "ъ"). Только если убрать всю
> избыточность - прочитать такой текст (который получится
> практически случайным) будет невозможно в силу строения
> человеческих органов речи.
Ага, если бы у бабушки был член - она была бы дедушкой. Придумать неизбыточный язык, доступный человеческим органам речи легко, вот только послушай анекдот:
У одной женщины был муж петр. Поехала эта женщина в командировку в сша. По приезду прямо с трапа самолета, завидев мужа и решив блеснуть интеллектом, закричала
- Hello, Peter
Когда подошла к мужу, он отвесил ей оплеуху и сказал
- Это тебе за @#$ло. А дома еще за @#$%ра получишь
Теперь представь, что было бы если ВСЕ слова в языке имели такие коллизии и их смысл менялся от того, что слегка меняется один звук.
> А избыточность английского текста, кстати говоря, меньше,
> чем избыточность русского. Если он ужимается сильнее, то
> это происходит только по причине того, что сам алвавит
> меньше, в то же время для записи символов используются те
> же 8 бит. И вот за счёт уменьшения избыточности, правила
> чтения английского текста гораздо сложнее правил чтения
> русского. Уменьшите избыточность ещё немного и читать такой
> текст будет вообще невозможно.
Ты чего. Избыточность английского ВЫШЕ. А правила русского языка, кстати, гораздо сложнее английского.
> Что же касается языков, то вообще-то избыточность АСМа
> значительно выше, чем избыточность Си, но это не делает АСМ
> более "прозрачным". Имхо, для нормального чтения, понимания
Избыточность асма ГОРАЗДО ниже, чем C. И еще ниже, чем C++
> и написания кода вполне достаточно различных скобок,
> комментариев и возможности вставлять неограниченное (в
> разумных пределах :-)) количество пробелов/переходов на
> новую строку. Статическая типизация указателей уже лишняя.
Ага, для "hello, world"-а достаточно. А для больших проектов не хватает уже и статической типизации.
> Однако бОльшая часть людей изучает и программирует в
> последствии не по Стандарту, а именно по Страуструпу. К
Если они вдруг прочитают в страуструпе чего то, не согласующееся со стандартом - это исключительно их проблемы.
> тому же, как показывает практика, ведущие разработчики ПО
> далеко не всегда к стандартам прислушиваются. Ну и как уже
Это проблемы разработчиков. Если ты найдешь место, которое не согласуется со стандартом, ты имеешь полное право сидеть и долбить этих разработчиков пока они не сделают так как НУЖНО
> заметил Den, если стандарт и будет меняться, то обязательно
> с оглядкой на прошлые версии.
Как уже заметил я, чего делать с NULL-ом в комитете еще не решили и в следующих версиях все может СИЛЬНО измениться.
|
| | | | | | | |
А может быть за перенос проголосовать? 12.03.05 06:38
Автор: Heller <Heller> Статус: Elderman
|
Всей этой ветки, начиная с "углубился я в дизассемблер".
Ладно, оставим в стороне вопрос оптимизации и кодогенерации, раз он так не нравится, но вот про статистику не могу молчать.
> Ты чего. Избыточность английского ВЫШЕ. А правила русского
> языка, кстати, гораздо сложнее английского.
Это ты чего. Ссылка: http://libbb.by.ru/lecmatlog10.htm?extract=1110591938 (двойной поиск по странице слова "избуточность" приведёт к конкретным цифрам). Конечно, не самый авторитетный источник, но это к сожалению всё что удалось найти.
И правила английского языка ТРУДНЕЕ (я имею ввиду только фонетику - остальное в данном случае не важно, именно поэтому я и говорил об органах речи). Любую букву русского языка я могу прочитать только одним способом (то что в слове "молоко" слышится буква "а" не есть значительно для восприятия - можно читать и с буквой "о"). Единственное, согласные могут быть мягкими и твёрдыми, но как именно читать в каждом конкретном случае - опять же доподлинно известно (либо "ь/ъ" нам об этом говорит, либо идущая вслед за согласной составная гласная). Теперь вспомни сколько правил чтения приходится в английском языке на каждую отдельно взятую букву, да плюс к тому если ещё исключения посчитать..
> > Что же касается языков, то вообще-то избыточность АСМа
> > значительно выше, чем избыточность Си, но это не
> делает АСМ
> > более "прозрачным". Имхо, для нормального чтения,
> понимания
>
> Избыточность асма ГОРАЗДО ниже, чем C. И еще ниже, чем C++
Да, блин, как же это? По определению, если на пальцах, то избыточность - это количество текста, которое можно выкинуть без ущерба для информации.
Пример на Си:
a=b+c
То же самое на АСМе:
mov ax, a
add ax, b
mov c, ax
И это я ещё не указывал в коде конкретных типов. Просто сравните объёмы c учётом того, что смысл здесь один и тот же. А в экзешнике получится так вообще девять байтов.
> > и написания кода вполне достаточно различных скобок,
> > комментариев и возможности вставлять неограниченное (в
> > разумных пределах :-)) количество пробелов/переходов
> на
> > новую строку. Статическая типизация указателей уже
> лишняя.
>
> Ага, для "hello, world"-а достаточно. А для больших
> проектов не хватает уже и статической типизации.
Ну, не только "hello, world" мне писать доводилось. Если уж ТАКАЯ НЕОБХОДИМОСТЬ жёстко задать тип указателя, кто мешает сделать это в его имени? Например как-то так:
int a;
ptr xxx_int=&a;
ptr - это я "ввёл" такой тип нетипизированного указателя.
>
> > Однако бОльшая часть людей изучает и программирует в
> > последствии не по Стандарту, а именно по Страуструпу.
> К
>
> Если они вдруг прочитают в страуструпе чего то, не
> согласующееся со стандартом - это исключительно их
> проблемы.
>
> > тому же, как показывает практика, ведущие разработчики
> ПО
> > далеко не всегда к стандартам прислушиваются. Ну и как
> уже
>
> Это проблемы разработчиков. Если ты найдешь место, которое
> не согласуется со стандартом, ты имеешь полное право сидеть
> и долбить этих разработчиков пока они не сделают так как
> НУЖНО
Да ладно. А то прям так сразу в Майкросовте кинутся исправлять все несоответствия. Всять хотя бы ситуацию с вэб-буилдингом. Каждый браузер по-своему уникален и плевать все хотели на W3C. Особенно если вспонить давнишнее противостояние MS и Netscape, когда два браузера отличались вообще ПРИНЦИПИАЛЬНО.
>
> > заметил Den, если стандарт и будет меняться, то
> обязательно
> > с оглядкой на прошлые версии.
> Как уже заметил я, чего делать с NULL-ом в комитете еще не
> решили и в следующих версиях все может СИЛЬНО измениться.
В этом самом комитете, я думаю, понимают, что если уж вводить стандарт, то делать это надо так, что бы люди не пострадали. Поэтому лично я не вижу поводов для опасения. Да и потом, даже если комитет и разрушит мой код, то что мне мешает сделать глобальную замену во всех моих проетах NULL'а на упомянутый уже (void *) 0? Это займёт от силы пол часа.
|
| | | | | | | | |
А может быть за закрытие? 14.03.05 14:13
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
А то стока флейма развели буквально на пустом месте.. Сорри за каламбур Ж)
|
| | | | | | | | | |
Не, всё же за перенос (имхо) 14.03.05 15:09
Автор: Heller_ne_smog_zaloginitsya Статус: Незарегистрированный пользователь
|
> А то стока флейма развели буквально на пустом месте.. Сорри
> за каламбур Ж)
Согласен, что флейм, да ещё и на пустом месте. Но вот лично я во флейме как таковом ничего плохого не вижу, тем более если он тематический. А вот то что происходит он в ветке, никакого отношения ни к оптимизации, ни к стандартам, ни к лингвистике не имеющей - это уже не хорошо. По-моему, этому обсуждению самое место в misc'е с пометкой в сабже [flame].
Или я бы вообще создал отдельную доску для флейма. Всё таки misc это немного не то, а scrap это всё же помойка, хотя в описании через запятую и идёт "флейм". А пофлеймить иногда ужас как хочется :-)
|
| | | | | | | | | | |
По моему сказано достаточно. Я бы уже закрыл. 14.03.05 15:23
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
| | | | | | | | |
По поводу языка спорить не буду - не лингвист. Но я точно... 14.03.05 12:43
Автор: amirul <Serge> Статус: The Elderman
|
По поводу языка спорить не буду - не лингвист. Но я точно читал где то, что русский язык - один из самых сложных для изучения (после китайских/вьетнамских). А на более высокую избыточность английского указывает хотя бы жесткий порядок слов в предложении.
> > Избыточность асма ГОРАЗДО ниже, чем C. И еще ниже, чем
> C++
> Да, блин, как же это? По определению, если на пальцах, то
> избыточность - это количество текста, которое можно
> выкинуть без ущерба для информации.
А вот тут речь уже идет об избыточности языка, а не текстов программ. Жесткая типизация - один из способов повышения избыточности. Если же говорить о тексте, то самым избыточным языком, который я знаю, является Ook:
http://en.wikipedia.org/wiki/Ook
> Пример на Си:
> a=b+c
> То же самое на АСМе:
> mov ax, a
> add ax, b
> mov c, ax
> И это я ещё не указывал в коде конкретных типов. Просто
> сравните объёмы c учётом того, что смысл здесь один и тот
> же. А в экзешнике получится так вообще девять байтов.
А вот C++ тянет с каждой переменной ее тип и в зависимости от этого принимает множество решений. На асме никакой дополнительной информации, кроме самих инструкций нет.
> > Ага, для "hello, world"-а достаточно. А для больших
> > проектов не хватает уже и статической типизации.
> Ну, не только "hello, world" мне писать доводилось. Если уж
> ТАКАЯ НЕОБХОДИМОСТЬ жёстко задать тип указателя, кто мешает
> сделать это в его имени? Например как-то так:
> int a;
> ptr xxx_int=&a;
> ptr - это я "ввёл" такой тип нетипизированного указателя.
И что помешает тебе использовать твой xxx_int не по назначению? Говорю же, что в больших проектах даже статической типизации становится мало и программисты начинают вводить избыточность, которая не поддерживается языком напрямую (например Принцип подстановки Лискоу, Принцип инверсии зависимостей и пр.)
> Да ладно. А то прям так сразу в Майкросовте кинутся
> исправлять все несоответствия. Всять хотя бы ситуацию с
> вэб-буилдингом. Каждый браузер по-своему уникален и плевать
> все хотели на W3C. Особенно если вспонить давнишнее
> противостояние MS и Netscape, когда два браузера отличались
> вообще ПРИНЦИПИАЛЬНО.
Ну к рекомендациям w3c стараются все таки прислушиваться. А вот в расширениях стандарта - там да, разница принципиальная
> В этом самом комитете, я думаю, понимают, что если уж
> вводить стандарт, то делать это надо так, что бы люди не
> пострадали. Поэтому лично я не вижу поводов для опасения.
> Да и потом, даже если комитет и разрушит мой код, то что
> мне мешает сделать глобальную замену во всех моих проетах
> NULL'а на упомянутый уже (void *) 0? Это займёт от силы пол
> часа.
Во первых (void *)0 - НЕДОПУСТИМОЕ определение NULL-а в C++, а во-вторых пробемы могут быть гораздо глубже
|
| | | | | | | | | |
Не знаю на счет Ook, но ИМХО, С++ избыточнее Паскаля и... 14.03.05 15:16
Автор: Den <Денис Т.> Статус: The Elderman
|
> А вот тут речь уже идет об избыточности языка, а не текстов
> программ. Жесткая типизация - один из способов повышения
> избыточности. Если же говорить о тексте, то самым
> избыточным языком, который я знаю, является Ook:
> http://en.wikipedia.org/wiki/Ook
Не знаю на счет Ook, но ИМХО, С++ избыточнее Паскаля и кол-во типов тут ни причем. В Паскале типов не на много больше чем в Си, зато нет перегрузки операторов (особенно, если один оператор перегружается разными действиями с разными типами), которая, на мой взгляд, очень затрудняет чтение исходных текстов и является для меня ПЕРЕизбыточностью.
> А вот C++ тянет с каждой переменной ее тип и в зависимости
> от этого принимает множество решений. На асме никакой
> дополнительной информации, кроме самих инструкций нет.
Да нет же... Про асм, это тебе приснилось. :))
Попробуй на асме описать переменную, как BYTE (DB), а затем обратиться к ней из программы следующим образом: mov ax, переменная
> И что помешает тебе использовать твой xxx_int не по
> назначению? Говорю же, что в больших проектах даже
> статической типизации становится мало и программисты
> начинают вводить избыточность, которая не поддерживается
> языком напрямую (например Принцип подстановки Лискоу,
> Принцип инверсии зависимостей и пр.)
Дык этож хорошо! При написании больших проектов на асме используется модульное программирование, в котором файлы *.inc содержат EXTERNDEF, описние типов и констант модуля, необходимые для использования в других модулях. Такое положение дел не позволит опытному кодеру запутаться в проекте.
> Во первых (void *)0 - НЕДОПУСТИМОЕ определение NULL-а в
> C++, а во-вторых пробемы могут быть гораздо глубже
А какое определение допустимое?
|
| | | | | | | | | | |
Паскаль - вообще язык для обучения, а не для программирования 14.03.05 15:46
Автор: amirul <Serge> Статус: The Elderman
|
> Не знаю на счет Ook, но ИМХО, С++ избыточнее Паскаля и
> кол-во типов тут ни причем. В Паскале типов не на много
> больше чем в Си, зато нет перегрузки операторов (особенно,
> если один оператор перегружается разными действиями с
> разными типами), которая, на мой взгляд, очень затрудняет
> чтение исходных текстов и является для меня
> ПЕРЕизбыточностью.
Выражение "статический полиморфизм" слыхал? Ну не нравится тебе перегрузка - не пользуйся. Равно как и темплейтами. Никто ж не заставляет
> Да нет же... Про асм, это тебе приснилось. :))
> Попробуй на асме описать переменную, как BYTE (DB), а затем
> обратиться к ней из программы следующим образом:
> mov ax, переменная
Гы. Размер переменной еще не тип. Просто поверь на слово: написать большой проект на асме невозможно. И не надо всякие menuetos-ы приводить. Во первых не такой уж он и большой, а во вторых игра не стоит свеч. Во многих случаях C-шный код скомпилируется в не худший (а иногда и лучший) машинный код. Вот только с контролем типов жить проще и писать быстрее.
> Дык этож хорошо! При написании больших проектов на асме
> используется модульное программирование, в котором файлы
> *.inc содержат EXTERNDEF, описние типов и констант модуля,
> необходимые для использования в других модулях. Такое
> положение дел не позволит опытному кодеру запутаться в
> проекте.
При чем тут модульное программирование? Модульное программирование - всего лишь одна из попыток решить проблему абстракции данных. В том же C++ это решено гораздо лучше (при сохранении поддержки модульного программирования). А запутаться в проекте проще простого. Все зависит от размера проекта.
Аргумент в пользу асма - мол ручная оптимизация рулит не прокатывает. Потому как ручная оптимизация больших участков кода - миф, а для небольших достаточно и inline-ассемблера в C/C++
> > Во первых (void *)0 - НЕДОПУСТИМОЕ определение NULL-а
> в
> > C++, а во-вторых пробемы могут быть гораздо глубже
>
> А какое определение допустимое?
0 или 0L
Сноска в параграфе 18 стандарта
|
| | | | | | | | | | | |
Да ладно, Серж, забей... Расслабься! С Днем Рождения!!! ;) 14.03.05 18:26
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
| | | | | | | | |
Эх... не удержался всё ж ;)) 12.03.05 09:23
Автор: void <Grebnev Valery> Статус: Elderman
Отредактировано 12.03.05 09:28 Количество правок: 1
|
> > Ты чего. Избыточность английского ВЫШЕ. А правила
> русского
> > языка, кстати, гораздо сложнее английского.
> Это ты чего. Ссылка:
> http://libbb.by.ru/lecmatlog10.htm?extract=1110591938
> (двойной поиск по странице слова "избуточность" приведёт к
Поскольку я слегка туповат, чтоб высказаться по существу вопросов, всёж выскажусь в части английского и избыточности... Дяденька в той статье говорит о том, что дескать можно анализировать частоту букв и прочая. Абсурд. Поскольку языком пользуется человек, а не вычислительная машина. Человек никогда (в отличие от вычислительной машины, кстати) не читает буквы. Вы удивитесь, но человек всегда читает целиком слова. Напротив, машина же анализирует буквы.
Наспивер, вы доытамычно янсо читвуте эту фразу. Фрпзы и предвафения с длинвыми словами читаются даже увереннее.
И наоборот, если бы я написал транслитом то, что выше - то читать было бы гораздо труднее. Потому, что вы читали бы буквы (которые пробует сосчитать "дяденька" ;)) ).
Русский - построен на суфиксах и окончаниях, и префиксах. Это основное. Поэтому русский человек читает первую(вые) букву, последнюю(ние) вконтексте Формула, как бы такая: первые буквы + последние буквы + контекст == слово.
Ну, а про английский (что я знаю ещё хуже, чем С/С++), могу сказать, что этот язык,на_мой_взгляд действительно один из самых компактных в мире. Но даже живущие "там" не все этим владеют. Одно и тоже можно выразить очень компактно (понять смысл можно только в контексте всего предложения) и более пространно (зато предложение можно читать, как бы по частям, и доступно даже среднему уровню владения языком). В хороших, дорогих газетах - блестящий английский. Есть простые (доступные по языковому уровню кусвйцам и прочим авимтам). Там таки да - похоже на то, что в школах у нас преподают.
ПС. Тут меня понесло ... Так что простите, ежели ерундус спорол.
|
| | | | | |
Сори, парни... Что-то я не совсем догоняю суть проблемы. В чем сопсна?... 10.03.05 21:32
Автор: Den <Денис Т.> Статус: 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 указывает, не
> важен.
> > Просто указатель на ноль. Если для вас и Страуструп не
> > стандарт, то я уж и не знаю :-)
> Ты будешь удивлен, но страуструп - НЕ СТАНДАРТ, а всего
> лишь мануал :-)
Пф-ф-ф-ф...
|
| | | | | | |
Да я тоже не понимаю, при чем тут оптимизация и сгенерированный код 11.03.05 12:18
Автор: amirul <Serge> Статус: The Elderman
|
> Уверен на 100%, что пересматривать стандарт Си в отношении
> значения NULL никто не будет, хотябы по соображениям
> обратной совместимости с уже имеющимися реализациями
> готовых компиляторов под существующие платформы.
Вот тут ты ГЛУБОКО заблуждаешься, на данный момент с NULL-ом столько проблем, что просто НЕОБХОДИМО с ним чего нибудь сделать.
> Если бы комитет по стандартизации мог разрушить чей-то код,
> тогда MS VC и Borland C++ Builder были бы братья близнецы
> со всеми вытекающими...
Не факт. Стандарт говорит только о том, какой СМЫСЛ имеет тот или иной код. Разница между BCB и MSVC как раз в качестве кода, удобстве среды программирования, собственных расширениях стандарта и т.д.
> Если ты про оптимизатор от WatCom, то доверять можно. ;)
MSVC-шный тоже дает весьма неплохой код при хорошей скорости компиляции
> Ну дык... Все зависит от дальности перехода по условию.
Да при чем тут дальность. СМЫСЛ не нарушается и это уже дело компилятора, что он посчитает нужным туда вставить
> А это как? Ты про .NET?
Нет, у дотнета свой байт-код есть. Я о C++ машине, которая воспринимает C++ непосредственно
> Ты ошибаешься. Есть люди, которые подсознательно помнят все
> правила оптимизации кода начиная с i386 и пишут на
> ассемблере оптимизируя налету, причем даже не задумываясь.
Нет, ошибаешься как раз ты. МАТЕМАТИЧЕСКИ доказано, что задачи оптимальной кодогенерации и оптимального распределения регистров NP-полные. Если найдешь человека, который "подсознательно" решает NP-полные задачи - покажи его мне. Мне можно будет умереть со словами "теперь я видел ВСЕ".
> Да не... Обычно оптимизируются соседние 3 - 7 мнемоник,
> поэтому, сложность ручной оптимизации не вырастает в разы,
> а скорее переходит в константу для одтельно взятой "версии"
> проца.
Оптимизация 3-7 мнемоник - не оптимизация вообще. ТАКУЮ оптимизацию может сделать любой компилятор в миллионы раз быстрее человека простым перебором вариантов
> Если бы существовал платформонезависимый ассемблер, мы бы
> им пользовались.
Ню-ню.
> Для проверки типа при компиляции и уменьшения ошибок
> кодирования.
"Ты знал" (с) :-)
> Пф-ф-ф-ф...
Так отож :-)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
