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?
