Если вы считаете, что std::array существует ради проверок границ
Мы только что говорили о мире пони и мармелада волшебного программирования, в котором используется только то, что нужно, и ничего лишнего. Если я решил заменить С-массив, то очевидно от std::array мне нужно только size (и то не всегда) и at(). Иначе смысл теряется совершенно.
Так, стоп, вы то ли не читали меня, то ли не поняли. Очевидно же, что если я веду разговор о сравнении С-массивов и std::array, то я ни в коей мере не говорю о возможностях использования последнего в качестве стандартного контейнера, потому что С-массив в таком качестве использован быть не может, а значит сравнение не имеет смысла. Речь идет о ситуации, когда мне просто нужен массив, который ни в какие функции стандартной библиотеки я передавать не собираюсь (потому что если бы собирался, то выбор был бы сделан сам собой).
Лично я не вижу никаких причин не использовать новые фичи, а про закостенелость команды разработчиков постараюсь узнать на собеседовании и сделать выводы о том, принимать оффер или нет
Вот это как раз и есть один из вариантов ответа на заданный мной вопрос, спасибо. Дальше можно не продолжать.
Вас же устраивает, что врачи вынуждены постоянно повышать свою квалификацию, осваивать новые лечебные методики, новые лекарства и т.д. Почему с программированием должно быть наоборот?
Интересное дело, а где я утверждал обратное? Даже в мраморном мире Си есть движение. Я говорил лишь о том, чтобы, обращаясь к вашей аналогии, не заниматься постоянными экспериментами на пациентах.
Тем более что, если уж мы философствуем, то как-то ни разу не очевидно, что развитие специалиста состоит именно в изучении фич языка, а не в изучении новых сущностей предметной области. Хотя конечно как обычно нужно все и сразу, ага.
Через operator[]() в релизной сборке — нет
Гм, а зачем он мне, если я использую array? Или наоборот — если я не использую at(), то на кой черт мне array?
Прочитайте и пользуйте. Только не копируя к себе их бездумно, а взяв оттуда всё, что, как вам кажется, вам подходит.
Уже читал. Но в целом занятно вы пишете — вот вам гайд, но вы его прямо так не берите… Редкая по мощи определенность.
А вы предлагаете выбрать структуру данных не сказав ни какие у вас ограничения, ни для чего она вам нужна… кто ж, при таких условиях, вам скажет?
Я и написал выше, что в открытом вот прямо сейчас на экране проекте нет нужды в векторах. А вот был проект, где были (по причинам, сходным с указанными у вас) самописные связные списки, и ни одного аргумента что-то в этом менять. Понимаете теперь?
Почему такое многообразие средств решения повседневных задач не вызывает сожалений, а наличие разных возможностей в ЯП вызывает?
Потому как с упомянутой посылкой документа во-первых все на самом деле просто, а во-вторых пока для вас это факультативное занятие — ну и фиг с ним, как-нибудь пошлем. Программирование же в том или ином виде является для нас профессиональной областью деятельности, которая должна отвечать требованиям максимальной эффективности. Поэтому нужно и не писать уж на С89, но и не посвящать жизнь постоянному следованию новинкам выбранного ЯП.
Под «почти» что подразумевается?
Мммм, а проверка границ для переменного индекса разве не создает накладных?
Если речь про новый код на C++11 или новее, то тут уместнее обратный вопрос: каковы причины использовать C-шный вектор вместо std::array?
Вопрос справедливый, но ведь… Ведь использование С-массивов не запрещено… Вопрос же в этом — как выбрать между "все новые фичи — в будущий релиз!" и "используем по необходимости"? Если необходимость эту никто толком не может обосновать.
Собственно, почему остановились именно на vector? Подобные соображения относятся и к любому другому контейнеру, как из stdlib, так и из сторонних библиотек.
На самом деле это std::array я зазря помянул, поскольку его поведение почти очевидно, и нет никаких причин его не использовать (ведь и накладных почти нет), а вот вектор весьма непрост, и должны быть веские основания его заюзать. Комментатор выше считает, что выбор контейнеров — целое искусство, и совершенно непонятно, что же делать, если лично вы не видите вообще ни одной причины использовать вектор (а все вокруг используют!). А фичи все добавляются…
Пожалуй дискуссию стоит завершить ввиду ее полного перехода в философскую плоскость.
А если вы пишите код и/или делаете рефакторинг — ну вот тогда и нужно вспомнить Мейрса и подумать — а нельзя ли тут написать проще, используя возможности C++
Естественно вопрос именно об этой ситуации, когда планируется вообще новый проект (небольшой) и обсуждается спектр решений: С99 (как было), С++03 (если вдруг придется переносить в продуктовый контент), либо взять и забабахать С++14 например.
это вообще не наука, а искусство, если бы на него можно было в двух абзацах ответить, то не получали бы программисты вдвое-втрое больше, чем токари и сварщики
Немного странная фраза, ибо теория резания например развита совершенно недостаточно для того, чтобы исключить понятие «хороший, опытный токарь», то есть как раз токарное дело — вполне себе искусство. А вот со структурами данных как раз таки обязана быть внятная система аргументов, наподобие упомянутой следующим комментатором.
ы можете использовать constexpr-переменные и if constexpr чтобы гарантировать, что какие-то вещи вычислятся при сборке прошивки, а не будут повторно вычисляться 100500 раз
А оно мне надо? Ну, серьезно, не стоит так уж рассуждать об эмбеде, будто там все те же 128 байт ОЗУ и 1к ПЗУ, и это повсюду. Ничего, я потерплю лишние вычисления… Впрочем разумеется вы правы, это вещь полезная, но как пример акцептации — так себе.
Да ну нет, я-то естественно не собираюсь гнаться за новыми фичами, это для вас должно быть уже немного очевидно. Вопрос был о том, приемлемо ли не гнаться, и где проходит тот водораздел между можно и необходимо. Простейший пример — как понять, когда std::array вместо С-массива уже нужен, а когда еще нет? Если ответ на это для вас окажется простым, то вот посложнее — как понять, что вам реально нужен std::vector, а не что угодно другое вместо него? Понятно, что в обоих случаях мы говорим о ситуации отсутствия внешних ограничений, выбирать можно что угодно, мне просто интересно, что вы об этом думаете.
Я это спрашиваю потому, что фраза «и вы удивитесь как быстро даже самые новые вещи, вдруг, окажутся востребованными» кажется мне небесспорной. Классический пример — был какой-то локальный велосипед для решения какой-то задачи, потом внезапно стало можно убрать/изменить велосипед за счет решения, примененного в новом стандарте. Но… зачем? Старый велосипед отлажен и впилен во все мыслимые библиотеки. Проблема перехода на новые фичи ничуть не проще, чем проблема перехода на новые архитектуры.
А они просты: включаем -std=c++17 в сборке, но запрещаем все фичи в Style Guide. Потом добавляем потихоньку те, которые полезнее всего
Отлично, привожу пример — понадобились только std::array (и то я хз, какова будет его ценность при отключенных прерываниях, разве что совсем уж глупые ошибки в компилтайме ловить), неймспейсы и классы (просто классы, любим инкапсуляцию и синтаксический сахар в виде конструкторов). Ииии… и что, это «modern C++»?
Да, я про макроячейки, но не про технологическую разницу, а про SRAM-based FPGA (то есть примерно все коммерческие СБИС, исключая CPLD-мелочь и космические антифузы). Там самые натуральные ячейки памяти, которые собственно и конфигурируют макроячейки. И если в ячейку памяти что-то этакое попадет… Уж явно в этой ситуации у ПЛИС нет никакого преимущества перед такой же ячейкой памяти в микроконтроллере.
А вот это как раз — очень плохая идея. Вещи, добавляемые в стандарт не из пальца высасываются.
А теперь представьте, что полезность этих вещей в конкретном проекте вообще никак не обоснована, зато ограниченную команду закостенелых разработчиков может попросту порвать от необходимости читать очередные вирши комитета. Вы же поняли, что я не просто так спрашиваю, а из серии show your practices.
Собственно и упоминание C++03 не просто так — это база для MISRA C++2008. Это пока не выступает ограничителем в нашем частном случае, но может.
Используя C вы получаете всё недостатки ограниченной выразительности Ada/Rust и не получаете гибкости C++ — зачем себя так мучить?
Вообще говоря все процитированное очень спорно, но это и неважно. Я не предлагаю отказываться от С++ в пользу С, вопрос был только о том, чтобы ограничить себя каким-то устаревшим стандартом.
Представьте себе, что это неважно — зачем и почему. Просто есть, положим, такая идея — ограничить себя НЕиспользованием каких-то новых фич. возможно это ограничение придумано даже не нами, но существует.
Недаром сейчас даже в embedded всё больше C++ и всё меньше C
По этому поводу еще раз спрошу, а то вы в прошлый раз не ответили — что вы думаете о том, чтобы в 2019 году писать на С++ 03 (то бишь 98), ну или, если более широко, вообще о концепции ограниченного использования С++ в эмбеде? Это просто вопрос, без намеков и подвоха.
Иногда, бывает нужна надежность. Чтобы контроллер не завис, не сбойнул и не сформировал какую-нибудь бяку из-за «поехавшей» в памяти программы. В этом плане ПЛИС неплох, т.к. по своей сути представляет цифровую схему из набора регистров
А эта цифровая схема из набора регистров в случае fpga чем конфигурируется, как вы думаете?
Мы только что говорили о мире
пони и мармеладаволшебного программирования, в котором используется только то, что нужно, и ничего лишнего. Если я решил заменить С-массив, то очевидно от std::array мне нужно только size (и то не всегда) и at(). Иначе смысл теряется совершенно.Вот это как раз и есть один из вариантов ответа на заданный мной вопрос, спасибо. Дальше можно не продолжать.
Интересное дело, а где я утверждал обратное? Даже в мраморном мире Си есть движение. Я говорил лишь о том, чтобы, обращаясь к вашей аналогии, не заниматься постоянными экспериментами на пациентах.
Тем более что, если уж мы философствуем, то как-то ни разу не очевидно, что развитие специалиста состоит именно в изучении фич языка, а не в изучении новых сущностей предметной области. Хотя конечно как обычно нужно все и сразу, ага.
Гм, а зачем он мне, если я использую array? Или наоборот — если я не использую at(), то на кой черт мне array?
Уже читал. Но в целом занятно вы пишете — вот вам гайд, но вы его прямо так не берите… Редкая по мощи определенность.
Я и написал выше, что в открытом вот прямо сейчас на экране проекте нет нужды в векторах. А вот был проект, где были (по причинам, сходным с указанными у вас) самописные связные списки, и ни одного аргумента что-то в этом менять. Понимаете теперь?
Потому как с упомянутой посылкой документа во-первых все на самом деле просто, а во-вторых пока для вас это факультативное занятие — ну и фиг с ним, как-нибудь пошлем. Программирование же в том или ином виде является для нас профессиональной областью деятельности, которая должна отвечать требованиям максимальной эффективности. Поэтому нужно и не писать уж на С89, но и не посвящать жизнь постоянному следованию новинкам выбранного ЯП.
Мммм, а проверка границ для переменного индекса разве не создает накладных?
Вопрос справедливый, но ведь… Ведь использование С-массивов не запрещено… Вопрос же в этом — как выбрать между "все новые фичи — в будущий релиз!" и "используем по необходимости"? Если необходимость эту никто толком не может обосновать.
На самом деле это std::array я зазря помянул, поскольку его поведение почти очевидно, и нет никаких причин его не использовать (ведь и накладных почти нет), а вот вектор весьма непрост, и должны быть веские основания его заюзать. Комментатор выше считает, что выбор контейнеров — целое искусство, и совершенно непонятно, что же делать, если лично вы не видите вообще ни одной причины использовать вектор (а все вокруг используют!). А фичи все добавляются…
Пожалуй дискуссию стоит завершить ввиду ее полного перехода в философскую плоскость.
Естественно вопрос именно об этой ситуации, когда планируется вообще новый проект (небольшой) и обсуждается спектр решений: С99 (как было), С++03 (если вдруг придется переносить в продуктовый контент), либо взять и забабахать С++14 например.
Немного странная фраза, ибо теория резания например развита совершенно недостаточно для того, чтобы исключить понятие «хороший, опытный токарь», то есть как раз токарное дело — вполне себе искусство. А вот со структурами данных как раз таки обязана быть внятная система аргументов, наподобие упомянутой следующим комментатором.
А оно мне надо? Ну, серьезно, не стоит так уж рассуждать об эмбеде, будто там все те же 128 байт ОЗУ и 1к ПЗУ, и это повсюду. Ничего, я потерплю лишние вычисления… Впрочем разумеется вы правы, это вещь полезная, но как пример акцептации — так себе.
На правах троллинга: есть же _Static_assert!
Я это спрашиваю потому, что фраза «и вы удивитесь как быстро даже самые новые вещи, вдруг, окажутся востребованными» кажется мне небесспорной. Классический пример — был какой-то локальный велосипед для решения какой-то задачи, потом внезапно стало можно убрать/изменить велосипед за счет решения, примененного в новом стандарте. Но… зачем? Старый велосипед отлажен и впилен во все мыслимые библиотеки. Проблема перехода на новые фичи ничуть не проще, чем проблема перехода на новые архитектуры.
Отлично, привожу пример — понадобились только std::array (и то я хз, какова будет его ценность при отключенных прерываниях, разве что совсем уж глупые ошибки в компилтайме ловить), неймспейсы и классы (просто классы, любим инкапсуляцию и синтаксический сахар в виде конструкторов). Ииии… и что, это «modern C++»?
А теперь представьте, что полезность этих вещей в конкретном проекте вообще никак не обоснована, зато ограниченную команду закостенелых разработчиков может попросту порвать от необходимости читать очередные вирши комитета. Вы же поняли, что я не просто так спрашиваю, а из серии show your practices.
Собственно и упоминание C++03 не просто так — это база для MISRA C++2008. Это пока не выступает ограничителем в нашем частном случае, но может.
Что-то я не понял, как это препятствует «скрытию противоречий в коде».
Да, причем не только Торвальдс об этом говорит.
Вообще говоря все процитированное очень спорно, но это и неважно. Я не предлагаю отказываться от С++ в пользу С, вопрос был только о том, чтобы ограничить себя каким-то устаревшим стандартом.
По этому поводу еще раз спрошу, а то вы в прошлый раз не ответили — что вы думаете о том, чтобы в 2019 году писать на С++ 03 (то бишь 98), ну или, если более широко, вообще о концепции ограниченного использования С++ в эмбеде? Это просто вопрос, без намеков и подвоха.
А эта цифровая схема из набора регистров в случае fpga чем конфигурируется, как вы думаете?