====== CK 2006-10-31 ======

I don't know what tmb meant with "1.*" in the ocr-binarize-sauvola/REVIEW
but I will do it like <svnRevision>.lineNumber:

General:
  * I still argue for the JavaDoc style when documenting a detailed description
    in code because I find it more readable and @param, @see and @return
    is quite useful - I mean, you don't HAVE to use them but I would like
    to be ABLE to use them (http://www.stack.nl/~dimitri/doxygen/docblocks.html)
     /**
      * 'detailed' in-code description
      */

     ///
     /// 'detailed' in-code description
     ///
  * should use unsigned types wherever we expect unsigned values to avoid misuse
  * we should talk again about spaces: The following examples are listed with
    increasing readability, at least in my opinion.
    for(int i=0;i<=n;i++)
    for(int i=0; i<=n; i++)
    for(int i=0; i <= n; i++)
    for(int i = 0; i <= n; i++)

===== narray.h =====

16.56: should we have a central CHECK with message parameter and only executed
        if not compiled with UNSAFE?
16.83-90: why are the fields of narray all public? It would be better to hide them
        from external access.
16.85,88,90: unsigned, private
16.95: all unsigned. shouldn't this method be private?
16.101: parameters unsigned. private?
16.103: the check should be one line above, before the actual dims are assigned
16.109: parameters unsigned. private?
16.127,133,139,145: parameters unsigned
16.157: allocated should also be set to null
16.168: parameters unsigned.
16.171: call dealloc() here or at least check if(data) before delete [] data.
16.181,188,204,211,219,228,238: parameters unsigned
16.246-249: parameters unsigned
16.253,259,265,271: parameters unsigned
16.287: return unsigned
16.293,300: parameter unsigned
16.309: the dimensions are not adapted to evtl. newly allocated memory! I cannot
        think of an elegant way to do this for any possible rank of narray.
        The comment says the same. Should this maybe be also only for 1D Arrays?
        Or should this method be publicly available at all?
16.356: what is this method for? pushing a new element which is set afterwards?
16.384: why not reuse operator()(int)?
16.446-448: should return bool true and false instead of 1 and 0
16.481-482: reuse samedims()?
16.491: shouldn't the narray be filled with a value of the type that it
        actually holds?

====== Ilya 2006-11-02 ======

Now that indexers have `const' specifiers, we can freely change items of a const array.
I think the solution might look like this:

        T &operator()(int i0) {
            check(dims[1]==0,"narray: bad rank");
            check_range(i0,dims[0]);
            return data[i0];
        }
        const T &operator()(int i0) const {
            check(dims[1]==0,"narray: bad rank");
            check_range(i0,dims[0]);
            return data[i0];
        }

===== narray.h =====

18.170              probably if(ntotal>allocated)?
(everywhere)        can we have lots of `inline' modifiers?
18.211,219,228,236  I suggest that operators() would use unsafe_at() to avoid duplication of formulas.
18.423-eof          add `const' modifiers?
