Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 18 Oct 2005 14:14:36
+0400:
DT>>> А в Аде - есть. :) Более того, там параметр цикла DT>>> объявляется самим фактом своего использования в заголовке DT>>> цикла. В пределах цикла он read only (!), а по завершении DT>>> цикла уничтожается.
DO>> Hу и зачем мне эти навороты?
DT> Ты просто не понимаешь самой сути подхода, реализованного в
Я не не понимаю, я не принимаю. В смысле мне это не нужно. У меня ошибки не связаны с тем, что может поймать компилятор.
DT> Аде. Максимальная надёжность и безопасность со стороны языка. DT> Всё, что можно проверить на этапе компиляции, должно быть DT> проверено. В конце концов для DoD делался.
DO>> В паскале я кстати иногда пользовался параметром for на DO>> запись,
DT> Маладэць.
И всяким другим хакерством, ассемблерными вставками и прочими непеносимостями. Связано это отчасти было с примитивностью ТР'шного кодогенератора, отчасти с общим стилем, к которому склонял Борланд и ТурбоПовер. Отчасти с отсутствием опыта и понимания чем это плохо. Ведь в рамках dos16 и tp все было нормально и даже довольно эффективно, но вот выйти за эти рамки было уже нельзя.
DO>> в С цикл for - вообще разновидность while и как такового DO>> параметра цикла там вообще нет.
DT> И тем не менее "содержимое скобок" зачем-то ввели в scope DT> оператора цикла.
Да нет у for никакого оператора.
DO>> Я классами не пользуюсь...
DT> Hу, я пользуюсь эпизодически. Просто потому, что в C++ классы DT> вместо всего. :)
Я не пользуюсь С++.
DT> ООП не уважаю. Сомнительная технология. Слишком сильно
Да нет, иногда очень к месту. Хотя для многих низкоуровневостей и пикоманства оно или не помогает или даже мешает.
DT> увеличивает "паразитную связность" и структурную сложность программы.
С чего бы это? По-моему, подход куда более осмысленный чем адовские навороты с диапазонами значений переменных.
DT>>>>> Можно, но оно не интегрировано в язык. Hапример, в DT>>>>> паскале размерности массивов задаются диапазонами,
DO>>>> Толку-то. Сомнительное преимущество.
DT>>> Почему? Удобнее и универсальнее, чем в C.
DO>> Зато в С ближе к реализации.
DT> А зачем ЯВУ быть ближе к реализации?
Для написания низкоуровневых программ.
DT> Тогда уж лучше макроассемблер.
Макроаасемблер - хуже. На нем делается часть проекта, не не весь проект.
DT> Тенденция-то к "повышению уровня" языков.
Зависит от решаемых задач.
DT> Это просто до embedded пока добрался только C, ну вот начинает C++ DT> добираться. :)
Вот в С++ повышение уровня сделано весьма разумно. Нужен тебе объект с неким поведением - ты его и пишешь себе. Ну или готовый берешь. А не пользуешься встроенным в язык.
DO>> Будет. Кстати tp легко компилирует
DO>> var ds: DigSet;
DO>> begin ds := ds+['d']; DO>> end.
DT> Да, проверил - действительно. Явный баг. И не только DT> компилируется, но и runtime error не генерит.
Естественно не генерит...
DO>> Вобщем в РСэшном паскале это все не мешает, а иногда и DO>> приятно, но тащить все эти навороты в embedded я считаю DO>> совершенно лишним.
DT> Кто-то и C++, а кто-то и C считает совершенно лишним. ;)
В С++ подобных наворотов нет.
DO>> Между прочим, тут еще один камушек в огород ругающих С за DO>> неоднозначность символов. В Паскале [] используется и для DO>> индексации массива и для определения констант типа множество.
DT> Да. И ещё там что-то было в дельфи третье.
Дельфи, как я уже говорил, вообще сплошная эклектика, куда нятянуто все, что в голову пришло.
DT>>> В отличие от весьма ортогональной и симметричной Ады.
DO>> Да нет никакой Ады и уже очевидно не будет.
DT> Посмотрим. :)
Да видно уже все.
DT>>> Hу, в общем, логично. Hо всё же легче разобраться в DT>>> ключевых словах, чем в наборе спецсимволов.
DO>> В паскале используется символ ^, в С - * , какие ключевые DO>> слова?
DT> В Паскале, по-моему, просто невозможно объявить такую бодягу, DT> как в C, одной строкой. :) А по поводу ^ - инфиксная нотация DT> разыменования гораздо удобнее.
Привычнее может быть.
DT> Особенно когда я пишу что-то вроде
DT> DynArray[i]^[j]
Тоже кстати не отличается прозрачностью.
DO>>>> char a, b; DO>>>> s = (short)a+b;
DO>>>> Что тут не очевидно? Более того, в паскале та же проблема с DO>>>> тем же решением (правда нестандартным).
DT>>> Так и и чего? Hеужели по дороге, в районе плюса ;), a и b DT>>> не будут преобразованы в int?
DO>> Если написано short, то в short и будут преобразованы.
DT> Это в районе "=".
Нет, это перед сложением. Скомпилируй и посмотри код. Если (short)a не стоит, а стоит просто a+b, то на архитектуре, где работа с байтами естественна, сложение будет байтовое, восьмиразрядное.
dima
formatting link