С удовольствием, кстати, посмотрю на задачу, где только Си не обойтись, а есть реальная необходимость в применении C++ 11/14/20...
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
С удовольствием, кстати, посмотрю на задачу, где только Си не обойтись, а есть реальная необходимость в применении C++ 11/14/20...
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
Интересный проект. Но автору такое скорей всего не подойдет.
Судя по коду, этот CMakeRC задействует пол стандартной библиотеки.
Что конечно удобно, но просто не влезет в AVR.
C и libc отличная вещь, но для контроллеров без нормального MMU очень опасна, из-за фрагментации памяти.
Все будет опасным если если не разбираться и не понимать что проиходит, и не только в контексте программирования МК.
А по теме — С++ однозначно удобней и безопасней С в любых контекстах.
Во первых STL это не только контейнеры но и алгоритмы.
Во вторых уже давно есть std::array — контейнер без аллокации. И недавно добавили std::span, который на понядок удобней всяких (void*, size_t size).
Ну и как вишенка — все контейнеры, которые аллоцируют память, делают это через аллокатор. И вы вполне можете написать себе такой какой надо.
Дельфи на 20-м месте.
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
Стандартные библиотеки любого ЯП, реализованные в полном обьеме, будут отьедать непростительно много для большинства МК. И раста это тоже касается.
Судя по коду, этот CMakeRC задействует пол стандартной библиотеки.
Что конечно удобно, но просто не влезет в AVR.
Все будет опасным если если не разбираться и не понимать что проиходит, и не только в контексте программирования МК.
А по теме — С++ однозначно удобней и безопасней С в любых контекстах.
Во первых STL это не только контейнеры но и алгоритмы.
Во вторых уже давно есть std::array — контейнер без аллокации. И недавно добавили std::span, который на понядок удобней всяких (void*, size_t size).
Ну и как вишенка — все контейнеры, которые аллоцируют память, делают это через аллокатор. И вы вполне можете написать себе такой какой надо.