CS> To my knowledge, EGCS implements the entire ANSI C++ language. (I may
CS> be misinformed, of course.)
EGCS implements all parts of ANSI C++ language (temlates, exceptions,
namespaces, etc). But there are quite a few small places where it's not
compliant (something like "char *p=!!!1;" : "char *p=1-1;" accepted without
warnings, "char *p=~~~1;" will generate warning and "char *p=!!!1;" will
generate error even if all three constructs are allowed by ANSI C++ :-)
Small and [usually] easily fixable but still annoying...
CS> On the other hand, the C++ *library* that ships with EGCS,
CS> a.k.a. "libstdc++", is quite deficient.
CS> On the gripping hand, work on libstdc++ proceeds apace.
Yes, but still there are not "just a few ploblems are not solved" but rather
"some parts are done".
>> Yet again: multiple inheritance. Ugly code bloat in 99% cases.
>> WHAT code can be inherited from abstract "Modem" ?
CS> I agree that MI is not a good general-purpose tool. But it has
CS> specific limited value in specific limited cases. One nice idiom,
CS> for example, is mix-ins with MI and abstract classes. (This is the
CS> closest thing in C++ to Java's "interface" feature, AFAIK.)
Sometimes MI is great but in most cases it comes from bad design, not from
real need. Mix-ins can be realized effectively by smart compilers (I'm not sure
if egcs is smart enough though) and so more usefull but even this technique
is limited...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/