std::map::find не может найти элемент

Я не большой знаток STL, но ты уверен, что он ищет именно строку, а не указатель?

Тебе нужен кастомный компаратор или std::string вместо char*.

Осталось показать что такое root_funcs а также реализацию данного класса - и дело в шляпе. Может там у тебя переопределен operator== на какой-нибудь лютый трешак, кто ж тебя знает?

std::map<const char*, func_proto> root_funcs;

аа. оно не умеет в указатели...

оно именно что умеет в указатели - и по адресам сравнивает. Временами полезно.

но не со строками.

Умеет, но нужно свой класс для сравнения передавать, у которого оператор == перегружен и делает грубо говоря strcmp. Но лучше string использовать и не выделываться. :)

ЧЯДНТ??

Код оформляешь как удак.

Только вот компаратор который мапе передается должен не == делать, а <

const cahr* - это не строка, идиот

Почему ты хочешь жрать говно, а не использовать std::string?

!strcmp(it->first,f->name.c_str())
ЧЯДНТ??

Это - НЕ С++. Когда же до вас до всех дойдет...

Таки да. А в unordered_map еще и класс реализующий хэшфункцию надо.

Когда же до вас до всех дойдет

В SSE4.2 есть инструкции для ускорения strcmp, и она используется в glibc. А в std::string::operator== сравнение, скорее всего, побайтное. Так что в случае одинаковых длин strcmp может и побыстрее будет. Надо сравнивать.

У GCC 5 в сравнении строк — цикл for. Основная часть берёт минимальную длину и проходится циклом по ней до первого несовпадения.

В SSE4.2 есть инструкции для ускорения strcmp, и она используется в glibc.

Феерическое дермище. Я не знаю в какой там вселенной они «ускоряют» strcmp, но в этой явно нет.

А в std::string::operator== сравнение, скорее всего, побайтное.

Если его писали идиоты - возможно. А так - отличная история:

static int
      compare(const char_type* __s1, const char_type* __s2, size_t __n)
      {
	if (__n == 0)
	  return 0;
	return __builtin_memcmp(__s1, __s2, __n);
      }

memcmp быстрее, чем pcmp_str_-днище, есличё.

Раз ты такой уверенный, бенчмарки с тебя.

в std::string::operator== сравнение, скорее всего, побайтное ... У GCC 5 в сравнении строк — цикл for.

Это полная чушь. В gcc stl традиционно все возможные байтовые операции выполняются через build-in аналоги libc'шных функций которые при необходимости разворачиваются libc'шные вызовы.

Насколько это знание «свежее»? Ты сейчас проверил или просто где-то прочитал?

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

#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
char * gen_string(uint64_t n) {
  return memset(calloc(1, n + 1), 's', n);
}

#include <time.h>

double get_time_s(void) {
  struct timespec t;
  clock_gettime(CLOCK_REALTIME, &t);
  return (t.tv_nsec / 1e9) + t.tv_sec;
}

#define bench(data_len, n, f, ...) ({\
  volatile __auto_type i = (n);\
  double start = get_time_s();\
  do { (void)f(__VA_ARGS__); } while(--i);\
  double time = get_time_s() - start;\
  fprintf(stderr, "%s(%lu): %.3fGB/s\n", # f, data_len / n, ((data_len / time) / 1024 / 1024 / 1024));\
})


inline void __memcmp(char * a, char * b, uint64_t len) {
  asm volatile ("movq %0, %%rdi\nmovq %1, %%rsi\nmovq %2, %%rdx\ncall memcmp" :: "g"(a), "g"(b), "g"(len): "rdi", "rsi", "rdx", "rax");
}

inline void __strcmp(char * a, char * b) {
  asm volatile ("movq %0, %%rdi\nmovq %1, %%rsi\ncall strcmp" :: "g"(a), "g"(b) : "rdi", "rsi", "rax");
}

int main(void) {
  uint64_t block = 2, data_len = 1024 * 1024 * 1024, n;
  do {
    n = data_len / block;
    char * a = gen_string(block), * b = gen_string(block);
    bench(data_len, n, __memcmp, a, b, block);
    bench(data_len, n, __strcmp, a, b);
    free(a);free(b);
  } while((block *= 2) != (1 << 20));

}

Конечно работать оно не должно, но должно работать.

__memcmp(2): 0.649GB/s
__strcmp(2): 0.812GB/s
__memcmp(4): 1.444GB/s
__strcmp(4): 1.624GB/s
__memcmp(8): 2.599GB/s
__strcmp(8): 3.249GB/s
__memcmp(16): 5.198GB/s
__strcmp(16): 3.465GB/s
__memcmp(32): 9.449GB/s
__strcmp(32): 6.929GB/s
__memcmp(64): 15.984GB/s
__strcmp(64): 6.926GB/s
__memcmp(128): 18.888GB/s
__strcmp(128): 11.537GB/s
__memcmp(256): 23.767GB/s
__strcmp(256): 16.621GB/s
__memcmp(512): 29.181GB/s
__strcmp(512): 21.319GB/s
__memcmp(1024): 35.349GB/s
__strcmp(1024): 24.830GB/s
__memcmp(2048): 38.267GB/s
__strcmp(2048): 25.859GB/s
__memcmp(4096): 39.061GB/s
__strcmp(4096): 26.468GB/s
__memcmp(8192): 41.442GB/s
__strcmp(8192): 27.001GB/s
__memcmp(16384): 41.364GB/s
__strcmp(16384): 26.757GB/s
__memcmp(32768): 31.827GB/s
__strcmp(32768): 22.072GB/s
__memcmp(65536): 32.041GB/s
__strcmp(65536): 22.103GB/s
__memcmp(131072): 30.774GB/s
__strcmp(131072): 18.850GB/s
__memcmp(262144): 24.577GB/s
__strcmp(262144): 18.690GB/s
__memcmp(524288): 20.564GB/s
__strcmp(524288): 18.749GB/s

Я тебе выше выкатил то, во что разворачивается оператор== в стринге.

А как у вас объявлен root_funcs? Очень похоже на std::map<const char*, SomeType>

Конечно работать оно не должно, но должно работать.

Ты о чем вообще? Вы счас сами разговаривали про реализацию строки в STL, а сам даешь код чистых сях.

Я в специализацию char_traits для _CharT смотрел, оказывается.

Вы счас сами разговаривали про реализацию строки в STL

Я выкатил выше пруфец того, что реализация сравнения строк разворачивается в __builtin_memcmp, а __builtin_memcmp в memcmp из glibc - я их и сравниваю.

а сам даешь код чистых сях

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

Я выкатил то, что должно бенчить strcmp и memcmp - оно это делает. В реальности ты получишь те же результаты, только внутри своего кода. Ну можешь ещё померить не чётные длинны.

В конечном итоге видно, что memcmp быстрее, как я и говорил. strcmp имеет меньшую летенси, ибо там memcmp писали гении лсной мысли.