Требования к паролям — полная чушь

Я вот только что проверил, paypal не дает при регистрации указать пароль длинее 20 символов. Вы же не хотите сказать…

Требования к паролям — полная чушь

Я могу понять любые правила для паролей, кроме идиотского ограничения максимальной длины.
Какого черта до сих пор встречается максимальная длина в 16 или 20 символов?! Они там что, в открытом виде хранятся? В массивах константной длины?

Черная магия метапрограммирования: как работают макросы в Rust 1.15

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

Черная магия метапрограммирования: как работают макросы в Rust 1.15

Синтаксис «имя: тип» я думаю выбран потому, что в отличие от C++ где аннотации типа обязательны, в Rust они являются скорее исключением и обязательны только в прототипах функций и структурах. В подавляющем большинстве случаев, типы внутри метода могут быть выведены полностью.

К этому моменту у меня претензий нет, когда изначально есть вывод типов через let (а не прикостыленное auto), это выглядит вполне органично.
А возвращаемое значение у функции через -> позволяет избавиться от безумного сишного синтаксиса указателей на функции. Это все понятно, просто непривычно.

Но вот угловые скобки вообще — это все-таки не очень.
Сравните:

Box<Map<Vec<i8>>>
Box[Map[Vec[i8]]]
Box(Map(Vec(i8)))

Для угловых скобок еще и шифт надо нажимать.

Черная магия метапрограммирования: как работают макросы в Rust 1.15

Меня, например, пугает в первую очередь какая-то многословность синтаксиса в целом. При этом я понимаю, что явное лучше неявного и все такое, но некоторые куски вызывают ступор просто из-за обилия спецсимволов:

fn escape_str(wr: &mut fmt::Write, v: &str) -> EncodeResult 

fn tcx<'a>(&'a self) -> TyCtxt<'a, 'gcx, 'tcx>;

На это накладывается все еще непривычный синтаксис «имя: Тип», использование угловых скобок как для лайфтаймов, так и для «шаблонных» параметров.

Кстати, об угловых скобках. Относительно частая необходимость вложенных шаблонных параметров вызывает чисто читательский дискомфорт, ведь угловые скобки — на самом деле не скобки, большинство IDE не подсвечивает их правильно и чисто визуально они воспринимаются хуже, чем круглые или квадратные (а я-то гадал, почему в Scala дженерики используют квадратные скобки):

fn ast_ty_to_ty_cache(&self) -> &RefCell<NodeMap<Ty<'tcx>>>;

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

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

Знаете, насмотревшись на код, который пишут студенты 3 курса, я могу совершенно однозначно сказать — работоспособность, конечно, важна, но оформление — это тоже очень важно!

Слабонервным не смотреть!

Установка FreeRTOS для Stm32vlDiscovery

HAL просто все еще слишком свежая, сообщество к ней относится скептически. Когда SPL была свежая, в ней тоже баги попадались, но их со временем исправляли. Скепсис еще пару лет держался. С HAL сейчас такая же история.

Многим (мне, кстати, тоже) еще плохо понятно, зачем переходить на HAL, если уже SPL есть и работает. Поэтому HAL юзают в основном «новоприбывшие» на платформу или те, кто переходит на свежие чипы, для которых SPL вообще не было.

Установка FreeRTOS для Stm32vlDiscovery

Вот это 100% баг, признанный и исправленный. Прошу обратить внимание, что пост был в марте 2014 года, а в последнем комменте (в сентябре) упоминается, что баг все еще присутствует.
https://community.st.com/thread/24409

Даже не знаю, баги это или нет, но поведение действительно весьма неожиданное. Тут я уже не следил за исправлениями.
https://community.st.com/thread/8588
https://community.st.com/thread/8624

Конечно, все это было довольно давно, вполне возможно, что теперь все хорошо, я уже давненько не проверял, как там у HAL'a и CubeMx дела.

Установка FreeRTOS для Stm32vlDiscovery

Всегда это удивляет. Вот сидит наш парень и вдруг находит ошибки в коде произведенном серьёзной европейской компанией. И таких вдруг целая страна. А производитель и не знаеи и не подозревает.

Вы удивитесь, но я лично в HALe и в CubeMx находил несколько довольно глупых багов. Разумеется, я хотел их зарепортить… а репортить-то некуда. Багтрекера нет. Ну ладно, пошел на форум, создал несколько тем. В них отписались три с половиной человека, мол, да, действительно.
Через полгода отписался модератор. Еще через полгода баги поправили.

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

HAL сам по себе неплох, у него хотя бы есть написанная человеком (а не генерированная) документация.

Установка FreeRTOS для Stm32vlDiscovery

Расскажу про пару граблей, на которые мы в свое время очень больно наступили:

— удостоверьтесь, что во freertos_config.h есть непустой #define configASSERT( ( x ) ) (например, что-нибудь вроде if(!x) {__disable_irq(); while(1){;}}

— сделайте вот это до запуска RTOS — NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );

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

