Embedded Software Developer. Быть или не быть.

[Medium-rare]

Не мешайте, пожалуйста, очередному рецидиву острого ООП. Все остальное это побочные явления.

Не удивительно, что теперь в банальный телефон требуются и гиги память и гиги герцев...

И бутлоадер согласится, не нужно ООП, насколько он это в состоянии понять. Но если надо банальный телефон уровня сложности бутлоадера или даже чуть выше, то без гигов и гигагерцев, можно и сейчас за пару копеек купить, и он будет вполне работать, как телефон, без ненужных вам извращений. Feature phones никуда не делись, появились smartphones.

[RobinF]

Неужели тормоза уже от ООП?

Ну расскажите же мне уже, чем

Code: Select all

class A{
int b;
inf f(){return b+1;}
};

тормознее и жрет больше памяти, чем

struct A {
int b;
};
int f(A* a)
{
return a->b + 1;
}

[Medium-rare]

IMHO, метать бисер... ну вот не покажете преимуществ в бутлоадере...

Это скорее C++ в целом, как более мощный инструмент, позволяет делать и избыточность легко, если плохо следить. Как-то code bloat, распухание кода, от неразумного применения templates. Вроде, захотел бинарный поиск, и растиражировал один и тот же параметризованный алгоритм с одним и тем же критерием, везде, где применяется. Но никто не запрещает использовать тот самый binary_search template в одной функции, и вызывать её повсюду... Да, ООП тут вовсе ни при чём, но возможно неправильное пользование орудием труда.

[RobinF]

Да, ООП тут вовсе ни при чём, но возможно неправильное пользование орудием труда.

О чем и речь. Все проблемы, в тч и тормоза, от неквалифицированных людей, а не от ООП. Чаще всего - в менеджменте (квалифицированного менеджера просто найти и заманить куда труднее чем квалифицированного программиста).
А где неквалифицированные люди - там и тулзы/языки/архитектуры неправильно выбираются, и слишком мало человекочасов (и не тех человеков) на задачу дается, или наоборот - слишком много, и тд и тп.

[Byka]

Неужели тормоза уже от ООП?

Ну расскажите же мне уже, чем

Code: Select all

class A{
int b;
inf f(){return b+1;}
};

тормознее и жрет больше памяти, чем

struct A {
int b;
};
int f(A* a)
{
return a->b + 1;
}

Коллега, перестаньте! Не солидно. Вы же не с детьми в школе на проф. ориентации беседуете.

Тормознее и жрет памяти больше скорее от этого:

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

Никто не нападает на ООП как на метод. Но не стоит делать из этого фетиш!

После того, как производители железа сделали доступным это поле для людей из "настольного программирования" идеологии из "Hello World" мира стали проникать в "железный мир". Но как-то все больше с идеей, что не надо понимать, что вокруг. Без вопросов вроде "Почему все так, как оно есть?" Просто все вокруг идиоты, и не понимают своего счастья. Надо все переписать "с классами" и все станет шоколадно.

При этом как все работает на низком уровне не имеют не малейшего представления. Как, где, когда и какие данные оказываются, имеют самое туманное представление. То, что в настольном мире делается "само собой" оказывается полной неожиданностью. А определение класса в качестве локальной переменной в обработчике прерываний вообще рядовым делом. "А какая разница? Так же элегантнее! И код компактнее!"

При этом знания инструментов - компилятора, языков, линкеров и прочей языковой лабуды у "суровых" железячников как правило на очень не плохом уровне и попрекать их в косности не правильно. Как раз для них знание, чем статический член класса отличается от обычного не является откровением. И как, какой компилятор, маскарадит код - тоже не новость.

Главная идея - не надо считать, что вокруг идиоты. И все будет проще!

[Medium-rare]

Byka, вы своему совету последовать собираетесь?

Я писал в точности про спагетти код на C (что там опять понавыделяли, как аргумент, что-ли?), как попало имплементирующий workflow с очень красивой диаграммы состояний. Да-да есть такой документ, описывающий этот модуль. Потому что дальше анализа там OO подход не пошёл. Там на диаграмме штук 20 кружочков и связи между ними, ну, по 2-3 от каждого. Реальный код - "кружочки" размазаны и зачем-то пересекаются причудливым образом, а стрелок там не 20 * 3, а непойми-сколько в файле исходного кода > 200 kb (вообще-то есть и прочие файлы, но меньше вовлечены). В точности про тот код и сказал, что никуда не годится. И переписать его надо с применением популярного патерна state machine с выраженными объектами состояний и переходами между ними (метод каждому, с горсткой переходов). В сложном embedded софте это далеко не единственное "правильное" место для применения C++. Можно продолжать и на C мудохаться, конечно. Можно изобразить из структур объекты. Не очень ясно, зачем, когда есть лучше инструмент.

