WINAVR

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Thu, 03 Nov 2005 06:32:02

+0300:

DT> Всё очень просто:

DT> 1) nil не разыменовывается, runtume-проверка;

Не хочу никаких рантайм проверок. Если мне надо, я сам могу это написать.

DT> 2) у указателя должен быть тип и тип этот должен проверяться;

Это и так есть.

DT> 3) не должно быть "адресной арифметики" кроме присваивания DT> указателю значения и сравнения указателей;

Не удобно в практической жизни.

DT> 4) указателю можно присвоить значение nil, значение, DT> возвращаемое оператором new и значение "адреса" существующего DT> объекта (&var);

Потом объект перестал существовать, и что?

DT> 5) при уничтожении объекта всем указателям на этот объект DT> должно автоматически присваиваться значение nil.

Как это вообще можно сделать?

DT> Конечно, требует рантайм-поддержки, но очень существенно.

Ничего себе поддержечка... Лично мне такой язык не нужен.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Kirill Frolov on Thu, 03 Nov 2005 11:04:35

+0300:

q>> Careful C programmers can produce safe C programs, but, in q>> practice, many C programs are unsafe.

DT> А попробуй это объяснить некоторым любителям свободы...

Объяснить довольно просто - показать в количестве написанный на этих safe средствах прикладной и системный софт.

dima

Hello, Andrey Solomatov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 3 Nov 2005 09:59:29

+0000 (UTC):

AS> [кусь] AS>>> *Не* совершенно разные, а очень даже похожие. На то, что

DO>> Похожие, но _совершенно_ разные. Как и числа собственно.

AS> Значит в этом вопросе мы не сойдёмся. AS> Все команды типа add изначально появились для выполнения AS> операции сложения. Ещё в те времена, когда дополнительного AS> представления числа не существовало - и даже тогда, когда не AS> все компьютеры были двоичными.

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

AS> [кусь] AS>>> Ну значит он и там есть - от чего инкрементация "на sizeof" AS>>> безопаснее не делается.

DO>> Делается. В ТР за этим надо ручками следить.

AS> Ты упёрся. Второй круг.

Во что уперся?

AS> int i; AS> int *p = &i; /* здесь указатель вполне валиден */

AS> .... /* здесь может делаться любой код */

AS> p = p + 1000; /* а вот здесь мы "совершенно безопасно" куда-то AS> уползли. */

И что? В ТР ты можешь сделать совершенно тоже самое, только хуже, потому что можешь попасть не только в чужую память, но и в середину какого-то объекта.

AS>>> Система калибровки.

DO>> Система калибровки чего?

AS> А это важно?

Нет, важно, что это не шаблон вывода.

DO>> Выглядит как типичная абракадабра, и ничем не лучше сишных DO>> шаблонов для printf.

AS> (Пожимая плечами) Это индустриальный стандарт.

А типа С - не стандарт, причем куда более распространенных, чем какие-то ЭСУД (я даже с аббревиатурой такой не знаком).

AS> Я вот только не понял - как Вы собираетесь выводить через AS> printf массивы, и как смещать и нормировать величину будем

Какие массивы и что нормировать?

AS> (потому, что 0x10 на самом деле может означать +2С, к примеру)?

0x10 где? В шаблоне printf?

DO>> И зачем мне на экране десяток ничего не значащих цифр?

AS> Это последнее, от чего голова болит у калибровщиков.

Да мне как-то до твоих калибровщиков ну совершенно нету дела.

AS>>> От чего-то. И как сюда присобачить (x)printf мне не ведомо.

DO>> Тебе много чего не ведомо...

AS> Ну так расскажите.

Так спросите.

DO>> Значит документированная ошибка. Не пользуйся, хотя по-моему DO>> от этих полей толку чуть.

AS> Угу. Куда-ж я денусь.

Куда хочешь.

AS> А толк - в возможности написания ясного, компактного и легко AS> модифицимруемого кода.

Не вижу чем a.b = 3 лучше a |= 3 << B.

AS> Для меня лично, по крайней мере.

dima

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 03 Nov 2005 21:16:41

+0300:

DT>>> 5) при уничтожении объекта всем указателям на этот объект DT>>> должно автоматически присваиваться значение nil. DO>> Как это вообще можно сделать?

VV> Язык без указателей вообще и/или вся работа через хендлы.

DT>>> Конечно, требует рантайм-поддержки, но очень существенно. DO>> Hичего себе поддержечка... Лично мне такой язык не нужен.

VV> Такой язык давно придуман. Hазывается Java.

Вот она мне и не нужна. Не вижу смысла без острой необходимости плодить сущности.

dima

Привет, Dimmy !

01 Nov 05 , 21:58 Dimmy Timchenko писал к Kirill Frolov:

DT> Да при чём тут нечисла? Корень из нуля равен нулю, корень из малой DT> величины будет _больше_ этой величины. Вполне себе числа. Проверил DT> на BP7 - считает правильно.

Я во времена первых 486-х компьютеров в школе писал на паскале программу для рассчета и показа множества мандельброта. алгоритм - Z -> Z^2+Z_0, где Z_0 начальное значение, Z комплексное число, алгоритм - Z -> количество итераций, после которого Z уходит в бесконечность алгоритм - Z -> (точнее, становится по модулю больше двух) - цвет точки с алгоритм - Z -> координатами Z. В некоторых координатах оно как раз с алгоритм - Z -> антипереполнением вылетало.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Hаверное ему швея под хвост попала

Hello Nickita.

03 Nov 05 22:07, you wrote to Dimmy Timchenko:

DT>> Да при чём тут нечисла? Корень из нуля равен нулю, корень из DT>> малой величины будет _больше_ этой величины. Вполне себе числа. DT>> Проверил на BP7 - считает правильно.

NS> Я во времена первых 486-х компьютеров в школе писал на паскале NS> программу для рассчета и показа множества мандельброта. алгоритм - Z NS> -> Z^2+Z_0, где Z_0 начальное значение, Z комплексное число, NS> количество итераций, после которого Z уходит в бесконечность (точнее, NS> становится по модулю больше двух) - цвет точки с координатами Z. В NS> некоторых координатах оно как раз с антипереполнением вылетало.

Hормальные девелоперы не размышляют, "будет оно работать или нет", а пишут систему тестов, которая, кстати, может быть сложней и развесистей, чем рабочий код. И вместе с метриками test coverage подшивают у проектной документации. Делать это или нет зависит от того, насколько сильно будут иметь исполнителя заказчики, если написанная пионерами кривая программа вызовет нехорошие последствия при подаче на вход -1 вместо 0.

Dmitry

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 04 Nov 2005 02:45:51

+0300:

q>>>> Careful C programmers can produce safe C programs, but, in q>>>> practice, many C programs are unsafe.

DT>>> А попробуй это объяснить некоторым любителям свободы...

DO>> Объяснить довольно просто - показать в количестве написанный DO>> на этих safe средствах прикладной и системный софт.

DT> Дима, извини, но, может, хватит примитивно передёргивать? Ты DT> прекрасно знаешь причины такого широкого распространения C.

Знаю. Это удачное сочетание свойств языка и ничего более.

DT> Примерно те же причины, что и с PC и x86-архитектурой.

Основные причины распространенности РС - открытость архитектуры ну и конечно удачное сочетание возможностей и цены. Прямого отношения к языками программирования это не имеет.

dima