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

а ада на ноль не разделила бы что-ли? просто посоны не написали правильные валидаторы и не проверяли параметры при подстановке в функцию. что опять же грех.

В ада деление на ноль не вышло бы за пределы задачи, так как в ней нет UB. И «что привело к переполнению буфера , в результате чего вышли из строя все машины в сети» не случилось бы.

В ада деление на ноль не вышло бы за пределы задачи, так как в ней нет UB

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

задачу прервут по любому, что тут, что там.

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

Судя по всему перехватили и затем сделали UB (переполнение буфера).

задачу прервут по любому, что тут, что там.

В Ада просто прервут. А в Си(++) перед смертью возможны произвольные действия. UB он такой.

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

А в Си(++) перед смертью возможны произвольные действия. UB он такой.

это миф. UB - это вообще пугалка от плюсов. в плюсах все смешано в одну кучу - неустранимые ошибки и ошибочное поведение. деление на ноль - это неустранимая ошибка, она немедленно перехватывается и программа завершается, если не было попытки перехватить и восстановаиться . а какое-нить обращение по мусорному указателю - ошибочное поведение. работать в принципе можно…пока не возникнет неустранимая ошибка.

деление на ноль - это неустранимая ошибка, она немедленно перехватывается и программа завершается, если не было попытки перехватить и восстановаиться

Да, с делением на ноль всё хорошо. Проблема была, видимо, в UB в обработчике этой ошибки.

а какое-нить обращение по мусорному указателю - ошибочное поведение. работать в принципе можно…пока не возникнет неустранимая ошибка.

Обращение на запись по мусорному указателю может испортить данные любой другой части программы. Для надёжных программ это неприемлемо. Это всё равно что ОС без защиты памяти: любая программа может произвольным образом менять код ОС.

Не. Я пас. =)

Дело даже не в том, что у меня, в моём сумеречном git лежит парочка своих ОС. Думаю, у любого эмбеддера их не по одной. =) Я свои строгал именно и чисто из академического такого интереса.

Я просто достаточно сильно озадачен по поводу «повторяемости». Т.е., сегодня может быть ARM, завтра MIPS, … В общем, ну его на фиг развлекаться лишний раз на ровном месте. Если мы говорим о чисто эмбеддед, то скорее всего у нас просто дохленький проц, на котором крутится несколько задачек по сбору данных/управлению, плюс какие-то коммуникации. Значит, нам тут нужно что-то мелкое и быстрое.

Самым общеупотребительным вариантом я бы назвал FreeRTOS. И достаточно гибкий проект и достаточно небольшой. Если без особых «наворотов», то там буквально три файла. С наворотами не намного больше. И писать ничего не нужно типа планировщика. Всё есть и портировано практически на все мелкие платформы. Просто реализуем своё функциональное наполнение и всё. В данном случае там всё на С, который по своей сути это портируемый ассемблер и не более того.

Стек TCP/IP так же есть, если он внезапно понадобится. В общем, если не хочется делать лишнюю рутинную работу и долго трахаться с портированием в дальнейшем, то самое оно.

P.S. Ну а про использование абстрактных типов данных (ADT), если уж они действительно понадобятся в проекте для каких-то целей, то это к Седжвику. Там всё расписано. И ни каких stl и бюстов.

Да. В том-то и проблема.

UB - это вообще пугалка от плюсов. в плюсах все смешано в одну кучу - неустранимые ошибки и ошибочное поведение.

В плюсах именно из-за переусложнённости механизма экспешонов такой звиздец и творится. Если в сях дёрнул функцию, она либо что-то сделала, либо возвратила код ошибки и потом, если нужно можно посмотреть чё там за errno, а дальше уже решить падать или исправлять (это если мы говорим про Linux), то в плюсах не будешь в try-catch каждый отдельный вызов функции оборачивать. Как правило, оборачивают группу вызовов и получаем что где-то в пределах этой группы упало, а где именно не ясно, дебажить надо.

Если уж совсем «по-правильному» (чисто примера ради!), то даже printf(); имеет возвращаемое значение и, если мы его хотим проигнорировать, то по идее, надо записать (void)printf(); В случае, если printf(); вернула бы отрицательное значение, я мог бы просто вывести текущее значение errno, которое сказало бы почему у меня не сработал вывод.

На практике да, именно так ни кто не делает, но эта возможность синтаксически есть и в коде она включается куда как проще чем в плюсах.

На плюсах тоже можно так, но тогда смысл плюсов?

