Re: [9fans] c++

[Bakul Shah <bakul@bitblocks.com>]

On Nov 19, 2012, at 2:48 PM, steve wrote:

> so far i have written a couple of hundred lines of c++, but for me the problem
> i see is how to develop a sense of c++ style.  I want to write good code, but I
> don't even know what good c++ code looks like!

Look at something like OpenSceneGraph. Looks to be pretty
decent code.  Look at Russ's RE2 code. Look at code for varius
data structures (but *not* the boost library or templates).

But I think the only way to develop good intuition is to write
code.  Lots of it!

IMHO, for a competent C programmer it is not hard to pick up
C++ and continue using a spare style.  Basically use C++
features only as needed.  Data structures map fairly naturally
to objects (and hence classes) -- but just build in what you
need.  Rather than write your own implementation of linked
list, doubly linked list, priority queue etc. it may make
sense to use relevant templates. If you have more than one
related class, it may make sense to factor out the common
interface in a separate base class. If it is an interface,
functions will either be virtual or depend on virtual
functions. Deep hierarchies are another thing needing very
strong justification -- they are worse than a chain of #define
macros.

It is probably a good idea to get in the habit of writing test
classes right at the outset. Often you can write the test
class exercising the interface of a class even before you
implement this interface!  This forces you to look at the API
from a user perspective early on and you are less afraid to
experiment as you can quickly test. If your program gets used
a lot, over time you will end up wanting to replace classes
for better performance or changes in usage.

I used the "gang of four" book (desing patterns) in mid 90s
and experimented with it but I haven't even opened the book in
last decade. There are lots of useful patterns in there but as
always one must justify use of every new pattern. Some
patterns are powerful but make the code very hard to read.
A few months ago I rewrote one such program on a challenge. It
was so hard to follow I ended up just looking at its input and
output and reimplementing from scratch.

And profile your code! One should avoid optimizations that 
makes the code uglier but keeping an eye on performance helps
find stupid bugs and hotspots early on when things are not so
complicated.

So that is a long way of saying just dive in and trust your
judegment!

> 
> i will press on with it, and read the pointers that have been suggested.
> 
> thanks again.
> 
> -Steve
> 
> ps i am studiously not reading anything about go in case it distracts me... :-)

Go too considered harmful?