Re: Squid 3 build error using Visual Studio

> 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
Received on Tue Aug 14 2007 - 18:50:57 MDT