SEclone program layout

The program is  developed using the Visual C++ 2010 express IDE.

The general layout is in line with the standards of a new project in that IDE.


For a command line application, there is one main file assembling all data.

The structure of that file is the following

#include "stdafx.h"           //system includes and most general datas and includes

#include "h\_00_  assSE.h"    //declarations files for the program


#include "c\_00_  Batch_Start.cpp" // main routine initial and command line parsing

#include "c\_00_  Batch_Go.cpp"    // main routine processing puzzles


//============================<<main file


int main(array<System::String ^> ^args)

{if(Batch_Start(args))    Batch_Go();

 return 0;}


//=============== general data 



/=========================general routines (now obsoletes in visual C++ or « quasi datas »)

char * stpcpy(char * d, char * o)

{strcpy_s(d,strlen(o)+2,o); return (d+strlen(d));}


char * Blancs(int n,int pastrait)

 {static char wt[]="___________________ ",

              wn[]="                    ";

              if(pastrait)return &wn[20-n]; else return &wt[20-n];}




Here a list of includes of cpp detailed files


The file "stdafx.h" should not change significantly from now on. It is given here below.


The code is located in sub directories .

The 2 directories for the first aprt of the program are


/h for .h files

/c for .cpp files.


Other subdirectories are  open called


/h1 /c1  for the standard chains

/h2 /c2  for more complex chains


The program does not use at all precompiled headers (no true need, the program is not that big).


Consequently, I entered as much code as possible within the .h files. The consequence is that the assembly order of the .h file must be strictly controlled; This is done in the assembly routine h\_00_  assSE.h



The main routine is quite simple, calling


a subroutine handling all tasks to achieve before processing puzzles

a routine processing the input file.


The rest of that block is divided in 2 sections:


Data not included in .h files (few of them at the start of  h\_00_  assSE.h)


And finally, in any order, the .cpp detailed files.



// stdafx.h :  standards  Include files and basic classes


typedef unsigned short int  USHORT;

typedef unsigned int UINT;

typedef unsigned long ULONG;

typedef unsigned char UCHAR;


#include <math.h>

#include <sys/timeb.h>

#include <time.h>   // s_posit 

#include <fstream>

#include <iostream>

#include < stdio.h >

#include < stdlib.h >

#include < vcclr.h >

#include <string.h>

#include "stdafx.h"

using namespace System;

using namespace std;



Processing the input file.


There is no freedom in the way to organize the process for one puzzle.

The eliminations assignments have to follow the rating scale of SE.


To activate filters defined in the command line,


. a general routine must be called at the start of  each step,

. another one has to be called at the end of the step if an elimination has been found.



Moreover, ass soon as we reach the chains, The rating must be adjusted depending on the chain length, so, a table of chains (or nice loops) found with the lowest rating is kept as long as the next step has not an equivalent minimum rating.


If the waiting list has a rating below the highest ER already found, then the list is processed immediately.

Here is a typical step (looking for XYWings) in the process


           o$.Step(XYWing); if(o$.ir>1)return 0; else if(o$.ir)continue;

           if(zpaires.XYWing()){o$.SetEr();continue;}  //4.2



0$ is the class (only one member) storing and managing options of the command line.


  Store the rating level (difficulty) and ask for a status toward options.

  Return 0 if the process goes on

  Return 1 if the step must be skipped

  Return 2 if we have passed the limit for ER



  Search for an XYWing elimination

  Return 0 nothing found,

  Return 1 an elimination has been found



  Is the option setting or results in case an elimination has been found.

  A return code should be studied to get the earliest stop thru filters.


  The process can update the difficulty posted above.



In the chain area, the process seems to be the same, but is in fact slightly different.

It could be that the chain process should be extended to the full scope.


In the chain process, a table (class TCHAIN, one member tchain) stores all chains having the minimum found rating with the following data :



CHAIN_POINT cp[30]; // buffer eliminations (limited to 30)

USHORT ncp,         //number of candidates to clean

            Base          // rating

      urem,        // milestone of the explanation

            tag;          // tag cleared or first tag of a loop 


In that list, base if the rating found, but is in redundant with the class data base. “urem” and “tag” are there to help in debugging, so the only important data is the table of potential eliminations cp[30] ; ncp



On request, the status of the table is analyzed and action is done if conditions are there.


Splitting the file and setting the final rating


At the end of the process, in o$ (class OPSUDO), 


If the process was ok till the end, the rating appears in “output 1”


If any other condition occurs, the puzzles is written in “output 2” with appropriate values for ER/EP/ED.


(see the description of OPSUDO)


Debugging a puzzle


Debugging is an option of the command line ( -t ) so the program can deliver some prints.


Prints are made in “output 1”. The printing process is derived from my solver where the “no print” option maintains a computation of the length of the print.


Elementary prints are made thru specific calls to the output file (no use of the “<<“ operator).

As “no print” is the default option, some filters have been added in the code to skip important prints.


The typical shunt is


If (o$.ot)  {…. Print code   … }


Another debugging tool can be used with constants op0=0 and op1=1.

This is used to activate/de activate temporarily some code avoiding messages during compilation..