just to add to what others have said, it's easier to write code using
C++ features that are applicable to the task at hand, than it is to
read and understand a random piece of C++ code. keep in mind that
writing code will eventually lead to using STL and other libraries; so
you'll be forced to read complex code and decipher what the compiler
thinks it says.
but, allow me to get on the soapbox :)
starting a new system in C++ today would need justification. if you
need language features that C doesn't have, then the next logical step
is Go (or Python) because it take a lot less time to master it than to
master C++. Proof of Go's expressiveness and ease of use is the huge
number of packages that have been developed in it -- only three years
after its first release. another bonus, it is available on Plan 9.
-Skip
On Tue, Nov 20, 2012 at 11:05 AM, Bakul Shah <***@bitblocks.com> wrote:
> 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?
>
>