Вы с самого начала либо не вникали, либо вам просто было скучно. Припёрли бут-лоадер. Чего хотели?

[RobinF]

А определение класса в качестве локальной переменной

Это ж как?

[Dm.uk]

> Операционная система? Это такой кусочек кода который универсально позволяет что-то делать прочим кусочкам кода, и то не всегда. Зачастую в embedded нет и операционной системы.

+1


> Не везде ООП применимо, особенно, если не "натягивать" это решение на неподходящую задачу.

+2

> Ваши "сущности", похоже, довольно сильно изолированы от реального "железа" слоями готового кода.

похоже на то, еще +3


> Не удивительно, что теперь в банальный телефон требуются и гиги память и гиги герцев...

с одной стороны хочется сказать "во-во!", а с другой стороны понимаю что для поддержки нескольких распространенных интерфейсов работающих _параллельно_ и независимо друг от друга потребуется поддерживать их различные протоколы итд итп. Плюс юзер интерфесы, фичи итд итп. В данном случае - к.г. паралельте все (точнее почти все) на здоровье.


> ... стали проникать в "железный мир". Но как-то все больше с идеей, что не надо понимать, что вокруг. Без вопросов вроде "Почему все так, как оно есть?" Просто все вокруг идиоты, и не понимают своего счастья. Надо все переписать "с классами" и все станет шоколадно.

При этом как все работает на низком уровне не имеют не малейшего представления. Как, где, когда и какие данные оказываются, имеют самое туманное представление.

+500
о, регулярно встречаю таких на различных проектах.
Как только найду коллектив где таких нет - тут же пойду туда, да хоть на graduate роль!

[Medium-rare]

Dm.uk, вы за поговорить? Ну да я же не против. Товарищ набрасывает аргументы бо знает откуда. С 9 утра до 6 вечера примерно "имеем представление", по локоть в. Реальные проблемы, чесслово, не в обслуживании прерываний, не в чтении порта, не в (де)сериализации. Те низкоуровневые проблемы вполне недавно порешали очередной раз, портируя код на POSIX. Те проблемы достаточно тривиальны и отнимают небольшой процент времени.

[Byka]

А определение класса в качестве локальной переменной

Это ж как?

Да, это Вы меня подловили. Некорректно выразился.

Фразу:

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

Следует читать:

А объявление экземпляра класса в качестве локальной переменной в обработчике прерываний вообще рядовым делом.

Прошу прощения за допущенную неточность.

[AndreyT]

Это скорее C++ в целом, как более мощный инструмент, позволяет делать и избыточность легко, если плохо следить. Как-то code bloat, распухание кода, от неразумного применения templates. Вроде, захотел бинарный поиск, и растиражировал один и тот же параметризованный алгоритм с одним и тем же критерием, везде, где применяется.

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

Но никто не запрещает использовать тот самый binary_search template в одной функции, и вызывать её повсюду...

Для чего именно? Еще раз, если параметры инстанциирования одни и те же, то вызов 'binary_search' "из одной функции" не дает ничего, кроме ненужного преумножения сущностей. Если же параметры инстанциирования разные, то для "вызова из одной функции" придется перейти от compile-time параметризации к run-time параметризации. А вопрос выбора между compile-time и run-time параметризацией - это вопрос того, что именно вам нужно, что вы хотите получить в результате, а не вопрос правильного или неправильного использования средства.

[Medium-rare]

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

Предположим, есть модуль .cpp, в нём в разных местах, в разных функциях, инстантиируется binary_search для одного и того же типа данных. Вы хотите сказать, что компилятор неявно создаст отдельную функцию в которую и определит этот binary_search?

[AndreyT]

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

Предположим, есть модуль .cpp, в нём в разных местах, в разных функциях, инстантиируется binary_search для одного и того же типа данных. Вы хотите сказать, что компилятор неявно создаст отдельную функцию в которую и определит этот binary_search?

Компилятор неявно создаст отдельную функцию по имени 'binary_search<тип итератора, тип значения>' и будет вызовать именно ее во всех местах, где используется шаблонный 'binary_search' именно с таким типом итератора и именно с таким типом искомого значения. Такая функция гарантированно будет единственной на всю программу.

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

Code: Select all

int *int_array_begin, *int_array_end;
...

int a = 5;
short b = 3;

