lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master 084f1b49 5/5: Make a different virtual pu


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 084f1b49 5/5: Make a different virtual pure
Date: Tue, 12 Jul 2022 16:22:21 +0200

On Tue, 12 Jul 2022 13:42:30 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 7/12/22 11:34, Vadim Zeitlin wrote:
GC> > On Mon, 11 Jul 2022 22:53:09 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> > GC> branch: master
GC> > GC> commit 084f1b493d38aea81cb6efa174751bbb82ebaef2
GC> > GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> > GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> > GC> 
GC> > GC>     Make a different virtual pure
GC> > 
GC> >  How was the choice of the function to be made pure done here? I.e. why 
did
GC> > you decide to make allowed_keywords() pure and not, say, 
default_keyword()?
GC> 
GC> I picked the only one that would actually compile with no further changes.

 This is what I thought, but I also thought that this wasn't a good
strategy for determining whether a function should be pure virtual,
generally speaking. But I see now that here the two criteria coincided and,
of course, all this is not really relevant any more, so I won't discuss it
any longer except to say that I still think that in case of doubt, leaving
function pure virtual in the base class and explicitly implementing it in
the derived ones is usually a better solution than providing default
implementation that needs to be overridden.

GC> >  FWIW I'd probably make all virtual functions here pure
GC> 
GC> Try it:
GC>   pure virtual method called
GC>   terminate called without an active exception

 Just to be clear, I meant "make them pure and override them as necessary".

GC> without exceeding the width of a Hollerith card.

 I'm much more conservative (in technical matters) than average, but even I
start to think that 80 might be too limiting nowadays. I still believe that
overlong lines should be avoided because of many good reasons, both
ideological and practical, but I think that 100 or 120 characters might be
a better default choice than 80 nowadays. So perhaps we could consider
increasing the limit used in lmi too?

VZ

Attachment: pgpnKMxsx52p1.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]