stack underflow issue

I am writing an N-queens problem using stacks in C. I am only doing boards of size 4 thru 8. I initially had my prog displaying the first solution for boards of those sizes, however, i needed it to display all solutions. When i finally got it to display all solutions, it would get to the first non-solution and instead of jumping out would print the non-solution over and over until i ^C to get out. So it is not doing that any more but now i am popping an empty stack somewhere in my program. I'm pretty sure which function it is and I think I need to add code, not change something i already have, but i have been racking my brain all night and getting nothing. Is there anyone who can help me. I think i am probalby missing one line of code here somewhere but can't figure out what it is. This is my fillBoard function (I thinkthat is where i'm missing something ):

Code:

void FillBoard(STACK *currSolution, STACK *lastSolution, int BoardSize)
{

  int row;
  int col;
  int board[9][9] = {{0}};  /*0 no queens: 1 queen*/

  ELEMENT *place;
  place = (ELEMENT *)malloc(sizeof(ELEMENT));



  if(emptyStack(lastSolution))
  {
    row = 0;
    col = -1;
  }
  else
  {
    while(!emptyStack(lastSolution))
    {
      pop(lastSolution, place);
      push(currSolution, *place);
      board[place->row][place->col] = 1;
      row = place->row;
      col = place->col;
    }
    pop(currSolution, place);
    board[row][col] = 0;

    if( col == BoardSize )
    {
      pop(currSolution, place);
      row = place->row;
      col = place->col;
      board[row][col] = 0;
    }
  }

  while(row < BoardSize)
  {
     while(col < BoardSize && row < BoardSize)
     {
       col++;

       if(!guarded(board, row, col, BoardSize))
       {
         board[row][col] = 1;

         place->row = row;
         place->col = col;

         push(currSolution, *place);

         row++;
         col = -1;
       }
       while(col >= BoardSize - 1)
       {
          pop(currSolution,place);
          row = place->row;
          col = place->col;
          board[row][col] = 0;
       }
     }
  }
  free(place);
  return;
}

First of all, this code doesn't adhere to the K&R bible. So, I don't think you'll get much help here. I'd try posting on the C++ board even though it's essentially C code.

The code that you posted doesn't help a whole lot because I have no idea what type of processing is being done prior to calling the function. But I did notice that there are 4 pops and 2 pushes. Thus, 2 too many pops which will definitely cause a stack underflow. I would such you use try... catch statements. This way you'll be able to catch any thrown exceptions such as a stack underflow. They're great debugging tools.

Have you considered running the code thru a source level debugger? They're great for a problem like this.

Good luck

Bob

Looks like C to me, but you the OP hasn't posted the full program, so we don't know the types of ELEMENT/STACK, or the prototypes of pop/push.

First of all, I have to apologize here. It was late last night and I made the mistake of assuming you were using the push and pop from the C++ std library. In retrospect, this is plain C code.

But for fear of violating any standards, you can still use the try catch statements and catch your exception. I wish to empahsize that this approach is NOT an ANSI C standard approach

Bob

I realized after i posted that function that it was difficult to tell everthing i was doing without the rest of the program. it turned out that i had two mistakes, first in the fillBoard function I made my board array a 9X9, it should have been an 8X8, so i was actually incrementing my board by one, everytime i called my guarded function and thus had board filled correctly in FillBoard, but guarded was looking at it incorrectly. It took about 2 hours for me to figure this out. I am unfamiliar with debuggers and my school does not teach their use at all, there philosophy on them is that they are for lazy poeple. This is a direct quote from one of the heads of the department. Anyway, a friend in class does use debuggers, as she is self taught programmer, who has already written many programs herself before she started school. And with her help, using debugger, we were able to find out about the declaration issue. So thanks for taking the time and making comments.

carmen

camo,

You're instructor is absolutely right. Debuggers should never be used for learning the language. You really don't learn anything by using a debugger.

Debuggers serve their purpose when you're working on a large project, let's say 100,000 lines of code. In this scenario, they minimize the grief of finding a "needle in the haystack" problem.

Good luck on your school project,


Bob, a lazy kind of guy

Wow, I must be lazy then. I can't understand why you wouldn't want to use a debugger while learning a programming language! I use my debugger frequently even on projects with less than 2500 lines.

place = (ELEMENT *)malloc(sizeof(ELEMENT));

In C you should not cast the return of malloc. If you return to me and say "But the compiler complains when I don't have the cast" I will retort with "Then compile it as C and not C++".

I am unfamiliar with debuggers and my school does not teach their use at all, there philosophy on them is that they are for lazy poeple. This is a direct quote from one of the heads of the department.

Correction: debuggers are for smart people.
Example: Recently I was helping a tutee with thier assembly program. The problem was that it wasn't displaying any output. After looking over their code nothing jumped out at me. It was only by putting a break right before it was suppose to do the output and looking at the values at certain locations was I able to determine why it wasn't outputting anything. From there I knew where to to look at the code and found the problem.

Debuggers are a major asset to your coding. They help you find all kinds of errors, memory leaks, etc. Don't use it at your own risk. Your school 'head' of dept needs to get their 'head' screwed on tighter. Not using a debugger is for lazy people. To assume that you can create errorless code the first time through is completely insane.

I wonder how this 'head' debugs MFC code when Windows comes back with it's so non-informative dialog box stating your program got hosed. You could write exception handlers for sure, but I still don't think that would catch everything.

And using the debugger in DirectX code is absolutely 100% necessary. In debug mode DirectX spits out all kinds of nice things at you when you have created a memory leak and/or a COM resource leak.


Now I've pretty much heard everything. Note to self: Don't attend the schools mentioned on cprog.

>You're instructor is absolutely right. Debuggers should never be used
>for learning the language. You really don't learn anything by using a debugger.
You might not learn anything, but people who actually realize that they're human and can make mistakes will discover that a debugger is useful for learning as well.

>Debuggers serve their purpose when you're working on a large project, let's say 100,000 lines of code.
I use a debugger for as little as 1 line of code because it's an incredibly valuable tool. Anyone who thinks so little of a debugger clearly isn't a very experienced programmer.

>Bob, a lazy kind of guy
There are two kinds of lazy. The first kind is productive, where you work harder now so that you can work less later. The second kind is unproductive and stupid, where you cut corners and ignore your tools in favor of a slacker's approach.

so half of the programmers worldwide shouldnt use debuggers?

>so half of the programmers worldwide shouldnt use debuggers?
How did you come about that conclusion? Judging from how many people have no idea how to fix their own problems, you're probably right, but I'd like to hear your reasoning.

I thought my school was bad been even they tell me to use a debugger (coming from a school who tells me to use fflush(stdin), void main, casting malloc, etc).

Laziness can often be a virtue in a programmer - sometimes it makes the difference between someone who will manually copy and paste many lines of code and change one value per line, and someone else who thinks "there must be a better way" and learns about loops. :P

Maybe I just like Unix too much, but honestly, I see nothing wrong with minimising your effort as a programmer, so long as you don't do so in stupid ways (like not commenting your code, or making your variable names so short no one knows what they mean).

Debuggers are a valuable tool and should be a part of learning how to program, especially in a language like C where you can have all sorts of difficult to track down memory bugs. Compare, for instance, peppering your code with printf's to find where a segmentation fault is, to simply typing 'where' in gdb. A coder's time can be better spent than typing up printf statements unecessarily.

If your instructor objects to debuggers, maybe you should ask them if they code in assembler. After all, high-level languages are just to make life easy for the programmer. Or better yet, machine code - assembler is just mnemonics to help programmer's remember things more easily. That sort of argument can be endless and, while sometimes entertaining, ultimately pointless.

Use the right tool for the job. Debuggers are a good tool for their job, so why on earth wouldn't you use them?