Member Discussions

I was just thinking.. when does it become more useful to use if() over switch()? I was thinking this in relation to strings though. See, we have one command which has the potential to take 140 separate arguments and return an individual statement. Now, I can either write 139 else if statements, or I can use a
switch(char_of_argument[0]) {
case 'a': switch(char_of_argument[1]) {
case 'a': // If there was a possible 'aa' argument
Now, which is better, meaning more efficient and more code-alytically correct? I understand the switch statements would definitly sort things out better(and prettier :P) in the code, but both would eventually give out the same output, yes? And given the switches, you'd only need to go to the third letter at most. So there'd only be a total of two inside switches for 140 items. It may involve more coding and more work, but overall(with personal time aside), which is better?

The switch would be more efficient, but your compiler will likely turn your big block of ifs into the same structure as a switch anyhow [optimizations are nice like that] so it doesn't generally make a difference. I would suggest throwing all 140 arguments in a table and match them with their statements. Then in the code, scan through the arguments until you find a match and use its statement. A nice, easy way to do this in C++ is the map class...map MyArguments. return (*MyArguments.find(input)).second;

Kelson

> return (*MyArguments.find(input)).second;

Or even:

return MyArguments[input];

*Scratches head* So it honest to god doesn't matter anyway? (Between switch and if?)

From what I know, it can matter, but most of the time it won't.

The compiler should be smart enough to apply the optimization to your long list of if statements, especially with modern compilers. However, if something weird happened it might give you the unoptimized code.

This isn't a big deal unless you are really trying to get that last bit of performance out of some frequently used code (you are clearly already aware of this). In that case I would examine .asm file to see if my code is being optimized correctly. That is the only way to be sure after all.

I prefer to use the switch when I care enough, to make it more apparent to myself when I look back on the code.

(Comment added by cDalem on Tue Oct 5 15:17:15 2004)

By more apparent I was referring to the effort I decided was necessary. I realized that my statement was unclear.

If you're really concerned about efficiency, write one test program that makes a couple million runs through some if statements, and an identical program with a select in place of the ifs. Run them a couple of times and compare their average runtimes.

> *Scratches head* So it honest to god doesn't matter anyway?
> (Between switch and if?)

Nope, doesn't matter. They're both the wrong tool for what you want to do. Here's what you want to do:

> See, we have one command which has the potential to take 140
> separate arguments and return an individual statement.

Kelson's suggestion was pretty much spot on. You need to build a table of some sort (out of C++ maps or the Diku plain old arrays of structs) and stop thinking about such hideousness as 139 if else statements. If you're inexperienced, you should follow the model that your mud uses for command input and apply it to this complex command, with different functions to cover the various arguments that are selected.

Thanks for the reply, I hadn't even known about that option. I only ran into maps a couple months ago and I've been using them pretty often lately; the only thing I've been disliking is the verbosity of a command along the lines of what I had written above...this is much nicer. Thank you :)

However, now I have a question. I was reading through my nice C++ referance book and it says that MyArguments[input] would insert input into the map if it did not exist there, but what value would it assume...the default for whatever was paired with that key? And, if it did so, how would you know it hadn't been in there...or should one have some 'invalid' default value to ensure that doesn't happen?

Kelson

> I was reading through my nice C++ referance book and it says
> that MyArguments[input] would insert input into the map if
> it did not exist there, but what value would it assume...the
> default for whatever was paired with that key?

Yup. I really really hate that too, by the way. It essentially makes it so if your key is unknown, you shouldn't ever use operator[]. For user input that pretty much regulates you to the find() method. I just assumed that you had a known key in your little snippet because you immediately dereferenced the value that you found.

IMO the invalid value should be a constructor argument or a public property that defaults to the default for constructor for that type, so you could tell it to return things like "(null)" or just "" without actually inserting the value into the map. The current design with side effects is stupid.

That is horrible...why would they do that?

Kelson

There was a committee involved.

.

Yui:

IMO the invalid value should be a constructor argument or a public property that defaults to the default for constructor for that type, so you could tell it to return things like '(null)' or just '' without actually inserting the value into the map. The current design with side effects is stupid.

Kelson:

That is horrible...why would they do that?

It is hardly horrible, it is just the way the language must go. operator [] returns a reference, and non-const references aren't allowed to hold rvalues. operator [] must create an lvalue; otherwise, it wouldn't work.

For a map, you just need to make sure the type you are using has a suitable default constructor for your needs. You maybe could get by with something like this:

template<typename T>
class Wrapper; //intentionally undefined

//specialize:
template<>
class Wrapper<std::string> {
private:
  std::string _val;
public:
  Wrapper() : _val('(null)') { }

  operator std::string( void ) const { return _val; }
};

I think you get what I mean (even if this code wouldn't work as well as you would like).

(Comment added by Razzer_9 on Tue Oct 5 22:24:53 2004)

Whereas an rvalue would be an aribtary, default object (like a string("")) that would be temporary.

This came up before

> It is hardly horrible, it is just the way the language must
> go.

I don't see a distinction: The end result is still stupid =).

I know! Maybe we could inherit from std::map and override the default behavior with polymorphism! That way I wouldn't have to make a ridiculous wrapper that reflects everything with a HAS_A relationship to a private std::map. Oh wait. Can't do that either.

(Comment added by unifex on Wed Oct 6 5:53:10 2004)

> operator [] returns a reference, and non-const references
> aren't allowed to hold rvalues. operator [] must create an
> lvalue; otherwise, it wouldn't work.

That's fine with me. We don't want the default constructed anew each time, we can simply store what we set. That would allow us to implement a missing object pattern with a singleton reference.

A switch statement is usually a sign that you've done something wrong. A 140 case switch statement is a sure sign that you've left this world and moved on to a better place.

Oh yeah, I saw one once. Not pretty. 6,000 lines long, it was.

Arrays (and even associative arrays like our best friend std::map) are the way forward.

Use a trie!


http://www.ascendantmud.net/ascendant/downloads/DTrie.h

A switch statement may be ugly, but for some speed-critical applications (not MUDs) they're the way to go. Compilers will (generally) optimize switch statements into lookup tables and JMP instructions. For example, in a VM, a function call to run five lines of code is a huge waste.

Although, 6000 lines for 140 cases does indicate some level of insanity.

I don't see a distinction: The end result is still stupid =).

Well, I don't see you sumbitting a solution to the Committee. :P

We don't want the default constructed anew each time, we can simply store what we set. That would allow us to implement a missing object pattern with a singleton reference.

Unforetuneately, that wouldn't work. It would be fine it everyone would just use non-pointer/reference types, but for pointers and references it would be a problem. What if the map was destructed before the pointer/reference holding the default value was destructed?

The better solution (which has been proposed) is to add an at function like the one in std::vector. The best solution would maybe be redesign map and/or the language, but I doubt that will happen anytime soon.

> Well, I don't see you sumbitting a solution to the
> Committee. :P

Yeah, I'm too busy working around all of C and C++'s quirks =).

>> We don't want the default constructed anew each time, we
>> can simply store what we set. That would allow us to
>> implement a missing object pattern with a singleton
>> reference.
>
> Unforetuneately, that wouldn't work. It would be fine it
> everyone would just use non-pointer/reference types, but for
> pointers and references it would be a problem. What if the
> map was destructed before the pointer/reference holding the
> default value was destructed?

The map shouldn't be responsible for the destruction of an object you give it, unless you're giving it value types in which case scoping in general is responsible for its destruction. I don't see a problem with destruction issues at all.

> The better solution (which has been proposed) is to add an
> at function like the one in std::vector.

Nah, vector::at throws exceptions which makes it quite a bit more work in many scenarios. The whole point is to help me work less, not more!

> The best solution would maybe be redesign map and/or the
> language, but I doubt that will happen anytime soon.

Agreed.

I say we form a committee. hehe :P

[Thyrr]
> A switch statement may be ugly, but for some speed-critical
> applications (not MUDs) they're the way to go.

Speed-critical applications, embedded software in particular, can feel free to break any rule in any way. Most software doesn't have such tight constraints, so we can afford to write in an understandable, maintainable way.

[Unifex]
> > We don't want the default constructed anew each time, we
> > can simply store what we set. That would allow us to
> > implement a missing object pattern with a singleton
> > reference.

[Razzer_9]
> Unforetuneately, that wouldn't work. It would be fine it
> everyone would just use non-pointer/reference types, but for
> pointers and references it would be a problem. What if the
> map was destructed before the pointer/reference holding the
> default value was destructed?

boost::shared_ptr<> is your friend.