Developers and getting them to improve their code.

[Benjamin Meyer]

On Wednesday 08 January 2003 2:44 pm, George Staikos wrote:
> On Wednesday 08 January 2003 14:18, Benjamin Meyer wrote:
> > A C++ optimization guide.  I have searched online and found many litt=
le
> > one liner hints.  Some are obvious, but others aren't.  I really have=
n't
> > found a common book/faq/website that has C++ optimizations.  This sho=
uld
> > 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 ev=
en
> > thought about. Putting together a comprehensive listing and asking fo=
r
> > feedback from the community is a good project that would pay for itse=
lf
> > 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 al=
ways
> portable too.  KImgio had non-portable optimisations for instance.

I agree.  I am talking about adding const where it was forgotten, removin=
g=20
empty deconstructors, changing the order of items in a class to match up=20
better with use, using refrences in function headers where you forget. =20
Little things like that which add up.

>    There are some very good books about optimisation available.

And at the end of this list we could list some books that people have=20
recomended.  P.S. I looked a few months ago, but found mostly C optimizat=
ion=20
books.  Do you know of a C++ book that you recomend?

> > 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 kno=
w
> > what to write for.  Even having them have the same api (minus class n=
ame)
> > 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 class=
es.
>
>    We do try to remove these classes as they are obsolete.  Sometimes a=
re
> 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.

Glad to hear.  Anyone want to put together a list of the current over lap=
ping=20
classses?

> > 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 asse=
rt()
> > 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 n=
ot
> what the developer intended, then it should be an if() instead of an
> assert().

That was simply my example.  There was many more.

-Benjamin Meyer