From: markus_kohler at hp.com (Markus Kohler)
Date: 29 Apr 1999 16:05:25 +0200
Subject: Dangers of C++ (Way off topic)
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com> <p5g15lmb35.fsf@bidra241.bbn.hp.com> <slrn7ieipq.8uk.wtanksle@dolphin.openprojects.net> <372769B0.3CE8C0F3@prescod.net> <slrn7if4d4.9lh.wtanksle@dolphin.openprojects.net> <372827D8.7A5F@mailserver.hursley.ibm.com>
Message-ID: <p5wvyvldy2.fsf@bidra241.bbn.hp.com>
Content-Length: 1271
X-UID: 1152                                                  

>>>>> "Paul" == Paul Duffin <pduffin at mailserver.hursley.ibm.com> writes:

    Paul> William Tanksley wrote:
    >>  Let me expand a little on the dangers of C++.
    >> 
    >> - virtual functions.  It shouldn't be my job to tell the
    >> compiler when virtual lookups are the only thing to do; the
    >> compiler ought to be able to tell.  For performance gurus, a
    >> way to hint to the compiler that virtual lookups were _not_
    >> needed might be useful -- but what if the programmer was wrong?
    >> 

    Paul> How can the compiler tell ?

What William means (I think) is that the default should be that functions
are virtual. Since even virtuals functions can be inlined this makes sense. 

    >> - inline functions.  Again, a good compiler HAS to make this
    >> decision for itself, and in a good compiler, whether or not
    >> this decision was made should be transparent to the programmer.
    >> 

    Paul> A good compiler will, inline is only a hint to the compiler,
    Paul> the compiler can choose whether or not to inline that
    Paul> function, it can also choose to inline other functions which
    Paul> have not been marked as inline.

[agree with all the other points]


Markus

-- 
Markus Kohler  mailto:markus_kohler at hp.com




