My sudoku program, any comments, improvements appreciated

Question

Hi all,
So I've been refining my amateur-ish programming skills for around a month, and have been writing a C++ program that solves sudoku. (My background is in physics.) I realize there are a lot of mathematical sides in sudoku, but I'm concentrating on the programming side and not too much on the math/brain side. Now the program is basically finished (I hope!) and I just thought the hackers here can have a look and see if there are any things I can improve.
The link is here: http://ifile.it/jkr56v8/Sudoku.tar
Basically, a sudoku is an instance of Board, an abstract base class with the pure abstract function Go(). Any concrete class derived from it is essentially a strategy. I think this design pattern is called strategy?
I've implemented two basic strategies, BruteForce and Priority. BruteForce does the good old sudoku brute force algorithm, which use trial-and-error from the top left box to the bottom right box all possibilitiies until the correct one is found. Priority does basically the same as BruteForce, except instead of trying from top left to bottom right, it plugs numbers in the box that has the most filled "associated" boxes.
To accommodate "composite strategies," I implemented the prototype pattern, so for example, I can write
void HyperBF::Go(void)
BruteForce::Go();
When a solution is found, I throw an exception to notify the main program, am I correct in that this is a clear and elegant use? Or is it a misuse and an alternative should be considered?
To actually choose a strategy, I created an abstract factory, a singleton. I'm aware there are all the advice out there that says don't use a singleton unless absolutely necessary? So, should I use a singleton in this case? Also, I think my implementation of the singleton leads to a bug, which is the only known bug: when I put a completed sudoku as input, it gives the output as usual, but gives a segmentation fault afterwards:
./Sudoku Puzzle/test_1_Basic.psv BruteForce | tail -n 12 | head -n9 | tee completed
|5|1|8|2|9|6|7|3|4|
|3|9|7|8|4|1|2|6|5|
|6|4|2|5|7|3|1|9|8|
|1|5|6|4|2|7|3|8|9|
|4|7|9|3|6|8|5|1|2|
|8|2|3|9|1|5|6|4|7|
|7|8|4|1|3|2|9|5|6|
|2|3|5|6|8|9|4|7|1|
|9|6|1|7|5|4|8|2|3|
./Sudoku completed BruteForce
Starting configuration:
|5|1|8|2|9|6|7|3|4|
|3|9|7|8|4|1|2|6|5|
|6|4|2|5|7|3|1|9|8|
|1|5|6|4|2|7|3|8|9|
|4|7|9|3|6|8|5|1|2|
|8|2|3|9|1|5|6|4|7|
|7|8|4|1|3|2|9|5|6|
|2|3|5|6|8|9|4|7|1|
|9|6|1|7|5|4|8|2|3|
Final configuration:
|5|1|8|2|9|6|7|3|4|
|3|9|7|8|4|1|2|6|5|
|6|4|2|5|7|3|1|9|8|
|1|5|6|4|2|7|3|8|9|
|4|7|9|3|6|8|5|1|2|
|8|2|3|9|1|5|6|4|7|
|7|8|4|1|3|2|9|5|6|
|2|3|5|6|8|9|4|7|1|
|9|6|1|7|5|4|8|2|3|
Number of attempts: 0.
Time elapsed: 0.00 s.
Segmentation fault
So what's wrong here?
Having implemented the basic functionalities, I tried to play around and gain some simple experience in some optimization. I looked at the Go() function and saw probably the expensive operation is IsConsistent(), so I optimized it by only checking the consistency of changed boxes. By doing so, I reduced the computational time to around 1/3 the original time. Is this the right move, or bad move, or are there better moves?
As a last question, I defined the number of attempts as a global variable. My reason is that, although it is possible to put it in class Board, I just think it doesn't "naturally belong" there, and putting it in a restricted scope would mean a lot of passing of parameters, slowing the program down unnecessarily. So, is this global variable fine?
Lastly, please have a look at my Makefile. This is the first Makefile I wrote, and it took me 3 solid days to get all the .o files in Release/ ! Are there things I've left out?
I realize the Generator is a joke, but at this moment I don't care too much about that, unless anyone has some good ideas.
Any comments would be greatly appreciated! Thanks in advance!

Answer 1

Grazz256 wrote:
Just looking over your code a little I have a couple of comments about your coding style. Please keep in mind that these are just comments...
I think you need to comment your code more. I know its a pain and I'm horrible about it as well but it really does help when/if you go back to read your code in a couple of years.
I try to avoid lines like these:
  fprintf( stdout, "Starting configuration:\n" ); a->Write(stdout);
  start = clock(); a->Go();
