Basic RPN expression evaluator

Works perfectly!!! Got it within 2 tries...but had to put 'p' and 'm' for '+' and '-' respectively.....Any idea why '+' and ' - ' characters are not accepted by the program? TIA
If possible please compile the code and see if '+' and '-' do the job in your case..

Code:

#include<string>
#include<sstream>
#include<iostream>
#include<deque>
using namespace std;

int main()
{
    string input;
    getline(cin,input);
    deque<double> stack;
    istringstream in;
    in.str(input);
    double opn;
    char opt;
    for(;;)
    {
        if(in>>opn)
        {
            stack.push_back(opn);

            continue;
        }
        else
        {
            in.clear();
            if (in>>opt)
            {

            switch (opt)
            {
                case 'p':
                {
                    opn = stack.back();
                    stack.pop_back();
                    opn += stack.back();
                    stack.pop_back();
                    stack.push_back(opn);
                    break;
                }
                case 'm':
                {
                    opn = stack.back();
                    stack.pop_back();
                    opn=stack.back()-opn;
                    stack.pop_back();
                    stack.push_back(opn);
                    break;
                }
                case '*':
                {
                    opn = stack.back();
                    stack.pop_back();
                    opn *= stack.back();
                    stack.pop_back();
                    stack.push_back(opn);
                    break;
                }
                case '/':
                {
                    opn = stack.back();
                    stack.pop_back();
                    opn=stack.back() / opn;
                    stack.pop_back();
                    stack.push_back(opn);
                    break;
                }
                default: cout<<"sorry._ :( _.";


            }
            }
            else break;
        }

    }
    opn = stack.back();
    stack.pop_back();
    if(stack.empty())
    cout<<opn;
    else
    cout<<"More Operands than Operators";
    cin.get();
    return 0;

}

Also searching for a better way to implement the operator selection than the cumbersome switch-case which would grow in complexity with increase in operators .

Originally Posted by manasij7479

Also searching for a better way to implement the operator selection than the cumbersome switch-case which would grow in complexity with increase in operators .

It would not really grow in complexity (or become more complicated, if that is what you mean). It would just become longer, but that is not necessarily a problem. In fact, with what you have now, you can move this:

Code:

opn = stack.back();
stack.pop_back();

to before the switch and move this:

Code:

stack.pop_back();
stack.push_back(opn);

to after the switch. As for what I had in mind as an alternative: map strings to function pointers/objects. This way, if you want to add a new operation, you just modify the creation of the map, and add the definition of the function (or function object class).

After some unary operations or (implementations of a algebraic library ) are added, it could potentially become become more complex.
How would I fit things like "sin" or "log" inside the switch?
Is using goto a very bad idea for implementing the unary operators? (to jump over the 2nd pop_back statement)

Originally Posted by manasij7479

How would I fit things like "sin" or "log" inside the switch?

It is similiar to a unary operator.

Originally Posted by manasij7479

Is using goto a very bad idea for implementing the unary operators?

Yes, avoid goto.

Originally Posted by laserlight

...... and move this:

Code:

stack.pop_back();
stack.push_back(opn);

to after the switch.

just after that I've put

Code:

          stack.pop_back();
                if(in>>opt_s)
                {
                    if(opt_s=="sin")stack.push_back(sin(opn));
                }

for the similar unary functions...(.as the switch didn't accept them)
but it shows a segmentation fault at runtime.....Tried putting up cout 's to determine the source with no success...

As to why + and - are giving you fits: you are trying to read in a double. A double can start with + and with -, so those symbols are taken as the start of a double rather than falling through to the character parser. I would suggest this is why trying to read doubles-and-somethimes-characters vs. reading character at a time is a pretty bad idea.

Originally Posted by manasij7479

but it shows a segmentation fault at runtime.....Tried putting up cout 's to determine the source with no success...

Use a debugger.

I would suggest this is why trying to read doubles-and-somethimes-characters vs. reading character at a time is a pretty bad idea.

Then I have to put the character portion of the code before trying to play with the doubles...

Use a debugger.

I tried to put off learning to do so as long as possible...!..Would the Code::blocks debugger be a better option than the built in gnu debugger?

Originally Posted by manasij7479

I tried to put off learning to do so as long as possible...!..Would the Code::blocks debugger be a better option than the built in gnu debugger?

C::B has nothing of its own (no compiler, no debugger, no anything). If you have the gnu debugger, then you can use that. C::B has a front end for that debugger, but I've not used it much.

I thought the debugger was a standalone plugin of c::B unlike the compiler....!.........So, theoretically any any debugger would work well with it..
What is the most used debugger in a linux envionment ?

I'd say GDB - you most probably already have it, and it should work with C::B. I don't know what other debuggers does the C::B frontend support, to be honest.

As for what I had in mind as an alternative: map strings to function pointers/objects. This way, if you want to add a new operation, you just modify the creation of the map, and add the definition of the function (or function object class).

I concur. Actually, this is exactly what I did (well, it differed in implementation details, irrelevant at this point ).