С перехватом (маскированием) сигналов тоже просто. На раз-два можно сказать. По сути, тот же SIGFPE это просто одно из состояний процессора. Надо смотреть откуда оно в коде прилетело. И вообще откуда в коде для эмбеддеда взялось деление на ноль. Как правило, на контроллере ему просто неоткуда взяться. Ну нет там каких-то суперсложных вычислений и данные, находящиеся в обработке именно на контроллере всегда проходят валидацию. Даже если система основана на QNX и, собственно, реалтаймовая и не эмбеддед вовсе.

Если говорить о других случаях UB, то это как правило, недостаточно тестированные случаи. Тут TDD в помощь и инструментальные средства. Нарваться на проблемы можно, но это крайне сложно.

По поводу Ada ни чего не скажу. Единственная контора, которая его использует из мне известных, это Пентагон и там чего-то всё не особо весело, судя по «результатам». =))) Думаю, здесь не в языке дело.

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

просто надо ставить флаг компиляции -fno-exceptions, и тогда все эксепшены и все что с ними связано, снимает как рукой.

проблемы остаются только там, где явно делают throw, catch, тогда это становится ошибкой компиляции. эти места над переделать. но у тех, кто понимает, таких мест и нет.

Возможно.

просто надо ставить флаг компиляции -fno-exceptions, и тогда все эксепшены и все что с ними связано, снимает как рукой.

Ну, если задача – получить из С++ голый С, то в принципе можно и ексепшоны убрать и вообще «писать на С++ как на С». Но я лучше предпочту «писать на С с ООП» (на С можно даже с ФП писать и тоже до некоторой степени). В конце-концов, классы до некоторой степени можно заменить структурами с callback-функциями (указателями на функции) и жить с этим спокойно.

В С++ напрягает то, что его стандарт разнесло за последние годы так, что у меня подозрения что из-за синтаксического сахара у С++ уже синтаксический диабет начался. А вся эта беда требует своей поддержки в рантайм, так что и рантайм тут тоже жиреет.

С тонкий, лёгкий, стройный. Собственно, это и подкупает.

А вся эта беда требует своей поддержки в рантайм, так что и рантайм тут тоже жиреет.

Это говорит о том что про С++, его стандарт и «жирный» рантайм тебе Сара по телефону напела.

Таки да! =)))

Это говорит о том что про С++, его стандарт и «жирный» рантайм тебе Сара по телефону напела.

Открываем стандарт С++ (pdf, ISO/IEC JTC1 SC22 WG21 N 3690 Date: 2013-05-15) Смотрим. 1374 страницы ровным счётом.

Открываем стандарт С++ (pdf, Working Draft, Standard for Programming Language C++ Document Number: N4868Date: 2020-10-18) Смотрим. 1857 страницы.

Теперь смотрим С. C99 – WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3. 552 страницы. Ажно 2007 год.

C11 – December 2, 2010 ISO/IEC 9899:201x 696 страницы. 2010г.

За семь лет и так «крупненький» стандарт на С++ раздуло на 483 страницы. За 3 года тоненький С раздуло на 144 страницы. 483/7 = 69 и 144/3 = 48 условных страниц в год.

Вам таки надо было слушать тёту Сару, которая всегда говаривала – «если Ви таки не хотите щоби Вас разнесло, не надо жрать после шести и курить возле бензоколонки».

И дальше.

Так же я могу позавидовать Вашей… незамутнённости. Видимо, Вы действительно не читали стандартов. И на С++ в том числе.

Потому что фраза собеседника типа – *просто надо ставить флаг компиляции -fno-exceptions, и тогда все эксепшены *

Говорит о том, что собеседник зачем-то – Ну, если задача – получить из С++ голый С, то в принципе можно и ексепшоны убрать

Получает из С++ С. Просто потому, что механизм exceptions является неотъемлемой частью стандарта С++. Откройте первую же ссылку в данном комменте и убедитесь в этом на стр. 386 в разделе 15. Exception handling. Можете открыть и вторую ссыль, там тоже про экспешоны есть.

И нет. Ни какие бредни упоротых преподов из местечковых ГПТУ, которе кто-то и зачем-то назвал ВУЗами, здесь не канают.

Как люди делают.

Пробежимся по известным проектам.

LittleKernel. Операционка, на основе которой гугль теперь пилят свою Фуксию. Изначально создана именно для embedded, в отличие от fuschia, которая вообще-то не для него.

Уже упоминавшаяся в треде FreeRTOS. Опять С. А дальше – uOS/II, rt-thread, smx, contiki (это по большей части для IoT, но ядро тут С, проверял лично), TKkernel. Это только то, с чем я работал и работаю лично. И это всё С, знаете ли…

Наконец.

Про runtime я даже и говорить ничего не буду, и так времени чуть больше на Вас потратил, чем Вы заслуживаете. Если Вы не понимаете что сказанное в стандарте должно поддерживаться в рантайме в более-менее полном объёме, то это уже значит что мне нужно заниматься Вашим пост-ГПТУшным образованием. А мне лень. Честно. Да и денег от Вас я за это не получу.

