🚀 go-pugleaf

In article <DHou9J.L8t@falcon.daytonoh.attgis.com>
Dick Menninger <Dick.Menninger@DaytonOH.ATTGIS.COM> writes:

    >> ==========Kaelin Colclasure, 11/5/95==========
    >> 
    >> 
    >> Thanks for the clarification!  I wonder, though, if this isn't
    >> something of a gratuitious inconsistancy.  For all other
    >> function definitions, extern is the default-- you have to use
    >> the static keyword to restrict the definition to file scope.
    >> Now the draft is saying that inline functions get exactly the
    >> *opposite* semantics (ie. static is assumed, extern must be
    >> declared explicitly).
    >> 
    >> The only reason I can fathom for this is for compatibility with
    >> existing, pre-standard C++ code-- and I'd say that's a pretty
    >> weak basis given my intuition that this usage in existing
    >> implementations should be pretty rare.  Am I just missing
    >> something?  -- // Kaelin Colclasure

    Dick>    A better way to look at this is to see that inline
    Dick> behaves like const as they both default to internal scope.
    Dick> I suspect this choice comes from applicability to member
    Dick> functions.  If you made inline default to external scope,
    Dick> you would have difficulty changing that to internal scope
    Dick> for member functions.  Attaching static would have a rather
    Dick> different semantics.  However, having inline default to
    Dick> internal scope allows extern to be applied without a change
    Dick> of class-level semantics of the function.

Hmmm, I don't really understand how member functions enter into the
picture here.  The visibility of member functions is determined a) by
the visibility of their enclosing class and b) by the explicit
public/protected/private visibility tag they are assigned.  The
concept of an "extern" member function is meaningless-- all member
functions are implicitly visible from any "file scope" providing that
the language's visibility criteria outlined above are satisfied.  This
is why "static" can be safely overloaded in the context of a class
declaration as it is.

Indeed, as another respondant pointed out, my example inline function
when declared within a class scope would be treated as though it had
the extern keyword added implicitly.  So this just reinforces my
intuition that the "current working paper" has this exactly
backwards.

Your example of const variables defaulting to "file scope" is
something of a surprise to me as well.  I recognize the obvious
benefit from a code generation perspective, but if this is true do we
ever expect anyone to learn this language (C++) without first
assimilating a massive body of historical and practical knowledge from
which to draw insight as to why these inconsistancies exist?

Not that I'm implying this is all your fault, Dick. ;-)
-- 
// Kaelin Colclasure -------------------------------------------------------
// EMail: kaelin@bridge.com           Mail: Bridge Information Systems, Inc.
// Voice: (314)567-8463                     717 Office Parkway
//   Fax: (314)432-5391                     St. Louis, MO 63141
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]