|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Kirill Frolov 2:5030/827.2 08 Nov 2003 03:30:16
To : All
Subject : Re: Kylix крек
--------------------------------------------------------------------------------
On Fri, 07 Nov 03 05:52:01 +0300, Alexandr Molchevsky wrote:
AM>>> То есть программный код который ты пишешь на С/С++ для тебя
AM>>> всегда очевиден?
KF>> Если он для меня не очевиден, я его и писать не буду. Можно ведь
KF>> записать проще, или хотя-бы проверить что получается.
AM> то есть глянув на с = а + b; ты сразу можешь сказать что делает этот
AM> код будучи собранным любым компилятором?
Для того чтобы глянуть и сказать нужно хоть понять, что C и
C-два-креста это совершенно разные языки и мешать всё в кучу не стоит.
KF>> А приведённый пример, в оператором "++" -- это сплошное кулхакерство,
KF>> которое и без компилятора порождает массу неочевидностей. Если язык
KF>> такое позволяет не значит, что кто-то будет так писать.
AM> Это же только маленький примерчик, да и то очевидный. Его можно легко
AM> привести к виду когда хрен догадаешься что в результате получиться
AM> именно это.
Везде русским по белому написано, что поведение компилятора не
определено, порядок вычисления операндов тоже. Можно сдуру и всяких
глупостей наделать, это ещё ничеого не значит.
KF>> Уж от языка это не зависело. И кроме того, об очевидных
KF>> неопределённостях любой честный компилятор предупреждает.
AM> Вот если бы он предупреждал о неочевидных.
Hапример, об "if (a=b)" предупреждают практически все.
AM> А вообще он уже умеет предупреждать о выходе за пределы массива,
AM> например?
Для ассемблера это не нужно. Адресация за пределами массива может
быть задумана программистом. Тем более, что и массивов-то нет. Это всё
сплошь индексная адресация, как в процессоре.
AM> Можно тогда вспомнить, например, о понятии символьного типа со знаком в
AM> одном чудесном языке. :)
Это не символьный тип, это считай байт. Против знакового типа есть
более весомые аргументы вроде переполнения. Что касается именно
символов, то проблемы создаёт вовсе не знак.
AM> Практически как раз получается что не одно и то же, хотя бы, потому что
AM> программеры ошибок делат меньше а работают быстрее на паскале и иже с ним.
Весьма спорное утверждение.
--- [ZX]
* Origin: Зенит -- чемпион! (2:5030/827.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
