Stylistic changes and documentation.

[Felix Salfelder]

Hi there.

We expect some movement in the develop branch in the next weeks, so
maybe this is a good time to revisit style and standard.

1) auto. While generally not a good idea (obfuscates code too quickly),
        there are use cases, where auto makes code faster to type, less
        redundant and helps avoid line breaks.

        auto ptr = new TYPE(args);
        auto ptr = some_case<NEW_TYPE*>(thing);
        
        especially in

        if(auto ptr = dynamic_cast<NEW_TYPE*>(thing)){
          [..]
        }

2) override. Functions intended to override others should be marked as
   such. This will improve readability as well as catch typos and type
        mismatch immediately.

3) delete. It is easier to delete unwanted defaults than implementing
   dummies.

        class C{
           // explicit C(){ unreachable(); } // note: may be ill formed.
           explicit C() = delete;
                [..]
        };

        As a side effect, this will produce errors at compile time, not at
        run time.

4) Private data members. In some (presumably old?) code they are at the
   top of the class.  I believe they should always be at the bottom. They
   are not very interesting or insightful when looking at the interface.

5) New code must apply to style rules. Trivial style Changes in existing
   code have to be be committed seperately. We should actually do this
   sooner than later esp. in regions where changes are expected.

Do you agree with these? There are proably more. Let me know, I will add
them to [1].

cheers
felix

[1] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:tech:style