Switch для строк в C++11

так что под CASE мы её всё равно не загоним

Легко, через escape-последовательности. Например:

ullong const h1 = str_hash("\x03\x01", 2);
ullong const h2 = str_hash("\x01\x01\x01", 3);

Кстати, о коллизиях — эти строки дают одинаковый хэш.

Вообще звучит очень правильно использовать функцию хеширования.

До пустим возьмем строку 'FIBONACI_STRING_REPLACE' ( ее размер 24 байта если это только MBC строка). Ее нужно сравнить с многими другими строками как например с 'MACLIACI_STRING_REPLACE' итд. Правда одно дело когда строк всего пару для сравнения, другое дело когда количество строк переваливает за 10 тысяч.

Куда проще будет вычислить Хешкод (в итоге у нас будет 4 байта для типа INT). И сравнить просто числа размером по 4 байта. у нас получится примерно 5 кратное увеличение производительности.

Господа как Вы думаете стоит ли перевести или написать статью про внутренности Хеш таблицы и про Хеширование ??
Мне сама это тема интересена так как я сечас работаю над оптимизацией кода в проекте связаного с хешированием и хеш таблицами!!!

конечно, понятно, что статья больше о constexpr и красоте кода, но для решения конкретной задачи лучше бы подошел perfect hash. А то ограничение на 10 символов как-то смущает.

Если хэши двух различных строк совпадут, то программа может перепрыгнуть со switch на ложную case-ветку.

Разве мы можем иметь пару одинаковых значений в switch? По стандарту вроде нет. Так что получим ошибку во время компиляции.

сравнение строк в рантайме — дорогостоящая операция, и проводить её для каждой строки из CASE слишком расточительно

Обычно «кейс по строкам» попадает в те 80% кода программы, которые вобще не влияют на производительность. Исключения невероятно редки, для них придуманы утилиты вроде gperf (подбирает совершенную хеш-функцию для заданного набора строк).

Afaik сделать такое не привлекая сторонних тулзов в процесс компиляции, даже в C++ последней ревизии, невозможно.

Похожий механизм есть в glib (хоть он и не имеет отношения к C++), называется GQuark. В glib есть что-то типа глобальной статической строковой коллекции, состоящей из массива и хэш-таблицы. При переводе строки в GQuark, если эта операция делается впервые, строка дописывается в массив, полученный индекс заносится в хеш-таблицу, и возвращается этот же индекс. Сам по себе GQuark просто является синонимом int. Повторная попытка приведения той же строки к GQuark приведёт к получению того же индекса. Обратная же операция сводится к получению элемента массива по индексу.

switch по ним не сделать, поскольку они не являются константами, но они позволяют минимизировать число операций сравнения строк, например, путём использования кварков в качестве ключей в ассоциативных массивах.

Посмотрите тут, как можно static_assert, заменив его на throw, перенести в constexpr функцию. Тогда можно обойтись без макросов:

case hash("string"):

Если MAX_LEN=10, то есть 70 бит, то как они могут упаковаться в 64 бита?

Важное замечание насчёт кодировок — Linux и Windows тут ни при чём, UTF-8 сейчас стандарт практически везде… кроме самого C++. Есть хорошее эмпирическое правило — не работать с юникодом в C++ без соответствующих библиотек вообще, слишком много подводных камней. Так что попытка скормить UTF-8 литерал куда попало абсолютно точно попадает под ошибочное использование.

Есть еще такая штука, как typeswitch, исходный код можно найти здесь. Правда эта библиотека делает немного другое, она позволяет осуществить диспетчеризацию по типам, вот пример использования:

int eval(const Expr& e)
{
    Match(e)
    {
        Case(const Value&  x) return x.value;
        Case(const Plus&   x) return eval(x.e1) + eval(x.e2);
        Case(const Minus&  x) return eval(x.e1) - eval(x.e2);
        Case(const Times&  y) return eval(y.e1) * eval(y.e2);
        Case(const Divide& z) return eval(z.e1) / eval(z.e2);
    }
    EndMatch
}

Или здесь

Причем сами авторы позиционируют данную библиотеку, как максимально быструю и эффективную.

Прежде всего — чтобы это был полноценный switch, а не его «эмуляция» путём скрытия if-операторов и функций для сравнения строк внутри макросов, поскольку сравнение строк в рантайме — дорогостоящая операция, и проводить её для каждой строки из CASE слишком расточительно.

Пройдусь по пунктам.

То, что это реальный switch/case это хорошо, но есть ряд нюансов.

switch стоит использовать не из-за удобства, а из-за быстродействия.

Ветвление со сравнениями (if) плохо влияет на быстродействие.

Правильный switch позволяет его избежать — давая на выходе простые джампы без сравнения.

Неправильный switch, например, для значения более одного байта с неизвестным набором значений имеет чуть больше чем все шансы стать набором того же множества операций ветвления со сравнением. Об этом много где написано. На вскидку ссылку не дам — помню по тем временам, когда я длительное время разрабатывал алгоритмы для задач high-load на C/C++ после изменения кода всегда изучая, что получается в машинном коде.

Использование хэша в риалтайме добавит еще больше ветвления и лишнего оверхеда — длинна строк, циклы и ветвление.

Кстати, ради интереса — смотрели, какой машинный код получается на выходе?

Когда строки заранее известны, то вместо хэша более быстрым может быть конечный автомат реализованный на том же switch, например (из старого кода):

/* Jan-Dec to 1-12 */
unsigned long time_parse_month(unsigned char *b)
{
	switch(*b)
	{
		case 'j':
		case 'J':
			if((b[1]=='a')||(b[1]=='A'))
			{
				return(1);
			}
			if((b[2]=='n')||(b[2]=='N'))
			{
				return(6);
			}
			return(7);
		case 'f':
		case 'F':
			return(2);
		case 'm':
		case 'M':
			if((b[2]=='r')||(b[2]=='R'))
			{
				return(3);
			}
			return(5);
		case 'a':
		case 'A':
			if((b[1]=='p')||(b[1]=='P'))
			{
				return(4);
			}
			return(8);
		case 's':
		case 'S':
			return(9);
		case 'o':
		case 'O':
			return(10);
		case 'n':
		case 'N':
			return(11);
		case 'd':
		case 'D':
			return(12);
		default:
			break;
	}
	return(0);
}

У нас это для парсинга логов использовалось — вариант с if внутри switch вышел быстрее на практике.