aux::tokenizer::token tk = m_tok.current_token();
if (is_command(tk))
{
if (std::strncmp(tk.ptr, "#PAGE_PLOT", tk.len) == 0)
{
parse_page_plot_cmd();
}
else
if (std::strncmp(tk.ptr, "#WELL", tk.len) == 0)
{
parse_well_cmd();
}
else
if (std::strncmp(tk.ptr, "#PWDW", tk.len) == 0)
{
parse_pwdw_cmd();
}
else
if ()
// . . .
// и дальше штук двадцать
и я вот думаю менять его или нет:
может заменить эту конструкцию на std::map
или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете.
а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Re: Чем заменить if () else if() else if() else if() else if
В самом деле, представляется неплохой идеей иметь map, в котором ключами являются строки, а значениями — указатели на функции.
Тогда вместо ифов получается очень элегантно:
the_map[tk.ptr]();
Не ГИС часом пишешь?
Да здравствует мыло душистое и веревка пушистая.
Re: Чем заменить if () else if() else if() else if() else if
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте,
K>имею такой код: K>
K> aux::tokenizer::token tk = m_tok.current_token();
K> if (is_command(tk))
K> {
K> if (std::strncmp(tk.ptr, "#PAGE_PLOT", tk.len) == 0)
K> {
K> parse_page_plot_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#WELL", tk.len) == 0)
K> {
K> parse_well_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#PWDW", tk.len) == 0)
K> {
K> parse_pwdw_cmd();
K> }
K> else
K> if ()
K> // . . .
K> // и дальше штук двадцать
K>
K>и я вот думаю менять его или нет: K>может заменить эту конструкцию на std::map K>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Здравствуйте, korzhik, Вы писали:
K>и я вот думаю менять его или нет: K>может заменить эту конструкцию на std::map K>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Почитай про паттерн state. Возможно, он тебе подойдет.
Re[2]: Чем заменить if () else if() else if() else if() else
Здравствуйте, Vamp, Вы писали:
V>В самом деле, представляется неплохой идеей иметь map, в котором ключами являются строки, а значениями — указатели на функции. V>Тогда вместо ифов получается очень элегантно:
V>
V>the_map[tk.ptr]();
V>
что элегантно это конечно хорошо, но карту(std::map) ещё заполнить надо:
получается конечно красивее, наверно так и переделаю, но меня больше в этом вопросе волнует скорость.
То есть сможет ли компилятор в случае if else if else... сам составить карту?
V>Не ГИС часом пишешь?
скажем так, дорабатываю
Re[2]: Чем заменить if () else if() else if() else if() else
korzhik wrote:
> Здравствуйте, > > имею такой код: >
> aux::tokenizer::token tk = m_tok.current_token();
>
> if (is_command(tk))
> {
> if (std::strncmp(tk.ptr, "#PAGE_PLOT", tk.len) == 0)
> {
> parse_page_plot_cmd();
> }
> else
> if (std::strncmp(tk.ptr, "#WELL", tk.len) == 0)
> {
> parse_well_cmd();
> }
> else
> if (std::strncmp(tk.ptr, "#PWDW", tk.len) == 0)
> {
> parse_pwdw_cmd();
> }
> else
> if ()
> // . . .
> // и дальше штук двадцать
>
> > и я вот думаю менять его или нет: > может заменить эту конструкцию на std::map > или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. > а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Надежды, я думаю, нет.
Если бы мне нужен был бы absolute raw perfomance, я бы посчитал хэши для твоих контсант ("#PAGE_PLOT", "#WELL"), подобрав такую хэш ф-цию, чтобы хэши по модулю N для всех констант были уникальными. Далее я бы использовал массив[N] указателей на ф-ции.
Здравствуйте, Vamp, Вы писали:
V>оффтоп. V>Ллойд пхнул минус тебе, ты ллойду. А разъяснить за что?
Он видимо пнул мне за то, что я ему пнул. Учили видимо в детстве стоять за себя.
Я поставил минус потому что считаю, что вариант, предложенный Lorenzo_LAMAS-ом обладает как плохой читаемостью, так и плохой сопровождаемостью. И при этом ни одним преимуществом перед первоначальным вариантом не обладает.
Re[4]: Чем заменить if () else if() else if() else if() else
Здравствуйте, Lloyd, Вы писали:
L>Я поставил минус потому что считаю, что вариант, предложенный Lorenzo_LAMAS-ом обладает как плохой читаемостью, так и плохой сопровождаемостью.
да он же пошутил.
Re[3]: Чем заменить if () else if() else if() else if() else
K>в этом случае я бы пользовался std::map, быстрее обработчик искать будет.
а где-то было сказано, что надо быстрее?
использование std::map -- это вопрос оптимизации.
я тоже могу придумать ситуацию, когда std::map() для такой задачи будет не лучшим вариантом.
Re[2]: Чем заменить if () else if() else if() else if() else
Здравствуйте, MaximE, Вы писали:
ME>Если бы мне нужен был бы absolute raw perfomance, я бы посчитал хэши для твоих контсант ("#PAGE_PLOT", "#WELL"), подобрав такую хэш ф-цию, чтобы хэши по модулю N для всех констант были уникальными. Далее я бы использовал массив[N] указателей на ф-ции.
хорошая мысль. Будет свободное время, может сделаю.
Re[3]: Чем заменить if () else if() else if() else if() else
K>что элегантно это конечно хорошо, но карту(std::map) ещё заполнить надо:
Естественно.
K>получается конечно красивее, наверно так и переделаю, но меня больше в этом вопросе волнует скорость. K>То есть сможет ли компилятор в случае if else if else... сам составить карту?
Не знаю. Я бы на это не особо рассчитывал. Если хочешь скорости — составь не карту, а хэш-таблицу. Обеспечишь вызов функции за константное время.
V>>Не ГИС часом пишешь? K>скажем так, дорабатываю
Похоже на парсер las-файлов. Сам когда-то этим занимался.
Да здравствует мыло душистое и веревка пушистая.
Re[4]: Чем заменить if () else if() else if() else if() else
Здравствуйте, IamLexa, Вы писали:
K>>в этом случае я бы пользовался std::map, быстрее обработчик искать будет.
IL>а где-то было сказано, что надо быстрее? IL>использование std::map -- это вопрос оптимизации.
правильно, вопрос оптимизации.
предложенный тобой вариант аналогичен использованию std::map, только std::map быстрее будет выполнять поиск.
Вот я тебе об этом и написал.
ЗЫ
Всё равно спасибо за участие в дискуссии.
Re[4]: Чем заменить if () else if() else if() else if() else
Здравствуйте, Vamp, Вы писали:
K>>То есть сможет ли компилятор в случае if else if else... сам составить карту? V>Не знаю. Я бы на это не особо рассчитывал. Если хочешь скорости — составь не карту, а хэш-таблицу. Обеспечишь вызов функции за константное время.
пока сделаю std::map,
будет время подумаю над хэш-функцией
V>>>Не ГИС часом пишешь? K>>скажем так, дорабатываю V>Похоже на парсер las-файлов. Сам когда-то этим занимался.
с las'ами я тоже работаю, но сейчас это не las, а внутренний формат.
Re: Чем заменить if () else if() else if() else if() else if
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте,
K>имею такой код: K>
K> aux::tokenizer::token tk = m_tok.current_token();
K> if (is_command(tk))
K> {
K> if (std::strncmp(tk.ptr, "#PAGE_PLOT", tk.len) == 0)
K> {
K> parse_page_plot_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#WELL", tk.len) == 0)
K> {
K> parse_well_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#PWDW", tk.len) == 0)
K> {
K> parse_pwdw_cmd();
K> }
K> else
K> if ()
K> // . . .
K> // и дальше штук двадцать
K>
K>и я вот думаю менять его или нет: K>может заменить эту конструкцию на std::map K>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Только хотел предложить решение с хешами, да вот заметил пост Макса... Действительное, самое хорошее решение с точки зрения производительности, значительно лучше мапа. В строчном мапе каждый раз прийдется делать сравнение строк, в случае хеша ты только раз хешируешь входную строку и делаешь разрешение индекса на указатель на функцию, значительно дешевле. А заполнять массив не обязательно каждый раз в конструкторе, этот массив можно сделать статическим, он по логике не связан с конкретным инстансом твоего парсера.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[2]: Чем заменить if () else if() else if() else if() else
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, korzhik, Вы писали:
K>>и я вот думаю менять его или нет: K>>может заменить эту конструкцию на std::map K>>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
L>Почитай про паттерн state. Возможно, он тебе подойдет.
а при чем здесь state, может быть command ?
Re: Чем заменить if () else if() else if() else if() else if
... K>и я вот думаю менять его или нет: K>может заменить эту конструкцию на std::map K>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Насколько я понял словарь фиксированный, тогда можно сделать для него ДКА (детерминированный конечный автомат). Если памяти не жалко, то можно сделать O(m), где m — длина конкретной строки, а не количество слов в словаре, т.е. очень быстро . Пример как делать ДКА
Здравствуйте, MaximE, Вы писали:
ME>korzhik wrote:
>> и я вот думаю менять его или нет: >> может заменить эту конструкцию на std::map >> или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. >> а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
ME>Надежды, я думаю, нет.
ME>Если бы мне нужен был бы absolute raw perfomance, я бы посчитал хэши для твоих контсант ("#PAGE_PLOT", "#WELL"), подобрав такую хэш ф-цию, чтобы хэши по модулю N для всех констант были уникальными. Далее я бы использовал массив[N] указателей на ф-ции.
Например, можно попробовать gperf, или подобный кодогенератор.
А можно попробовать symbols<void (*)()> из boost.spirit. В доках написано, что он основан на Ternary State Trees. Не надо будет генерировать код внешней утилитой и перфоманс должен быть хороший (я сам это не проверял).
Кстати, недавно Joel de Guzman написал письмо о том, что hash целых чисел быстрее чем switch. Есть надежна, что он это добавит в sririt.
Date: Thu, 05 Aug 2004 12:40:15 +0800
From: Joel de Guzman
Subject: [boost] Sparse tables and perfect hashing [ was: multidimensional
arrays (was Boost Mathematicians) ]
Larry Evans wrote:
>I'd be very interested. I'm thinking about using a sparse matrix >where T is symbol_set, where symbol_set is the set of terminal >and non-terminal symbols in a grammar. This could be used by >spirit in deriving LL(k) parser as described in: > > http://facweb.cs.depaul.edu/tchristopher/llkppr.pdf
Larry, I've recently experimented on perfect hashing (minimal
and non-minimal) where the input is a char or wchar_t or int.
What's interesting is that, based on my tests, I exceeded the
speed of C++'s switch-case.
I did a test on perfect hashing of integers and tested it against
a switch in a loop:
int test(int i)
{
switch (i)
{
case 1: return 0;
case 4: return 1;
case 9: return 2;
case 16: return 3;
case 25: return 4;
case 36: return 5;
case 49: return 6;
default: return -1;
}
}
vs. a corresponding perfect hash table. I got 6.6 secs (switch)
vs. 0.422 (perfect hash) secs on VC7.1. G++'s switch was faster
(i got 2.2) but still 4X slower than the perfect hash. The perfect
hash generation can be done at runtime using metaprogramming. I
based the algorithms on Bob Jenkin's perfact hash stuff:
int test(int i)
{
switch (i)
{
case 1: return 0;
case 4: return 1;
case 9: return 2;
case 16: return 3;
case 25: return 4;
case 36: return 5;
case 49: return 6;
case 88: return 7;
default: return -1;
}
}
int const n = 8;
int in[] = { 1,4,9,16,25,36,49,88 };
//1,4,6,0,3,7,2
int g;
typedef unsigned long ub4;
typedef unsigned char ub1;
ub1 tab[] = {
0, 2, 2, 7, 5, 0, 5, 0,};
/* The hash function */
ub4 phash(ub4 val)
{
ub4 a, b, rsl;
b = (val >> 3) & 0x7;
a = ((val << 31) >> 29);
rsl = (a^tab[b]);
return rsl;
}
int look[] = {0,0,0,0,0,0,0};
int
main()
{
{
boost::timer t;
for (int i = 0; i < 100000000; ++i)
{
g = test(in[i & 7]);
// if (g != i & 7)
// {
// std::cout << "switch error at:" << i << ", expected: " << (i & 7) << " got: " << g << std::endl;
// break;
// }
}
double el = t.elapsed();
std::cout << "switch took " << el << " seconds" << std::endl;
}
{
for (int i = 0; i < 8; ++i)
{
std::cout << i << ", " << in[i] << ", " << phash(in[i]) << std::endl;
look[phash(in[i])] = i;
}
std::cout << std::endl;
std::cout << std::endl;
for (int i = 0; i < 8; ++i)
{
std::cout << look[i] << std::endl;
}
std::cout << std::endl;
std::cout << std::endl;
boost::timer t;
for (int i = 0; i < 100000000; ++i)
{
g = look[phash(in[i & 7])];
// std::cout << i << ", " << in[i & 7] << ", " << g << std::endl;
// if (g != i % n)
// {
// std::cout << "phash error at:" << i << ", expected: " << (i & 7) << " got: " << g << std::endl;
// break;
// }
}
double el = t.elapsed();
std::cout << "phash took " << el << " seconds" << std::endl;
}
}
Re[3]: Чем заменить if () else if() else if() else if() else
вот почему я люблю постить сюда вопросы, потому что на простой вроде бы вопрос
получил множество различных вариантов, причём очень интересных.
Ещё раз всем спасибо.
Сейчас не имею возможности проанализировать все варианты.
Но в будущем постараюсь их рассмотреть.
Пока переделал на std::map:
код стал проще и красивее
время обработки файла уменьшилось (на ничтожно малую величину):
для 1000 обработки файла:
вариант с if else if else ... 0.734 s
вариант с std::map 0.720 s
Re[3]: Чем заменить if () else if() else if() else if() else
[]
> vs. a corresponding perfect hash table. I got 6.6 secs (switch) > vs. 0.422 (perfect hash) secs on VC7.1. G++'s switch was faster > (i got 2.2) but still 4X slower than the perfect hash. The perfect > hash generation can be done at runtime using metaprogramming. I > based the algorithms on Bob Jenkin's perfact hash stuff:
[]
Joel de Guzman — острейший перец
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 1.9 beta
Re[4]: Чем заменить if () else if() else if() else if() else
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте,
K>всем спасибо
K>вот почему я люблю постить сюда вопросы, потому что на простой вроде бы вопрос K>получил множество различных вариантов, причём очень интересных. K>Ещё раз всем спасибо. K>Сейчас не имею возможности проанализировать все варианты. K>Но в будущем постараюсь их рассмотреть. K>Пока переделал на std::map: K>код стал проще и красивее K>время обработки файла уменьшилось (на ничтожно малую величину): K>для 1000 обработки файла: K>вариант с if else if else ... 0.734 s K>вариант с std::map 0.720 s
Попробуй такой вариант, с самым простым хешем но на мапе, уверен что при большом размере мапа перформенс будет ощутимо отличаться.
Здравствуйте, Batiskaf, Вы писали:
B>Попробуй такой вариант, с самым простым хешем но на мапе, уверен что при большом размере мапа перформенс будет ощутимо отличаться.
спасибо.
размер карты 30.
Результаты для 1000 обработок файла:
вариант с if else if else ... 0.734 s
вариант с std::map<> 0.720 s
вариант Batiskaf'а 0.700 s
Re[3]: Чем заменить if () else if() else if() else if() else
K>вариант с if else if else ... 0.734 s K>вариант с std::map 0.720 s
Это значит, что твой if/else является даааалеко не самым узким местом
Ты бы попрофилировал сначала, что б знать что именно
надо оптимизировать для получения более ощутимого результата.
Re[3]: Чем заменить if () else if() else if() else if() else
Hi!
A>Кстати, недавно Joel de Guzman написал письмо о том, что hash целых чисел быстрее чем switch. Есть надежна, что он это добавит в sririt.
Я очень удивился результату, и пошел смотреть почему так.
Мда. Кэш проца рулит
1) функция со свитчем инлайнится только по __forceinline.
кстати, разница сразу _сильно_ сокращается.
2) суммарный объём кода варианта со свитчем ощутимо больше.
соответственно такая ошеломляющая скорость в общем то
результат отсутствия полезной нагрузки.
В общем-то в некоторых случаях это действительно может заролять.
Надо будет взять на заметку
Re[5]: Чем заменить if () else if() else if() else if() else
Здравствуйте, e-Xecutor, Вы писали:
EX>Здравствуйте, korzhik, Вы писали:
K>>вариант с if else if else ... 0.734 s K>>вариант с std::map 0.720 s
EX>Это значит, что твой if/else является даааалеко не самым узким местом EX>Ты бы попрофилировал сначала, что б знать что именно EX>надо оптимизировать для получения более ощутимого результата.
Не обязательно, может в первых ифах расположились наиболее часто вызываемые функции, вот и не вызывается часто strcmp, а поменяй очередность проверок может все станет иначе
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[5]: Чем заменить if () else if() else if() else if() else
Здравствуйте, e-Xecutor, Вы писали:
EX>Здравствуйте, korzhik, Вы писали:
K>>вариант с if else if else ... 0.734 s K>>вариант с std::map 0.720 s
EX>Это значит, что твой if/else является даааалеко не самым узким местом EX>Ты бы попрофилировал сначала, что б знать что именно EX>надо оптимизировать для получения более ощутимого результата.
согласен. оптимизировать ещё рано.
просто глянул я на два экрана ифелсовифелсов... и решил переделать.
Re[2]: Чем заменить if () else if() else if() else if() else
Здравствуйте, sergey_shandar, Вы писали:
_>Здравствуйте, korzhik, Вы писали:
_>... K>>и я вот думаю менять его или нет: K>>может заменить эту конструкцию на std::map K>>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
_>Насколько я понял словарь фиксированный, тогда можно сделать для него ДКА (детерминированный конечный автомат). Если памяти не жалко, то можно сделать O(m), где m — длина конкретной строки, а не количество слов в словаре, т.е. очень быстро . Пример как делать ДКА
.
_>PS. Но что то я не уверен что понадобяться все эти выверты, std::map наверняка хватит.
И еще, в дополнение... IMHO, если действительно нужно скорость (а не простота чтения программы). Обратим внимание прежде всего на вот этот кусок кода, а не на if(){} else if:
Здравствуйте, sergey_shandar, Вы писали:
_>Ёлки, это же токинайзер... так а че он токинайзит в строки? Пусть токинайзит в адреса функций . Т.е. ДКА рулит одназначно
Может быть, язык команд описан так, что имя команды — нетерминальный символ. И лексический парсер выполняет тупую работу, а распознавание команды — уже задача следующей ступени.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, sergey_shandar, Вы писали:
_>>Ёлки, это же токинайзер... так а че он токинайзит в строки? Пусть токинайзит в адреса функций . Т.е. ДКА рулит одназначно
К>Может быть, язык команд описан так, что имя команды — нетерминальный символ. И лексический парсер выполняет тупую работу, а распознавание команды — уже задача следующей ступени.
Согласен. Судя по всему так и сделано. Но если надо ускорять алгоритм, то это и есть узкое место, так как проверка символов происходит как минимум два раза (первый раз токинайзер, второй раз распазнование команды), с такой же скоростью можно в конце распознавания токена иметь не строку, а адрес функции (это все что я хотел сказать ).
Хочу поделиться своим скромным опытом (тоже ГИС )
В моей софтине похожая задача, использовал раньше map. Сейчас наверное буду переделывать (в частности под влиянием данного topic).
К>Во-первых, strncmp
Вот именно, что во-первых. Но только в другом смысле. Не знаю как на VC, но в BCB функция strncmp почему-то странно реализована. Короче говоря, когда я подменил strncmp на собственную тупую реализацию (простую strcmp написанную в виде for с break безо всяких оптимизаций и asm-ов), скорость parsing выросла раз в 10. Я прекрасно понимаю, что здесь дело не в strncmp, а скорее в стечении нескольких факторов. Тогда я разбираться не стал, очень торопился. А сейчас мне прямо стало интересно, почему тогда такой трюк сработал. Память что ли внутри strncmp выделялась динамически. Понятное дело, в VC такого не случилось бы, компилятор НЕкривой. В любом случае, std::strcmp можно попрофилировать.
К>
используется... Посмотрел я на дизассемблер этой протенькой строчки и ужаснулся. ПРАВДА У МЕНЯ ИСПОЛЬЗОВАЛСЯ ВРУЧНУЮ НАПИСАННЫЙ MAP. В этом, а также в особенностях BCB наверное всё дело. Однако, в любом случае, если бы было у меня поменьше this, и не было бы никакого ООП, то всё бы наверное работало бы побыстрей...
Понимаю, что лезу со свинным рылом в калашный ряд. У меня всё было сделано заумно, второпях, давно, когда был я ещё совсем маленький . К тому же в BCB. Однако, может всё мною сказанное будет кому-то полезно, а кому-то будет интересно прокомментировать мои глупые комментарии.
Re: Чем заменить if () else if() else if() else if() else if
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте,
K>имею такой код: K>
K> aux::tokenizer::token tk = m_tok.current_token();
K> if (is_command(tk))
K> {
K> if (std::strncmp(tk.ptr, "#PAGE_PLOT", tk.len) == 0)
K> {
K> parse_page_plot_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#WELL", tk.len) == 0)
K> {
K> parse_well_cmd();
K> }
K> else
K> if (std::strncmp(tk.ptr, "#PWDW", tk.len) == 0)
K> {
K> parse_pwdw_cmd();
K> }
K> else
K> if ()
K> // . . .
K> // и дальше штук двадцать
K>
K>и я вот думаю менять его или нет: K>может заменить эту конструкцию на std::map K>или ещё какой вариант, который вы мне здесь, я надеюсь, подскажете. K>а может оставить как есть, в надежде что компилятор сделает подобие map за меня?
Мне кажется, что самое быстрое (но и, конечно, самое сложное по реализации) решение — это закодировать распознающий конечный автомат для этих строк и читать посимвольно. Автомат можно закодировать следующим образом:
каждое состояние автомата представляется массивом из 256 элементов, где изначально все элементы установлены в нуль. Потом для переходов из текущего состояния в те элементы, которые соответствуют символам перехода (например, в элемент под номером 65 записывается номер состояния перехода по символу A, не помню что там, маленькое или большое). Работать будет бустрее не придумаешь. Вот пример для трех слов вверху:
#PAGE_PLOT
#WELL
#PWDW
первое состояние начальное, переход только по символу #, значит ставим переход в состояние 2 только для этого символа:
int state1[ 256 ] = {0};
state1[ '#' ] = 2;
второе состояние для символа 'P' в третье и для символа 'W' в другое, добавим позже.
int state2[ 256 ] = {0};
state2[ 'P' ] = 3;
после этого строим переходы из состояния 3, их два: по символам 'A' и 'W'.
Здравствуйте, mefrill, Вы писали:
M>Мне кажется, что самое быстрое (но и, конечно, самое сложное по реализации) решение — это закодировать распознающий конечный автомат для этих строк и читать посимвольно.
Здравствуйте, MaximE, Вы писали:
>я бы посчитал хэши для твоих контсант ("#PAGE_PLOT", "#WELL"), подобрав такую хэш ф-цию, чтобы хэши по модулю N для всех констант были уникальными.