Интересно, а почему вообще были введены эти два оператора? Ведь один delete вполне мог бы проверять, что он сейчас будет удалять, массив или не массив.
Лично мне было тяжело воспринимать данные измерений, если они были записаны без разделителей десятичных разрядов (т.е. как 210349179, а не 603,500,301), слишком уж числа длинные. А в разных местах написано то так, то эдак, что еще сильнее затрудняет восприятие.
Отмечу, что существует проект Wix#, который позволяет описывать инсталлятор на C# и генерировать XML для Wix
var project = new Project("MyProduct",
new Dir(@"%ProgramFiles%\My Company\My Product",
new File(@"Files\Docs\Manual.txt"),
new File(@"Files\Bin\MyApp.exe")));
project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
На мой неискушенный разметкой взгляд, это читается и пишется гораздо приятнее, плюс можно втыкать любые костыли расширения в виде произвольного кода на шарпе.
Если позволяет специфика, то можно прямо на "боевой" плате развести отладчик и вывести USB на корпус устройства; да, далеко не в любом случае можно такой девайс поставлять заказчику, но если можно - то это очень сильно облегчает отладку устройства в собранном виде.
Future proof - продумать, что может потребоваться улучшать. Футпринт с расчетом, что может потребоваться проц пожирнее; разъемы с небольшим запасом пинов, интерфейсы с запасом по скорости - тут сложно какой-то общий совет дать, но в целом подумать "а что мы можем захотеть поменять" полезно.
Если устройство в достаточно крупной серии, то загрузчику хорошо бы поддерживать какой-то вариант "обновить все девайсы разом", просто перетыкивать кабель больше 10 раз само по себе напряжно; перепрошивание через интернет или беспроводным способом тоже может быть полезно.
Возможность делать "factory reset" - с откатом на гарантированно рабочую прошивку, если предполагаются регулярные обновления.
Если делается какой-то вариант настроек (не суть, с файловой системой или без), то должен быть способ до этих настроек дотянуться без залезания в отладчик. Может через отдельную утилиту, может через CLI, может имитацией USB Mass Storage - не очень важно, главное, чтобы это можно было сделать не через перепрошивание. Ну и возможность "скачать" настройки с девайса тоже полезна.
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов. При отладке устройств, которые управляют собственным питанием, бывает очень полезно. Или полный дамп выдать.
Контроль версий. git, само собой, но и в саму прошивку можно запихать информацию о сборке - хеш коммита, время компиляции, может быть что-то еще. Главное, чтобы не вручную! Это нужно редко, но когда нужно - реально спасает.
Отладочные светодиоды на плате - банально, но про них часто забывают или делают только один, по питанию. Хотя бы два управляемых и разноцветных тоже сильно помогают жить - особенно если никаких других средств диагностики нет. Отладочная пищалка или динамик тоже хорошо, дает более широкий диапазон различимых сигналов :)
Серийный номер и версия платы прямо на текстолите; в идеале наносится автоматизированно.
Тест-поинты на платах и в целом продумывать "как мы это будем тестить автоматизированно" - если, конечно, девайсов планируется на 2-3 штуки.
Про юнит-тесты я писал пост; имхо тестами "на железе" дело ограничиваться не должно.
Нормальные IDE, современные стандарты языков, С++11 вместо С89, статический анализ (ну или сразу Rust, для смелых :)
Было бы интересно почитать больше подробностей про сам процесс программирования - какую IDE использовали, насколько все плохо/хорошо с отладкой, какие специфические растопроблемы всплывали, которых на С++ не было бы?
Мне вот интересно, не пора ли уже включать yaml в список языков программирования?
Глядя на то, как его гоняют в хвост и в гриву всякие кубернетесы и хельмы, собирая те же грабли, на которые традиционные ЯП уже наступали, мне становится грустно..
Всегда ненавидел тернарный оператор (сперва потому что никак не мог запомнить, где у него какая ветка, потом за то, что он в С/C++ работает _не так же_ как if-else)
И после сишных `int * ptr, const a, *const * b` у меня дергается глаз при виде множества объявлений на одной строке
Но понятно, что это все - вкусовщина.. до некоторой степени :)
«Золотым стандартом» паролей сегодня принято считать комбинацию из не менее восьми символов, которая, помимо букв английского алфавита обоих регистров, содержит цифры и специальные символы.
Насколько мне известно, этот "золотой стандарт" взялся из древней рекомендации NIST, и просто безбожно устарел; этот стандарт сейчас приводит только к тому, что люди не могут запомнить свои пароли и вынуждены опираться на сохранение паролей в браузерах и менеджеры паролей.
А сайты вводят шизофренические требования для паролей - требуют то большую букву обязательно, то маленькие, то специсмолвы, то цифры, то ограничивают минимальную длину, то ограничивают максимальную (sic!).
Текущая рекомендация NIST гораздо разумнее (макс. длина не менее 64 символов, не требовать от человеческих паролей наличия спецсимволов и цифр, но проверять наличие длинных повторов (ааааа) или последовательностей (1234), сверять пароль с блэклистом самых частых паролей) и т.д.
Соответственно новый золотой стандарт (в отличии от старого) не мешает, к примеру, использовать длинные многословные парольные фразы в стиле "correct horse battery staple", обладающие значительной энтропией.
Как - это была бы забота компилятора, так же как сейчас
Интересно, а почему вообще были введены эти два оператора? Ведь один delete вполне мог бы проверять, что он сейчас будет удалять, массив или не массив.
Желание снизить оверхед для хранения не-массивов?
Справедливо
Спасибо!
Имхо это не подделка, а редакторские правки :)
Лично мне было тяжело воспринимать данные измерений, если они были записаны без разделителей десятичных разрядов (т.е. как 210349179, а не 603,500,301), слишком уж числа длинные. А в разных местах написано то так, то эдак, что еще сильнее затрудняет восприятие.
Отмечу, что существует проект Wix#, который позволяет описывать инсталлятор на C# и генерировать XML для Wix
На мой неискушенный разметкой взгляд, это читается и пишется гораздо приятнее, плюс можно втыкать любые
костылирасширения в виде произвольного кода на шарпе.С удовольствием использую в С++ библиотеку https://github.com/LouisCharlesC/safe, которая реализует аналогичный API.
А в Rust компилятор за такое ругает... И можно запретить не-ASCII идентификаторы.
Это если прошивка еще отвечает, плата еще не сгорела, батарейка еще не села и т.д. А логи - вот они!
Ну и логи можно слать по DMA, чтоб не тормозило.
Но в целом это просто еще один вариант, универсальных ответов нет :)
Ну я так, за компанию уже :)
Если позволяет специфика, то можно прямо на "боевой" плате развести отладчик и вывести USB на корпус устройства; да, далеко не в любом случае можно такой девайс поставлять заказчику, но если можно - то это очень сильно облегчает отладку устройства в собранном виде.
Future proof - продумать, что может потребоваться улучшать. Футпринт с расчетом, что может потребоваться проц пожирнее; разъемы с небольшим запасом пинов, интерфейсы с запасом по скорости - тут сложно какой-то общий совет дать, но в целом подумать "а что мы можем захотеть поменять" полезно.
Если устройство в достаточно крупной серии, то загрузчику хорошо бы поддерживать какой-то вариант "обновить все девайсы разом", просто перетыкивать кабель больше 10 раз само по себе напряжно; перепрошивание через интернет или беспроводным способом тоже может быть полезно.
Возможность делать "factory reset" - с откатом на гарантированно рабочую прошивку, если предполагаются регулярные обновления.
Если делается какой-то вариант настроек (не суть, с файловой системой или без), то должен быть способ до этих настроек дотянуться без залезания в отладчик. Может через отдельную утилиту, может через CLI, может имитацией USB Mass Storage - не очень важно, главное, чтобы это можно было сделать не через перепрошивание. Ну и возможность "скачать" настройки с девайса тоже полезна.
CLI необязательно делать "дуплексным", зачастую вполне хватает просто вывода отладочной печати или логов. При отладке устройств, которые управляют собственным питанием, бывает очень полезно. Или полный дамп выдать.
Контроль версий. git, само собой, но и в саму прошивку можно запихать информацию о сборке - хеш коммита, время компиляции, может быть что-то еще. Главное, чтобы не вручную! Это нужно редко, но когда нужно - реально спасает.
Отладочные светодиоды на плате - банально, но про них часто забывают или делают только один, по питанию. Хотя бы два управляемых и разноцветных тоже сильно помогают жить - особенно если никаких других средств диагностики нет. Отладочная пищалка или динамик тоже хорошо, дает более широкий диапазон различимых сигналов :)
Серийный номер и версия платы прямо на текстолите; в идеале наносится автоматизированно.
Тест-поинты на платах и в целом продумывать "как мы это будем тестить автоматизированно" - если, конечно, девайсов планируется на 2-3 штуки.
Про юнит-тесты я писал пост; имхо тестами "на железе" дело ограничиваться не должно.
Нормальные IDE, современные стандарты языков, С++11 вместо С89, статический анализ (ну или сразу Rust, для смелых :)
Спасибо!
Спасибо за статью!
Было бы интересно почитать больше подробностей про сам процесс программирования - какую IDE использовали, насколько все плохо/хорошо с отладкой, какие специфические растопроблемы всплывали, которых на С++ не было бы?
Мне вот интересно, не пора ли уже включать yaml в список языков программирования?
Глядя на то, как его гоняют в хвост и в гриву всякие кубернетесы и хельмы, собирая те же грабли, на которые традиционные ЯП уже наступали, мне становится грустно..
Всегда ненавидел тернарный оператор (сперва потому что никак не мог запомнить, где у него какая ветка, потом за то, что он в С/C++ работает _не так же_ как if-else)
И после сишных `int * ptr, const a, *const * b` у меня дергается глаз при виде множества объявлений на одной строке
Но понятно, что это все - вкусовщина.. до некоторой степени :)
Отличная статья, спасибо!
Позволю себе поправить вас в одной мелочи :)
Слово нишевое, и его очень часто произносят так - "гаудж", ну gauge же!
Но читается это "гейдж" (и англоговорящие, в свою очередь, путают его написание с gage).
Насколько мне известно, этот "золотой стандарт" взялся из древней рекомендации NIST, и просто безбожно устарел; этот стандарт сейчас приводит только к тому, что люди не могут запомнить свои пароли и вынуждены опираться на сохранение паролей в браузерах и менеджеры паролей.
А сайты вводят шизофренические требования для паролей - требуют то большую букву обязательно, то маленькие, то специсмолвы, то цифры, то ограничивают минимальную длину, то ограничивают максимальную (sic!).
Текущая рекомендация NIST гораздо разумнее (макс. длина не менее 64 символов, не требовать от человеческих паролей наличия спецсимволов и цифр, но проверять наличие длинных повторов (ааааа) или последовательностей (1234), сверять пароль с блэклистом самых частых паролей) и т.д.
Соответственно новый золотой стандарт (в отличии от старого) не мешает, к примеру, использовать длинные многословные парольные фразы в стиле "correct horse battery staple", обладающие значительной энтропией.
(см. https://pages.nist.gov/800-63-3/sp800-63b.html пункты 5.1.1.1 и Appendix A)
Стандарт умер (и давайте уже похороним его побыстрее), да здравствует стандарт!
PrimeCoin еще был
Справедливо :)
Ага, ну то есть строка в компайл-тайм таки парсится? Только это делает особая компиляторная магия, специально сделанная для этого случая, а не макрос?