Question about handling this

[lochnessmonster]

i recently asked a on a forum how to handle the problem if a user pushes onto a full stack or pops from an empty stack on how to handle this problem.....
my question is could anyone give a accurate example code of the first example he gave me below? i dont know how to ensure the user calls isFull or isEmpty before a call to push...i don't understand

Pushing to a fixed size stack with user responsibility:
User can only call Push if they've first called "IsFull" and got a return value of false. As long as the user does this, then Push can never fail.
Seeing as it's never meant to fail, simply add an assertion to check for failures.

Pushing to a fixed size stack without user responsibility:
Make push return a boolean value indicating success/failure.

[WaltP]

If you wish to use his solution, ask him. Otherwise, you
1) call the isFull() function.
2) if the stack is not full, return FALSE.
3) if the stack is full, return TRUE.
How you test for full is up to you since you design the stack itself.

There is no need for an assertion.

[mike_2000_17]

"with user responsibility" == "bad design"

Don't use that solution, it is bad, it violates coding standards, it is cumbersome to implement correctly, it is unmaintainable, etc. etc. Just don't do that.

The second solution is already a lot better, it's easy, safe, maintainable to some degree, and a very common way to do it.

The third solution is to throw exceptions if the stack is full (or popped empty), but, depending on the style/constraints already adopted by your project, it might be appropriate or not.

[template<>]

An alternative is to have the push return true/false...

template<int MAX_SIZE>
class Stack
{
public:
    Stack()
    :_count(0)
    {
    }
    bool push(int val)
    {
        if( _count < MAX_SIZE )
        {
            _array[_count++] = val;
            return true;
        }

        return false;
    }
private:
    int _count;
    int _array[MAX_SIZE];
};

[WaltP]

"with user responsibility" == "bad design"

Disagree -- based on the definition of the problem. User does not mean the person running the program. User means the programmer, and it is a very appropriate way to teach techniques.

The third solution is to throw exceptions if the stack is full (or popped empty), but, depending on the style/constraints already adopted by your project, it might be appropriate or not.

This is not a solution because throwing an exception by definition is a failure. The question, as I read it, is to prevent a failure.

[mike_2000_17]

@WaltP

>>Disagree -- based on the definition of the problem. User does not mean the person running the program. User means the programmer, and it is a very appropriate way to teach techniques.

Of course the user is not the person running the program, I never assumed it was. My assumption was that the user is the programmer which is using the class (or code in general) that you have written. And in this case, it is very reasonable to say that delegating responsibilities to the user is bad design. You say it is an "appropriate way to teach techniques"... ?!?!? Even if it was the case (and it is not), it would be a ridiculous thing to say. You don't write code such that you can teach the user about programming techniques! When you write library code, it's to be useful to whoever wants to use it. It's more productive and effective to write code that puts the least amount of responsibility on the user, simply because it reduces the amount of errors that the user could commit if he doesn't completely understand your library or is not aware of the implementation details. That's the whole point of encapsulation. You must assume that if it is possible for the user to mishandle your library, then a user might eventually do so, and thus, you need to make that either impossible or very difficult to do.

>>throwing an exception by definition is a failure.

Dude, you need to brush up on what exceptions are useful for. This case in question is exactly the kind of cases in which exceptions are useful. Exceptions are a mechanism to signal exceptional conditions that break away from the normal control flow. You might not like exceptions, personally, but that doesn't change what they are useful for. Your objections to them are not so relevant anyways since I have Herb Sutter, Bjarne Stroustrup and Andrei Alexandrescu on my side of the argument; they all have, through the years, made very strong and interesting arguments that promote the usage of exceptions (a few of which include: efficiency, separation of normal control-flow from error-handling, ease of propagation, and information content). In general, the only reason left to use error-codes instead is if you are stuck with it because of an old API that uses them (e.g. win32).

[WaltP]

Your analysis is perfect for a professional setting. But for an instructional setting, in order to understand all aspects of programming, you must learn how to do certain things that would not be good in a professional setting. Like writing your own strcmp() function, or testing whether a stack is full or not.

So Dude, brush up on what is needed in a school, not your job. Instructors do not teach all aspects of coding C++ immediately. It takes time. When you start learning stacks, queues, etc., chances are exceptions are still far in the future. And judging from the OP's post, he's not that far along or the question would not have stumped him. That's why the answer did, too. He's new.