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

Тоже вариант, но так нагляднее, не приходится везде во всех методах писать проверку на nullptr для m_data. Впрочем никто не запрещает создать шаблон от типа данных, наподобие nullable<typename data_type> и перегрузить там operator -> для проверки на nullptr указателя на data_type. Но опять же, теряется наглядность учебного материала.

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

Ну сам-то object с данными по умолчанию вполне себе всегда is_null(), а вот его наследники null далеко не всегда.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Не стоит забывать о том, что мапа всё-таки сортирована по ключам. Иногда это важно.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Ну и чего обижаться-то? Как можно сравнивать листинг IL-кода против нативных инструкций скомпилированного и оптимизированного кода на C/C++? Каким бы шустрым CLR ни был, это всё равно лишняя трансляция в машинные инструкции. Хотите померяться с сишником скоростью выполнения managed кода против нативного. Весьма похвально стремление, с каким отстаивается точка зрения и любимые технологии, но это малость опрометчиво. Сериализацию вообще на C# или Java писать не очень эффективно, но если есть пример, где прямо по бенчмаркам C# библиотека уделывает все сишные, я бы на это посмотрел.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Я знаю C# достаточно хорошо, как и .NET Framework в целом и CLR в частности, я говорю лишь о том, что unsafe конструкции не являются нормальной практикой языка и их использование всегда несёт некоторые ограничения, не говоря уже об обёртках из namespace Marshal. Их применение сродни ассемблерной вставке и в этом случае я предпочитаю написать честный нативный модуль и работать с памятью из C/C++, а уж точно не из C#, который в этом случае использовать неэффективно иначе, кроме как для вызова кода обёрток методов.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

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

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

Массив индексов будет перестраиваться каждый раз, когда будет применяться операция замены по регулярному выражению. По сути может перестроиться вся строка, а фактически и весь набор твоих элементов. Либо ограничиваешься константностью представленного строкового объекта, вынуждая разработчика автоматически и безконтрольно создавать совершенно ненужные промежуточные мини-объекты строк, как это сделано, например, в Python. Если же у тебя два массива дублируют друг друга, возникает также проблема консистентности двух представлений одних и тех же данных.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

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

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Как я уже написал выше, unsafe блок крайне ограниченная по своему применению структура языка C#, что именно там можно, а что нельзя. Можно также вспомнить про Marshal и IntPtr, но это вообще доступ к коду, фактически написанному на C/C++ и больше подходит для обёртки, чем для полноценной работы.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Векторизация памяти — это фактически оптимизация работы с оперативной памятью на уровне инструкций CPU, и std::vector для этого отлично подходит. Имя структуры std::vector совсем никак не связано с понятием «динамический массив», как и std::deque. В Java и C# доступ к памяти напрямую настолько же убог и специфичен, насколько и ограничен, сколько всего нельзя в том же unsafe блоке C#, по факту это аналог ассемблерной вставки в С/C++ зачастую абсолютно ненужная операция для высокоуровневых языков. В С/C++ доступ к памяти осуществляется на уровне понятий языка, оптимизация работает как надо и всё можно, что и обычно, это нормальная практика, в отличие от Java/C#.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Это всё здорово, но вычисление длины null-terminated строки фактически не влияет на замеры, по сравнению с заполнение N-го числа std::string это как раз копейки. Можно нивилировать стандартной передачей указателя на конец, аналогичного итератору end(). push_back() у std::vector запросто может пойти за новой памятью, и поэлементно будет перемещать все элементы из старого блока в новый, std::deque'у это не грозит. С alignment знакомы, пожалуй, все, m_buffer на это никак не влияет, разница между выделением памяти внутри самого объекта или в куче, да или на стеке, где угодно, для alignment нулевая.

Как продеть слона через игольное ушко. Обработка максимальных объемов данных за минимальное время

Замечательно, действительно, надо запретить себе даже думать об указателях и представить что их нет. Правда что ли? 14-й стандарт отменяет использование указателей? Наиболее эффективное и оптимизированное построение алгоритма происходит именно на основе умелого управления памятью напрямую из кода C/C++. Можно сколько угодно отговаривать новичков от использования указателей в коде, но в этом случае из них не вырастет специалистов, умело управляющихся с памятью вручную. Именно такая магия и нужна как крупным компаниям, так и маленьким стартапам, и именно от получения этих бесценных навыков ты отговариваешь новичков? Не скажу, что очень уж ценный совет для начинающих.

Всё, точка, приплыли! Учимся работать с числами с плавающей точкой и разрабатываем альтернативу с фиксированной точностью десятичной дроби

Напишите непосредственно редактору, он выкладывает тексты.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

Да ладно, каждый раз у вас будет перестроение таблицы символов. Хэш-таблица весьма чутко реагирует на любое мало-мальски серьёзное перестроение и чтобы оставить всё с константным доступом перестраивает весь исходный набор цепочек коллизий. Вы хотите после каждого регэкспа перестроения хэш-таблицы? Весьма спорное стремление.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

Да, но чтобы находить подстроку, нужно обходить строку, сравнивая с эталоном, но куда проще обходить элементы строки как символы, нежели пытаться разобраться в байтовой каше.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

Да вы заколебётесь перестраивать хэш-таблицу с индексами индексов(!) при любой регулярке, изменяющей текст.

Грустная история забытых символов. Как не сойти с ума при работе с кодировками в C++

Я вижу два символа, а вот toupper как раз не показатель. Всякие надстрочные и подстрочные символы — суть отдельные символы. Если определить соответствие 1:1 как соответствие одного символа одному коду таблицы Юникод, то всё становится на свои места.

Сериализация, сэр! Сегодня на ужин байтовая каша, сваренная из объектов C++

Кто это?

Сериализация, сэр! Сегодня на ужин байтовая каша, сваренная из объектов C++

Не смотрите новости, читайте лучше хорошие журналы.

Сериализация, сэр! Сегодня на ужин байтовая каша, сваренная из объектов C++

Кроме сериализации для передачи по сети, есть ещё сериализация в общепринятые протоколы: JSON, XML, YAML, ASN.1 или любой протокол, которого требует задача. И тут, увы, ваш google/protobuf становится ненужен чуть менее, чем абсолютно.