glib dependancy in KDE3.x

[Maks Orlovich]

>     -> no virtual functions

This seems to be detrimental to the ABI stability to me, by making it harder 
to extend code. 

>  - portability
>     -> no exceptions

Is there actually a compiler that doesn't support them yet?

>  - efficiency
>     -> no virtual functions

Pointless use of virtual functions is of course wasteful. Using something else 
instead of virtual functions where virtual functions are appropriate at best 
saves you one indirection of getting the vtable pointer; and likely at the 
cost of memory use/higher cache pressure. And if you call this more than 
once, CSE will probably take care of the redundance, too. And, BTW, switch 
statements are typically array of pointers look ups too (although other 
implementation strategies are possible, but those are typically even *more* 
complicated, unless you have 2 or 3 arms). Plus, switches require an 
extraneous range check most of the time which is guaranteed not to happen 
when indexing into the vtables.


> 	-> no inheritance

Hmm? Single inheritance is overhead-free. 

> 	-> no standard new/delete operators

At most a single function call overhead. And custom new/delete operators are a 
powerful performance tools. Plus, since these are specials they can be 
handled optimally by the compiler, unlike stuff like g_new().

-> + Standard inlining in the widely used version, not a proprietary extension 
(and if you care abouty portability, C99 isn't for you)

-> + Tighter aliasing rules, IIRC

-> + Generics

Frankly, I think anyone who is suggesting to use C for "performance" reasons 
and isn't referring to using C99's restricted pointers for numerics is simply 
wrong. 

>  - extreme long-term API/ABI stability
>     -> no inheritance

Again, inheritance improves API/ABI stability by making the interface more 
powerful/flexible.