> On tis, 2007-08-14 at 14:10 +0300, Tsantilas Christos wrote: > >> The major problem you may have is that c++ compilers some times return >> error messages which looks completely unrelated with the real problem. > > Or quite related but where it's impossible to grok what is related or > how... > > http://www.henriknordstrom.net/code/loreley_warning.html > >> (I had similar problem today morning trying to understand what the hell >> means the "undefined reference to vtable for .....") > > My experience: Missing object file implementing the class, only having > header references. But if I hadn't known already that the vtable is what > the object internal table of virtual methods is called I would not have > understood that error much at all.. > >> But I think as someones learns the compilers and tools which his is >> using these problems disappeared .... > > And then the tools gets upgraded and you have to learn new errors.. > > The problem with C++ compared to C is complexity. C++ is a fairly > complex language with many levels of abstraction and a lot of "hidden > magics" which needs to be understood apart from the syntax itself. This > makes a very steep learningcurve when trying to understand existing > code. > > Tools like doxygen helps a lot to decipher unknown code. Without them > reading and understanding complex C++ code is a nightmare. > > But this is also where the powers of C++ lies. The abstraction levels do > allows for clean code to be done easier than in for example C. > > The Squid-3 code is currently a bit messy with 4-5 differen generations > of coding style. But gradually things do get cleaned up. And I am also > looking forward to the docs project getting merged which is a > significant step along that path imho.
:-) Thanks. Even if it was your idea in the first place. Guido (or anyone); if you want to use the docs project to understand any code its public at http://squid.treenet.co.nz/Doc/Code/ Two notes though for now: - there is presently some breakage caused by those semi-colon-free macros: " void orphan() {} MACRO(x) void fooBarInvisible() { orphan(); } " - MACRO will screw up so docs will not include fooBarInvisible() and details for orphan() will say its never referenced. So for the present, unless a function has a docs comment or is linked from the module page directly it needs checking for use manually. Overall though its good now for a quick check of inheritance details and what belongs where. Amos