Re: Idiots
On Apr 14, 5:37 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <bZednVFnQ6c3TVjWnZ2dnUVZ8vydn...@giganews.com>,
le...@i42.co.uk says...
Not necessarily trying to contradict your conclusion, but it
doesn't look to me like everything you've said is entirely cut
and dried.
1) Don't use the unsigned integral types despite the fact that
the C++ standard library is full of their use.
I could as well point out that the standard library contains
quite a few examples of statically allocated buffers and
(worse) returning pointers to those buffers to the user (e.g.
many of the time-oriented functions).
The standard library has gets. Nuff said:-).
That was a reasonable decision when it was made, and now the
standard library is stuck with it, even though it's now far
from ideal.
2) Don't use abstract interfaces (as they advocate against
using public virtual functions).
Nonsense! You can have abstract interfaces without public virtual
functions. At least AFAIK, this was first advocated by Herb Sutter,
Come now. Nathan Myers (I think) advocated it long before Herb,
to the point of getting the standard to break the pre-standard
streambuf interface. I'd posted an article (or two) explaining
how it could be used to implement programming by contract. In
some ways, I disagree with Herb's arguments, because I think he
takes them too far: there are cases when a contract doesn't make
sense (call inversion, for example), and in those cases, there's
no point in making the virtuals private. Also there are
practical cases where, although I've explained in postings *how*
to do it, I notice that the number of errors in practice is
small enough that it isn't worth the bother (e.g. clone()). And
as others have pointed out, if no one is ever going to derive
from the class but you (e.g. it's your personal code, not
something you're doing professionally), you can safely cut a few
corners.
who certainly is NOT an idiot (e.g. he is on the standard
committee, so he helped design a fair amount of what you're
treating as exemplary in your previous point).
Herb's activities in the standard committee certainly postdate
much of what Leigh was citing (e.g. sizeof resulting in an
unsigned---which goes back to C).
I'd also note that if you look through the standard library
(especially iostreams) you'll find a lot of public, non-virtual
functions that start out with 'pub' (e.g. pubsetbuf) that call
private, virtual functions -- so by your logic of following what the
standard library does, you really should avoid public virtual
functions.
IIRC, that's Nathan Myer's doing:-).
I'd note as well, that this was designed _relatively_
recently, and when it was made it _broke_ backward
compatibility (to some degree). Despite this, I'd guess that
if they were designing those parts of the library again today,
there's a _pretty_ fair chance that they'd do it the same way
again -- and if they didn't, it wouldn't be because they'd
decided it was really wrong, but only that the gain was too
small to justify the pain.
3) Never derive from standard containers despite the fact that
interface augmentation is useful.
...and yet, Alexander Stepanov, the guy who originally
designed those containers, publicly and explicitly states that
he has no use for inheritance at all.
Which is a different argument:-). But it's certain that
std::vector wasn't designed to be a base class (and just as
certain that there are a few, limited cases, where it's
perfectly justified to derive from it---I just derived from
std::map a day or two ago).
For example, see his comments at:
http://www.stlport.org/resources/StepanovUSA.html
Again, if you're going to use the standard library as an
example, you can quickly find that they don't use inheritance,
even when one provides essentially an augmented interface of
another's. If you read _Elements of Programming_ (by Alexander
Stepanov and Paul McJones) you'll quickly find strong
indications that if he were designing this part of the
standard library again today, there's basically no chance at
all that he'd even consider using inheritance.
4) Don't use reference members despite the fact that not all
classes need to be Assignable.
Hmm...I can't find any evidence that anybody has advocated an
absolute proscription against reference members. I can find
threads going back quite a ways that address this sort of
issue. For example:
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thr
ead/c1731b41131cf195/37817cb28c82f9e3?hl=en#37817cb28c82f9e3
with, among other things, a post from James Kanze, saying:
"...if you intend to support assignment, you shouldn't use
reference members."
Other posts in that thread outline the "unsafe bad hack"
needed to (sort of) support assignment when you do have
reference members, in case anybody cares. I certainly would
NOT advise that you use it, but it does give an indication of
the alternatives.
Again, it's an "it depends" issue. References were definitely
designed for parameters and return values, in order to support
operator overloading with the usual semantics. But that doesn't
mean that they can't be used elsewhere.
--
James Kanze