Меня эта проблема тоже беспокоит, как начинающего писателя поискового движка. Чтобы контент просто проиндексировать и честно на него сослаться — тоже нужно сначала распарсить. Какие могут быть решения для этой проблемы? Только грубая сила — куча прокси с разными IP, ну и не качать много страниц с одного сайта подряд?

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

Именно тем же удобно, чем удобно иметь оглавление к книге. Быстрая навигация по коду, лекго окинуть взглядом весь класс. А ошибки несоответствия объявления и определения компилятор легко и сразу выявляет, анализатор реального времени в IDE тоже.

1. Не понял суть претензии. То есть я верю, что для вас это проблема, но вот я уже больше 10 лет профессионально программирую на С++, и не только не испытывал такой проблемы, но даже плохо понимаю, в чем она заключается.
3. Разделение на хедеры и сорцы — это гениально. .cpp и хедер — это как книга и её оглавление. Очень удобно и полезно.

Спрос есть, почему же дефицит STM32 появился и держится? Они явно не по передовым ТП делаются, как я смог нагуглить — 90 нм.

ИМХО отличная яркая палитра для игр. Commodore 64 — вот где ужасная палитра из бледно-серо-буро-малиновых цветов.

Потому и воруют, что люстрация не в моде :)

Мне тоже кажется, что это единственно возможное решение. Либо хэш, либо пара публичный/приватный ключ. Рассчёты проводить на стороне клиента, на сервер передавать только хэш или ключ, слишком длинный, чтобы забрутфорсить.

P. S. Промахнулся комментарием, извините. Отвечал на вопрос выше про использование хэшей.

Спасибо за полезную информацию!

Интересно, спасибо за ответ. Регулярно (уже несколько лет) пользуюсь Paint на свежей Windows 10, ни одного бага не замечал. Но у меня нет картинок со стороной 33 тысячи пикселей :) И текст в нём не рисую, только геометрические фигуры.

Лично я встречаю плесень в быту в виде белой пушистой поросли на консервации. Самодельный томатный соус, или варенье, но слабо засахаренное, ближе к компоту. Хранится годами, но когда я его открываю первый раз и ставлю в холодильник — часто не успеваю съесть и треть маленькой баночки, как под крышкой или на крышке изнутри появляется эта белая гадость. Что это за вид плесени, и можно ли её удалить и употреблять продукт, если в массе продукта никакой плесени не видно и запах нормальный? И это при том, что у меня новый холодильник и температура внутри +5-6 градусов. На фотографиях в статье я не увидел ничего похожего на мою белую плесень.

Регулярно пользуюсь Paint, что в нем сломано?

Ого. И весь этот свинец попадает в окружающую среду в виду мелкой пыли по мере исзноса колодок?

Код действительно плохой, С++ здесь ни при чем. Автор — не профессиональный программист, если можете лучше — причешите и сделайте pull request.

А чем вам не нравится Хром?

Бывает и такое. Хотя, конечно, Apple это запрещает. Типа, купить прямо у разрабов, получить лицензионный ключ и ввести его в приложении.

Спасибо!

А как под капотом реализована загрузка и исполнение кода? Ведь на любом современном компьютере/ОС нельзя запустить на исполнение произвольный адрес в памяти, скомпилированный код изначально должен быть загружен именно как программный код. Единственный известный мне механизм подгрузки кода во время выполнения приложения — это загрузка динамической библиотеки с диска, но здесь наверняка реализовано как-то по-другому, без промежуточного файла (.so / .dll).

недавно у нас авиамоделизм стал практически запрещен

Как так?

Вот как раз в дебажной сборке намного проще отловить баг благодаря всяким memory guards и дебажным функциям стандартной библиотеки (в MSVC это отлично работает, полагаю, что в clang не хуже). Ну а лучше всего — address sanitizer, раз уже всё равно clang используете. Я понимаю, что у вас очень большой проект и с ним сложно экспериментировать, но вывод о том, что clang обнаружил ошибку и активно помогал вашему коду её обойти, почти наверняка неверен.