Яко тебя помотало по миру языков программирования. Истинно, что для всего нужны свои тулы, и ООП не панацея от всего, но некоторые задачи, например, GUI хорошо ложатся на эту парадигму.
Вот например, есть у Гугла классный язык Go, и пишутся на нём хорошо бэки, но хочется и GUI, и мобилки, всё это, и изобретает Гугл ещё один язык - Dart. Казалось бы, пиши Flutter на таком классном языке Go, но нет, нужон ООП в полный рост!
Время вкатывания в Go ~ 2 недели, в Rust ~ от 2х месяцев и больше. В мысле, если вы на чём то ещё раньше программировали, а не просто на пианино играли.
Не раскрыта тема оптимизации компиляторами всех этих range конструкций. Часто в hot path не будут применять ranges, а заменят на циклы с сырыми указателями, или старый добрый STL algorithm, потому что такой компилятор хорошо оптимизирует. Дополнительные абстракции с range adaptor closures, т.е. когда можно через pine | писать, добавляет состояние, вызовы функций next(), и это не просто циклы с сырыми указателями (во что практически превращается шаблон std::transform например), и компилятор может не увидеть сквозь всё это, и не применить оптимизации.
В том то и дело - не понятно что профилируете, толи форматтер, толи конкатенатор, толи вообще аллокатор. Кому нужна скорость, каким-нибудь геймдевам, то за лишнюю аллокацию удавятся, хотя бы format_to(). Если руками не хочется писать преобразование числа в символы, то хотя бы std::to_chars.
Ещё забыли классику - char buf[1024] /* Должно хватить :-) */; snprintf(buf, sizeof(buf), ...; return std::string(buf). Можете добавить в бенчмарк для общей статистики?
std::format меделнный, потому что в runtime всё делает. Можете для эксперимента добавить вариант на популярной библиотеке {fmt} с compile-time выражением?
#include <fmt/format.h>
#include <fmt/compile.h>
std::string make_answer_fmt(std::string_view str_answer, int count) {
return fmt::format(FMT_COMPILE("The answer is {}, count is {}"), str_answer, count);
}
Можно я, например, Pool поревьюирую? Я понимаю, что это не полная реализация, но всё равно, мимо косяков пройти не могу.
Аллокация new uint8_t[count * sizeof(T)] будет гарантировать выравнивание по alignof(std::max_align_t). А что если я в T напихаю каких-нибудь __m256? В C++17 надо вот так написать new (std::align_val_t{alignof(T)}) uint8_t[count * sizeof(T)];
reinterpret_cast<FreeNode*> - классический UB. В старых C++ надо вот так new (node) FreeNode{m_free_list}; В C++23 уже вот так можно auto* node = std::start_lifetime_as<FreeNode>(m_buffer + i * sizeof(T));
Деструктор забыли, хотя это просто демо. Не забываем, что мы же выравненный new делали! ~Pool() { ::operator delete[](m_buffer, std::align_val_t{alignof(T)}); }
Говорят (за что купил за то и продаю), что тех, кто приезжает в гости на Родину, заводят в комнатку и несколько часов проводят беседы. Итого, чтобы продолжить свой путь обратно, надо написать статьи и/или выложить ютубы про загнивающий запад, как там всё плохо, и туда ехать не надо. Иначе, если не выполнить это требование, то пересечение границы закрывается.
Любой современный компилятор имеет "format string checking", например, в gcc/clang -Wformat, так что более-менее тоже type-safety. Кстати, когда вы пишете свой логгер, который принимает форматирование в формате printf, то следует обложить атрибутом __attribute__((format(printf, ...))), тогда компилятор и тут проверит аргументы и типы.
Яко тебя помотало по миру языков программирования. Истинно, что для всего нужны свои тулы, и ООП не панацея от всего, но некоторые задачи, например, GUI хорошо ложатся на эту парадигму.
Вот например, есть у Гугла классный язык Go, и пишутся на нём хорошо бэки, но хочется и GUI, и мобилки, всё это, и изобретает Гугл ещё один язык - Dart. Казалось бы, пиши Flutter на таком классном языке Go, но нет, нужон ООП в полный рост!
Время вкатывания в Go ~ 2 недели, в Rust ~ от 2х месяцев и больше. В мысле, если вы на чём то ещё раньше программировали, а не просто на пианино играли.
Почему в Go не как не завезут оператор '?' как в Rust? Не было бы такого бойлерплейта
было бы
Не понравился ваш стиль со слайдами в виде jpeg. Текст масштабируется в зависимости от моего экрана и размера шрифта, а ваши jpeg слайды нет.
Typo.
Не раскрыта тема оптимизации компиляторами всех этих range конструкций. Часто в hot path не будут применять ranges, а заменят на циклы с сырыми указателями, или старый добрый STL algorithm, потому что такой компилятор хорошо оптимизирует. Дополнительные абстракции с range adaptor closures, т.е. когда можно через pine | писать, добавляет состояние, вызовы функций next(), и это не просто циклы с сырыми указателями (во что практически превращается шаблон std::transform например), и компилятор может не увидеть сквозь всё это, и не применить оптимизации.
Так а как же она устроена то? C++ с Boost и STL? Всё, весь секрет обработки 47 миллионов инструментов в реалтайме?
В том то и дело - не понятно что профилируете, толи форматтер, толи конкатенатор, толи вообще аллокатор. Кому нужна скорость, каким-нибудь геймдевам, то за лишнюю аллокацию удавятся, хотя бы
format_to(). Если руками не хочется писать преобразование числа в символы, то хотя быstd::to_chars.Ещё забыли классику -
char buf[1024] /* Должно хватить :-) */; snprintf(buf, sizeof(buf), ...; return std::string(buf). Можете добавить в бенчмарк для общей статистики?std::formatмеделнный, потому что в runtime всё делает.Можете для эксперимента добавить вариант на популярной библиотеке {fmt} с compile-time выражением?
Я тоже так подумал - это про OpenCV как-то, чтобы на изображении что-то искать.
Можно я, например, Pool поревьюирую? Я понимаю, что это не полная реализация, но всё равно, мимо косяков пройти не могу.
Аллокация
new uint8_t[count * sizeof(T)]будет гарантировать выравнивание по alignof(std::max_align_t). А что если я в T напихаю каких-нибудь__m256?В C++17 надо вот так написать
new (std::align_val_t{alignof(T)}) uint8_t[count * sizeof(T)];reinterpret_cast<FreeNode*>- классический UB.В старых C++ надо вот так
new (node) FreeNode{m_free_list};В C++23 уже вот так можно
auto* node = std::start_lifetime_as<FreeNode>(m_buffer + i * sizeof(T));Деструктор забыли, хотя это просто демо. Не забываем, что мы же выравненный new делали!
~Pool() { ::operator delete[](m_buffer, std::align_val_t{alignof(T)}); }Говорят (за что купил за то и продаю), что тех, кто приезжает в гости на Родину, заводят в комнатку и несколько часов проводят беседы. Итого, чтобы продолжить свой путь обратно, надо написать статьи и/или выложить ютубы про загнивающий запад, как там всё плохо, и туда ехать не надо. Иначе, если не выполнить это требование, то пересечение границы закрывается.
Библиотека https://github.com/TartanLlama/expected позволяет использовать std:expected ещё с C++11, до официального появления в стандарте C++23.
Что же вы не указали, как с появлением концептов в C++20, SFINAE конструкции уже сильно устарели, и синтаксис концептов сильно лучше читаем.
Публикация должна была выйти первого апреля.
Надо было сразу просить написать на ассемблере, и без функций, без именования переменных, всё сплошником.
Возможно из за выбора ИИ моделей из не самых топовых. Как бы и на думающих дорогих моделях ИИ знатно косячит, но тут эталон бездарности.
Любой современный компилятор имеет "format string checking", например, в gcc/clang
-Wformat, так что более-менее тоже type-safety.Кстати, когда вы пишете свой логгер, который принимает форматирование в формате printf, то следует обложить атрибутом
__attribute__((format(printf, ...))), тогда компилятор и тут проверит аргументы и типы.Если передавать как ссылку, то и проверять на Nullptr не надо ;-)