What is optimal algorithm for switch case

[andre]

Also, have a look at "this":http://stackoverflow.com/questions/126409/ways-to-eliminate-switch-in-code discussion.

[qxoz]

[quote author="Andre" date="1321960751"]
[quote author="BilbonSacquet" date="1321959522"]I assume that 'val' is a type char, why not do 2 index tables and a string list:

@
int type_index[256] = { };
int state_index[256] = { };
QString messages[] = { "mode a", "mode b", "free", "busy", "not def" };

type = messages[type_index[val]]];
state = messages[state_index[val]]];
@

?[/quote]

Interesting solution,

[/quote]

Yes it is but unfortunately i have holes in sequence as said Volker.

[qxoz]

[quote author="rokemoon" date="1321961438"]Or like this:
@
SomeClass::SomeClass()
{
//here you cache needed types and states and associate them with value
//you can init in for example constructor of some class
QString modeA("mode a"), modeB("mode b");
QString stateFree("free"), stateNotDef("not def"), stateBusy("busy");
typedef QPair<QString, QString> type_state_t;
QMap<QChar, type_state_t > map;
map['0'] = type_state_t(modeA, stateFree);
map['1'] = type_state_t(modeA, stateBusy);
map['2'] = type_state_t(modeA, stateNotDef);
map['a'] = type_state_t(modeB, stateFree);
// and so on
}
@

@
void SomeFunc::setStateAndType(const QChar &val)
{
//here your new switch
QMap<QChar, type_state_t >::iterator it;
it = map.find(val);
if (it != map.end()) {
type = it.value().first;
state = it.value().second;
}
}
@
This code not tested, but I think the main idea you get.[/quote]

Nice, i like it. And what about code rate?

[andre]

What is "code rate"?

[qxoz]

[quote author="Andre" date="1321960502"]

Is this a speed-critical part of your code, for instance? How important is code size for you, if you weigh it against maintainability and against speed? [/quote]

Speed is more important, maintainability is next and then size.

[qxoz]

[quote author="Andre" date="1321966635"]What is "code rate"?[/quote]

Sory i translate by google :)

I mean code speed.

[andre]

In that case: you should probably stick to using a switch, or something that results in a switch like the macro-based version I showed you. Those will probably perform better than the alternatives, though only measurements can of course tell you in the end. Note that if there are differences in the frequency the cases occur, you need to at least sort the cases in that order (most occurring one at the top). "Some":http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm even suggest to split up the switch in multiple nested blocks. Not nice for readability, but perhaps better for speed (again: measure to be sure).

Edit:
Then again: realize that premature optimization is the root of many programming issues. Are you sure this is your time-critical bottleneck? How did you determine that?

[qxoz]

Program receive messages from devices and do some action with result of switch()
Yes it is maybe not so critical but i assume speed is more important.

[andre]

Never assume such things, especially if you are about to sacrifice maintainabiltiy of your code for it.

My first concern is to write code that I (and others) can read and understand later, and can modify if needed later on. Only when profiling shows that a section is time critical, I spend the effort to optimize the design of the code in that area.

[qxoz]

[quote author="Andre" date="1321968332"]Never assume such things, especially if you are about to sacrifice maintainabiltiy of your code for it.

My first concern is to write code that I (and others) can read and understand later, and can modify if needed later on. Only when profiling shows that a section is time critical, I spend the effort to optimize the design of the code in that area. [/quote]

You right. Thank you.
I think i'll use rokemoon's solution.
And thank you everybody for respond and advices

[giesbert]

So,

just some side notes:

switch / case results in a jump (which is fast)

The solution of BilbonSacquet with the arrays result in 3 index based array accesses, which should also be fast.

The solution of rokemoon with the QMap results in a binary search, which should not be too slow, but I assume it slower then the array based access (as it is a search).

But to know, whether that really affects your app and makes it significant slower depends, how often you use it. If it is called 100 times in an msec, it could affect it, if it is called due to user input, forget optimization here. The user is slower ;-)

[qxoz]

[quote author="Gerolf" date="1322037382"]So,

just some side notes:

switch / case results in a jump (which is fast)

The solution of BilbonSacquet with the arrays result in 3 index based array accesses, which should also be fast.

The solution of rokemoon with the QMap results in a binary search, which should not be too slow, but I assume it slower then the array based access (as it is a search).

But to know, whether that really affects your app and makes it significant slower depends, how often you use it. If it is called 100 times in an msec, it could affect it, if it is called due to user input, forget optimization here. The user is slower ;-)[/quote]

Thanks :)

And it's called maximum 10 times per sec.

[rokemoon]

@qxoz
So which solution will you use :-) ?
My question just for information.

[qxoz]

[quote author="rokemoon" date="1322046502"]@qxoz
So which solution will you use :-) ?
My question just for information.
[/quote]

I've already written an algorithm based on yours solution. ;)

[rokemoon]

[quote author="qxoz" date="1322046932"]
I've already written an algorithm based on yours solution. ;)[/quote]
I'm glad to hear it :-)

[giesbert]

[quote author="qxoz" date="1322045941"]And it's called maximum 10 times per sec.[/quote]

Don't care about speed optimization, care about maintainability then :-)

[qxoz]

[quote author="Gerolf" date="1322056043"][quote author="qxoz" date="1322045941"]And it's called maximum 10 times per sec.[/quote]

Don't care about speed optimization, care about maintainability then :-)
[/quote]

I will. Thank you.