Developers and getting them to improve their code.

[George Staikos]

On Wednesday 08 January 2003 14:18, Benjamin Meyer wrote:

> A C++ optimization guide.  I have searched online and found many little one
> liner hints.  Some are obvious, but others aren't.  I really haven't found
> a common book/faq/website that has C++ optimizations.  This should really
> get top priority for there are many C++ tricks that even old C++ developers
> don't know about and most new C++ developers have never even thought about.
> Putting together a comprehensive listing and asking for feedback from the
> community is a good project that would pay for itself many times over.

   The most important thing is to write the code correctly first, then 
optimise second.  It really helps to be able to prove (contract, logic 
operations, etc) that the optimisation does not change the behaviour of the 
code too.  Sometimes it's not always obvious.  Optimisations are not always 
portable too.  KImgio had non-portable optimisations for instance.

   There are some very good books about optimisation available.

> Code bloat. Between Qt and KDE there are a number of classes that do the
> same thing such as far as the developer is concerned.  (Such as
> QSocket/KSocket). These classes confuse developers for they don't know what
> to write for.  Even having them have the same api (minus class name) is a
> good start.  Combining these classes [with the help of TrollTech] would not
> only reduce binary size of the libraries it would free up developers who
> are doing duplication of work of enhancing these classes.

   We do try to remove these classes as they are obsolete.  Sometimes are 
goals are not common though.  In particular, KSocket includes a lot of 
functionality that QSocket doesn't - built in socks handling, build in ipv6 
support, etc.

> I forget where I saw it, but there is a compiler that when compiling will
> spit out messages about code that is unessesary in release versions because
> they will bloat the binary's quite a bit.  ( Such as the assert() call ) so
> that developers can check to see if those calls are really needed and
> remove/change them.

   assert() should always be compiled out in release mode.  If that's not what 
the developer intended, then it should be an if() instead of an assert().

> uic last I checked (this may be wrong in 3.1) will generate extra code
> where it is not needed.  Making uic be a little smarter about how it
> generates its files wont improve much on the application scall, but overall
> it will do a bit of good.

   Code generators are notorious for producing the worst/most difficult to 
compile code.  It's always been that way.  This is an ongoing battle.  We 
still have releases of yacc afterall. :)

-- 

George Staikos