Oberon space
General Category => Общий раздел => Тема начата: vlad от Январь 27, 2012, 05:12:40 am
-
Предлагаю обсудить здесь тему отсюда: http://forum.oberoncore.ru/viewtopic.php?p=70068#p70068 (http://forum.oberoncore.ru/viewtopic.php?p=70068#p70068)
По поводу нулевых указателей. Проблема частично языковая (нет в языке средств статического контроля). Но чаще всего это следствие дизайна. Компонент допускает "непроиниченность". Или задает протокол типа "get/set", делегируя на пользователя ответственность за то, что и когда туда выставляется и берется. Ошибиться становится легко.
По поводу второго пункта. Не уверен, что правильно понял в чем проблема. Как я понял, речь идет о том, что есть красивый общий интерфейс, который подразумевает функциональность, которая на деле реализована лишь частично. Мой подход такой, что красивый интерфейс приносится в жертву суровой реальности. Либо неподдерживаемая функциональность ассертится сразу на входе.
Про себя могу сказать, что чисто технических ошибок очень мало. Основная масса ошибок в каких-то неучтенных сценариях взаимодействия компонентов.
-
По поводу нулевых указателей. Проблема частично языковая (нет в языке средств статического контроля). Но чаще всего это следствие дизайна. Компонент допускает "непроиниченность". Или задает протокол типа "get/set", делегируя на пользователя ответственность за то, что и когда туда выставляется и берется. Ошибиться становится легко.
Что имеется в виду под непроиниченностью? Непосредственно нулевой указатель?
-
Что имеется в виду под непроиниченностью? Непосредственно нулевой указатель?
Нет, речь идет об уровне выше - компоненте и его дизайне. Попробую на примере:
converter = create_converter();
converter.set_source(source);
converter.set_destination(destination);
converter.run();
В данном случае дизайн компонента (converter) допускает, что его могут попросить что-то сконвертировать (вызвать run) не указав откуда и куда. В случае, если source и destination - объекты, получим обсуждаемое разыменование нулевого указателя. Мало того, в каждом методе этого компонента (если там будет что-то кроме run) - надо будет проверить (ASSERT), что source и destination не нулевые. Головная боль и писателю компонента, и пользователю.
Если переделать вот так:
converter = create_converter(source, destination);
converter.run();
То пользователю труднее ошибиться. Код проще, ошибок меньше, проверять указатели надо только один раз - в create_converter (пользователь, естественно, не имеет доступа к set_source/set_destination).
P.S. Существуют рекомендации для С++ (в том числе от самой M$) о том как полезно разносить создание объекта (конструктор) и его инициализацию (какой-нибудь Create). Архивредная "рекомендация" и антипаттерн.
-
Ну да, я тоже такие многоступенчатые инициализации не люблю. И в простых случаях стараюсь передать все нужные данные в конструкторе. А то при отсутствии NIL непонятно, как объекты возвращать из прцедур : ).
-
Данный дизайн (допускающий отложенную инициализацию) подразумевает возможное использования экземпляра класса в течении длительного времени(либо повторные использования экземпляра), если бизнес логика КОНЕЧНОГО приложения подразумевает частичное использование функциональности компонента и ДОПУСТИМО его небольшое время жизни - (в моей практике весьма частый случай)- я предпочитаю делать wrapperы в виде функций (компонента создается локально).
-
Данный дизайн (допускающий отложенную инициализацию) подразумевает возможное использования экземпляра класса в течении длительного времени(либо повторные использования экземпляра),
Это единственное разумное объяснение. Но даже в таком виде - это premature optimization. Со всеми описанными проблемами.
если бизнес логика КОНЕЧНОГО приложения подразумевает частичное использование функциональности компонента и ДОПУСТИМО его небольшое время жизни - (в моей практике весьма частый случай)- я предпочитаю делать wrapperы в виде функций (компонента создается локально).
Угу. Создание враппера как раз подтверждает, что оригинал задизайнен плохо. Компонент изначально должен быть с макимально простым и однозначным интерфейсом, недопускающим разных толкований и неоднозначностей. А вот если нам нужна оптимизация - ничинаем коверкать дизайн.
-
Угу. Создание враппера как раз подтверждает, что оригинал задизайнен плохо. Компонент изначально должен быть с макимально простым и однозначным интерфейсом, недопускающим разных толкований и неоднозначностей. А вот если нам нужна оптимизация - ничинаем коверкать дизайн.
Да нет, чаще всего это означает, что функциональность используемого компонента в КОНЕЧНОМ приложении - излишняя (это, с моей точки зрения, вполне допустимое "зло"). Нда, кстати - одно из немногих (в моей практике) применений замыканий - использование их именно в ПОДОБНЫХ ситуациях - они позволяют консервировать ресурсы программы (использовать один и тот же экземпляр БЕЗОПАСНО много раз в течении длительного времени). Мм все ожидал, что наши любители функциональщины приведут пример в этом роде, ну ладно...
-
Да нет, чаще всего это означает, что функциональность используемого компонента в КОНЕЧНОМ приложении - излишняя (это, с моей точки зрения, вполне допустимое "зло").
Да, такой вариант, конечно, тоже может быть. И это не зло.
Нда, кстати - одно из немногих (в моей практике) применений замыканий - использование их именно в ПОДОБНЫХ ситуациях - они позволяют консервировать ресурсы программы (использовать один и тот же экземпляр БЕЗОПАСНО много раз в течении длительного времени). Мм все ожидал, что наши любители функциональщины приведут пример в этом роде, ну ладно...
Для меня замыкания - это прежде всего дешевый способ избавиться от ненужных зависимостей. Дешевый по сравнению с созданием новых интерфейсов и т.д. по все строгости ООП.
-
Нда, кстати - одно из немногих (в моей практике) применений замыканий - использование их именно в ПОДОБНЫХ ситуациях - они позволяют консервировать ресурсы программы (использовать один и тот же экземпляр БЕЗОПАСНО много раз в течении длительного времени). Мм все ожидал, что наши любители функциональщины приведут пример в этом роде, ну ладно...
Это что же, долгоживущий мутабельный объект? Это же зло с точки зрения ФП...
-
Это что же, долгоживущий мутабельный объект? Это же зло с точки зрения ФП...
С другой стороны, плодить на каждый чих новый объект - тоже зло.
Это противоречие довольно удачно решено в языке Clean. Там можно менять содержимое объекта и не отступать от ФП.
-
Это что же, долгоживущий мутабельный объект? Это же зло с точки зрения ФП...
С другой стороны, плодить на каждый чих новый объект - тоже зло.
Это противоречие довольно удачно решено в языке Clean. Там можно менять содержимое объекта и не отступать от ФП.
Трудно сказать -- удачно или нет. По отзывам, уникальные типы не так уж и удобны на практике...
-
Это что же, долгоживущий мутабельный объект? Это же зло с точки зрения ФП...
А причем тут это? Я попытался сказать о "естественном" (с моей точки зрения) применении элементов ФЯП в контексте реальных "практических" случаев (обсуждаемых в этой ветке). И это использование (в противовес к точке зрения Алексея - о ненужности многословных лямбд и замыканий) не сводится к "сахару" ,т.е. формально может быть оправданием введения многословных "REFERENCE TO PROCEDURE" в ИЯП.
-
Тем временем на оберонкоре просиходит забавное:
Вспомнил ещё одну довольно шаблонную ошибку. Это отсутствие явной инициализации полей.
Например, если в процедуре записи в базу данных используется (часто объявляемая локально) некая структура, поля которой совпадают с полями таблицы на сервере и какое-то поле непроинициализировать, то в базу может улететь произвольное значение. Зачастую это приводит к совершенно загадочному поведению системы и отыскать причину бывает проблематично.
Я для таких дел имел процедуру ZeroRec (имя, как в Дельфе) и ей зачищал записи до использования.
В качестве замечания: инициализация # зануление; ZeroRec, об которой речь, требует IMPORT SYTSTEM.
То есть в КП (Компонентном Паскале) для повышения надежности модуля (обязательного зануления (хотя бы) полей записи) нужно делать IMPORT SYSTEM. То есть пользоваться низкоуровневыми платформозависимыми возможностями.
Что-то меня с этого когнитивно диссонансит
-
То есть в КП (Компонентном Паскале) для повышения надежности модуля (обязательного зануления (хотя бы) полей записи) нужно делать IMPORT SYSTEM. То есть пользоваться низкоуровневыми платформозависимыми возможностями.
Что-то меня с этого когнитивно диссонансит
Насколько я понимаю, тут речь идет о процедуре на все случае жизни (работающей для произвольной записи) - а что удивительного ? Хотя, лично я предпочитаю на каждый определенный тип записи иметь фабричную функцию - всех проблем не решает, но пусть хоть компилятор проверит наличие факта передачи значений ВСЕХ полей. А по поводу дефолтной инициализации - так с пол года назад у нас Игорем здесь на форуме был обмен мнениями...а еще раньше был comdiv со своими предложениями...
-
Насколько я понимаю, тут речь идет о процедуре на все случае жизни (работающей для произвольной записи) - а что удивительного ?
Изначально Вирт и компания предполагали SYSTEM использовать в не безопасных модулях не портабельных модулях. То есть, по сути, в Обероне если модуль импортирует SYSTEM, то это метка, что модуль не безопасный и, возможно, не портабельный.
Тут же предлагается импортировать SYSTEM для повышения безопасности модуля.
Таким образом, практически любой модуль будет импортировать SYSTEM. Что делает любой модуль потенциально опаснобезопасным. Стирается грань. Это не хорошо.
-
А язык тут причем? - надо Илье сказать - айайайай, и укоризненно покачать пальцем :D
-
А язык тут причем? - надо Илье сказать - айайайай, и укоризненно покачать пальцем :D
Язык при том, что не позволяет это сделать универсально, удобно и быстро (по производительности) без подобных хаков :-)
-
А язык тут причем? - надо Илье сказать - айайайай, и укоризненно покачать пальцем :D
Язык при том, что не позволяет это сделать универсально, удобно и быстро (по производительности) без подобных хаков :-)
А с чего вы взяли что он ДОЛЖЕН это делать? ;)
-
А с чего вы взяли что он ДОЛЖЕН это делать? ;)
Ну, если нам нужен действительно безопасный язык, то либо он сам должен всегда занулять (точнее забивать дефолтными значениями, дефолтное значение зависит от типа) все поля записей и прочее (предоставляя возможность прагмой или как-то иначе отрубить это забивание в данном конкретном месте), либо он должен предоставить возможность написать самому подобное используя лишь безопасные средства языка.
Скажем в D можно и так и эдак. То есть по умолчанию он всегда инициализирует все дефолтными значениями, зависящими от типа данных. Это можно отключить в данном конкретном месте, если там мы экономим такты процессора. Но если бы даже этого и не было бы, то в D это можно было бы сделать средствами метапрограммирования времени компиляции (то есть накладных расходов в рантайме будет не больше чем от возможности вшитой в язык). И все это не покидая уютненького safe-подмножества D. И никаких IMPORT SYSTEM.
-
А с чего вы взяли что он ДОЛЖЕН это делать? ;)
Ну, если нам нужен действительно безопасный язык, то либо он сам должен всегда занулять (точнее забивать дефолтными значениями, дефолтное значение зависит от типа) все поля записей и прочее (предоставляя возможность прагмой или как-то иначе отрубить это забивание в данном конкретном месте), либо он должен предоставить возможность написать самому подобное используя лишь безопасные средства языка.
Скажем в D можно и так и эдак. То есть по умолчанию он всегда инициализирует все дефолтными значениями, зависящими от типа данных. Это можно отключить в данном конкретном месте, если там мы экономим такты процессора. Но если бы даже этого и не было бы, то в D это можно было бы сделать средствами метапрограммирования времени компиляции (то есть накладных расходов в рантайме будет не больше чем от возможности вшитой в язык). И все это не покидая уютненького safe-подмножества D. И никаких IMPORT SYSTEM.
Ну вы даете... вроде давно уже было показано, что текущие Обероны это плод комплексных усилий Вирта и К . в которые входят 1. стремление к примитивизму 2. Стремление к универсальности 3. Неспособность рассматривать текущие реалии 4. ... И тупое нежелание увеличивать описание языка хотя бы на страницу. :D Как результат - имеет то , что имеем. Нетривиальным (по крайней мере, для меня) является вопрос об области наиболее эффективного использования их творений...
:D :D
-
Кстати, вопрос к Илье - а не лучше ли подобные средства для обеспечения пущей безопасности, которые, тем не менее реализуются через системные возможности (типа ZeroRec), то есть требуют SYSTEM, завернуть в еще один модуль?
То есть есть SYSTEM.ZeroRec и компания. Берем, пишем какой-нибудь модуль SafeInit, уже в нем импортируем SYSTEM, и определяем SafeInit.ZeroRec, в которой дергается уже SYSTEM.ZeroRec. Таким образом модули которым SYSTEM не нужен, а безопасное зануление переменных для пущей безопасности, нужно, будут импортировать лишь SafeInit c безопасной функцией ZeroRec. А IMPORT SYSTEM останется для тех, кому нужны не безопасные возможности этого система, для неких своих низкоуровневых грязных хаков.
-
Кстати, вопрос к Илье - а не лучше ли подобные средства для обеспечения пущей безопасности, которые, тем не менее реализуются через системные возможности (типа ZeroRec), то есть требуют SYSTEM, завернуть в еще один модуль?
То есть есть SYSTEM.ZeroRec и компания. Берем, пишем какой-нибудь модуль SafeInit, уже в нем импортируем SYSTEM, и определяем SafeInit.ZeroRec, в которой дергается уже SYSTEM.ZeroRec. Таким образом модули которым SYSTEM не нужен, а безопасное зануление переменных для пущей безопасности, нужно, будут импортировать лишь SafeInit c безопасной функцией ZeroRec. А IMPORT SYSTEM останется для тех, кому нужны не безопасные возможности этого система, для неких своих низкоуровневых грязных хаков.
;) А я почему -то уверен, что так у него и сделано....
-
Кстати, вопрос к Илье - а не лучше ли подобные средства для обеспечения пущей безопасности, которые, тем не менее реализуются через системные возможности (типа ZeroRec), то есть требуют SYSTEM, завернуть в еще один модуль?
Так оно и есть. Импорт SYSTEM требует сама ZeroRec для своей реализации, но импорт SYSTEM не требуется от того кто использует уже готовую ZeroRec.
-
Кстати, вопрос к Илье - а не лучше ли подобные средства для обеспечения пущей безопасности, которые, тем не менее реализуются через системные возможности (типа ZeroRec), то есть требуют SYSTEM, завернуть в еще один модуль?
Так оно и есть. Импорт SYSTEM требует сама ZeroRec для своей реализации, но импорт SYSTEM не требуется от того кто использует уже готовую ZeroRec.
А по другому сделать вроде и невозможно -идиотский вариант помещения этой процедуры в модуль где она вызывается исключаем (но даже в этом случае "небезопасная часть" ограничена этим модулем+ факт, что для использования сущности из SYSTEM НЕОБХОДИМО использование полного квалификатора )
-
Кстати, вопрос к Илье - а не лучше ли подобные средства для обеспечения пущей безопасности, которые, тем не менее реализуются через системные возможности (типа ZeroRec), то есть требуют SYSTEM, завернуть в еще один модуль?
Так оно и есть. Импорт SYSTEM требует сама ZeroRec для своей реализации, но импорт SYSTEM не требуется от того кто использует уже готовую ZeroRec.
Ну, там народ не однозначно написал. У меня сложилось впечатление, что у Ильи слегка подхачен псевдомодуль SYSTEM, в который добавлена функция ZeroRec. Таким образом заимпортировав псевдомодуль SYSTEM получаем в свое рапоряжение инлайн-функцию ZeroRec, то есть на самом деле вызывая ZeroRec мы не получим вызова функции, обнуление будет выполнено на месте - минимум накладных расходов + минимум синтаксического оверхеда (не нужно писать ModuleName.ZeroRec, можно писать просто ZeroRec). Возможно конечно я тут ошибся.
-
Ну, там народ не однозначно написал. У меня сложилось впечатление, что у Ильи слегка подхачен псевдомодуль SYSTEM, в который добавлена функция ZeroRec. Таким образом заимпортировав псевдомодуль SYSTEM получаем в свое рапоряжение инлайн-функцию ZeroRec, то есть на самом деле вызывая ZeroRec мы не получим вызова функции, обнуление будет выполнено на месте - минимум накладных расходов + минимум синтаксического оверхеда (не нужно писать ModuleName.ZeroRec, можно писать просто ZeroRec). Возможно конечно я тут ошибся.
Инлайн - процедуры в КП? -а что они там есть ?, но пусть даже и есть, лично мне непонятно как можно ВЫЗВАТЬ ZeroRec без ModuleName.ZeroRec - даже если она и находится в SYSTEM (SYSTEM.ZeroRec)?
-
Ну, там народ не однозначно написал. У меня сложилось впечатление, что у Ильи слегка подхачен псевдомодуль SYSTEM, в который добавлена функция ZeroRec. Таким образом заимпортировав псевдомодуль SYSTEM получаем в свое рапоряжение инлайн-функцию ZeroRec, то есть на самом деле вызывая ZeroRec мы не получим вызова функции, обнуление будет выполнено на месте - минимум накладных расходов + минимум синтаксического оверхеда (не нужно писать ModuleName.ZeroRec, можно писать просто ZeroRec). Возможно конечно я тут ошибся.
Инлайн - процедуры в КП? -а что они там есть ?, но пусть даже и есть, лично мне непонятно как можно ВЫЗВАТЬ ZeroRec без ModuleName.ZeroRec - даже если она и находится в SYSTEM (SYSTEM.ZeroRec)?
SYSTEM это ж не модуль, это псевдомодуль. То есть импортируя его модифицируешь язык. Например новые языковые конструкции становятся доступны (могуть становиться). См в ББ например всякие там [untagged] [call] и прочее. То есть импорт этого дела не просто добавляет возможность вызывать какие-то новые процедуры, а модифицирует в том числе и синтаксис языка. Ну и добавить несколько предопределенных inline-процедур - как нефиг делать.
-
То есть импорт этого дела не просто добавляет возможность вызывать какие-то новые процедуры, а модифицирует в том числе и синтаксис языка. Ну и добавить несколько предопределенных inline-процедур - как нефиг делать.
Не понимаю
Причем тут инлайн процедуры?- я знаю 2 значения этого понятия:
1. Процедуры написанные с использованием кодов процессора (сверх - низкий уровень) - изредка использовались в ранних версиях Борландовых паскалей
2.В СИ++ "безопасный" аналог макроподстановки -требует 2- проходного компилятора.
Но ни первое, ни второе определение не позволяют изменить КОМПИЛЯТОР - в частности, правила по которым обрабатываются идентификаторы (в данном случае вызовы процедур). Конечно можно представить себе некий препроцессор, который перед компиляцией заменят M.Proc -на SYSTEM.ZeroRec - но это в контексте задачи идиотизм в квадрате...
-
Еще раз - IMPORT SYSTEM может добавить встроенных в язык функций. Ведь никто не указывает имя модуля когда использует функцию LEN, или INC, или ASSERT. При этом они не являются зарезервированными, ключевыми, словами языка.
Так вот - импортировал SYSTEM, получил еще одну встроенную функцию ZeroRec.
Кроме того, ни INC ни LEN ни ASSERT обычно не являются функциями/процедурами, то есть никто ничего на стек не кладет, не делает call и не разбирает возвращаемое значение. Это чисто inline-функции/процедуры. То же самое может быть и с ZeroRec.
-
Еще раз - IMPORT SYSTEM может добавить встроенных в язык функций. Ведь никто не указывает имя модуля когда использует функцию LEN, или INC, или ASSERT. При этом они не являются зарезервированными, ключевыми, словами языка.
Так вот - импортировал SYSTEM, получил еще одну встроенную функцию ZeroRec.
Кроме того, ни INC ни LEN ни ASSERT обычно не являются функциями/процедурами, то есть никто ничего на стек не кладет, не делает call и не разбирает возвращаемое значение. Это чисто inline-функции/процедуры. То же самое может быть и с ZeroRec.
МОЖЕТ , например если вы покопаетесь в компиляторе, кстати чего-то не увидел ИСХОДНИКИ модуля SYSTEM , с чего бы это ? ;) и добавить процедуру туда точно уж - НЕ "как нефиг делать".
-
Еще раз - IMPORT SYSTEM может добавить встроенных в язык функций. Ведь никто не указывает имя модуля когда использует функцию LEN, или INC, или ASSERT. При этом они не являются зарезервированными, ключевыми, словами языка.
Так вот - импортировал SYSTEM, получил еще одну встроенную функцию ZeroRec.
Кроме того, ни INC ни LEN ни ASSERT обычно не являются функциями/процедурами, то есть никто ничего на стек не кладет, не делает call и не разбирает возвращаемое значение. Это чисто inline-функции/процедуры. То же самое может быть и с ZeroRec.
МОЖЕТ , например если вы покопаетесь в компиляторе, кстати чего-то не увидел ИСХОДНИКИ модуля SYSTEM , с чего бы это ? ;) и добавить процедуру туда точно уж - НЕ "как нефиг делать".
Да не. Там относительно просто (в ББ). Там для подобного есть забавный расширизм (и как раз получаем inline-функцию. одну, да. и включается этот расширизм как раз по импорту SYSTEM):
Code procedures
Code procedures make it possible to use special code sequences not generated by the compiler. They are declared using the following special syntax:
ProcDecl = PROCEDURE "[" SysFlag "]" IdentDef [FormalPars]
[ConstExpr {"," ConstExpr}] ";".
The list of constants declared with the procedure is interpreted as a byte string and directly inserted in the code ("in-line") whenever the procedure is called. If a parameter list is supplied, the actual parameters are pushed on the stack from right to left. The first parameter however is kept in a register. If the type of the first parameter is REAL or SHORTREAL, it is stored in the top floating-point register. Otherwise the parameter (or in the case of a VAR/IN/OUT parameter its address) is loaded into EAX. For function procedures the result is also expected to be either in the top floating-point register or in EAX, depending on its type. Be careful when using registers in code procedures. In general, the registers ECX, EDX, ESI, and EDI may be used. Parameters on the stack must be removed by the procedure.
Examples
PROCEDURE [code] Sqrt (x: REAL): REAL (* Math.Sqrt *)
0D9H, 0FAH; (* FSQRT *)
PROCEDURE [code] Erase (adr, words: INTEGER) (* erase memory area *)
089H, 0C7H, (* MOV EDI, EAX *)
031H, 0C0H, (* XOR EAX, EAX *)
059H, (* POP ECX *)
0F2H, 0ABH; (* REP STOS *)
-
Да не. Там относительно просто (в ББ). Там для подобного есть забавный расширизм (и как раз получаем inline-функцию. одну, да. и включается этот расширизм как раз по импорту SYSTEM):
......
Ну да, в смысле 1 определения инлайна :) , то есть вы утверждаете что написать ZeroRec в машинных кодах "относительно просто" - что же почему бы и нет :), осталось только поместить ее в SYSTEM....
-
... Конечно же, использовался отдельный модуль с ZeroRec.
По поводу SYSTEM. Если правильно определить минимум базовых абстракций работы с двоичными данными (модули этих абстракций, конечно, будут IMPORT SYSTEM), то можно на них написать приложение класса, например, Web-сервера, без единого IMPORT SYSTEM...
-
... Конечно же, использовался отдельный модуль с ZeroRec.
По поводу SYSTEM. Если правильно определить минимум базовых абстракций работы с двоичными данными (модули этих абстракций, конечно, будут IMPORT SYSTEM), то можно на них написать приложение класса, например, Web-сервера, без единого IMPORT SYSTEM...
Имелось ввиду другое - можно ли без ковыряния в компиляторе сделать так, чтобы к ЛЮБОМУ приложению можно было прицепить ZeroRec аналогично LEN или ASSIGN? (фактически , речь идет о расширении списка предопределенных процедур)
-
... Конечно же, использовался отдельный модуль с ZeroRec.
По поводу SYSTEM. Если правильно определить минимум базовых абстракций работы с двоичными данными (модули этих абстракций, конечно, будут IMPORT SYSTEM), то можно на них написать приложение класса, например, Web-сервера, без единого IMPORT SYSTEM...
Имелось ввиду другое - можно ли без ковыряния в компиляторе сделать так, чтобы к ЛЮБОМУ приложению можно было прицепить ZeroRec аналогично LEN или ASSIGN? (фактически , речь идет о расширении списка предопределенных процедур)
Это выходит за рамки оберон парадигмы: простой язык <-> простой компилятор. Если язык что-то не позволяет - компилятор допиливается (предполагается, что легко). Можно соглашаться с таким подходом или нет, но он такой. Можно спорить насколько такой подход оправдался в конкретной реализации (ББ) при решении конкретных задач...
P.S. Лично я не стал бы вводить никаких ZeroRec, а просто сделал нормальную инициализацию рекордов по умолчанию, раз уж все равно компилятор ковырять "под себя".
-
Естественно это ВЫХОДИТ но мы говорим о ХАКЕ - насколько легко его сделать(устойчивости к придуркам). Но ладно, пусть даже есть возможность засунуть эту инлайн процедуру в SYSTEM - Vlad - скажите какого УРОВНЯ ДОЛЖНЫ быть навыки у человека решившего написать ZeroRec (обнуляющие ВСЕ поля записи ПРОИЗВОЛЬНО-ДОПУСТИМОЙ структуры) в кодах, в особенности для ЯП где строение ВНУТРЕННЕЙ структуры обьектов НЕ ДЕКЛАРИРУЕТСЯ (в том же Эйфеле язык ГАРАНТИРУЕТ предопределенную инициализацию для структур ЛЮБОЙ сложности)?
-
P.S. Лично я не стал бы вводить никаких ZeroRec, а просто сделал нормальную инициализацию рекордов по умолчанию, раз уж все равно компилятор ковырять "под себя".
Угу. И при импорте SYSTEM'a добавил бы возможность тёггирования переменной тэгом [uninit], что означало бы, что вот эту штуку инициализировать автоматом не надо, что мы тут боремся за эффективность - вон даже SYSTEM ради этого импортировали.
То есть безопасное поведение по умолчанию с возможностью быстрого поведения когда это явно указано, а не наоборот (как сейчас).
-
Естественно это ВЫХОДИТ но мы говорим о ХАКЕ - насколько легко его сделать(устойчивости к придуркам). Но ладно, пусть даже есть возможность засунуть эту инлайн процедуру в SYSTEM - Vlad - скажите какого УРОВНЯ ДОЛЖНЫ быть навыки у человека решившего написать ZeroRec (обнуляющие ВСЕ поля записи ПРОИЗВОЛЬНО-ДОПУСТИМОЙ структуры) в кодах, в особенности для ЯП где строение ВНУТРЕННЕЙ структуры обьектов НЕ ДЕКЛАРИРУЕТСЯ (в том же Эйфеле язык ГАРАНТИРУЕТ предопределенную инициализацию для структур ЛЮБОЙ сложности)?
Ну естественно, что это не учебные навыки. С другой стороны, чтобы полноценно писать на каком-нибудь С++, в котором не ковыряясь в компиляторе можно много всего интересного сделать (да! даже это самое автоматическое обнуление!) - тоже нужны не учебные навыки. Можно поискать что-то между этими двумя крайностями - ЯП много...
-
Нетривиальным (по крайней мере, для меня) является вопрос об области наиболее эффективного использования их творений...
Ну, мне более-менее понятно что Оберон as is не является инструментом для прикладного программирования, это инструмент для системного программирования. Но не в том смысле в котором обычно (и, на мой взгляд неправильно) системное программирование понимают. То есть не для написания операционной системы, драйверов и вообще не для программирования хоть чего-то на самом обероне (как он есть искаропки). Оберон хорош как полуфабрикат из которого системный программист может сделать, относительно быстро и затратив относительно немного усилий, инструмент для прикладного программирования в области где еще нет удовлетворительных готовых решений.
-
То есть не для написания операционной системы, драйверов и вообще не для программирования хоть чего-то на самом обероне (как он есть искаропки). Оберон хорош как полуфабрикат из которого системный программист может сделать, относительно быстро и затратив относительно немного усилий, инструмент для прикладного программирования в области где еще нет удовлетворительных готовых решений.
ММ прототипирование? , возможно, но точно НЕ пользовательского интерфейса конечного приложения.
-
Я чо-то не понял, с чего ZeroRec нужно приравнивать к предопределённым процедурам.
Обычная процедура.
Не помню, как она была у меня написана, но можно хоть так:
VAR zeroArray: ARRAY 1024 OF BYTE;
PROCEDURE ZeroRec (VAR rec: ANYREC);
VAR t: Kernel.Type;
BEGIN
t := SYSTEM.TYP(rec)(Kernel.Type);
SYSTEM.MOVE(SYSTEM.ADR(zeroArray[0], SYSTEM.ADR(rec), t.size)
END ZeroRec;
-
Я чо-то не понял, с чего ZeroRec нужно приравнивать к предопределённым процедурам.
Обычная процедура.
Не помню, как она была у меня написана, но можно хоть так:
VAR zeroArray: ARRAY 1024 OF BYTE;
PROCEDURE ZeroRec (VAR rec: ANYREC);
VAR t: Kernel.Type;
BEGIN
t := SYSTEM.TYP(rec)(Kernel.Type);
SYSTEM.MOVE(SYSTEM.ADR(zeroArray[0], SYSTEM.ADR(rec), t.size)
END ZeroRec;
1. Да нет же , это обсуждение возникло после Reply #24 Алексея
2.НЕ ПОНЯЛ, что это код ОЧИЩАЕТ ВСЕ ПОЛЯ ПРОИЗВОЛЬНОЙ записи?
-
Я чо-то не понял, с чего ZeroRec нужно приравнивать к предопределённым процедурам.
Мы просто увлеклись моими фантазиями. :-)
Спасибо за ответ.
-
Да, он затирает область памяти размером, соответствующим размеру записи, нулями.
-
Да, он затирает область памяти размером, соответствующим размеру записи, нулями.
Да, но только если размер записи меньше 1024 байт.
-
Я так и знал, что Вы на это укажете :)
Можно поставить ASSERT на размер записи...
Можно плюнуть на небольшое убыстрение и затирать нулями вручную, приведя S.ADR(rec) к POINTER [untagged] TO ARRAY OF BYTE.
Я, помнится, спёр из модуля Kernel процедуру в маш. коде Erase. Но та требует чтобы размер области был кратен 4. Впрочем, для RECORD это истина, там выравнивание.
-
Я так и знал, что Вы на это укажете :)
Можно поставить ASSERT на размер записи...
Можно плюнуть на небольшое убыстрение и затирать нулями вручную, приведя S.ADR(rec) к POINTER [untagged] TO ARRAY OF BYTE.
Я, помнится, спёр из модуля Kernel процедуру в маш. коде Erase. Но та требует чтобы размер области был кратен 4. Впрочем, для RECORD это истина, там выравнивание.
Да это только начало :) (хотя замечу Assert не решит проблему обнуления в конкретном случае):
Меня больше беспокоит другое (оговорюсь, мне лень смотреть в детали конкретной реализации ББ), из общих соображений
2. Для различный типов данных зарезервированы различные "нулевые" (дефолтные ) значения
3. Не испортится ли внутренняя структура ПРОИЗВОЛЬНО -ДОПУСТИМОЙ записи - пример, в старых паскалях массив имел следующую структуру - последовательность байт , в первых 2 из которых содержались значения конечного и начального индексов - представьте, что с ним будет, если по записи "проехаться" вашей процедуркой...
-
Ну, мне более-менее понятно что Оберон as is не является инструментом для прикладного программирования, это инструмент для системного программирования. Но не в том смысле в котором обычно (и, на мой взгляд неправильно) системное программирование понимают. То есть не для написания операционной системы, драйверов и вообще не для программирования хоть чего-то на самом обероне (как он есть искаропки). Оберон хорош как полуфабрикат из которого системный программист может сделать, относительно быстро и затратив относительно немного усилий, инструмент для прикладного программирования в области где еще нет удовлетворительных готовых решений.
И в этом сомневаюсь - такой язык, на мой взгляд , должен ДЕКЛАРИРОВАТЬ внутреннюю структуру всех своих обьектов (в терминах некоторой базовой модели) не зависящую от реализации - без этого хаки , по качеству аналогичные приведенному в сообщении выше.
-
Ну, мне более-менее понятно что Оберон as is не является инструментом для прикладного программирования, это инструмент для системного программирования. Но не в том смысле в котором обычно (и, на мой взгляд неправильно) системное программирование понимают. То есть не для написания операционной системы, драйверов и вообще не для программирования хоть чего-то на самом обероне (как он есть искаропки). Оберон хорош как полуфабрикат из которого системный программист может сделать, относительно быстро и затратив относительно немного усилий, инструмент для прикладного программирования в области где еще нет удовлетворительных готовых решений.
И в этом сомневаюсь - такой язык, на мой взгляд , должен ДЕКЛАРИРОВАТЬ внутреннюю структуру всех своих обьектов (в терминах некоторой базовой модели) не зависящую от реализации - без этого хаки , по качеству аналогичные приведенному в сообщении выше.
Неа. Не должен. Он должен деклалировать что-то конкретное про потроха только если мы на нем собираемся что-то писать. Если же мы собираемся на базе вот этого базового описания слепить что-то свое (что-то поменяв, что-то конкретизировав) и уже на этом писать, то такое вот не полное описание языка как у Вирта - самое оно.
-
Неа. Не должен. Он должен деклалировать что-то конкретное про потроха только если мы на нем собираемся что-то писать. Если же мы собираемся на базе вот этого базового описания слепить что-то свое (что-то поменяв, что-то конкретизировав) и уже на этом писать, то такое вот не полное описание языка как у Вирта - самое оно.
Только если вы под "созданием инструмента" понимаете реализацию модификации языка.
-
1) Конкретно для ББ данная процедура работает корректно.
- все базовые типы КП расчитаны на нулевое дефолтное значение;
- структура RECORD и ARRAY точно также рассчитана на простое начальное зануление. Именно оно выполняется для области данных модулей.
Обсуждать её корректность вне рамок ББ бессмысленно, т.к. она явно использует Kernel ББ. Очевидно, что никакой ОБЩЕЙ реализации данной процедуры для разных реализаций КП быть не может. Будут специфичные реализации для каждой платформы. Т.е. термин "хак" непонятно, к чему. Процедура написана прозрачно, использует базовые механизмы языка и рантайма.
2) Если говорить о декларации структуры памяти. В конкретной реализации современных языков такая декларация с необходимостью будет, т.к. есть рантайм с рефлексией. Для ББ внутренняя структура задекларирована в типах и операциях Kernel. На Kernel уже давно есть полная документация, которая опубликована на OberonCore (когда-то составлена мной).
3) Если говорить о декларации структуры памяти вообще для всех реализаций. Одно из благих пожеланий, которые никуда не ведут. Унифицируйте структуру памяти, например, между ББ и GPCP. Даже между GPCP-JVM и GPCP-.NET.
(Даже в том, в чём было бы возможно... Детальные и исчерпывающие стандарты всегда идут вдогонку опыту, а не впереди. И ставить в претензию кому-то, что он не высосал их заранее из пальца, чтобы тем же пальцем в небо...)
-
Неа. Не должен. Он должен деклалировать что-то конкретное про потроха только если мы на нем собираемся что-то писать. Если же мы собираемся на базе вот этого базового описания слепить что-то свое (что-то поменяв, что-то конкретизировав) и уже на этом писать, то такое вот не полное описание языка как у Вирта - самое оно.
Только если вы под "созданием инструмента" понимаете реализацию модификации языка.
Реализацию языка (понятно что с уточнением и модификацией под конкретную область применения) + всю обвязку. Это и будет инструмент для прикладного программирования. Оберон as is для прикладного программирования не годится (хотя бы потому, что там нет например стандартной библиотеки - даже Hello World не написать, нет освобождения памяти и так далее).
-
1) Конкретно для ББ данная процедура работает корректно.
Возможно, не проверял(и не собираюсь - лазить по исходникам (тем более таким) мне только не хватало) .
- все базовые типы КП расчитаны на нулевое дефолтное значение;
Это прописано в сообщении языка?
- структура RECORD и ARRAY точно также рассчитана на простое начальное зануление. Именно оно выполняется для области данных модулей.
Обсуждать её корректность вне рамок ББ бессмысленно, т.к. она явно использует Kernel ББ. Очевидно, что никакой ОБЩЕЙ реализации данной процедуры для разных реализаций КП быть не может. Будут специфичные реализации для каждой платформы. Т.е. термин "хак" непонятно, к чему. Процедура написана прозрачно, использует базовые механизмы языка и рантайма.
Так ББ или КП ? или это эквивалентно.
2) Если говорить о декларации структуры памяти. В конкретной реализации современных языков такая декларация с необходимостью будет, т.к. есть рантайм с рефлексией. Для ББ внутренняя структура задекларирована в типах и операциях Kernel. На Kernel уже давно есть полная документация, которая опубликована на OberonCore (когда-то составлена мной).
будет , так будет.
3) Если говорить о декларации структуры памяти вообще для всех реализаций. Одно из благих пожеланий, которые никуда не ведут. Унифицируйте структуру памяти, например, между ББ и GPCP. Даже между GPCP-JVM и GPCP-.NET.
(Даже в том, в чём было бы возможно... Детальные и исчерпывающие стандарты всегда идут вдогонку опыту, а не впереди. И ставить в претензию кому-то, что он не высосал их заранее из пальца, чтобы тем же пальцем в небо...)
Кчему это... я говорил про модели типа сишных
-
Т.е. термин "хак" непонятно, к чему. Процедура написана прозрачно, использует базовые механизмы языка и рантайма.
Использование того что НАПРЯМУЮ НЕ ДЕКЛАРИРОВАНО СОЗДАТЕЛЕМ -ХАК (точнее , более коварная его форма -ЭКСПЛОИТ).
-
Для ББ внутренняя структура задекларирована в типах и операциях Kernel. На Kernel уже давно есть полная документация, которая опубликована на OberonCore (когда-то составлена мной).
Классика ЭКСПЛОИТА
-
Использование того что НАПРЯМУЮ НЕ ДЕКЛАРИРОВАНО СОЗДАТЕЛЕМ -ХАК (точнее , более коварная его форма -ЭКСПЛОИТ).
Используйте модуль Meta вместо Kernel. И будет Вам всё задекларировано. Рассматривайте Kernel как оптимизацию.
Какая разница, что скрыто за вызовом ZeroRec.
Я выше уже упоминал, что если организовывать базовые абстракции с толком, то IMPORT SYSTEM, Kernel делается в модулях, которые можно пересчитать по пальцам одной руки.
А вся остальная системщина использует базовые безопасные средства этих модулей.
Мысль такова, что хорошая архитектура позволяет локализовать даже тот же хак-эксплойт так, что никаких проблем вы с этого никогда не получите...
(и не собираюсь - лазить по исходникам (тем более таким) мне только не хватало) .
Господа. Нам должно быть стыдно. Мы заставляем уважаемого dizer-а лазить по исходникам, да ещё - о Боже! - каким исходникам. Мы нарушаем его свободу, покой и сон, принуждаем... показываем какой-то код....
Давайте немедленно перестанем принуждать его... лазить... :)
-
Используйте модуль Meta вместо Kernel. И будет Вам всё задекларировано. Рассматривайте Kernel как оптимизацию.
Какая разница, что скрыто за вызовом ZeroRec.
Я выше уже упоминал, что если организовывать базовые абстракции с толком, то IMPORT SYSTEM, Kernel делается в модулях, которые можно пересчитать по пальцам одной руки.
А вся остальная системщина использует базовые безопасные средства этих модулей.
Мысль такова, что хорошая архитектура позволяет локализовать даже тот же хак-эксплойт так, что никаких проблем вы с этого никогда не получите...
:) С этого НУЖНО и было начинать (этого я ожидал от вас) - а получил - ХАК (что меня удивило, неприятно).
-
[оспода. Нам должно быть стыдно. Мы заставляем уважаемого dizer-а лазить по исходникам, да ещё - о Боже! - каким исходникам. Мы нарушаем его свободу, покой и сон, принуждаем... показываем какой-то код....
Давайте немедленно перестанем принуждать его... лазить... :)
Читаю... и чувствую... стыдно, то как...
-
[оспода. Нам должно быть стыдно. Мы заставляем уважаемого dizer-а лазить по исходникам, да ещё - о Боже! - каким исходникам. Мы нарушаем его свободу, покой и сон, принуждаем... показываем какой-то код....
Давайте немедленно перестанем принуждать его... лазить... :)
Читаю... и чувствую... стыдно, то как...
По разному бывает, вот мне бы, например, было стыдно соловьем в публичном месте "заливать" о правильной "инженерии" программного кода, совершенстве ББ - на деле занимаясь хаканием его. ;).
-
[оспода. Нам должно быть стыдно. Мы заставляем уважаемого dizer-а лазить по исходникам, да ещё - о Боже! - каким исходникам. Мы нарушаем его свободу, покой и сон, принуждаем... показываем какой-то код....
Давайте немедленно перестанем принуждать его... лазить... :)
В принципе, я вас Илья понимаю -Если долго лазить в дерьме, то перестаешь чувствовать его запах...
-
Мысль такова, что хорошая архитектура позволяет локализовать даже тот же хак-эксплойт так, что никаких проблем вы с этого никогда не получите...
Да. И никакой ЯП тут не спасет от этого в общем случае. Только виртуальная машина (а это потеря гибкости и невозможность применять это в некоторых областях).
-
Мысль такова, что хорошая архитектура позволяет локализовать даже тот же хак-эксплойт так, что никаких проблем вы с этого никогда не получите...
Да. И никакой ЯП тут не спасет от этого в общем случае. Только виртуальная машина (а это потеря гибкости и невозможность применять это в некоторых областях).
:) :) :) :) Вот ЯП и спасает (частично), в данном случае требованием использования полного имени идентификатора... в противном случае, вам нужно разбираться с авоськой кода - чему, в свою очередь, помешает чувство СТЫДА описываемого Ильей. ;D
-
Это прописано в сообщении языка?
...
Кчему это... я говорил про модели типа сишных
На самом деле
-
Это прописано в сообщении языка?
...
Кчему это... я говорил про модели типа сишных
На самом деле
Что?
-
Это прописано в сообщении языка?
...
Кчему это... я говорил про модели типа сишных
На самом деле сей низкоуровневые детали прописаны очень даже "свободно". 20-битные char'ы... нулевые указатели, которые могут быть представлены не нулями в памяти и т.д.
-
На самом деле
Что?
Форум сглюкнул ;)
-
Это прописано в сообщении языка?
...
Кчему это... я говорил про модели типа сишных
На самом деле сей низкоуровневые детали прописаны очень даже "свободно". 20-битные char'ы... нулевые указатели, которые могут быть представлены не нулями в памяти и т.д.
Если язык высокоуровневый, то внутреннее строение структур описывать необязательно. Пример - Массив - совокупность однотипных 'элементов с возможностью доступа к произвольному элементу по индексу и временем доступа не зависящему от номера элемента (в эту модель влазят любые индексируемые структуры с доступом O(1)). В языке СИ модель массива определена более четко.
-
В языке СИ модель массива определена более четко.
Я не буду защищать описание (сообщение) оберона :) Да, оно не выдерживает никакой критики. Это работа одного человека, для которого составление док не самое интересное. Тем не менее, если сделать скидку на то, что это не законченное описание законченного промышленного языка - оно вполне катит. Типа лучше такое, чем ничего.
P.S. Да, сравнение объемов пресловутого 16-страничного описания с нормальными стандартами - со стороны оберонщиков крайне некорректно.
-
В языке СИ модель массива определена более четко.
Я не буду защищать описание (сообщение) оберона :) Да, оно не выдерживает никакой критики. Это работа одного человека, для которого составление док не самое интересное. Тем не менее, если сделать скидку на то, что это не законченное описание законченного промышленного языка - оно вполне катит. Типа лучше такое, чем ничего.
P.S. Да, сравнение объемов пресловутого 16-страничного описания с нормальными стандартами - со стороны оберонщиков крайне некорректно.
А с чего вы взяли, что я нападаю на описание... что сделано то сделано... более того правильно оно или нет, хорошо оно или нет, полно оно или нет - зависит от того подо что проектировался язык (области эффективного использования).Я чуть раньше , сказал , что лично для меня этот вопрос открыт. В offspine выше мы плавно перебрались от вопросов связанных с локализацией эффектов ZeroRec - тут все понятно, до модификации реализации и легкости хака ББ (следуя идеям Алексея) - хреново, учитывая существующую официальную документацию , но а закончили темой "о роли хака в использовании ББ" на примере реализации ZeroRec от Ильи :) -оказалось что радетели безопасного и грамотного инжениринга кода хакают его, только за ушами трещит (не забывая поучать неофитов в коровнике), причем ЗНАЯ об официально-допустимой реализацией возможности (Мета). Вот с чего бы это - у меня лично есть доля уверенности, что "совершенная" реализация ББ , на самом деле не очень то пригодна, даже для их задач.
-
Не стоит преувеличивать. То, что не нужно в языке, легко реализуется в системной библиотеке. Эта библиотека может быть стандартной для всего каркаса или для конкретного проекта. Та же сериализация/десериализация требует приведения типов. Главное, чтобы опасный код был сконцентрирован в одном месте. 16-истраничное описание языка - это описание языка, а не конкретной реализации для конкретных целевых платформ.
-
Не стоит преувеличивать. То, что не нужно в языке, легко реализуется в системной библиотеке. Эта библиотека может быть стандартной для всего каркаса или для конкретного проекта. Та же сериализация/десериализация требует приведения типов. Главное, чтобы опасный код был сконцентрирован в одном месте. 16-истраничное описание языка - это описание языка, а не конкретной реализации для конкретных целевых платформ.
Зависит от языка. Но вообще то вы правы. Одно только -для высокоуровневого языка можно очень многое сбросить на реализацию (и все будет ОК пока вы действуете в рамках систем описываемых языком, геморы начинаются когда вы выходите за нее , либо взаимодействуете с окружающим миром - системой и кодом написанном на других ЯП), для системного языка вроде этот подход, не есть гуд.
-
оказалось что радетели безопасного и грамотного инжениринга кода хакают его, только за ушами трещит (не забывая поучать неофитов в коровнике), причем ЗНАЯ об официально-допустимой реализацией возможности (Мета). Вот с чего бы это - у меня лично есть доля уверенности, что "совершенная" реализация ББ , на самом деле не очень то пригодна, даже для их задач.
По-моему все понятно. ZeroRec довольно общая функция - хочется ее максимально оптимизировать. Никаких сдерживающих факторов в виде переносимости или совместимости нет - почему бы и SYSTEM не влепить. Причем Илья говорит, что по факту такими вещами приходится заниматься нечасто - почему бы ему и не поверить? :)
Я бы даже не назвал это "хаком" - просто мертвая завязка на конкретную реализацию (но зато в одном месте).
-
Не стоит преувеличивать. То, что не нужно в языке, легко реализуется в системной библиотеке.
Собственно, претензии у меня конкретно всегда были к пропагандируемой "легкости". Тот же ZeroRec - не понятно как будет выглядеть в классическом обероне (без ANYREC). Таки придется компилятор точить :) Что тоже может быть и ладно, но все же это не библиотека. И требует квалификации выше пропагандируемой "легкости".
-
По-моему все понятно. ZeroRec довольно общая функция - хочется ее максимально оптимизировать. Никаких сдерживающих факторов в виде переносимости или совместимости нет - почему бы и SYSTEM не влепить. Причем Илья говорит, что по факту такими вещами приходится заниматься нечасто - почему бы ему и не поверить? :)
Я бы даже не назвал это "хаком" - просто мертвая завязка на конкретную реализацию (но зато в одном месте).
Я не против SYSTEMa, я против эксплоитов... ;D (не увидел ни в сообщении о ЯП ни в документации по реализации информацию о занулении, верить Илье - оснований все меньше и меньше, лезть в исходники.... КАК ВАМ НЕ СТЫДНО ПРЕДЛАГАТЬ такое "уважаемому Dizer'у" :D)
-
Вводить в языке, ориентированном на 100% прозрачность в отображении на машину, какую-либо другую инициализацию структур, нежели нулями... Такого маразма не стоит ожидать и от авторов языка, и от авторов реализаций.
-
Вводить в языке, ориентированном на 100% прозрачность в отображении на машину, какую-либо другую инициализацию структур, нежели нулями... Такого маразма не стоит ожидать и от авторов языка, и от авторов реализаций.
Илья, :) бросьте впадать в крайности, мы просто обсуждаем тему... формируем целостную картину...
-
Вводить в языке, ориентированном на 100% прозрачность в отображении на машину, какую-либо другую инициализацию структур, нежели нулями... Такого маразма не стоит ожидать и от авторов языка, и от авторов реализаций.
Ну, таки например float-числа логичней инициализировать не нулем (zero) а NaN. То есть это должно быть значение по умолчанию. По сути тут NaN играет ту же роль, что и NIL для указателей/ссылок. Нуль же для float'a эквивалентен инициализации указателя не нулем, а адресом некого дефолтного валидного объекта.
-
Ну, таки например float-числа логичней инициализировать не нулем (zero) а NaN. То есть это должно быть значение по умолчанию. По сути тут NaN играет ту же роль, что и NIL для указателей/ссылок. Нуль же для float'a эквивалентен инициализации указателя не нулем, а адресом некого дефолтного валидного объекта.
Может и логичнее, но исторически не оправдано. В смысле это будет "не так как везде", а ситуаций на практике где таки удобнее 0, ИМХО, будет все равно больше.
-
Ну, таки например float-числа логичней инициализировать не нулем (zero) а NaN. То есть это должно быть значение по умолчанию. По сути тут NaN играет ту же роль, что и NIL для указателей/ссылок. Нуль же для float'a эквивалентен инициализации указателя не нулем, а адресом некого дефолтного валидного объекта.
Может и логичнее, но исторически не оправдано. В смысле это будет "не так как везде", а ситуаций на практике где таки удобнее 0, ИМХО, будет все равно больше.
Везде - это где? В D default для float это NaN, в ActionScript'е тоже.
-
Везде - это где? В D default для float это NaN, в ActionScript'е тоже.
Если рассматривать элементы базовых типов как простые обьекты, то логично инициализировать их нейтральными элементами (нулями) относительно некоторых наиболее часто базовых операций (сложение, конкатенация).
-
Но по мимо логики есть еще и человеческий фактор, например, в СИ базовые операции +,-,*, / над элементами целочисленных типов никогда не приведут к выходу за пределы этих типов, что несомненно логично. Человек же ждет от 1/2 не 0, а 0.5