Ada_Ru форум

Обсуждение языка Ада

Потенциально опасные конструкции языка Ada

Оставить новое сообщение

Сообщения

Vadim Godunko
Потенциально опасные конструкции языка Ada
2003-04-23 16:40:25

Доброго времени суток!

 

Помогите, пожалуйста, подготовить список потенциально опасных конструкций языка Ada.

 

-- Vadim Godunko

 

 

Vadim Godunko wrote:

 

Доброго времени суток!

 

Помогите, пожалуйста, подготовить список потенциально опасных

конструкций языка Ada.

 

Хмммм......

 

Что мы имеем в качестве отправной точки?

 

RM95, приложение H

 

Ada 95 Quality and Style Guide

 

Код, который должен оказаться хорошим.

 

Чего мы хотим. Нет, постановка задачи ставит в тупик...

 

Кроме goto, ну ничего в голоу не лезет. Можно, конечно, Unchecked_Conversion и Unchecked_Deallocation, но если они нужны по делу?

 

Более одного оператора return в теле функции...

 

Изменене подпрограммой (особенно функцией) глобальных объектов

данных...

 

Да нет в Аде "потенциально опасных конструкций"! Язык специально так сделан, что их нет!

 

А есть пример потенциально опасной конструкции в другом языке, чтобы хоть понять, в какую сторону думать?

Помогите, пожалуйста, подготовить список потенциально опасных

конструкций языка Ada.

 

Вадим, а чем Вам труды в рамках модели Рэйвенскар и аналогичные не подходят? Или Вы ищете аналоги сишного

if (c = 0) ...

 

Так тогда Сергей прав, искать придется долго ;)

 

Василий.

Sergey I. Rybin wrote:

 

Чего мы хотим. Нет, постановка задачи ставит в тупик...

 

Это мягко сказано...

 

Кроме goto, ну ничего в голоу не лезет.

 

Да почему goto потенциально опасная? Внуть цикла - низя, в другую подпрограмму/задачу/защищенный объект - низя. Если откуда и можно, то finalization для всех блоков, откуда выходим никто не отменял.

 

Кривая - согласен. Но вот опасности от неё... как от комара.

 

Можно, конечно, Unchecked_Conversion

и Unchecked_Deallocation, но если они нужны по делу?

 

Ага, при наличии считай 8_000 операторов связи с C-шным кодом, так считай всё опасно. :)

 

Более одного оператора return в теле функции...

 

Ну здесь может быть, но с бААльшой натяжкой. Это скорее из области стилистических соглашений.

 

Изменене подпрограммой (особенно функцией) глобальных объектов

данных...

 

Это идея! Особенно для функции.

 

Да нет в Аде "потенциально опасных конструкций"! Язык специально так

сделан, что их нет!

 

Вот в свете того, что об этом пишется в _каждой_ книге, я и забуксовал.

 

А есть пример потенциально опасной конструкции в другом языке, чтобы хоть

понять, в какую сторону думать?

 

Василию удалось попасть в точку. Именно это и нужно. Но что делать если это удалили ещё в далеком 1983 году (или ещё раньше)? Как это объяснить простым людям, привыкшим искать подобные косяки?

 

 

-- Vadim Godunko

Я бы посоветовал вот что: взять Ada 95 Quality and Style,

посмотреть для каждой главы Summary (А в особенности - для

главы 5 (Programming Ptactice)) и понадергать оттуда с дюжину

понятных и легко проверяемых органичений и требований.

 

И с наглой мордой заявить, что Ада - супер-язык, и косяков в ней - днем с огнем не сыскать.

 

Иначе - "пустые хлопоты в казенном доме" до опупения.

Sergey I. Rybin wrote:

Я бы посоветовал вот что: взять Ada 95 Quality and Style,

посмотреть для каждой главы Summary (А в особенности - для

главы 5 (Programming Ptactice)) и понадергать оттуда с дюжину

понятных и легко проверяемых органичений и требований.

 

Спасибо!

 

И с наглой мордой заявить, что Ада - супер-язык, и косяков в ней -

днем с огнем не сыскать.

 

Иначе - "пустые хлопоты в казенном доме" до опупения.

 

Для начала я проштудировал GNAT UG. Нашел там раздел предупреждений компилятора. Как закончу перевод и описание к чему бы это, отправлю в этот список рассылки на рецензирование.

 

PS Чем-то мне кажется, что подобную информацию и на сайте разместить не помешает.

 

-- Vadim Godunko

И с наглой мордой заявить, что Ада - супер-язык, и косяков в ней - днем с огнем не сыскать.

 

Все таки совсем без проблем уважающему себя языку нельзя. Взять хотя бы самые разнообразные выч.тупики, инверсирование приоритета, и прочие прелести в межзадачном взаимодействии. Оно конечно не совсем то, но крови попить может изрядно. Молчаливое окончание задачи при необработанном исключении тоже весьма и весьма способствует.

 

Крепко налететь можно также допустим с перегружаемыми именами. Особенно при модификации старого кода. Забыл скажем удалить внутреннюю переменную, она закрыла

