According to rfg@NCD.COM (Ron Guilmette):
>According to cok@islsun.Kodak.COM (David Cok):
>+I agree that class names can be reused in local scopes within functions and
>+other classes.   But can they be reused at file scope in different
>+compilation units?
>
>Why ask me?  Why not try it yourself?  You do have a C++ compiler (or
>translator) don't you?

We have progressed beyond the point of "My compiler allows X,
therefore it's legal", haven't we?

The ARM explicitly notes its dependence on name equivalence.  Flouting
that rule is just asking for trouble.
--
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
   "All this is conjecture of course, since I *only* post in the nude.
    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre

In article <27D3E544.619A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
+According to bill@robots.oxford.ac.uk (Bill Triggs):
+>Creation of an instance of an implicitly specified class....
+>It seems that an appropriately global `class-designator' is
+>indispensable for this, whether string or global address or
+>global enumeration constant ...
+
+The class name is already guaranteed to be unique (name equivalence
+and all that).  What need of more?

Not only are file-scope class names not guaranteed to be unique across
multiple independent compilation units (which may later be combined to
form a single program) but class names need not even be unique *within*
a single compilation unit.  (Remember that any given compilation unit may
contain numerous independent declarative scopes.)
--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.

According to rfg@NCD.COM (Ron Guilmette):
>In article <27D3E544.619A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>+The class name is already guaranteed to be unique (name equivalence
>+and all that).  What need of more?
>
>Not only are file-scope class names not guaranteed to be unique across
>multiple independent compilation units (which may later be combined to
>form a single program) but class names need not even be unique *within*
>a single compilation unit.

Quite right; I had forgotton about local types.

On the other hand, I do not believe that avoidance of local types for
persistent and/or transmitted data is too much to ask of a programmer,
especially since such a restriction would avoid the need for two class
names (lexical and unique).
--
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin

In article <4338@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <27D3E544.619A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>+According to bill@robots.oxford.ac.uk (Bill Triggs):
>+>Creation of an instance of an implicitly specified class....
>+>It seems that an appropriately global `class-designator' is
>+>indispensable for this, whether string or global address or
>+>global enumeration constant ...
>+
>+The class name is already guaranteed to be unique (name equivalence
>+and all that).  What need of more?
>
>Not only are file-scope class names not guaranteed to be unique across
>multiple independent compilation units (which may later be combined to
>form a single program) but class names need not even be unique *within*
>a single compilation unit.  (Remember that any given compilation unit may
>contain numerous independent declarative scopes.)
>--

I agree that class names can be reused in local scopes within functions and
other classes.   But can they be reused at file scope in different
compilation units?  I thought these were effectively global, as free
functions are.  If you try this with Sun C++ (and the classes happen to
have non-inline functions with the same name and parameter types) you
will get a link error with a multiply defined function error.  Not to
necessarily advocate the use of a class name as a type tag, but it seems
that it would work, with suitable mangling for local scopes, if one
wanted to do it.

David R. Cok
Eastman Kodak Co.
cok@Kodak.COM

In article <1991Mar12.123811.13701@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
+In article <4338@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
+>In article <27D3E544.619A@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
+>+According to bill@robots.oxford.ac.uk (Bill Triggs):
+>+>Creation of an instance of an implicitly specified class....
+>+>It seems that an appropriately global `class-designator' is
+>+>indispensable for this, whether string or global address or
+>+>global enumeration constant ...
+>+
+>+The class name is already guaranteed to be unique (name equivalence
+>+and all that).  What need of more?
+>
+>Not only are file-scope class names not guaranteed to be unique across
+>multiple independent compilation units (which may later be combined to
+>form a single program) but class names need not even be unique *within*
+>a single compilation unit.  (Remember that any given compilation unit may
+>contain numerous independent declarative scopes.)
+>--
+
+I agree that class names can be reused in local scopes within functions and
+other classes.   But can they be reused at file scope in different
+compilation units?

Why ask me?  Why not try it yourself?  You do have a C++ compiler (or
translator) don't you?

+I thought these were effectively global, as free
+functions are.

What is a "free function"?  I never heard of such a thing before.  Most
function I have seen are quite expensive. :-)

+If you try this with Sun C++ (and the classes happen to
+have non-inline functions with the same name and parameter types) you
+will get a link error with a multiply defined function error.

Yes.  On every other Thursday, if there is a full-moon and if a dog
is howling, you will get a link-time error.  In general however, you
will not.

+Not to
+necessarily advocate the use of a class name as a type tag, but it seems
+that it would work, with suitable mangling for local scopes, if one
+wanted to do it.

Well you could try to use tags a "globally" unique identifiers (across
compilation units) for their respective classes, but that would tend to
be unsafe.

I think that there are safer (and more efficient) ways to provide globally
unique "type identifiers" for class types.
--

// Ron ("Shoot From The Hip") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.

According to bill@robots.oxford.ac.uk (Bill Triggs):
>Type info is *essential* for safe down-casting.  The alternative
>of pushing all Derived functions (and implicitly members) into
>the Base -- either as full implementations or as empty or
>error-calling stubs -- is simply laughable...

"Laughable" is not a very helpful description.  Specific objections,
please.

Note that downcasting to Derived* can itself be _one_ virtual function
of Base.

>Creation of an instance of an implicitly specified class....
>It seems that an appropriately global `class-designator' is
>indispensable for this, whether string or global address or
>global enumeration constant ...

The class name is already guaranteed to be unique (name equivalence
and all that).  What need of more?

>... appropriate `static Class* Class::' or `friend Class*'
>new_object() or read_object(), parse_object() functions...

What's missing from a virtual function "Base *Base::clone() const"?

>... Switch()-ing on type ought to be possible.

I fail to see why such a feature should be supported, when the
difficulties of producing a global (multi-module) class->integer
equivalence are so well known.
--
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
   "All this is conjecture of course, since I *only* post in the nude.
    Nothing comes between me and my t.b.  Nothing."   -- Bill Coderre