С вами всегда приятно поспорить, так что с вами и поспорю в единственный выходной на этой неделе. :)
правильно, что не используете exception — офигенный оверхед, недопустимо использовать для SIL и вообще можно обойтись из них, преимущества их использования для встроенного ПО вообще мне непонятны
Несмотря на бесспорность утверждения, я как-то в разговоре с одним коллегой пришел к обратному выводу. Представьте себе, что при вычислениях, при каком-нибудь банальном сложении, что-то пошло не так и (если вам повезло и у вас локстепнутое ядро) вывалилось исключение процессора. Вы можете внутри него просто передать управление на резервный комплект, а тут уйти в перезагрузку и ресинхронизацию. А можете в его коде применить разнообразную эвристику (типа пройтись по стеку например) и вернуться обратно в кодец и например заново пройти данный цикл вычислений, пересинхронизировавшись с другим комплектом без перезагрузки (соответственно коэффициент готовности растет). А если его нет, или если потеря точности в один цикл несущественна (например вы там сидите и интегрируете дифур) — так и пойти дальше. И вот когда есть исключения и код обернут верно, то вы получите инфу об этом в нужном месте основного кода, без сложных способов возврата из обработчика, дропнете этот цикл и все.
Недопустимость оных для SIL sensitive приложений вообще веселая штука. Вот есть в Аде обработчики исключительных ситуаций процедур, по сути те же самые, но их не только можно, а нужно использовать…
Смысл использовать вектор вообще не понятен
Положим вам нужен массив переменной длины с постоянным размером в памяти. Для std::array потребуется отдельная переменная длины, а range based for вообще не взлетит. Вот отсюда и рождается вектор на некоем заранее заданном хранилище.
Тоже самое, что и с вектором — стреляем из пушки по воробьям
А почему? И это, разве есть способ никогда-никогда не использовать shared_ptr?
Автодополнения может не быть, либо такое, чтобы его лучше не было. Занятно, но почему-то интеллисенс студийный — какой-то оверхайтек, так сложно его повторить, просто не для средних умов…
На самом деле ваше сравнение неудачное имхо, принципиальных отличий нет, вызываете ли вы foo(*bar, baz...) или bar.foo(baz...). Как по мне, кратно более крутое отличие, понятное широкой аудитории — наличие неймспейсов в плюсах.
Как раз чтобы бороться с выходом за границы массива.
Да я их прекрасно понимаю, че уж. С по крайней мере можно целиком в голове удержать, а С++ уже кажется нельзя
Да-да-да… Там вон ниже гражданин возмущается, но я воздержусь от ответа, так как в общих чертах его уже знаю — «вам надо было написать программу совершенно иначе, и тогда не было бы проблем». Этим плюсы и «прекрасны» для любого человека на планете, кроме, вероятно, khim-а, что как бы вы ни написали ваш код на плюсах, где-то в последнем стандарте есть способ написать его более правильно.
Вот очередной пример гребаного трэша, если честно. То есть эмбеддер должен пойтить и почитать про их переопределение, а судя по статьям на Хабре сие есть тема непростая, если глубоко копать.
Кто-нибудь сейчас читает и думает — ага, норм, шаблоны, классы, операторы можно переопределять, просто мякотка. Только сперва надо язык обрезать садовыми ножницами, которых притом нет… Ой, да ну его…
Парсер не особо, но просто какую-то логику «событийную» типа «послать такой запрос — подождать ответ (или таймаут) — послать следующий — подождать» — иногда очень хочется.
Да, тут бы асинк, но и на потоках можно.
На мой взгляд, оно растет чаще просто от незнания; многие думают, что в С++ память как-то «сама по себе тратится» и не пытаются вникать дальше, просто сходу отметают.
Людей можно понять, в плюсах и функции «сами собой вызываются». Причем ведь накалываешься на мелочах — упустил буквально один символ при наборе, и если бы у тебя не был удален конструктор копирования, то ты бы не увидел ошибку, и возможно нескоро узнал бы, что делаешь что-то не то.
Я лично регулярно за границы вылезал, прям фобия развилась. Особенно учитывая, что никаких санитайзеров-то нема, можно ведь вылезти и не заметить вообще.
Хм, а я ни разу. А что с санитайзерами кстати, почему нет?
Можно и потоки, лишь бы не городить полотнища свитчей для конечных автоматов
А вы про какую ситуацию? Просто какой-нибудь парсер со сложным автоматом на кучу потоков не заменишь. Или вы про другое?
В embedded — скорее наоборот, насколько я могу судить; многие придерживаются мнения, что С++ в принципе — это недопустимо.
Да, и оно ведь во многом растет от библиотеки шаблонов. Так что тут так — и этим своим не станешь, и эти врагами объявятся)))
Но в std есть куча полезных вещей, которые с контейнерами не связаны — скажем, std:nth_element или std::atomic; контейнеры в отдельный неймспейс не выделили.
Про std:nth_element даже не знал, спасибо, неплохая вещь для поиска медиан.
Атомики жалко, да.
Меня лично спан (как и все остальные контейнеры STL) огорчает в основном тем, что он не проверяет выход за границы в операторе [] — а легко везде заменить [] на at — не особо получается.
Требования совместимости. Впрочем, выход за границы массива — вещь нечастая. А при наличии foreach… Который еще и оптимизируется лучше.
Но спан все равно лучше, чем отдельно указатель и размер
Имхо норм указатель и размер, я даже в шарпе этого не стесняюсь при работе со строками (иначе получается нечитаемая хтонь), просто дело же не только в этом, спан типа вообще лучше.
Вы Аду не пробовали? Тут параллельно идет обсуждение. Там все есть, и все красиво. :)
больше не хватает асинхронщины какой-нибудь, но она на плюсах пока что выглядит довольно мерзко в любом случае
Ммм, вы находите? Вроде норм… Но вообще, как по мне — уж лучше в потоки, я к асинхронщине в принципе отношусь с сомнением.
Я как-то без контейнеров стандартных и исключений вполне себе обхожусь
Да, но не использовать контейнеры — это же почти идиоматическое преступление, могут и к высшей мере приговорить в интернетах!!!111
Впрочем это может быть интересной концепцией — запретить вообще пространство имен STL. Только сишные либы (выпилив и из них динамику) и сам стандарт языка. То есть все эти вот извращения вокруг STL это примерно как мамкино веганство («курицы глупые, их можно есть»), а вот такой подход — чистое, настоящее веганство.
Правда велосипеды вместо std::function и std::span таки изобрелись
М, да, кстати, спан бывает полезен, впрочем я и к нему с сомнением отношусь.
Ну, обычно что-то в духе -fno-exceptions -fno-rtti и еще какой-нибудь финт, чтобы динамику отключить
А, ну вы про РТТИ еще вспомнили, точно. Главное же кучу задать нулевой!
Все верно. Особенно от ООП (а именно от инкапсуляции и конструкторов/деструкторов) пищать хочется. Но если отключаешь динамику, то начинается адище — либо как в статье, либо ETL (который имхо в обозримом будущем подавится и упадет под диван), в общем широкий набор способов создать новый язык. Это плохо само по себе, к тому же туго ложится на индустрию.
Признаться, я не понял, к чему вы клоните, я просто исхожу из того, что на шарпе писать хорошо, очень хорошо. Если вам нравится на Дельфи — не проблема. Но уж точно вряд ли есть достаточный объем платформы для Ады под ПиСи.
Теперь вы в списке людей, которых я ненавижу. Вы лично, и все упомянутые в статье коллеги. Мало того, что вы там все пипец умные и пишете полетные контроллеры (а я занимаюсь непонятно чем и пятый год только мечтаю этим заняться), так еще и делаете это на Аде! Я недавно с крайним удивлением на Адакоре увидел чудесные разделы (клянусь, что джва года назад их не было) и запоем прочитал записки «как с С/С++ перейти на Аду». Отметил впрочем, что на плюсах все то же самое (и даже больше) можно сделать даже проще (но не очень), а еще чот кода готового маловато на Аде, и вербозно как-то (хотя я любитель длинных имен), и задрачивать новый язык все же придется сильно, и вообще слезы_боль_я_никто, в общем прочитал — и ничего на Аде писать не стал, даже никакой крохотной фитюлечки.
Тут еще xrEon понимаете ли накинул, оказывается проектов на Аде больше, чем три с половиной! ЧСХ писать на Аде под писюк наверное станет только псих (когда есть элитный шарп), а вот в эмбеде оно и правда хорошо.
К слову, раз тут знатоки собрались, переспрошу кое-что, что я не понял — есть аспект, с помощью которого можно задать минимальный размер типа в битах, но как задать точный размер?
Ну, знаете, про тестирование всяких условий это уже мы тут придумали от нечего делать. Исходно постановка была проще и скорее была на знание базовой геометрии (видимо совсем базовой).
Ну, все же здесь нет универсального способа, говорю по опыту с обеих сторон (больше из найма правда). Если поток большой, встречи короткие, то «да/нет» может быть достаточно. Но если ищут целевым поиском людей, особенных по какому-то признаку, общаются несколько раз (суммарные затраты идут на часы), обсуждают уже разные company-related штуки, а потом кто-то из участников процесса просто исчезает или обходится «вы нам не подходите / я к вам не приду», то это однозначно в ЧС.
Несмотря на бесспорность утверждения, я как-то в разговоре с одним коллегой пришел к обратному выводу. Представьте себе, что при вычислениях, при каком-нибудь банальном сложении, что-то пошло не так и (если вам повезло и у вас локстепнутое ядро) вывалилось исключение процессора. Вы можете внутри него просто передать управление на резервный комплект, а тут уйти в перезагрузку и ресинхронизацию. А можете в его коде применить разнообразную эвристику (типа пройтись по стеку например) и вернуться обратно в кодец и например заново пройти данный цикл вычислений, пересинхронизировавшись с другим комплектом без перезагрузки (соответственно коэффициент готовности растет). А если его нет, или если потеря точности в один цикл несущественна (например вы там сидите и интегрируете дифур) — так и пойти дальше. И вот когда есть исключения и код обернут верно, то вы получите инфу об этом в нужном месте основного кода, без сложных способов возврата из обработчика, дропнете этот цикл и все.
Недопустимость оных для SIL sensitive приложений вообще веселая штука. Вот есть в Аде обработчики исключительных ситуаций процедур, по сути те же самые, но их не только можно, а нужно использовать…
Положим вам нужен массив переменной длины с постоянным размером в памяти. Для std::array потребуется отдельная переменная длины, а range based for вообще не взлетит. Вот отсюда и рождается вектор на некоем заранее заданном хранилище.
А почему? И это, разве есть способ никогда-никогда не использовать shared_ptr?
На самом деле ваше сравнение неудачное имхо, принципиальных отличий нет, вызываете ли вы foo(*bar, baz...) или bar.foo(baz...). Как по мне, кратно более крутое отличие, понятное широкой аудитории — наличие неймспейсов в плюсах.
gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
github.com/google/sanitizers/wiki/AddressSanitizer
Как раз чтобы бороться с выходом за границы массива.
Да-да-да… Там вон ниже гражданин возмущается, но я воздержусь от ответа, так как в общих чертах его уже знаю — «вам надо было написать программу совершенно иначе, и тогда не было бы проблем». Этим плюсы и «прекрасны» для любого человека на планете, кроме, вероятно, khim-а, что как бы вы ни написали ваш код на плюсах, где-то в последнем стандарте есть способ написать его более правильно.
Кто-нибудь сейчас читает и думает — ага, норм, шаблоны, классы, операторы можно переопределять, просто мякотка. Только сперва надо язык обрезать садовыми ножницами, которых притом нет… Ой, да ну его…
Да, тут бы асинк, но и на потоках можно.
Людей можно понять, в плюсах и функции «сами собой вызываются». Причем ведь накалываешься на мелочах — упустил буквально один символ при наборе, и если бы у тебя не был удален конструктор копирования, то ты бы не увидел ошибку, и возможно нескоро узнал бы, что делаешь что-то не то.
Хм, а я ни разу. А что с санитайзерами кстати, почему нет?
А вы про какую ситуацию? Просто какой-нибудь парсер со сложным автоматом на кучу потоков не заменишь. Или вы про другое?
Да, и оно ведь во многом растет от библиотеки шаблонов. Так что тут так — и этим своим не станешь, и эти врагами объявятся)))
Про std:nth_element даже не знал, спасибо, неплохая вещь для поиска медиан.
Атомики жалко, да.
Требования совместимости. Впрочем, выход за границы массива — вещь нечастая. А при наличии foreach… Который еще и оптимизируется лучше.
Имхо норм указатель и размер, я даже в шарпе этого не стесняюсь при работе со строками (иначе получается нечитаемая хтонь), просто дело же не только в этом, спан типа вообще лучше.
Вы Аду не пробовали? Тут параллельно идет обсуждение. Там все есть, и все красиво. :)
Ммм, вы находите? Вроде норм… Но вообще, как по мне — уж лучше в потоки, я к асинхронщине в принципе отношусь с сомнением.
Да, но не использовать контейнеры — это же почти идиоматическое преступление, могут и к высшей мере приговорить в интернетах!!!111
Впрочем это может быть интересной концепцией — запретить вообще пространство имен STL. Только сишные либы (выпилив и из них динамику) и сам стандарт языка. То есть все эти вот извращения вокруг STL это примерно как мамкино веганство («курицы глупые, их можно есть»), а вот такой подход — чистое, настоящее веганство.
М, да, кстати, спан бывает полезен, впрочем я и к нему с сомнением отношусь.
А, ну вы про РТТИ еще вспомнили, точно. Главное же кучу задать нулевой!
Кстати, почему тремя?
Тут еще xrEon понимаете ли накинул, оказывается проектов на Аде больше, чем три с половиной! ЧСХ писать на Аде под писюк наверное станет только псих (когда есть элитный шарп), а вот в эмбеде оно и правда хорошо.
К слову, раз тут знатоки собрались, переспрошу кое-что, что я не понял — есть аспект, с помощью которого можно задать минимальный размер типа в битах, но как задать точный размер?
Не тот язык на проекте, изи.
Наверное предполагалось, что тестер должен написать шаблонную функцию проверки, а потом бомбить ее комплексными числами, на то он и тестер)))