binary_search(int_array_begin, int_array_end, a);
binary_search(int_array_begin, int_array_end, b);

по вышеописанным причинам породят две разные функции 'binary_search', в то время как можно было обойтись одной, написав

Code: Select all

binary_search(int_array_begin, int_array_end, a);
binary_search(int_array_begin, int_array_end, (int) b);

или

Code: Select all

binary_search<int *, int>(int_array_begin, int_array_end, a);
binary_search<int *, int>(int_array_begin, int_array_end, b);

С этой точки зрения во избежание неумышленного размножения имеет смысл заоболочить вызов в другую, нешаблонную функцию.

Но, в любом случае, размножение - это следствие различия шаблонных параметров. Т.е. опасность code bloat, разумеется, присутствует, особенно в случаях, когда у шаблона много шаблонных параметров: при неосторожном обращении с этими параметрами можно получить комбинаторный взрыв. Но когда различия нет, то и размножения нет.

[Medium-rare]

Компилятор неявно создаст отдельную функцию по имени 'binary_search<тип итератора, тип значения>' и будет вызовать именно ее во всех местах, где используется шаблонный 'binary_search' именно с таким типом итератора и именно с таким типом искомого значения. Такая функция гарантированно будет единственной на всю программу.

ЕМНИП, в g++ когда-то по умолчанию были выключены тимплейты, поскольку он не мог эффективно бороться с code bloat, и была статья на тему, как включить опцию, но не допускать bloat. А в то время я как раз активно с тимплейтами эксперементировал, почему и "залипло".

Кстати, вставлять неявный function call, с другой стороны, тоже не всегда кошерно... но таки зло не столь большой руки.

Так или иначе, с таким мощным аппаратом подавления code bloat, С++ становится ещё более мощным и немного более безопасным инструментом.

[RobinF]

Следует читать:

А объявление экземпляра класса в качестве локальной переменной в обработчике прерываний вообще рядовым делом.

Прошу прощения за допущенную неточность.

Ну-ка, ну-ка, расскажите нам, что такого страшного и нерядового в следующем коде

Code: Select all