видимость внешней, в итоге подпрограмма не имеет ожидаемого эффекта. Или наоборот,

забыл переменную внутреннюю объявить, подпрограмма запортила значение внешней. Учитывая многоуровневость правил видимости, в Аде на это налететь КУДА проще чем в Си.

 

Могу поинтересоваться у "старых, опытных камикадзе" с моей работы, какие конструкции могут нести беду. Заявить что таких просто нет - это к сожалению боюсь кривить душой.

 

Василий.

Vasiliy Fofanov wrote:

 

Могу поинтересоваться у "старых, опытных камикадзе" с моей работы, какие

конструкции могут нести беду. Заявить что таких просто нет - это к

сожалению боюсь кривить душой.

 

Буду признателен.

 

 

-- Vadim Godunko

Все таки совсем без проблем уважающему себя языку нельзя. Взять хотя бы самые разнообразные выч.тупики, инверсирование приоритета, и прочие прелести в межзадачном взаимодействии. Оно конечно не совсем то, но крови попить может изрядно. Молчаливое окончание задачи при необработанном исключении тоже весьма и весьма способствует.

 

Искать такое статически...

Крепко налететь можно также допустим с перегружаемыми именами. Особенно при модификации старого кода. Забыл скажем удалить внутреннюю переменную, она закрыла

видимость внешней, в итоге подпрограмма не имеет ожидаемого эффекта. Или наоборот,

забыл переменную внутреннюю объявить, подпрограмма запортила значение внешней. Учитывая многоуровневость правил видимости, в Аде на это налететь КУДА проще чем в Си.

 

Могу поинтересоваться у "старых, опытных камикадзе" с моей работы, какие конструкции могут нести беду. Заявить что таких просто нет - это к сожалению боюсь кривить душой.

 

Дык, эта! Мы ж с Вадимом на одни и те же грабли наступили! Когда вместо вызова АСИСного запроса по правилам видимости получили преобразование типа, а для нас это выглядело так, как будто запрос тупо возвращает свой аргумент, вместо того, чтобы считать, чего положено.

 

Счас найду имя... О, вот оно - Subtype_Mark. Это и запрос в Asis.Definitions, и подтип типа Elements, объявленный в пакете Asis.

 

Однако, господа-товарищи, не забывайте: мухи-отдельно, котлеты - отдельно. Я в том смысле, что с точки зрения конкретной сертификации конкретного продукта тут и о благе Отечества думать надо!

 

 

Vadim Godunko wrote:

 

Vasiliy Fofanov wrote:

 

Могу поинтересоваться у "старых, опытных камикадзе" с моей работы, какие конструкции могут нести беду. Заявить что таких просто нет - это к сожалению боюсь кривить душой.

 

Буду признателен.

 

Как камикадзе-любитель, подписываюсь под тем, что правила видимости - они везде грабли, а Адский use - это хорошо замаскированные грабли с чугунной ручкой (пример - в предыдущем письме)

Sergey I. Rybin wrote:

 

Как камикадзе-любитель, подписываюсь под тем, что правила видимости - они

везде грабли, а Адский use - это хорошо замаскированные грабли с чугунной

ручкой (пример - в предыдущем письме)

 

А также шипами, крючьями и искроразбразгивателями, к тому же аккуратно прикрытыми красивой неповреждаемой оболочкой, безпрепятственно пропускающей всё разнообразие содержимого к Вашему лбу.

 

:)

 

-- Vadim Godunko

