Re: Code guidelines, state of C++ compilers used, and general C++ comments


Subject: Re: Code guidelines, state of C++ compilers used, and general C++ comments
From: Mike Nordell (tamlin@algonet.se)
Date: Thu May 11 2000 - 11:40:44 CDT


> > 12. Add: Never EVER put a member variable under any other access
> > specification than private. Derived classes have NO business of
probing
> > the baseclass' private parts (pun intended).
>
> I agree with this. I never liked 'protected' as a language feature.

Me neither, at least not for variables. For member functions it's however
vital to have 'protected' for a "healthy" hierarchy of classes (e.g.
think "baseclass' public non-virtual create() gets called by client code,
and in turn calls protected virtual '_create()' ").

> > To use an intrusive double linked list template class could really be
of
> > benefit. An (incomplete) example of how such an interface could look
like
> > can be found with my patch of fp_Run.
>
> I always sympathize with the desire to use templates in this way, but
> I don't think the hassle is worth it yet. The CM problems on the
> AbiWord project are already bad enough as it is.

It is? OK that I've only been at it for (oh, it's less than a week!) "a
while", but IFAIK the problems aren't compiler issues, they're now design
and functionality issues.

> I certainly believe
> that C++ will erase its reputation for unportability due to differing
> compiler implementations, but I'd like to see somebody else be the
> bleeding edge of this wave.

Agreed. I never suggested the use of e.g. <list> or <vector>, I just
wanted this to be an eye-opener that the language is by ISO (and for you
americans, yes ANSI also approved :-) ) standards over two years old now
and that compilers should have gotten a grip of at least the _language_,
the standard C++ library is another issue. :-)
There is btw a "small-feature-comparison-by-compiler-and-platform"
somewhere at Sams' site (http://sam.rh.uchicago.edu). I don't know how
up-to-date it's yet though.

> > It's always legal in C++ to delete a null pointer, e.g.
> > delete (int*)0;
> > The compiler does all the checking for you.
>
> I didn't know this either, and I'm not sure I like it. Then again,
> Bjarne has *never* called me for advice.

Since C++ was to be a conceptually higher-level language than C, it makes
perfect sense that delete checks fror null. Why should MB after MB of
client code have to check for this when the language (or library if it
was a library) can do it? Waste? No, bloat (IMO).

As a drill instructor once told me "Like it or not, you're here and
you'll do it!". :-)

/Mike - please reply to AbiWord-dev only



This archive was generated by hypermail 2b25 : Thu May 11 2000 - 10:40:56 CDT