Пардон, но нет. Вы ненужны ни для чего, касающегося embedded programming, ни в каком количестве. Вам просто незачто платить денег, даже оскорбительных для нормального спеца 50-60т.р. в месяц.

Точка, пожалуй.

P.S. Сознательно разделил на несколько сообщений. Можете комментировать любое. Вперёд.

Это говорит о том что про С++, его стандарт и «жирный» рантайм тебе Сара по телефону напела.

За семь лет и так «крупненький» стандарт на С++ раздуло на 483 страницы. За 3 года тоненький С раздуло на 144 страницы. 483/7 = 69 и 144/3 = 48 условных страниц в год.

Я ему про рантайм, он мне про стандарт. Понимать написанное можем? А мойша, или слабо? И поэтому 69 станичек в год это уже капец как сложно?

Говорит о том, что собеседник зачем-то – Ну, если задача – получить из С++ голый С, то в принципе можно и ексепшоны убрать

Ути пути, мойша играется в демагога. Если из С++ убрать эксепшоны, то останется еще куча вещей.

Но если пойти по твоему пути и начинать говорить всякую херню, то вот тогда можно утверждать что ни одна прошивка для МК на С не написана, сигналов, то и нетути. А стандарт С их требует. Раздел сам найдеш? Также стандарт требует что б функция printf умела форматировать в том числе и float/double. Cознавайся мойша, не выключаешь поддержку форматирования плавучки? Все ташишь в МК ? Или как, трепло?

Да и денег от Вас я за это не получу. Конечно не получишь, я ж не лошара какой-то, которому можно тупо по ушам ездить.

Ну, коль скоро Вы такой...

бестолковый и неугомонный, давайте я Вас ещё в дерьмецо ткну. Мне не сложно, да и сборка идёт долгая.

Итак.

Я ему про рантайм, он мне про стандарт.

Хмм… Т.е., батенька, Вы в глазоньки изволите долбиться, как я правильно понимаю? =))) Я же Вам по-русски написал:

Если Вы не понимаете что сказанное в стандарте должно поддерживаться в рантайме в более-менее полном объёме, то это уже значит что мне нужно заниматься Вашим пост-ГПТУшным образованием.

Судя по Вашим же цитатам, вроде видели. А выводов не, сделать не смогли?

Вот сейчас под руками аналог уже упомянутого в треде сс1310, правда, сс1352. Там я не могу глянуть, т.к. там просто нет отдельного С++ рантайма.

Давайте глянем на х86_64. Система тщательно и со вкусом оптимизирована по ключам компиляции и линковки. Так что, откосить тут не получится. У нас стандартными runtime libraries будут glibc и libstdc++.

Итак, для начала я напишу два хеловорлда, чтобы максимально точно понять какие либы у нас используются. Не, написать их нужно, т.к. в стандартной либе С++ будут использоваться функции из стандартной С-либы. Проверим так ли это. =)))

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

Итак, С-вариант:

/* gcc 1.c -o 1 */
#include <stdio.h>

int main() {
	printf("%s\n", "Hi, anonymous woodpecker!");
	return 0;
}

C++ вариант:

/* g++ 2.cpp -o 2 */
#include <iostream>

using namespace std;

int main() { 
    cout << "Hi, anonymous woodpecker! =)))" << endl;
    return 0;
}

Теперь смотрим ldd 1:

        linux-vdso.so.1 (0x00007ffff4bc7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f94545e5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f94547d2000)

Далее смотрим ldd 2:

        linux-vdso.so.1 (0x00007ffd633d4000)
	libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libstdc++.so.6 (0x00007f68f7068000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f68f6f2f000)
	libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/libgcc_s.so.1 (0x00007f68f6f14000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f68f6d5a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f68f72b0000)

С какого перепою здесь болтаются вызовы сишного рантайма? Да с такого, что плюсовый рантайм, как я и сказал выше, на нём и основан. И его поэтому использует.

Но мы же хотели на размер рантайма посмотреть? Извольте:

C++:

-rwxr-xr-x 1 root root 2165312 июл 30 14:49 libstdc++.so.6.0.29

C:

-rwxr-xr-x 1 root root 1794208 авг 18 22:39 libc-2.33.so

То есть, даже при условии того, что С++ рантайм использует С-рантайм, один пень размеры плюсового рантайма больше. Какие были бы размеры, если бы плюсовый рантайм жил сам по себе и без сишного, я Вам сразу могу сказать – приплюсуйте к плюсовому сишный и возрадуйтесь. Вот эта разница и есть «цена» Вашего плюсового стандарта. Потому как системные вызовы в Linux можно и на С спокойно сделать, а не как на С++ через анус.