Что-то с почтой у меня стало. Видно ФСБ-шники отключили :) Битый час не могу ничего отправить. :(

 

-- Vadim Godunko

Первая редакция списка косячков, отлавливаемых GNAT-ом. Если что не так, прошу подправить.

 

-- Vadim Godunko

 

Помогите, пожалуйста, подготовить список потенциально опасных

конструкций языка Ada.

 

Для меня самые неожиданные грабли были следующие.

 

у типа данных.

 

type Money is delta 0.01 range 0.0 .. 1000.0;

 

дельта на самом деле не 0.01 а ближайшая к 0.01 степень двойки.

а для того что бы она стала на самом деле 0.01 надо добавить в описание типа параметр совсем не относящийся к дельта.

 

type Money is delta 0.01 digits 10 range 0.0 .. 1000.0;

 

И эта (по моему глубочайшему убеждению кривость) прописана и узаконена в Ada95 RM.

--------

Вот примерчик.

---------------------------------

with Ada.Text_IO;

 

procedure Fixed is

type Money is delta 0.01

-- digits 10

range 0.0 .. 1000.0;

 

subtype Number is Long_Float;

Price : Money := 0.01;

begin

Ada.Text_IO.Put_Line (Money'Image (Price * 10.0));

Ada.Text_IO.Put_Line (Number'Image (Number (Price)));

end Fixed;

----------------------------------

 

Если раскомментировать -- digits 10 результаты будут совсем другие.

И эта (по моему глубочайшему убеждению кривость) прописана и узаконена в Ada95 RM.

--------

Вот примерчик.

---------------------------------

with Ada.Text_IO;

 

procedure Fixed is

type Money is delta 0.01

-- digits 10

range 0.0 .. 1000.0;

 

subtype Number is Long_Float;

Price : Money := 0.01;

begin

Ada.Text_IO.Put_Line (Money'Image (Price * 10.0));

Ada.Text_IO.Put_Line (Number'Image (Number (Price)));

end Fixed;

----------------------------------

 

Если раскомментировать -- digits 10 результаты будут совсем другие.

 

Дык, десятичные типы в Аде 95 для того и придуманы, чтобы деньги точно считать!

Так что не косячок это, а продуманное техническое решение!

Sergey I. Rybin wrote:

with Ada.Text_IO;

 

procedure Fixed is

type Money is delta 0.01

-- digits 10

range 0.0 .. 1000.0;

 

subtype Number is Long_Float;

Price : Money := 0.01;

begin

Ada.Text_IO.Put_Line (Money'Image (Price * 10.0));

Ada.Text_IO.Put_Line (Number'Image (Number (Price)));

end Fixed;

----------------------------------

 

Если раскомментировать -- digits 10 результаты будут совсем другие.

 

Дык, десятичные типы в Аде 95 для того и придуманы, чтобы деньги точно считать!

 

Так что не косячок это, а продуманное техническое решение!

 

Хорошо продуманное решение в виде граблей.

Забыл написать digits 10, и получил по лбу без предупреждения.

 

Я написал мелкую программулю, считающую расходы за интернет за месяц, и долго не мог понять, почему результаты не сходяться со счетом.

Потом умные люди подсказали что я digits не написал где положено.

И эта (по моему глубочайшему убеждению кривость) прописана и узаконена в Ada95 RM.

 

Ну нет, с такой интерпретацией я согласиться не могу категорически. Это точно также как утверждать что кривость языка С состоит в том что написал int i - получился один тип, а int *i - получился совсем другой. И арифметические операции все прекрасно работают, но i++ дает разный результат.

 

Василий.

Dmitriy Anisimkov wrote:

 

Так что не косячок это, а продуманное техническое решение!

 

 

Хорошо продуманное решение в виде граблей.

Забыл написать digits 10, и получил по лбу без предупреждения.

 

Я написал мелкую программулю, считающую расходы за интернет за месяц, и долго не мог понять, почему результаты не сходяться со счетом.

Потом умные люди подсказали что я digits не написал где положено.

 

Тут всё продумано. Это GNAT использует для вычислений с фиксированной точкой целые числа. А приличные машины обязательно имеют набор команд для работы с двоично-десятичными упакованными/неупакованными числами. Так вот, при описании таких чисел используется два поля: общая длинна и количество точек после запятой. Допустимый диапазон - это уже наворот Ады.

 

 

 

-- Vadim Godunko

Так что не косячок это, а продуманное техническое решение!

 

Хорошо продуманное решение в виде граблей.

Забыл написать digits 10, и получил по лбу без предупреждения.

 

Я написал мелкую программулю, считающую расходы за интернет за месяц, и долго не мог понять, почему результаты не сходяться со счетом.

Потом умные люди подсказали что я digits не написал где положено.

 

Наша беда - в оторванности от мировой Ада-культуры. В свое время

(в ходе пересмора стандарта Ады) на эту тему была отдельная дискуссия, и эти самые десятичные типы (которые с digits) специально провозглашались и рекламировались как средство ТОЧНОГО подсчета денег.

 

Просто оно мимо нас прошло. Я об этом знаю только лишь потому,

что наша команда пыталась встрять в обсуждение нового стандарта,

а потому мы специально следили за происходящим. Боюсь, мы были единственным адресом в России, куда регулярно приходили документы проекта Ада 9X.

Так что для ихнего Ада-программиста это с куда меньшей вероятностью могло бы оказаться граблями.

Vasiliy Fofanov wrote:

И эта (по моему глубочайшему убеждению кривость) прописана и узаконена в

Ada95 RM.

 

Ну нет, с такой интерпретацией я согласиться не могу категорически. Это

точно также как утверждать что кривость языка С состоит в том что написал

int i - получился один тип, а int *i - получился совсем другой. И

арифметические операции все прекрасно работают, но i++ дает разный

результат.

 

Хорошо, не кривость, "потенцильная опасность" нарваться на неточность, когда ждешь точности написанной в delta. Это было мое предложение внести в список потенциальных опасностей языка. Если широкая общественность не считает это опасностью для новичков, не буду настаивать, все равно я уже на эти грабли не наступлю, даже если общественность не считает это граблями.

Sergey I. Rybin wrote:

Так что для ихнего Ада-программиста это с куда меньшей вероятностью

могло бы оказаться граблями.

 

Разговор идет о "потенциальной опасности" ошибиться. Поэтому предыдущий опыт программирования в расчет принимать нельзя. Мы не знаем кто будет ошибаться, бывший коболист, или сишник, или вообще таксист.

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти