UTF-8 — это просто способ кодирования 31-битных значений в виде последовательности 8-битных байт. Он никак не привязан к смысловому содержанию этих значений.
Для подавляющего большинства практических задач обработки строк посимвольный доступ (=преобразование UTF8 в UCS2/UCS4 на лету) не нужен — можно работать напрямую с UTF8 представлением строки.
Если всё-таки нужен произвольный посимвольный доступ, то будет гораздо эффективнее преобразовать строку в массив 2-байтных или 4-байтных значений, а после работы преобразовать обратно. А если ещё хочется и менять значения символов на месте, то как вы себе это представляете для UTF8?
Этот прикол с FF я уже давно заметил. Хочешь, чтобы сайт отображался одинаково — вырезай всю информацию о цветовых пространствах.
Ну а что касается перевода из одного цветового пространстве в другой, то сходу вижу проблему в понижении цветового разрешения: при сужении диапазона несколько значений из диапазона 0-255 перейдут в один, и наоборот: при расширении диапазона будут появляться дырки. Картинка с ровным градиентом будет выглядеть ужасно. Резюме: игры с цветом будут иметь смысл только когда 10-битный цвет станет стандартом.
В своём софте для отображения изображений я использую паттерн 2х2 для отображения 10-битного цвета на мониторе с 8-битной глубиной цвета. Вот пример. Изображение градиента поделено на 3 горизонтальные полосы: сверху 8-битный градиент, посередине 9-битный, снизу 10-битный. Можно в редакторе поднять контраст и посмотреть, как это сделано.
Современные светодиодные лампы не настолько совершенны, им ещё есть, куда развиваться дальше вместо включения запланированного устаревания:
— приблизить спектр к солнечному и к спектру ламп накаливания;
— достичь предела по светимости в 260-300 лм/вт для естественного спектра;
— полностью избавиться от пульсаций.
Так оно и есть: просто вместо уменьшения рабочего времени увеличилось потребление.
Например, можно жить в России на 15-20к в месяц. То есть работать программистом 1 день в неделю.
Использование auto — как использование паттернов. Есть люди, которые считают нужным притягивать за уши паттеры там, где они не нужны.
auto хорош для локальных переменных, возможно, некоторых приватных методов. Но нельзя допускать, чтобы публичный метод возвращал auto, кроме редких случаев, когда используются шаблоны и вывод громоздок или крайне затруднителен.
Да, в случае работы с сетью частая ошибка: уничтожить буфер до того, как он будет фактически отправлен. Тут действительно лучше скопировать — надёжнее будет.
Так предыдущий комментатор именно это и написал. Если есть 1 параметр, то будет 2 перегрузки, если 2, то 4, если 3, то 8 (дял всех возможных комбинаций) и так далее.
Обычно заботу о вызове WAIT берёт на себя компилятор.
Пикантная ситуация возможна, опять же, при прерываниях, если обработчик прерывания хочет прочитать область памяти, куда может писать сопроцессор. Обработчик прерываний не имеет права вызвать WAIT.
Касаемо 8086: да, прерывание может произойти во время выполнения команды: процессор может считать из памяти операнд и начать выполнять операцию, но не успеть записать результат. С точки зрения программиста это будет выглядеть как если бы команда не выполнялась вообще.
DMA и сопроцессор — отдельные темы. Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.
Итерация по символам юникода с полноценной поддержкой большого числа правил ресурсозатратна как по скорости обработки, так и по памяти.
Тут всё зависит от задачи. Если задача — просто распарсить JSON, то работа со строкой будет осуществляться как с обычным массивом с использованием небольшого числа строковых функций. В случае программирования микроконтроллера полноценная поддержка юникода тоже явно будет лишней.
Я бы вообще не изобретал велосипед, а пользовался исключительно средствами операционной системы. В STL включил бы только врапперы для их вызова. Для основных задач обработки строк этого достаточно. Ну а что касается поддержки экзотических случаев — не стоит ими засорять стандартную библиотеку.
Касаемо языковых фишек: простота увеличивается за счёт использования лямбд (больше не надо писать классы-функторы), range-based for (чуть меньше кода), constexpr (вместо шаблонов и метапрограммирования). Понятность — за счёт явного указание override и final для виртуальных функций, nullptr вместо константы NULL, отказа от enum в пользу enum class.
auto считаю злом.
Замечание про move semantics не понял. Любой старый класс будет неявно поддерживать перемещение, если не указано обратное. И всё будет работать корректно, но до тех пор, пока конструкторы копирования и перемещения будут выполнять только то, что они должны, без побочных действий.
А как быть с тем, что в универсете я легче воспринимал лекции, если параллельно играл в не требующую мозгов игру на КПКшке? Шарики, например. Если же я концентрировался только на лекции, то мозг оставался недогруженным и к концу лекции отрубался.
Принципиальных изменений в C++ не происходит. Происходит только медленное разрастание STL и добавление синтаксического сахара для увеличения простоты и уменьшения объёма кода.
Единственное фундаментальное изменение — это move semantics.
А так да, можно писать в стиле C++03.
UTF-8 — это просто способ кодирования 31-битных значений в виде последовательности 8-битных байт. Он никак не привязан к смысловому содержанию этих значений.
Для подавляющего большинства практических задач обработки строк посимвольный доступ (=преобразование UTF8 в UCS2/UCS4 на лету) не нужен — можно работать напрямую с UTF8 представлением строки.
Если всё-таки нужен произвольный посимвольный доступ, то будет гораздо эффективнее преобразовать строку в массив 2-байтных или 4-байтных значений, а после работы преобразовать обратно. А если ещё хочется и менять значения символов на месте, то как вы себе это представляете для UTF8?
Ну а что касается перевода из одного цветового пространстве в другой, то сходу вижу проблему в понижении цветового разрешения: при сужении диапазона несколько значений из диапазона 0-255 перейдут в один, и наоборот: при расширении диапазона будут появляться дырки. Картинка с ровным градиентом будет выглядеть ужасно. Резюме: игры с цветом будут иметь смысл только когда 10-битный цвет станет стандартом.
В своём софте для отображения изображений я использую паттерн 2х2 для отображения 10-битного цвета на мониторе с 8-битной глубиной цвета. Вот пример. Изображение градиента поделено на 3 горизонтальные полосы: сверху 8-битный градиент, посередине 9-битный, снизу 10-битный. Можно в редакторе поднять контраст и посмотреть, как это сделано.
— приблизить спектр к солнечному и к спектру ламп накаливания;
— достичь предела по светимости в 260-300 лм/вт для естественного спектра;
— полностью избавиться от пульсаций.
Например, можно жить в России на 15-20к в месяц. То есть работать программистом 1 день в неделю.
auto хорош для локальных переменных, возможно, некоторых приватных методов. Но нельзя допускать, чтобы публичный метод возвращал auto, кроме редких случаев, когда используются шаблоны и вывод громоздок или крайне затруднителен.
Пикантная ситуация возможна, опять же, при прерываниях, если обработчик прерывания хочет прочитать область памяти, куда может писать сопроцессор. Обработчик прерываний не имеет права вызвать WAIT.
DMA и сопроцессор — отдельные темы. Скорее всего, вам никогда не понадобится лезть в область памяти в тот момент, когда с ней работает сопроцессор или гадит DMA.
Тут всё зависит от задачи. Если задача — просто распарсить JSON, то работа со строкой будет осуществляться как с обычным массивом с использованием небольшого числа строковых функций. В случае программирования микроконтроллера полноценная поддержка юникода тоже явно будет лишней.
Я бы вообще не изобретал велосипед, а пользовался исключительно средствами операционной системы. В STL включил бы только врапперы для их вызова. Для основных задач обработки строк этого достаточно. Ну а что касается поддержки экзотических случаев — не стоит ими засорять стандартную библиотеку.
auto считаю злом.
Замечание про move semantics не понял. Любой старый класс будет неявно поддерживать перемещение, если не указано обратное. И всё будет работать корректно, но до тех пор, пока конструкторы копирования и перемещения будут выполнять только то, что они должны, без побочных действий.
Единственное фундаментальное изменение — это move semantics.
А так да, можно писать в стиле C++03.