Я могу даже больше сказать – именно из-за размеров сишного рантайма и появились такие альтернативные glibc проекты как newlib, uClibc, musl. Про плюсовый рантайм даже и не говорят, заметьте. Ну, по крайней мере, в трезвом уме и здравой памяти.

На ARM смотреть соотношения будем? =)))

сигналов, то и нетути.

Каких там сигналов нетути, бестолковый Вы мой? =))) Если прошивка написана даже с заменой glibc, то сигналы там будут. Если там использована иная библиотека и ясно сказано что она POSIX-compatible, то сигналы там тоже будут. Вот исходник от TI для сс13*/сс26*. Реализация сигналов в той же TI-RTOS отличается и от Linux-реализации и от FreeRTOS-реализации. Это просто у Вас мозгов нетути чтобы это понять.

Дальше.

Также стандарт требует что б функция printf умела форматировать в том числе и float/double. Cознавайся мойша, не выключаешь поддержку форматирования плавучки?

Скажите, Вы дурак от Бога или Вас таким жизнь сделала? =))) Не, ну серьёзно? А это ни чего что на контроллере считать с плавающей точкой что-либо, это махом быть уволенным? Ну просто потому, что это непроизводительный расход крайне ограниченных вычислительных ресурсов? Да и аппаратной поддержки операций с плавающей запятой в проце может не оказаться и тогда придётся считать всё в soft float. Нормально? Вы вообще в своём уме? =))) Может, Вам санитаров вызвать? Суровых и с галоперидолом?

Как Вас беспокоит наличие math.h, если в стандартной библиотеке реализация функций для работы с плавающей запятой есть и её ни кто никуда не убирал? Просто ею не пользуются. Ну, стараются не пользоваться, если только не дол… (не Вы лично) автор прошивки.

Вот например, поддержка операций с плавающей запятой для musl. Кто её отключает? Зачем? Вы где такой код видели, что у Вас родился такой идиотский вопрос? =)))

Из стандартной либы ничего не убирается. Это не эксепшоны из С++ выкидывать. =)))

P.S. Вы точно имеете какое-то отношение к программированию встраиваемых систем? А то у нас тут уже был один пОциент. Посмешила, да… =)))

Хмм… Т.е., батенька, Вы в глазоньки изволите долбиться, как я правильно понимаю? =))) Я же Вам по-русски написал:

Если Вы не понимаете что сказанное в стандарте должно поддерживаться в рантайме в более-менее полном объёме, то это уже значит что мне нужно заниматься Вашим пост-ГПТУшным образованием.

У тебя, мойшечка, непомерно раздутое ЧСВ. Вот Страуструп говорит, что с++ это язык с «zero cost abstractions» (гули, если непонимаеш). И вот поэтму-то именно что рантайм какраз таки НЕ ДОЛЖЕН поддерживать стандарт в более-менее полном объеме, а как раз таки НАОБОРОТ, в идеале в рантайме вообще ничего не должно быть, что не использует конкретная программа. Поэтому свое ценное мнение про то что кому и сколько должен рантайм засунь себе поглубже в …

А стандарт должен поддерживать компилятор (библиотека стандартная), фирштейн. Можешь своим скудным мозгом осознать разницу между компилятором(тулчейном) и программой (с или без рантайма)?

Вот тебе маленький пример:

//g++ ./main.cpp -o 2

#include <cstdio>

template<int N>
struct LoseCount {
    int moisha_suck_times() {return N*2;}
};

int main()
{
    printf("Hello Loser! Moisha suck %i times. \n", LoseCount<25>().moisha_suck_times());
    return 0;
}

$ ldd ./2
        linux-vdso.so.1 (0x00007fffc5992000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5dc44d0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5dc46b5000)

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

Посему, я делаю вывод, что ты ряды вооруженных сил покинул слишком поздно, и фуражка тебе таки подправила форму извилин.

Мало прочесть книгу.

Надо её ещё и понять. Чего Вы не удосужились сделать.

Показываю:

Вот Страуструп говорит, что с++ это язык с «zero cost abstractions» (гули, если непонимаеш).

Всё что говорит один долб… (ну, Вы поняли), который был слишком туп чтобы вкурить макросы в С и чтобы их типа избежать, он сговнокодил свой недоязычёк для убогих типа Вас, Вы умудрились переврать.

zero cost abstractions это ровно то, что я Вам показал выше. Наличие в стандртной библиотеке функций по работе с плавающей запятой вовсе не говорит о том, что они обязаны быть использованы, если в них нет нужды.

Дословно:

What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.

