Yeah, an operator has precedence, but that precedence is not unique, so looping through the operators by precedence is not enough. You would need to map a precedence value to multiple operators. An array of vectors would probably be the best choice.
However, I doubt this is the best way to evaluate an expression, because you can have parenthesis, which can force lower priority operators to be evaluated first.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
You absolutely can iterate through an unordered_map. unordered_map by definition uses a forward iterator.Originally Posted by manasij7479
I'm just assigning the values manually now.
As for parentheses, when they occour within an expression..other than being an holder for function arguments, I'd splice the list from the opening to the close, evaluating the resulting list as an independent expression, then substituting the list with that result token.
Didn't know...
I(thought that I) read in the Wikipedia article about associative data structures that it wasn't possible to iterate through hash tables.
Going back to that article, I found that there was a term "efficiently" present too. So, I think I'd be fine if I do it once in the whole program.
Last edited by manasij7479; 08-23-2011 at 09:45 PM.
I'd much rather you try out unordered_map in this specific instance rather than letting your preconceived notions dominate your choices.
Would do so.
To anyone who sees this after this post:
I was, by ignorance, unnecessarily trying to replicate(sort of) the task accomplished by the objects in <functional> which I found out(in detail) just now.
The objects in functional are for passing around operators as functions. That doesn't solve your problem of mapping strings to operators. And they may be inferior to a home brewed solution because you may want to store additional information with the function, such as the precedence.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I think I'll design a solution based on inheriting those objects(from the unary_function or binary_function if the others are too restrictive) if the home brewed ideas can't be translated into code nicely .
In that way I'd be mix the good from both and hopefully avoid possible pitfalls .
The implementations of those functions are trivial. They are only there to make it easy to pass operators to standard library algorithms. If your problem is more complex than that, I would not use them.
For instance, the functions in functional are all templates take two like typed operands. You seem to be writing an interpreter. Unless the language interpreted is like Lua, which only has one arithmetic type, then a container of those function objects isn't going to do it for you.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Ok ..then I'm going to design how my Operators are going to work, almost from scratch, because my current design which wasn't done carefully is quite messy.
That's why it's usually a bad idea to jump strait into coding. Design first, code later. It is not unusual for design to take the greater part of the project time. Between that and debugging, time spend coding can be quite small.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Well, the design(here) took place when I was bored during a particularly uncomfortable train journey.
I'm quite sorry now that I did not take the time to express it on paper with diagrams and such.
