Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Январь 14, 2014, 08:09:55 pm
-
Что-то у нас тут клеветы только на Оберон. Пора бы разбавить. Так что теперь про Си будет (нет. не про С++, хотя к нему частично тоже применимо, особенно если разработчиков давно плетьми не драли и они продолжают писать код в стиле Си).
Собственно сама история описана тут: http://habrahabr.ru/post/198836/
Если кратко - из за того, что в Сях есть две вещи:
1) взятие адреса у локальной переменной (&foo)
2) указателю можно присвоить целое число и ничто нигде не руганется
в коде случайно прошла замена вот такого:
void foo(error* err) {
*err = SUCCESS;
}
void bar() {
error err = SUCCESS;
foo(&err);
}
на такое:
void foo(error* err) {
*err = SUCCESS;
}
void bar() {
error* err = SUCCESS;
foo(err);
}
Ну и собственно всё. Ошибочный код замечательно прошел все тесты (то есть тестирование не спасло, ошибка вылезла только через 30 дней после рокового комитта). Врукопашную найти ошибку не вышло - искали 50 часов, не нашли, только примерно локализовали.
Удалось справиться только посредством сторонней тулзы для статического анализа кода (PVS Studio).
Такой путь появления ошибки в Обероне просто не возможен!
То есть чтобы компенсировать кривость языка Сишникам пришлось написать дико сложную тулзу статической проверки кода - вот она сложность порождающая еще бОльшую сложность на ровном месте (и позволяющая, между прочим, заработать на этих самых тулзах, чем народ и занимается)!
Примечательно также, что та контора по результатам (с помощью тулзы ошибку удалось найти и устранить за час) приобретать эту тулзу для анализа кода... отказалась! Ибо у них за все эти 50 часов поиска ошибки заплатил заказчик, так что с точки зрения бизнеса - всё норм. А тулзу покупать пришлось бы из своего кармана.
Вот такой он, современный мейнстрим в embedded разработке.
-
Замечу, что из за фигурных скобочек таких потерь времени, на моей памяти, не наблюдалось ни разу. А вот борьба с указателями у новичков и не только, в сишном (обычно именно в сишном, а не плюсовом) проекте наблюдается регулярно. В частности неоднократно видел как где-то заводится указатель, а затем сразу используется (разименовывание) явно либо не явно. Еще больше радости когда указатели двойные.
-
Cпасибо, посмеялся.
Правда, нормальный компилятор(gcc, clang) не будет ругаться при присваивании указателю не любого числа, а только 0, чем, очевидно, SUCCES и являлась. Взять, что ли, за правило, что SUCCES не ноль?
-
Cпасибо, посмеялся.
Правда, нормальный компилятор(gcc, clang) не будет ругаться при присваивании указателю не любого числа, а только 0, чем, очевидно, SUCCES и являлась. Взять, что ли, за правило, что SUCCES не ноль?
Ну, во-первых правило (в случае С++) простое - не пользоваться голыми указателями вообще. А в данной задаче указатели были вообще не нужны - ведь есть ссылки.
Во-вторых тут есть отличие у С++ и Си. Берем код:
void main()
{
int* ptr = 0;
ptr = 2;
}
На первую строчку оно в любом случае не ругается. А вот на вторую...
Берем gcc. В случае Си мы максимум получим warning. Такое языком разрешено. А вот в случае С++ будет error, то есть ошибка компиляции, ибо язык явным образом подобное ЗАПРЕЩАЕТ.
Соответственно вот сишный варнинг:
ptr.c:4:9: warning: assignment makes pointer from integer without a cast [enabled by default]А вот плюсовый еррор:
ptr.cpp:4:9: error: invalid conversion from 'int' to 'int*' [-fpermissive]
Так что я солидарен со Страуструпом - оставаться в embedded (да вообще везде) на Си нет ни одной причины, если там есть вменяемый компилятор С++.
-
Да, а в случае C++ если в них использовать нормальные, плюсовые enum'ы (для того же SUCCESS), то опять таки проблем не было бы.
http://en.wikipedia.org/wiki/C%2B%2B11#Strongly_typed_enumerations
-
То есть чтобы компенсировать кривость языка Сишникам пришлось написать дико сложную тулзу статической проверки кода - вот она сложность порождающая еще бОльшую сложность на ровном месте (и позволяющая, между прочим, заработать на этих самых тулзах, чем народ и занимается)!
Упрек к Си, по-моему, несправедливый.
Где тут изначальная сложность со стороны отцов-основателей. Что они могли в данном случае сделать по-другому? Изобрести сразу C++?
Типа, это и есть простота.
-
В чём претензии к Си(++) ??????????????????????????????????????
Всё ко всему можно присвоить?
ТАК ОН ИМЕННО ДЛЯ ЭТОГО И ДЕЛАЛСЯ! :)
-
В чём претензии к Си(++) ??????????????????????????????????????
Всё ко всему можно присвоить?
ТАК ОН ИМЕННО ДЛЯ ЭТОГО И ДЕЛАЛСЯ! :)
Ну, в С++ таки не все всему можно присвоить без явного указания компилятору, что ты знаешь что делаешь. Ибо типизация (в основном) строгая, в отличие от Си.
Кстати, многие сишники именно за это (значительно более строгую типизацию) С++ и не любят - лишняя писанина, говорят. Компилятор нам не доверяет, говорят. А уж современный С++ им совсем должен быть отвратен :-)
-
Но мне больше всего понравилось именно само объявление функции:
void foo(error* err) ...
У него - глубочайший сакральный смысл! В смысле что и для чего пользуем... :)
(Конечно же, может быть автор сообщения на хабре просто "проиллюстрировал"...)
-
Ну, в С++ таки не все всему можно присвоить без явного указания компилятору, что ты знаешь что делаешь. Ибо типизация (в основном) строгая, в отличие от Си.
Говорят - да...
Кстати, многие сишники именно за это (значительно более строгую типизацию) С++ и не любят - лишняя писанина, говорят. Компилятор нам не доверяет, говорят. А уж современный С++ им совсем должен быть отвратен :-)
Кстати, правильно говорят...
Си хорош в своей нише.
Даже более скажу, пока лучше - ничего не придумали для системного и низкоуровневого программирования.
А там - просто как воздух необходим всяческий произвол и "извращения" с минимальными усилиями. :)
-
Ну, во-первых правило (в случае С++)
...
Во-вторых тут есть отличие у С++ и Си.
...
Так что я солидарен со Страуструпом - оставаться в embedded (да вообще везде) на Си нет ни одной причины, если там есть вменяемый компилятор С++.
Ну я-то как раз использую Си, но стараюсь писать так, чтобы можно было собрать и как С++. И, кстати, поэтому могу сказать, что последнее утверждение не совсем верно. К примеру gcc выдаёт чуть более компактный и более быстрый код, если его собирать как Си проект. Странно, но факт, а уж g++ компилятор вменяемый.
-
Но мне больше всего понравилось именно само объявление функции:
void foo(error* err) ...
У него - глубочайший сакральный смысл! В смысле что и для чего пользуем... :)
(Конечно же, может быть автор сообщения на хабре просто "проиллюстрировал"...)
Ненене, в моем сообщение не было копипасты (ни кода, ни текста) из сообщения автора на хабре. Это чисто мой код, как я понял их проблему.
Код я предельно сократил.
-
Ну, во-первых правило (в случае С++)
...
Во-вторых тут есть отличие у С++ и Си.
...
Так что я солидарен со Страуструпом - оставаться в embedded (да вообще везде) на Си нет ни одной причины, если там есть вменяемый компилятор С++.
Ну я-то как раз использую Си, но стараюсь писать так, чтобы можно было собрать и как С++. И, кстати, поэтому могу сказать, что последнее утверждение не совсем верно. К примеру gcc выдаёт чуть более компактный и более быстрый код, если его собирать как Си проект. Странно, но факт, а уж g++ компилятор вменяемый.
Странно. Пример можно? А если отключить исключения и выкинуть рантайм (это в опциях компилятора есть)?
-
Кстати, правильно говорят...
Си хорош в своей нише.
Даже более скажу, пока лучше - ничего не придумали для системного и низкоуровневого программирования.
Я бы таки уточнил - железоориентированное программирование (то есть близкое к железу). Оно при этом может быть вполне себе высокоуровневым и прикладным, а не системным.
А там - просто как воздух необходим всяческий произвол и "извращения" с минимальными усилиями. :)
Нужны. Но нужно иметь возможность извращения эти огородить, кроме того, синтаксические извращения как раз не нужны :-)
По поводу того, что лучше не придумали - я пока не знаю. Скажем тот же Astrobe вроде бы вполне успешно решает задачи, народ не стенает и не мучается, хотя там Оберон. Ексельсиоровцы вроде бы вполне оный Ексельсиор на модуле-2 написали, и тоже без особых страданий. А это же юникс. Ну и так далее.
-
Странно. Пример можно? А если отключить исключения и выкинуть рантайм (это в опциях компилятора есть)?
Отключить рантайм я не могу, не поработав над проектом дополнительно, что мне разумеется не нужно. Как отключить исключения - не знаю, нас ведь уверяют, что в С++ не платят за то, что не используют. Разумеется, в проекте исключений нет. Сам проект, увы, привести не могу. Вот что показывают результаты эксперимента:
gcc - 4.4.3, strip 2.20.1, valgrind - 3.6.0
| Язык | Размер | Callgrind refs |
| Си | 153320 | 1,489,518,733 |
| С++ | 190252 | 1,532,850,808 |
Проект для ПК, но теоретически соотношение может соблюдаться и для специализированных версий gcc.
-
Странно. Пример можно? А если отключить исключения и выкинуть рантайм (это в опциях компилятора есть)?
Отключить рантайм я не могу, не поработав над проектом дополнительно, что мне разумеется не нужно. Как отключить исключения - не знаю, нас ведь уверяют, что в С++ не платят за то, что не используют. Разумеется, в проекте исключений нет. Сам проект, увы, привести не могу. Вот что показывают результаты эксперимента:
gcc - 4.4.3, strip 2.20.1, valgrind - 3.6.0
| Язык | Размер | Callgrind refs |
| Си | 153320 | 1,489,518,733 |
| С++ | 190252 | 1,532,850,808 |
Проект для ПК, но теоретически соотношение может соблюдаться и для специализированных версий gcc.
Не в случае исключений :-) Ну, то есть да, на скорость они считай не влияют, но стек таки жрут. Тем более что если они тебе не нужны, их нужно отключить явным образом: -fno-exceptions (это опция для gcc). Попробуй плиз.
Во-вторых таки valgrind - он не про скорость, а про безопасность, и привносит свой оверхед, причем скорее всего разный для разных языков.
-
Скажем тот же Astrobe вроде бы вполне успешно решает задачи, народ не стенает и не мучается, хотя там Оберон.
Конечно не мучается.
Некому просто.
Или - исчезающе малый процент. Практически - на уровне статпогрешности. :)
Ексельсиоровцы вроде бы вполне оный Ексельсиор на модуле-2 написали, и тоже без особых страданий. А это же юникс. Ну и так далее.
Экселсиор - не "это же юникс". :)
-
Скажем тот же Astrobe вроде бы вполне успешно решает задачи, народ не стенает и не мучается, хотя там Оберон.
Конечно не мучается.
Некому просто.
Или - исчезающе малый процент. Практически - на уровне статпогрешности. :)
Ну, те кто пользуют, вроде не стенают :-) Хотя, вот отсутствие отладчика для этого класса задач дико бесит. Отладочная печать в com-порт ведь далеко не всегда будет работать если что-то пошло действительно не так. Ну, то есть словил ASSERT/HALT, и... ничего! Просто не работает.
Ексельсиоровцы вроде бы вполне оный Ексельсиор на модуле-2 написали, и тоже без особых страданий. А это же юникс. Ну и так далее.
Экселсиор - не "это же юникс". :)
Ну, есть что-то в нем такое, юниксообразое, в операционке этой. :-)
-
Ну, те кто пользуют, вроде не стенают :-) Хотя, вот отсутствие отладчика для этого класса задач дико бесит. Отладочная печать в com-порт ведь далеко не всегда будет работать если что-то пошло действительно не так. Ну, то есть словил ASSERT/HALT, и... ничего! Просто не работает.
Не в этом дело.
Не применяе5тся он нгдк по-серьёзному.
Те, кто пишет ПО для "ящиков с картошкой на балконе" - пользуют взломанное или свободное от грандов отрасли, чьи кристаллы используются.
А для оборонки и всего остального - сертификация нужна. А Астроб этого в планах не имеет...
Ну, есть что-то в нем такое, юниксообразое, в операционке этой. :-)
Синтаксис командной оболочки немножко похож.
-
Ну, те кто пользуют, вроде не стенают :-) Хотя, вот отсутствие отладчика для этого класса задач дико бесит. Отладочная печать в com-порт ведь далеко не всегда будет работать если что-то пошло действительно не так. Ну, то есть словил ASSERT/HALT, и... ничего! Просто не работает.
Не в этом дело.
Не применяе5тся он нгдк по-серьёзному.
Те, кто пишет ПО для "ящиков с картошкой на балконе" - пользуют взломанное или свободное от грандов отрасли, чьи кристаллы используются.
А для оборонки и всего остального - сертификация нужна. А Астроб этого в планах не имеет...
Не, ну вон, не дешевые беспилотники пилят на нем: http://www.astrobe.com/forum/viewtopic.php?f=3&t=400 То есть это именно контора-разработчик этого Брат'а автопилот для него на Astrobe ваяет.
Ну, есть что-то в нем такое, юниксообразое, в операционке этой. :-)
Синтаксис командной оболочки немножко похож.
Ну и все остальное тоже, немножко похоже :-)
-
Не в случае исключений :-) Ну, то есть да, на скорость они считай не влияют, но стек таки жрут. Тем более что если они тебе не нужны, их нужно отключить явным образом: -fno-exceptions (это опция для gcc). Попробуй плиз.
Да, без исключений - лучше.
| Язык | Размер | Callgrind refs |
| Си | 153320 | 1,489,518,733 |
| С++ | 190252 | 1,532,850,808 |
| С++ no-exceptions | 157424 | 1,532,532,864 |
Во-вторых таки valgrind - он не про скорость, а про безопасность, и привносит свой оверхед, причем скорее всего разный для разных языков.
Далеко не только про безопасность. С опцией --tool=callgrind он становится хорошим профилировщиком, но и помимо callgrind в --tool= ещё есть интересное. Число, которое выдаёт инструмент коррелирует со временем выполнения, но отличается стабильностью и точностью.
-
Не в случае исключений :-) Ну, то есть да, на скорость они считай не влияют, но стек таки жрут. Тем более что если они тебе не нужны, их нужно отключить явным образом: -fno-exceptions (это опция для gcc). Попробуй плиз.
Да, без исключений - лучше.
| Язык | Размер | Callgrind refs |
| Си | 153320 | 1,489,518,733 |
| С++ | 190252 | 1,532,850,808 |
| С++ no-exceptions | 157424 | 1,532,532,864 |
Осталось выяснить что такое Callgrind refs и почему у плюсового кода их так много :-)
Мой hello world (без hello world) C и C++ компиляторы преобразуют в абсолютно идентичный асм-код (за вычетом манглинга имен). Надо найти пример когда у них начнется расхождение.
-
Callgrind refs - это стоимость выполнения. valgrind выполняет программу как виртуальная машина и считает количество выполненных инструкций, помноженных на их вес.
Про много речь и не шла :) . Выяснить причину затруднительно, потому что да, на helloworld -ах не заметно, а на крупной - поди сыщи.