Т.е., то, что Вы не используете (операции с плавающей запятой в моём примере выше), Вы не должны в коде платить за это. Не будет вызовов, накладных расходов. Однако, вторая часть фразы – для того, что Вы используете, лучше код не написать, как раз объясняет почему в runtime поддерживаются все необходимые сущности языка. Потому что лучше сущностей из стандартной библиотеки в случае их использования, Вы не найдёте.

Так что зачем было изобретать колесо заново, не ясно. С уже есть и делает ровно то же, что Страуструпу пришлось объяснять отдельно. Да, С++овцы частенько тупы неимоверно. Не отнять. =)))

И вот поэтму-то именно что рантайм какраз таки НЕ ДОЛЖЕН поддерживать стандарт в более-менее полном объеме, а как раз таки НАОБОРОТ, в идеале в рантайме вообще ничего не должно быть, что не использует конкретная программа.

То есть, в идеале, две наших программы на С++ должны иметь две разные рантайм библиотеки? Я Вас правильно понял? То есть, Вы настолько тупы, что утверждаете что каждая отдельная программа в моей или любой другой системе должна иметь свою, отдельную от других, рантайм библиотеку? Милейший, Вы ещё тупее чем я даже надеялся! =)))

На практике этого и не было и нет. Попытки кодерасить на чём-то похожем на С++ не в счёт.

перепутал рантайм и стандарт/реализацию стандарта.

Да Ви чьтооо? Теперь к Вашему говнокоду. =)))

Я понимаю почему Вы в «коде» на типа С++ использовали printf(). Тем самым Вы решили малость соптимизнуть и увернуться от созданной специально для Вас, Козлов, стандартной runtime library, т.е., от libstdc++ в нашем случае. Но тут же нарвались на стандартную runtime C library, libc.so.6. Вот про то и речь как раз. Как вы там ни выкручивайтесь, а от стандартной рантаймовской С-либы увернуться ой как не просто. =))) Да и смысла особого нет, с ней удобнее. Если не писать на С++ конечно и не изобретать колесо.

И да, как раз в стандарте прописаны эти самые cin, cout, cerr, которые Вы отказались использовать в своём говнокоде. Во второй ссылке, стр. 1379, параграф 29.4.3 Narrow stream objects и чуть ниже, но Вам это уже не поможет.

По поводу Вашего говнокода. Иногда я понимаю «Царя С++» (Царём С я его не называю, он сишник примерно как Вы С++овец).

Понимаете, за суржик, аналогичный продемонстрированному Вами, на собесах в более-менее серьёзную контору, Вас до дверей будут гнать ссаными тапками. И будут правы. Просто потому, что вот эта вот «разнузданная кодерастия», да ещё и с отключёнными эксепшонами, это признак того, что человек просто дятел новогодний. И он не в состоянии грамотно писать ни на С, ни на С++. Вы думаете что Вы увернулись от libstdc++, сунули вместо cout сишную printf() и молодец? Да нет, у Вас просто говно в коде. На С писать Вы не умеете, стандарт С++ не для Вас, С++овцев писан, вот и приходится выкручиваться. Тут всё понятно.

Я не знаю кто Вам платит денег за такой говнокод, но Вы к херам собачьим были бы уволены сразу, как только Вы бы мне его показали.

Не продолжайте пожалуйста дальше, я уже понял что Вы судак.

Не продолжайте пожалуйста дальше, я уже понял что Вы судак.

Сам такой. Ты это много раз тут демонстрировал.

Каштан.

мойша, ты в очередной раз обосрался, и вот этой вот простыней не прикроешся :) .

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

Ну и твое мнение про Сраутрапа - это показатель. Какая-то срань рязань пытается казаться умнее создателя языка программирования. П-ф-ф.

Кисо обиделось? =)))

Ну утри слёзки, тупенькое… Злой дядя сишник пришёл и нассал в вашу песочницу? Бывает, чё. Жизнь жестока и несправедлива. И не всегда эксепшоны спасают. Особенно, если их ещё и отключить… =)))

Злой дядя сишник пришёл и нассал в вашу песочницу

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

Ой, а что это, он еще и говно свое жрет.

Нет, это уже слишком!

Дадада...

Понятно. По теме сказать нечего, вот и остаётся вопить «ты абасрался!!!11адын-адын». =)))

Ну стойте и вопите, мне-то что? Мне от Страуструпа детей не рожать. А в коде выше уже всё написано и другого не придумать. Инторнет-то всё же помнит… =)))

Впрочем… Про Страуструпа и макросы! Чуть не забыл! Извольте полюбопытствовать

Macros do not obey the C++ scope and type rules. This is often the cause of subtle and not-so-subtle problems. Consequently, C++ provides alternatives that fit better with the rest of C++, such as inline functions, templates, and namespaces.

