#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? Но если батарея сдохла, то разве ноут не должен был продолжить работу, так как он был подключен к сети?
Если все хорошо с ноутом и дело только в батарее, значит по идее если я сниму батарею, то ноут должен включиться разве не так?
Я также подозреваю что проблема в батарее, так как перед тем как он вырубился окончательно, сначала ноут вырубился просто так
Амперметром
Я проверил зарядное устройство и оно получает питание из розетки, но не передает его в ноутбук.
.h, а вот определение - уже в .cpp.template <class Container>
void print(const Container& c, string sep=" ", string end="\n")Print( const TStorage<TItem, TAllocator>& storage )Print( const TValue& value ) не вступает с ним в конфликт, т.к. является менее конкретным, т.е. более общим. Описанной тобой проблемы у меня нет.
map_typeи в каком именно коде при вызовеaddDataтранслятор выдает ошибку?