memcmp вместо strncmp для оптимизации?

БЕЗ объявления переменной выполнять сравнение набора байт любой длины?

Чавой? Как это должно работать?

как то же работают(компилируются) варианты memcmp(msg, "\xFF\xD8\xFF", 3) и memcmp(msg, std::array<uint8_t,3>({0xFF, 0xD8, 0xFF}).data(), 3)

Ну я переменную вижу, а как без переменной?

Вариант с «\xFF\xD8\xFF» намного читаемее огорода с std::array.

И вообще штуки вроде временный_контейнер().data() внутри аргументов функции это антипаттерн, так как в более сложном случае можно легко получить use-after-free из-за преждевременного удаления временного контейнера

Можешь объяснить, чего ОП хочет именно? Чтобы не было литерала строки?

хочу что то вроде memcmp(msg, {0xFF, 0xD8, 0xFF}, 3)

memcmp(msg, {{0xFF, 0xD8, 0xFF}}, 3)?

Upd: туплю, тип-то восьмибитный должен быть. Так что лучше строкой.

Вот так можно: uint8_t[3]{0xFF, 0xD8, 0xFF}

:)

1
error: expected primary-expression before ‘[’ token
  if (memcmp(msg, uint8_t[3]{0xFF, 0xD8, 0xFF}, 3) == 0)

2
error: expected primary-expression before ‘[’ token
  if (memcmp(msg, uint8_t[]{0xFF, 0xD8, 0xFF}, 3) == 0)

3
: warning: ISO C++ forbids compound-literals [-Wpedantic]
  if (memcmp(msg, ((uint8_t[3]){0xFF, 0xD8, 0xFF}), 3) == 0)
                                                ^
.cpp:299:31: error: taking address of temporary array
  if (memcmp(msg, ((uint8_t[3]){0xFF, 0xD8, 0xFF}), 3) == 0)
                  ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

Можешь объяснить, чего ОП хочет именно? Чтобы не было литерала строки?

Да я сам не понимаю. Возможно, ОП думает, что строковый литерал является внутри не тупым массивом char, а чем-то ещё.

ну как минимум там 1 байт лишний добавляется же

А ну вот, не разрешают брать адрес временного массива, и правильно делают. Объявляй константу отдельно.

Обалдеть какие накладные расходы

) ну интересно просто, почему строку можно, а ничего другого нет

Строковый литерал является const char*. Если добавить const, то код выше наверное скомпилируется. Но это нечитаемый трэш.

Тебе бы глянуть, как эльф скомпонован. Эта шиза с приведением анонимного массива вообще не в тему.

Я тебе больше скажу - твои три чара влезают в один u64, вог бы просто их все запихать туда и сравнивать без отдельной функции.

наверное скомпилируется

нет )

ну 3 чара это просто частный случай, так то да можно записать в переменную и сравнить с константой

Тебе бы глянуть, как эльф скомпонован.

Литералы и прочие константы времени компиляции идут в .rodata, и могут не выравниваться. Теоретически, если у него таких массивов много, то эти концевые нули могут во что-то сложиться, и rodata в памяти займёт на одну страницу больше, а это уже целых 4K.

Техническотеоретически да, но он очевидно ловит мб несколько типов файлов топс.

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

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

Если это действительно сранвение литералов в цикле по очереди, то можно даже какой-нибудь re2c задействовать (или gperf), чтобы в один проход сматчить.

Или писать участок на асме луше поможет.

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

Если что, std::copy дает такой же результат по времени, что и std::memcpy()

https://stackoverflow.com/questions/4707012/is-it-better-to-use-stdmemcpy-or-stdcopy-in-terms-to-performance

Тут memcmp, а не memcpy

std::string_view?

твои три чара влезают в один u64, вог бы просто их все запихать туда и сравнивать без отдельной функции.

Я почти уверен, что ты с 1 раза корректный код для описанного приёма не напишешь. А он тем более.

весь «парсинг заголовка сообщения»

Я правильно понял, что ты не полагаясь на разбор сообщения своим сервером напрямую парсишь сообщеньки?

мне нужно сравнить байты а не строки

Так может тебе и надо сравнить байты а не массивы?

Объяви свой user-defined literal, создающий const char[] без концевого нуля

https://en.cppreference.com/w/cpp/language/user_literal

сервер mqtt не разбирает сообщения, я могу только разделить по веткам, но их уже и так столько, что начинает сложно вспоминать кто куда подписан должен быть и что куда приходит, сервис так вообще подписан по маске на топик(-и).

если смотреть на количество видов сообщений, то больше просто строк, просто количество каких пересылается не оценивал, очевидно в размере больше jpeg, от которых проверяю только первые 3 байта штатного заголовка.

да спасибо, уже начал читать про литералы

могу только разделить по веткам, но их уже и так столько, что начинает сложно вспоминать кто куда подписан должен быть и что куда приходит, сервис так вообще подписан по маске на топик(-и)

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

У меня такое ощущение, что ты пытаешься изучать плюсы по советам из интернета, как-будто это какой-то питон. Плюсы такое не любят и жестоко за это наказывают, причём месть может оказаться сильно отложенной. Так что советую найти опытного коллегу, который будет ревьюить весь твой код. Или писать на более простом языке.

Врёти, могу. Пруфов не будет, я балабол.

Без единого UB? Я лично не рискнул бы на такое спорить)

А в чём UB? 0, сложил, сдвинул, сложил, сдвинул, сложил. И всё, своего рода детерминант готов.

Твои сдвиги сломаются на big-endian архитектуре, так что первая попытка не удалась и ты проиграл.

Мне запомнилось, что сдвиг это самая подлая операция по части ub

А можно объяснить? Вот хочу всё знать!

Да, гогнокод, оно ещё и без компилятора не соберётся!

А вообще, автор, не беспокойся, компилятор оптимизирует этот memcmp и никакого лишнего нуля там не будет, да и вообще этот литерал он в виде строки никуда не сохранит

https://godbolt.org/z/hdGWfPnhs

Преждевременная оптимизация

https://godbolt.org/z/vEP8facjc

Компилятор заменил вызов strncmp на команду сравнения с константой

что то сомнительна его производительность

Практика главный критерий истины. У тебя профайлер отобрали? Руки отнялись?

Это разница которая видна лишь в коде, а не в итоговом файле. Что с переменной, что без нее, нужно выделить место под массив который будет передан в memcmp.

Разница в том что со строкой этот массив будет из 4 байт, а с массивом - из 3. Впрочем как уже выше показано, на современном компиляторе массива вообще не будет, как и memcmp-а.

) формально конечно картинка приходит в другой топик сейчас, но все топики все равно валятся в одного слушателя в один калбечный вызов - т.е. все равно шо так «парсить», шо эдак сравнивать топики.

) в целях ликбеза все таки чисто теоретически - memcmp быстрее strncmp?

С этим не спорю, я отвечаю на вопрос в начальном посте. И массив и строку можно передать как с объявлением переменной, так и без.

memcmp не нужно проверять ноль, поэтому он должен быть немного лучше.

Ах жеш, черт слепой. Виноват.