Но тут есть опять проблема – кто-то в говнокоде выше наотрез отказался использовать namespace std. И кто же это мог быть? Кто у нас тут Страуструпа Родину не любит? =))) Ненене… Я Вас Родину Страуструпа учить любить не буду. =)))

Детонацией пердака удовлетворён. =)))

.

Ты слишком смешон. Хотя представляю, как ты это пишешь, и представляешь себя королем.

Обратись к психологу. Комплексы можно вылечить.

Каштан.

Иэххх... Каштан...

Обратись к психологу. Комплексы можно вылечить.

С++ у психолога не лечится. Это вам, парни, к психиатору. Действительно, в вашем «исполнении» С++ это забавное недоразумение, затянувшееся на годы и изрядно перебаламутевшее индустрию. =)))

Ты слишком смешон.

царь был потешным, а этот - унлое говно, которое даже не может осознать на какой вопрос/аргумент отвечает.

Ну и плюс двойные стандарты, как уж без этого может тупенькое.

Значит когда с С надо влезсть в МК то неиспользование, например, флоатов - это крутое мастерство сишника. А когда я ему показываю подобный трюк с С++ оно ноет что это «не по правилам».

Короче, унылое, закомплексованное чмо.

затянувшееся на годы и изрядно перебаламутевшее индустрию. =)))

опять рязанская рвань рассуждает про индустрию и «приличные» фирмы.

Откуда тебе знать что-то про индустрию и приличные фирмы?

Вам не понять. Я и не надеюсь. =)))

Зато мне известно про ООП вообще ровно то, что о данной парадигме говорил некий Степанов Александр Александрович, по совместительству создатель STL, упомянутой так не кстати в данном треде:

«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать чёткие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

Я же вам убогим написал – хотя бы Седжвика потрудитесь прочесть, если упоротый в хлам препод вам про него ничего не говорил. Там про алгоритмы. Точно. Я сам читал. =)))

И я могу только присоединиться к словам Пол Грэм, утверждал, что половина всех концепций ООП являются скорее плохими, чем хорошими, в связи с чем он искренне сочувствует ООП-программистам. Тогда как вторая половина от оставшихся концепций — и вовсе не имеет никакого отношения к ООП, с которыми их почему-то постоянно ассоциируют

Мде… Не один я как выясняется уверен что ООП и, как следствие, С++ в рамках данного треда полное говно вызывает сочувствие. Да ещё и с таким «исполнением» как у вас… =)))

Там длинная статья, можно просто на цитаты растащить, ага. =)))

Зато мне известно про ООП вообще ровно то, что о данной парадигме говорил некий Степанов Александр Александрович, по совместительству

О, Степанов, это тот умный мужик который придумал шаблоны ? Те шаблоны которые я продемонстрировал тебе в своем маленьком примере? А как же так мойша то выходит? Тут значит ценим мнение Степанова, а тут уже не ценим? А? раздвоение?

А может тебе Дейкстру процитировать про goto? Или сам найдеш?

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

Читал Algorithms in C++, Parts 1-4: Fundamentals, Data Structure, Sorting, Searching. Отличная книга, рекомендую.

Мде… Не один я как выясняется уверен что ООП и, как следствие, С++

А вот разработчики gcc и clang/llvm уверены в С++. Поэтому повторюсь, мнение тупого ЧСВешника никому не интересно.

Еще раз убедилась, что российская армия оказывает неизгладимое влияние на кору головного мозга.

Да где Вы и где С++? =)))

Вы мечетесь мелким бесом.

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

То Вы вместо стандартных namespace std и плавно вытекающего из него того же cout втюхиваете printf() чтобы не нарываться на свою же, С++-стандартную библиотеку и тут же вляпываетесь в сишную стандартную либу, не понимая что если уже есть сишная, то на фиг тогда нужна жирная плюсовая. Смысл изобретения этого колеса так и не ясен.

То Вы апеллируете к Святому Мнению Старуструпа насчёт «zero cost abstractions» и когда Вам объясняют что Страуструп дятел и до него уже всё было и работало, Вы оскорбляетесь – Какжи! Самжи! Старуструпжи!. Да он такой же дятел как и Вы, приходится констатировать. Только он пишущий, а Вы – пытающийся читать. Вы вообще зачем книги читаете, если органически не усваиваете там написанное?

То Вам говорят что сам создатель STL как-то не в восторге от ООП, но Вы этого типа «не поняли» и делаете вид что Вы там какие-то шиблоны жи использовали… =)))