Источник: http://www.freertos.org/RTOS-Cortex-M3-M4.html

Думаешь, ты знаешь Си?

На мой взгляд, для некоторых вопросов возможны более точные ответы:

1) А, В и С возможны (в зависимости от конкретных размеров типов).
2) A или В (потому что == возвращает или 0 или 1). Но не С (потому что == не может вернуть 2, стандарт это явно оговаривает)
3) А, B или С возможны, в зависимости от размера char и от его знаковости. Но если копнуть глубже, то тут вариант «Не знаю» действительно подходит лучше, потому что стандарт С не оговаривает кодировку символов! И код пробела, вообще-то, может быть любым (стандарт только обязывает его влезать в 5 бит).
4) Вопроса нет, поэтому я действительно не знаю.
5) Это не «я не знаю», это называется «неопределенное поведение».

Еще пара моментов:
— Почему-то паддинг в структурах вы называете «отступы» — никогда не слышал такого применения, обычно отступ — это отступ в начале строки исходного кода. Но допустим, с русскоязычной терминологией у меня плохо.
— «Более того, размер типа char в битах не определен.» Вообще-то, он определен в макросе CHAR_BITS. Вы, видимо, имели в виду, что он не определен в стандарте — это так.

К вопросу о стиле

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

Вероятно, это дело вкуса, но лично мне не нравится, когда исходники и заголовочные файлы лежат в разных директориях. Почему?

• Это увеличивает дерево папок проекта, потому что папка каждого модуля (у вас же есть отдельные папки для модулей?) появляются в двух местах.
• Это заставляет вас либо писать путь в инклуде с какими-нибудь извращениями, вроде #include "../INC/header.h", либо прописывая путь до папки INC в настройках проекта или в makefile.
• Это не приносит никакой практической пользы.

Возможно, я каких-то бонусов просто не замечаю?

Сам я следую принципу «исходник и его заголовок лежат в одной папке, без разделения на SRC и INC», инклуд в исходнике при этом пишется просто #include «header.h». Дерево папок получается компактным, в настройках проекта ничего прописывать не нужно, инклуд получается короче.

К вопросу о стиле

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

Сразу же затрону тему беззнаковых чисел. Почему то сложилась практика, что для определении регистров внешних устройств (и при описании структуры пакетов передачи данных) применяют именно беззнаковые типы. Мне не очень понятно такое решение, поскольку единственное различие между знаковым и беззнаковым типом состоит в реализации операций > и <

Насколько мне известно, причина сего в том, что стандарт языка С описывает некоторые операции со знаковыми числами как неопределенное поведение, например:

• знаковое переполнение
• сдвиг отрицательных чисел влево
• сдвиг с залезанием в знаковый бит

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

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

typedef enum {False=0,True=1} Boolean;

Нет ну сколько ж можно-то, ну 2016 год на дворе, стандарту С99 уже 17 лет, ему скоро в университет поступать можно, а вы все еще изобретаете свой bool! Ну есть же stdbool.h, сколько ж можно-то?

И опять ничего это не дает, неявное приведение к int'у все равно будет! А уж сколько замечательных столкновений с чужими определениями False, True и Boolean можно получить, просто сказка.

Использование шаблонного метапрограммирования для микроконтроллеров AVR

Осмелюсь подкинуть старую, но все еще любопытную статью на эту же тему Работа с портами ввода-вывода микроконтроллеров на Си++

Почему я отказался от Rust

Пожалуй, единственное, что мне все же приходит в голову — это CRTP в C++. Но, по-моему, это слегка читерство:

template< typename T >
class Base
{
public:

    void foo()
    {
        std::cout << ((T *)(this))->text;
    }
};

class Derived : public Base< Derived >
{
public:
    Derived() : text("abc") {}
    std::string text;
};

int main(void)
{
    Derived d;
    d.foo(); // выводит "abc"

    return 0;
}

Почему я отказался от Rust

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

Почему я отказался от Rust

У меня тупой вопрос по вот этому куску кода:

trait Widget {
    fn font_size(&self) -> i32 {
        if self.font_size < 0 { //compiler error
            return self.theme.get_standard_font_size(); //compiler error
        } else {
            return self.font_size; //compiler error
        }
    }
}

Разве в том же С++ базовый класс может дотянуться до полей в потомках? Или в каком-то другом популярном языке так можно?

О выравнивании памяти на ARM процессорах на простом примере

Уточните, пожалуйста, какой именно у вас ARM?

Гейзенбаг, или как Луна портит код

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

Гейзенбаг, или как Луна портит код

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

В конце концов заметил, что это происходило, только если угол наклона девайса был 19 градусов…

Оказалось

Оказалось, что я зачем-то (совершенно не понимаю — зачем?!) включил программное управление потоком com-порта, в котором байт 19 (0x13, XOFF) означает «Остановить передачу». Протокол у меня был бинарный, угол передавался просто двумя байтами в градусах. Девайс выдавал данные только по запросу, а после байта 19 порт на компе больше никаких запросов отправлять не хотел.