by putting two commands on one line it makes the code harder to read. with one command on each line I can quickly scan through and know
generally what each line does, with two I have to actually read each line fully so that I don't miss anything.
Descriptive variable names can also help with readability, I've always been taught the convention of using the first character to indicate type then
using a short descriptive name. For instance you have a function that returns a long value, the value would be decalred like this:
long lRetVal;
so looking through the code I would know thats a long value that represents a return value.
This is an area I'm all over the place with, I always try to stick to one convention but never seem manage it...
As far as your problem goes, where are the boards normally deleted? ie if an incomplete sudoku is inputed?
One possible solution is to run an IsComplete check before you start processing the board. so you would have...
if (a->IsConsistent()) {
if (a->IsComplete()) {
a->Go()
I'll be honest in that I don't really understand the flow of your code, but instead of having the board deleted within strategy or within win why not just delete it on the next line... eg:
start = clock(); a->Go();
delete a;
the downside to this approach is that you would have to delete it within each exception as well but this is relatively minor.
Cheers
Thanks for your comments. At my present level of programming skills, any comments will help.
I thought all my code was basically concise and self-explanatory, and each function is small enough that a quick skim through the definition and declaration would be enough to understand. As the project grew, however, things got slightly more complicated. I have added more comments in my source files, trying to comment why rather than how. I thought the flow of the code was fairly obvious though, by inspecting the main loop. It takes care of the input, bark if anything's wrong, trigger a.Go(), and try to catch a Win. Do you mean the flow within Go()? Anyway, it is very true I need clearer coding style.
Yeah I now solved the segfault problem. The reason a completed sudoku was deleted twice is because the original sudoku is meant to be deleted by the abstract factory, while the solved sudoku is meant to be deleted by Win. When a solved sudoku is inputted it would be deleted twice. Due to lack of programming experience, I failed to see the obvious way is to, as Grazz256 said, check in the beginning whether the inputted sudoku is already solved. If it is, then I duplicate the inputted sudoku and throw the win exception.
By the way, I think I'm beginning to understand why some people are obsessed wtih optimization. I did 3 optimization techniques in my program. First, I thought the most expensive procedure is the IsConsistent() method. By evaluating it lazily I reduced the time to 1/3 the original time. Then following http://www.acm.org/crossroads/xrds1-4/ovp.html, I used initialized the 2D vector within each sudoku via constructor rather than as statements. Doing so gave a 20% time boost. Using a friend procedure while copying sudokus boost another 5%. Doing a right move and getting positive feedback through better performance can be so satisfying.
EDIT:
I found out there was memory leak after all, which I finally solved.
What happens is with all my brute force algorithms I keep creating new Board's and call the Board's Go() recursively. To delete all Board's in the heap I need to have, within each Board::Go(), instead of
Board* a = Clone(); // return new derived Board(*this);
a->Put(x,y,'0'+k);
a->Go();
delete a; // if an exception is thrown this line never gets executed
this
Board* a = Clone();
a->Put(x,y,'0'+k);
try {a->Go(); }
catch( const Win& e) {
delete a;
throw(e);
delete a;
But this deletes the winning sudoku too. This means I have to keep the result in Win, either by duplicating the winning sudoku or storing the string. In the end I overloaded Board::Write(File* f) to also have Board::Write(std::string& p) to sprintf on the reference of a string, so Win just stores the solution in string format. Finally, no memory leak, no need to do a first check to see if the inputted sudoku is already solved, and no pointer deleted twice.
So in the end, to manage pointers I recursively threw exceptions. That made me ask, is using exceptions worth it, or should I stick to the more conventional methods, such as have Go() return a boolean value, then deleting pointers which would give an implementation that is essentially the same as recursive exceptions?
I still think exceptions is the way to go, the reasons being:
1) Exception mechanism provide a natural place to hold the result. Throwing exceptions recursively and the traditional way is essentially the same, but where should the result be stored in the latter case?
2) Arguing over the dictionary, an exception is not necessarily an "error." Winning is an exception in this algorithm, because failure is the norm (as in life).
3) Exception arguably gives better presentation in the main loop, to my "unbiased" eyes at least. Board* a->Go() is triggered in the try block in the main(), with all (foreseeable) possible results caught as exceptions. It is true that this might be a bit unconventional, but given proper comments I still think it is at least as good as the conventional way, in terms of presentation.
So what do you think?
Last edited by dumas (2009-12-21 12:37:47)