У Вас в итоге получается я знаю что. Я бы это назвал «напёрсточное программирование». Кручу-верчу, чёта вымутить хочу. Вместо написания качественного кода, поддерживающего строгие реализации согласно стандартов (утверждённых именно комитетами по станадртизации языков, а не придуманных Вами только что и на ходу) Вы на ровном месте выкруживаете себе проблем. Показанный Вами суржик это вообще говнокод, а не С++. Даже близко. Нет там у Вас С++. С, кстати, тоже нет, но это не для средних умов – на С писать.

В общем, да. Чё только люди не придумают чтобы на С не писать. Просто 146%.

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

мойша в 13:37

zero cost abstractions это ровно то, что я Вам показал выше. Наличие в стандртной библиотеке функций по работе с плавающей запятой вовсе не говорит о том, что они обязаны быть использованы, если в них нет нужды.

мойша в 11:27

Вот когда ты пиз…ш ? а мойша?

То Вы вместо стандартных namespace std и плавно вытекающего из него того же cout втюхиваете printf()

А тут мойша нам показывает свою очередную тупость. мойша! printf - это и часть стандарта С++. Или шо, для танкиста слишкам много букав? не дочитал?

Запретная любовь к «крестам» в embedded лечится тяжким трудом, покаянием и молитвой. Надо просто поставить человека перед фактом - вот те, мил чек, SDK c тулчейном, кодом и либами стандартной либы и стартапа, примером хелловорлда, описанием регистров контроллеров SoC. Где не будет экцепшенов, STL и т.п. Топящие за C++ просто не работали в этом поле и не прочувствовали специфику. Брать их и учить или ну его нафиг?

Был у нас Epson s1c3305 (для принтеров, наверное, сделанный, начальство нахватило по случаю). В либе не было даже работы с heap-ом, всяких malloc, calloc, free. Только статические блоки памяти, адреса которых генерились и прописывались define-ми. Но в стартапе вызывалась __init_heap, если указатель на нее не NULL. Пришлось самому писать работу с heap-ом. Где был бы плюсовый new без malloc-а, чтоб развести бодягу с объектами в хипе?

Та же песня и с Windows WDM драйверами ядра, UEFI, Linux. Нету там хипа, есть пулы памяти и свои функции для выделения блоков там. Любитель крестов может для начала написать свои врапперы для malloc и т.п. Нет ни одной функции стандартных либ в UEFI, это голый код с точкой входа DriverEntry, никаких экспортов и импортов DLL. Что сам написал, то и жри, а писать такое проще и понятнее на C.

Никакой обработки structured exception-ов. Если обычное приложение системы на try регистрирует обработчик catch и система присылает exception на обработку, то в embedded таких механизмов просто нет. Для WDM исключение= BSOD, для UEFI=зависание.

А разработчики ядра Linux дураки? Зачем, например, на C++ городить базовый класс «драйвер», наследовать от него свой драйвер со своими функциями-обработчиками, чтобы компилятор создал таблицу вирт. функций. Можно в C в несколько строк инициализировать структуру драйвера указателями на свои функции. Гораздо проще и короче.

Надо просто поставить человека перед фактом - вот те, мил чек, SDK c тулчейном, кодом и либами стандартной либы и стартапа, примером хелловорлда, описанием регистров контроллеров SoC. Где не будет экцепшенов, STL и т.п. Топящие за C++ просто не работали в этом поле и не прочувствовали специфику.

Еще один ЧСВ-шник, который думает что прочитать даташит на атмегу8 это что-то запредельное для человека овоившего стандарт С++.

Если ты не так туп как мойша, то пойми простую вещь: в С++ можно точто также байтоё-ть как и в С, а если нет маллока (который тоже часть стандарта С++), то либо не пользовать его ваще. Работать на статическивыделенной памяти и плейсмент new. Либо так же как и на С сделать себе этот маллок (но пять же, по надоности).

А разработчики ядра Linux дураки?

А разработчики gcc дураки?

А пройдет лет 5-ь и в ядре появиться раст вообще. что тогда запоете?

Ну дык!

Запретная любовь к «крестам» в embedded лечится тяжким трудом, покаянием и молитвой.

В граните! =))) Кто б спорил-то… =))) Но тут, сдаётся мне в диспуте выше, ещё и определённый… особый такой… колорит примешивается. И он ни как не связан с С++, а с таким… особым отношением к жизни.

Нет ни одной функции стандартных либ в UEFI, это голый код с точкой входа DriverEntry, никаких экспортов и импортов DLL. Что сам написал, то и жри, а писать такое проще и понятнее на C.

В предшествующих UEFI стадиях (SEC, PEI, DXE) их тоже нет. Впрочем, UEFI runtime (да чтож такое-то, опять runtime) начинается в самом конце DXE, потом уже BDS идёт. Но и там плюсов нет, да…