class A {
int a,b;
void f();};
...
void interruptHandler(){
A a;
a->f();

По сравнению с

Code: Select all

struct A {
int a,b;
};
void f(A * a);
...
void interruptHandler(){
A a;
f(&a);

или даже

Code: Select all

void f(int *a, int *b);
...
void interruptHandler(){
int a,b;
f(&a, &b);

???

[RobinF]

Это скорее C++ в целом, как более мощный инструмент, позволяет делать и избыточность легко, если плохо следить. Как-то code bloat, распухание кода, от неразумного применения templates. Вроде, захотел бинарный поиск, и растиражировал один и тот же параметризованный алгоритм с одним и тем же критерием, везде, где применяется.

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

Строго говоря, один раз на один физический модуль. Т.е. если в Вашей программе 200 DLLек, из которых вызывается функция, полученная инстанциированием темплейта, то эта функция будет размножена 200 раз. К тому же реальные компиляторы требуют определения темплейтов классов inline (export никто нормально не поддерживает), поэтому и компиляторы имеют тенденцию еще и поинлайнить всласть, даже без необходимости (не всегда, и можно бороться с __noinline всякими, однако). В программах с тяжелым использованием темплейтных библиотек (начиная с той же STL) разница огромная.
Разумеется, на нынешнем этапе развития технологии это должно решаться не отказом от темплейтов, а отказом от ненужных DLLек - единый executable - это самый компактный, быстрый и беспроблемный вариант программы. А DLLки-soшки только там где без них нельзя, типа плагины.

[RobinF]

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

Предположим, есть модуль .cpp, в нём в разных местах, в разных функциях, инстантиируется binary_search для одного и того же типа данных. Вы хотите сказать, что компилятор неявно создаст отдельную функцию в которую и определит этот binary_search?

Да. Если в разных юнитах компиляции (cpp-шниках) - то компилятор создаст по одному разу на юнит (с одним именем), а линкер при сборке физического модуля (exe-шника или dll-ки, сошки и тд) выкинет лишние копии. Проблема только между модулями - линкеры производят и видят только один за раз, да и есть возможность использовать их самостоятельно - поэтому в каждом останется по копии.

[Medium-rare]

Чем дальше, тем меньше аргументов против C++ в embedded. Только что доставили диаграмку взаимодействия новую внутри одного из пяти состояний. Это, конечно, надо попытаться упростить изначально, но, тем не менее. Вот вам объекты. Диаграмма сделана с существующего спагетти кода, можно сказать, по требованию тех, кто пытается понять, как оно работает.

[Byka]

...
Ну-ка, ну-ка, расскажите нам, что такого страшного и нерядового в следующем коде

Code: Select all

class A {
int a,b;
void f();};
...
void interruptHandler(){
A a;
a->f();

По сравнению с

Code: Select all

struct A {
int a,b;
};
void f(A * a);
...
void interruptHandler(){
A a;
f(&a);

или даже

Code: Select all

void f(int *a, int *b);
...
void interruptHandler(){
int a,b;
f(&a, &b);

???

К RobinF.

Ну ведь просил же Вас, не считайте, что с Вы с детьми на уроке информатики беседуете!
Или Вам все кажется, что Вы интервью проводите?

Ну а по поводу Ваших примеров, то не серьезно все это!

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

Во вторых. Если задаете вопросы, то задавайте их корректно, пожалуйста. Какой компилятор предполагается использовать? Ну или хотя бы какое расширение у файлов? Вы безусловно в курсе, что для структур результат может быть разным.

Если хотите и готовы обсудить особенности применения С++ для встроенных и низкоуровневых приложений, давайте перестанем флудить в этой ветке и перенесем это в отдельное обсуждение. Там и про прерывания можем поговорить. И про особенности реализации для различных архитектур.

К Модератору.
Если начинаем надоедать с очередной войной тупоконечников с остроконечниками перенесите продолжение этого обсуждения в отдельную ветку.

Всем привет.

[RobinF]

...
Ну-ка, ну-ка, расскажите нам, что такого страшного и нерядового в следующем коде

Code: Select all

class A {
int a,b;
void f();};
...
void interruptHandler(){
A a;
a->f();

По сравнению с

Code: Select all

struct A {
int a,b;
};
void f(A * a);
...
void interruptHandler(){
A a;
f(&a);

или даже

Code: Select all

void f(int *a, int *b);
...
void interruptHandler(){
int a,b;
f(&a, &b);

???

К RobinF.

Ну ведь просил же Вас, не считайте, что с Вы с детьми на уроке информатики беседуете!
Или Вам все кажется, что Вы интервью проводите?

Ну а по поводу Ваших примеров, то не серьезно все это!

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

Это стрелку-то вместо точки Вы называете "концептуальной ошибкой"? Еще придеритесь что закрывающих фигурных скобок нет, возвращаемое значение не то что Вам нужно и тд. КОНЦЕПТУАЛЬНО как раз ясно как день что первые два примера по скорости абсолютно одинаковы, даже оптимизированный код будет в 99% случаев идентичен, а третий немного медленнее (и чем больше параметров - тем медленнее) на всех современных пайплайновых архитектурах.

Во вторых. Если задаете вопросы, то задавайте их корректно, пожалуйста. Какой компилятор предполагается использовать? Ну или хотя бы какое расширение у файлов? Вы безусловно в курсе, что для структур результат может быть разным.

Вы не крутитесь. Если побаиваитесь С++ по незнанию - начинайте работать над собой.

[Flash-04]

интересное наблюдение: сколько PDA ни видел (WinCE, Palm, Symbian), везде был урезанный C++. "Пострадавшие": exceptions, templates. Я так понял что выкинули их сознательно. Причем с exceptions все поступили одинаково - ввели свои какие-то _try/_catch которые работали не совсем корректно, да и не реализовали оригинальную функциональность. Соотвественно мат в работе использовался часто

[Medium-rare]

интересное наблюдение: сколько PDA ни видел (WinCE, Palm, Symbian), везде был урезанный C++. "Пострадавшие": exceptions, templates. Я так понял что выкинули их сознательно. Причем с exceptions все поступили одинаково - ввели свои какие-то _try/_catch которые работали не совсем корректно, да и не реализовали оригинальную функциональность. Соотвественно мат в работе использовался часто

То было давно, и уже не правда. Хоть это и не в самом деле embedded программирование, но на WinCE уже вполне full-fledged C++ давно как доступен. Настройками проекта/ опциями компиллятора там можно было подкрутить, как мне подсказывает склероз в районе 2007-го года. А Symbian одна очень большая компания рассматривала как платформу для развития своих смартфонов. Хотело ума им отказаться от Symbian, но дело не в том. Тот проект так и стартовал, как cross-platform уровень интеграции с GPS чипом. Exceptions были выключены сознательно, templates использовали без ограничений, никак они не пострадали. Потом практически без усилий всё это перенсли в POSIX/Android. Переписали пару модулей IO.

[Flash-04]

в районе 2007-го года

я уже тогда перестал под WinCE писать. Так и не застал своего счастья

[Byka]

...

Это стрелку-то вместо точки Вы называете "концептуальной ошибкой"? Еще придеритесь что закрывающих фигурных скобок нет, возвращаемое значение не то что Вам нужно и тд. КОНЦЕПТУАЛЬНО как раз ясно как день что первые два примера по скорости абсолютно одинаковы, даже оптимизированный код будет в 99% случаев идентичен, а третий немного медленнее (и чем больше параметров - тем медленнее) на всех современных пайплайновых архитектурах.

Во вторых. Если задаете вопросы, то задавайте их корректно, пожалуйста. Какой компилятор предполагается использовать? Ну или хотя бы какое расширение у файлов? Вы безусловно в курсе, что для структур результат может быть разным.

Вы не крутитесь. Если побаиваитесь С++ по незнанию - начинайте работать над собой.

Ну прямо и не знаю с чего начать! Столько всего! Просто непаханное поле!

Естественно, это ерунда! Какие-то незначительные детали!!! Ну там "стрелка" вместо "точки". Кого это интересует, в конце концов. Другой раз и указатели не проинициализируем... Главное, что бы концепция была верна. Только это как когда "козуля" из носа торчит. Лицо-то не кривое, не косое, чего уж на детали-то отвлекаться.

Ну а если вернуться к сути вопроса. Концептуально, так сказать. В варианте с экземпляром класса в теле функции Вы, своею рукой, без малейшего смущения, "привезли" себе, как минимум, один лишний, совершенно не оправданный вызов функции. Каждый вызов прерывания будет сопровождаться вызовом конструктора. А может так случится, что и деструктора. Или это тоже, как и скобки с несовпадающими параметрами, незначительные детали?! Или и тут все будет отоптимизированно до неузноваемости?! Вот если бы у вас там и правда был бы указатель, то все было бы более-менее "кошерно". Если бы Вы не забыли бы его проинициализировать, естественно. Подставьте вместо Вашего варианта класса, что-то имеющее функционал подобный "String" из STL. Это будет такое ООПе, что ой-ой-ой!!!

Так что про "пайплайны" и прочие алгебры тут еще речи не идет. Тут пока еще азбука.

Ну а по поводу разных компиляторов. Вы, безусловно, в курсе что struct в С++ может иметь весь набор обычного класса - и методы, и конструктор с деструктором. Я в это практически не сомневаюсь, что знаете! И стал быть сгенерированный код будет отличаться в зависимости какой компилятор Вы будете использовать - Сишный или Плюсный. Вот так!

Так, что никакого кручения-верчения. Вопросы азбучные. Даже для меня. Хотя я и не претендую, как Вы, на всеобщие знания.

Ну и последнее, что бы уж два раза не вставать.
Если Вы уж такой апологет ООП в низкоуровневом программировании, то что у Вас такие примеры-то такие не масштабные?! Давайте уж сразу предложите дизайн класса 'БазовогоОбработчикаВсехПрерыванийДляВсехАрхитектур'. Чего уж так мелочиться-то? Давайте же скорее спасать заблудших в "структурном грехе"? Мы уж от него отнаследуем, при необходимости.

За сим откланиваюсь.

Всем привет.

[Byka]

интересное наблюдение: сколько PDA ни видел (WinCE, Palm, Symbian), везде был урезанный C++. "Пострадавшие": exceptions, templates. Я так понял что выкинули их сознательно. Причем с exceptions все поступили одинаково - ввели свои какие-то _try/_catch которые работали не совсем корректно, да и не реализовали оригинальную функциональность. Соотвественно мат в работе использовался часто

Для встроенных приложений эти куски языка зачастую просто запрещены, отраслевыми стандартами или сертифицирующими организациями. В зависимости от уровня безопасности приложения, DO-178B, например, не рекомендует, или запрещает использование: исключений, шаблонов, виртуальных функций и информации времени выполнения. И имеет на это веские причины. Анализ "покрытия" например, становится очень затруднительным. Для "исключений" генерация стека - вообще пестня. Что-то они меняют, но очень осторожно и медленно. В консерватизме им не откажешь! Но "исключений", скорее всего не будет. Неприкакихобстоятельствах!!!

А "исключения" для версий языка старых наладонников и WinCE - это вообще была притча во языцах. Мы их просто "волевым решением" запретили для использования в проектах. По причине сильной кривизны. Без них все было не просто, но хотя бы без неотжиданностей. Но WinCE, это вообще была вещь в себе. Этакий байстрюк в семействе мелкомягких.

Всем Привет.