mbrtoc16, mbrtoc32, c16rtomb и c32rtomb. И это потому что, снова, не все реализации стандартной библиотеки C++ реализуют эти же функции. Многие разработчики приходят к такому же решению при отказе от codecvt. Иные пользуются тем же ICU и про codecvt даже не вспоминали. ;, который находится в конце строки. Люди ждут выражений не более чем в одну строчку. Когда в конце строки находится не ;, код снова начинает сбивать читателя с толку. В самом крайнем случае допускается разбивка арифметических выражений на несколько строк. Да и то, на ревью такой код с вероятностью 80% потребуют переформулировать в пояснительные константы. Больших арифметических выражений в коде тоже быть не должно.4. После размещения вопроса пользователю запрещается осуществлять:
4.1. Дублирование вопроса, который уже размещался на страницах Сервиса. В том числе и в случае, если вопрос был удалён модератором, или на вопрос не был дан ответ (т.е. категорически запрещается дублирование вопроса с целью повторного привлечения к нему внимания).
impression.float intension, empation, insignion, imposion;
int impresumption, impetition, inversion, illustration;
bool illusion, impretendion, imperception;client, которое ничего не выражает?struct data_t - абсолютно никак не объясняет смысл своего существования. Слово Data не выражает ничего, оно просто говорит что внутри какой-то бессвязный белый шум из байтиков. Почему для определения типа выбрано слово struct? Почему не class?struct authorization_t - словом Authorization обозначают данные уже авторизовавшегося пользователя, которому уже присвоен идентификатор сессии. У тебя в этой структуре записаны поля, которые другими людьми оформляются в термин Authentication. Разница между этими терминами даже близко не позволяет один с другим сравнивать.const char* login = nullptr, *password = nullptr; - через запятую никогда не пишем. Каждое поле должно быть легко читаемо на своей отдельной строке. А вот таким определением полей через запятую ты ничего не добиваешься, кроме как только усложнения чтения кода. Правило 0 при написании кода - не создавать проблем для его чтения.const char* login - константностью данных управлять нужно не так. Именно объекты типа struct authorization_t должны наделяться свойством константности там, где это требуется. Состояние же этих объектов константным делать просто незачем.const char* login ... size_t login_sz - при инициализации по умолчанию поле } authorization; имеет неконсистентное и алогичное состояние. Более того, такой набор полей нельзя отнести к коду на языке C++. Эта структура написана на C. Весь набор полей нужно изменить на два поля с типом std::string если ты хочешь писать на C++.} authorization; - от кого ты прячешь этот код? Определение поля должно быть легко читаемым. Сейчас оно абсолютно нечитаемое. Чтобы найти это поле глазами, требуется много непозволительных для этого занятия усилий. И, опять же, это не Authorization, а Authentication. С моей т.з. такого поля в этом месте существовать вообще не должно.const char* mac = nullptr, *proc_id = nullptr, *mbios = nullptr;mbios - что это, акроним или именование в стиле СовКомПоМорДе (Советский Комитет По Морским Делам)? Такие имена невозможно прочитать, они не отражают смысла своего существования. Почему в authorization_t для полей с типом const char* есть семантическая пара size_t, а тут - нет? Все эти поля нужно заменить на std::string.в моем проекте практически все классы объявлены глобально. потому что вся программа в бесконечном цикле
Комбинаторика, теория вероятностей, графы, матрицы, дискретная оптимизация
могли бы расписать развернутый ответ на вопрос и предложить свой вариант как читабельнее и правильнее бы это выглядело
владел только той информацией, что - _t = typedef
_t является частью соглашения об именовании.#include может привести к увеличению времени трансляции до +20%. Т.н. "include guard"-ы [?] спокойно увеличивают время трансляции до +5..10%. Любая эвристика с логарифмической трудоемкостью в шаблонах и при обильном использовании приводит к увеличению времени трансляции до +8%.strcat_s(res, 100+strlen(sentense1), sentense1);.decltype в этом месте все в порядке.const char[N]. Т.е. после получения характеристики ODR-used и размещения в статической памяти это будет точно такой же статически выделенный массив константных символов.constexpr статически выделенного массива.Ради оптимизации на обычных строковых литералах (первый юнит-тест) я пошёл на неочевидную работу на константных буферах (второй юнит-тест).
str::concat("alpha\0\0", "bravo"sv)"alpha\0\0" и строковой литерал "bravo" с приведением его к std::string_view. Верно я ведь понимаю?str::concat(const_cast<const decltype (a)&>(a), b)a ты называешь константным буфером? Я правильно понимаю? on_message?