А разработчики ядра Linux дураки?

Тсссс… Коллега! Тут где-то апологеты Страуструпа и прочих разработчиков clang/llvm бродят. Не говорите этого при них, я Вас умоляю… =)))

С Вашими аналитическими спсобностями...

А разработчики gcc дураки?

И что с ними не так? Они бросили пилить gcc?!? Когда??? Почему новости на главной не висит?!?

Ччёрт, у меня аж глаз задёргался!

А пройдет лет 5-ь и в ядре появиться раст вообще. что тогда запоете?

Я Вас умоляю! Я бы не рисковал предсказывать результат умножения 2х2… Вы крайне сильно рискуете! Поверьте моему опыту! =)))

Топящие за C++ просто не работали в этом поле и не прочувствовали специфику. Брать их и учить или ну его нафиг?

топим и работали. ничего страшного в крестах на эмбеде нет. я принимал участие в трех больших проектах(в пике порядка 30-40 разрабов), где все было на голом железе, написано на плюсах и работало как часы. как пустить плюсовый код на голом железе - в инете наверняка полно статей, поскольку тема эта давно рутинная. более того, писать такие проекты на си было б суровой ошибкой.

естественно везде эксепшены не использовались, rtti тоже, они в эмбеде не нужны.

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

и вы будете писать на плюсах, хоть с множественным наследованием.

каким образом на си работать со строками например? чтобы написать типа

string ls = «ssss» + some_other string + «hhhh»

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

Тсссс… Коллега! Тут где-то апологеты Страуструпа и прочих разработчиков clang/llvm бродят.

Ой, опять мойша пишет что хочет. А че разрабов gcc забыл? Так удобней прибрехивать?

Не торопитесь Вы так.

Тут не чат. Выше я задал вопрос про gcc.

printf - это и часть стандарта С++. 

Дано: МК без экрана.

Какой printf, cout? Вместо него в либу могут воткнуть stub c чистой совестью, чтоб у вас только собиралось. Вы сначала запилите этот printf, чтоб куда-нибудь в UART строчил, притащите сами код _vsprintf или как его из другой системы. А потом пользуйтесь на здоровье.

А разработчики ядра Linux дураки?

А разработчики gcc дураки?

И что с ними не так? Они бросили пилить gcc?!? Когда???

мойша, они его на С++ перевели. для сборки надо С++11 компилер. С они бросили. Или тебе прям все надо разжовывать?

Стоп.

каким образом на си работать со строками например? чтобы написать типа

Три вопроса, если позволите:

1. Есть ли в С строки?

2. Является ли «работа со строками» определяющей для эмбеддинга? Если нет, то почему?

Я задал не тот вопрос.

мойша, они его на С++ перевели. для сборки надо С++11 компилер. С они бросили.

Я задал вопрос – бросили ли разрабы gcc пилить С? Ненадо ничего придумывать. Итак, бросили они пилить С или нет? Волнуюсь. Жду ответа.

Есть ли в С строки? Является ли «работа со строками» определяющей для эмбеддинга? Если нет, то почему?

эмбединг на сегодня, при существующей моще процов, понятие расплычатое. смартфон - тоже эмбединг. что помещается в карман - то и эмбединг. какую схему нарисовали электронщики - то и эмбединг.

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

в си есть строковые константы. и указатели на char. а также понятие си строки. и набор примитивов ля сравнения строк, конкатенации и все такое.

каким образом на си работать со строками например

я за время работы на си понял, что конечный размер строки (на самом деле массива char) надо знать заранее или ты что-то делаешь не так

Спалили. =)))

А зря.

Не. Вот не соглашусь.

Про мобилы совсем не соглашусь. И с Nokia N900 работал и сейчас Sailfish OS именно что в кармане. В Seilfish/Aurora там вообще голый Linux с очень тоненькой прослойкой в виде Qt. Поищите, я писал на форуме.

Про ведроид даже молчу. Там ART/Dalvik это тоже прослойки, но слегка потолще, чем в Sailfish для Qt. А ядро так вообще собирается как линуксовое. И сырцы там тоже линуксовые, с некоторыми изменениями в части модулей ядра.

Так что, нет. Контроллеры сейчас это именно что контроллеры.

Дано: МК без экрана. Какой printf, cout? Вместо него в либу могут воткнуть stub c чистой совестью, чтоб у вас только собиралось. Вы сначала запилите этот printf, чтоб куда-нибудь в UART строчил, притащите сами код _vsprintf или как его из другой системы. А потом пользуйтесь на здоровье.

От чебурашка, а еще эмбеддером зовешся. Всего-то надо свою реализацию int _write (int fd, char *ptr, int len) слепить, что б плевалась байтиками в UART.