In article <7tthuc$e8d$1@nnrp1.deja.com>,
  AllanW <allan_w@my-deja.com> wrote:
>
> In article <7tst9p$ub5@library1.airnews.net>,
>   "Bill Wade" <bill.wade@stoner.com> wrote:
> [Re "unambiguous public base"]
> >
> > At other places in the standard the word order is reversed,
> > making the meaning clear:
> >
> > 5.2.7p5: "accessible unambiguous base class"
> >
> > or "and" is used between the adjectives making the meaning clear
> >
> > 5.5p2 "unambiguous and accessible base class"
>
> Well, I still don't understand how "unambiguous public base"
> can be misinterpreted. But some people have a problem with this
> wording, and Bill has shown us different wording used elsewhere
> in the standard with apparently the same effect.
>
> Since some people want to change the wording to clarify the
> meaning, and I suspect that everyone else will agree that the
> alternate wording used elsewhere in the standard has exactly
> the same meaning, then this "controversy" seems like a
> no-brainer: go ahead and change it!

We're only supposed to fix defects, not questions of wording
preference, at this point.  I remain to be convinced that the
Standard is broken at this point.  I'm certainly not arguing
that the current wording is preferable to some other
formulation, just that it does say what it is intended to say:
that the base class cannot be ambiguous and must be public.

As I said, though, if enough people at the meeting find the
current wording to be sufficiently confusing as to constitute
a defect, it will be changed.
--
William M. Miller, wmm@fastdial.net


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FE819B.E45A38A0@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
[Re: "unambiguous public base"]
> The issue is whether it needs to be unambiguous before or
> after restricting the set of possibilities to public bases.
> In other words, is it an unambiguous base that happens to
> be public, or a base that is unambiguous after restricting
> the possibilities to public bases.

That might be a problem if we had to rely on common English
usage of the word "unambiguous." However, the standard
clearly explains what constitutes "unambiguous" -- or
possibly it defines what constitutes "ambiguous," leaving
the opposite implicitly "unambiguous." (I don't have my
copy of the standard with me, but I'm positive that one of
these two things is true.)

In either case, the standard gives specific rules for
determining if a base class is "unambiguous," and these
rules specifically ignore the class access. Just as a
large blue rock MUST be blue, an unambiguous public base
MUST be unambiguous.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote in message <7to9ji$suu$1@nnrp1.deja.com>...

>I hear what you're saying, but I just don't believe the English
>allows that interpretation.  Ambiguity and access are completely
>unrelated in C++, just as size and color are unrelated in the
>physical world.  If I say "a small red ball," there is no escape
>from the fact that the ball I am talking about is both small and
>red.

Unambiguous denotes a singular object (within a particular context).  Small
categorizes a group of objects.

Change "small red ball" to "smallest red ball".  The ball (if any) is red.
It may not be particularly small.  It is smaller than any other red ball
that may or may not exist.

>In the same way, "an unambiguous public base" must be both
>unambiguous and public.  The accessibility of another base with
>which it might be ambiguous is irrelevant.

If you saw "unambiguous base sub-object" would you say that unambiguous and
base are completely unrelated?
  class foo: T { T x; } bar;
Does bar have an unambigous base sub-object of type T?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW wrote in message <7ttgnj$d9a$1@nnrp1.deja.com>...

>That might be a problem if we had to rely on common English
>usage of the word "unambiguous." However, the standard
>clearly explains what constitutes "unambiguous" -- or
>possibly it defines what constitutes "ambiguous," leaving
>the opposite implicitly "unambiguous." (I don't have my
>copy of the standard with me, but I'm positive that one of
>these two things is true.)

I think you are refering to 3.4/1 [basic.lookup].  This is refering to name
lookup.  In
  dynamic_cast<T*>(v);
the name lookup for 'T' occurs in the context of the scope of the dynamic
cast and must be unambigous.  I can't find anything that says 3.4/1 applies
once you get into the "internals" of dynamic_cast resolution.

>In either case, the standard gives specific rules for
>determining if a base class is "unambiguous," and these
>rules specifically ignore the class access. Just as a
>large blue rock MUST be blue, an unambiguous public base
>MUST be unambiguous.

However the "largest blue rock" need not be particularly large relative to
rocks in general.

You used 'base' as a noun, but in the standard it is usually an adjective.
   base class
vs.
  member class
If unambiguous and public are independent, are unambiguous and base
independent?  If a class has both a T base and a T member is T an
unambiguous base class?




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FE819B.E45A38A0@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
>
> wmm@fastdial.net wrote:
> ....
> > Given that fact, "unambiguous public base" means either "a public
base
> > that is unambiguous" or "an unambiguous base that is public."
Neither
> > of those readings allows "a public base that is ambiguous (with
> > non-public bases)."  I don't see any other way to read it.
>
> The issue is whether it needs to be unambiguous before or after
> restricting the set of possibilities to public bases. In other words,
is
> it an unambiguous base that happens to be public, or a base that is
> unambiguous after restricting the possibilities to public bases.

I hear what you're saying, but I just don't believe the English
allows that interpretation.  Ambiguity and access are completely
unrelated in C++, just as size and color are unrelated in the
physical world.  If I say "a small red ball," there is no escape
from the fact that the ball I am talking about is both small and
red.  In the same way, "an unambiguous public base" must be both
unambiguous and public.  The accessibility of another base with
which it might be ambiguous is irrelevant.

If there are enough people at the meeting who feel this is
genuinely confusing, the wording will be changed; it is on the
issues list.  For me, though, there's no way to read this any
other way than it was intended.

--
William M. Miller, wmm@fastdial.net


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>Speaking for myself, I have tried and I cannot find any way to read
>"unambiguous public base" with your meaning #2.  Ambiguity and access
>are orthogonal concepts; it is possible for a base to be either public
>or non-public without saying anything about its ambiguity, and either
>ambiguous or unambiguous without saying anything about its access.
>
>Given that fact, "unambiguous public base" means either "a public base
>that is unambiguous" or "an unambiguous base that is public."  Neither
>of those readings allows "a public base that is ambiguous (with
>non-public bases)."  I don't see any other way to read it.

To me the phrase
  an unambiguous foo
is nearly synonymous with
  the sole foo
and I don't see any definition in the standard that would change that
interpretation.  Replacing foo with "red truck" I get.

  The sole red truck.

There may be other trucks.  There may be other red vehicles.  There is only
one vehicle that is both red and a truck.  Are a vehicle's color and
uniqueness orthogonal?  I don't believe so.  A vehicle may be unique only
when its color is taken into account.

At other places in the standard the word order is reversed, making the
meaning clear:

5.2.7p5: "accessible unambiguous base class"

or "and" is used between the adjectives making the meaning clear

5.5p2 "unambiguous and accessible base class"

I don't believe that the rules in 3.4 [basic.lookup] apply here.

  dynamic_cast<T*>(x);

3.4 says T must be an accessible unambigous name in this scope.  It says
nothing about what it must mean in *x's scope (or in the most derived object
at *x).

If the intent of the standard is "accessible and unambiguous" it is an easy
change to make that intent clear.  Alternatively if the intent is "... the
most derived object has one public base (any non-public bases are
immaterial) ..." the standard could make that clear also.

HTH




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote:
>
> In article <37FE819B.E45A38A0@wizard.net>,
>   "James Kuyper Jr." <kuyper@wizard.net> wrote:
> >
> > wmm@fastdial.net wrote:
> > ....
> > > Given that fact, "unambiguous public base" means either "a public
> base
> > > that is unambiguous" or "an unambiguous base that is public."
> Neither
> > > of those readings allows "a public base that is ambiguous (with
> > > non-public bases)."  I don't see any other way to read it.
> >
> > The issue is whether it needs to be unambiguous before or after
> > restricting the set of possibilities to public bases. In other words,
> is
> > it an unambiguous base that happens to be public, or a base that is
> > unambiguous after restricting the possibilities to public bases.
>
> I hear what you're saying, but I just don't believe the English
> allows that interpretation.  Ambiguity and access are completely
> unrelated in C++, just as size and color are unrelated in the
> physical world.  If I say "a small red ball," there is no escape
> from the fact that the ball I am talking about is both small and
> red.

But a "big insect" is a small animal compared to a "small elephant".
That is, by saying "insect" you are restricting the set you are
looking at, and then make the following qualification based on
_that_ set. And in the set of insects, this specific insect
is big, although it's still a small animal.

> In the same way, "an unambiguous public base" must be both
> unambiguous and public.  The accessibility of another base with
> which it might be ambiguous is irrelevant.

In this case, you have three restrictions.
The first restriction is "base". For this one, it's obvious
that the rest are restricted to it (both accessibility and
ambiguity are only checked on the set of bases. For example,
the fact that the private base A is accessible as a global
class is not considered; since only the acessibility _as base_
is checked, A is considered not accessible).
Now the question is whether the preposition "ambiguous"
works on the set of public bases or on the set of all bases
(with an intersection done afterwards).

(For those speaking German: The question is if the quoted
phrase means "eine eindeutige oeffentliche Basisklasse" or
"eine eindeutige, oeffentliche Basisklasse". If there exists an
official German translation of the standard, and someone here
has access to it, it would be interesting which of the two
alternatives is used there.)

>
> If there are enough people at the meeting who feel this is
> genuinely confusing, the wording will be changed; it is on the
> issues list.  For me, though, there's no way to read this any
> other way than it was intended.

For me, there is. OTOH, English is not my native language,
so I might no see a fine distinction that might exist
in English to disambiguate the phrase.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38020D87.FE6C9FC0@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> ...a "big insect" is a small animal compared to a "small elephant".
> That is, by saying "insect" you are restricting the set you are
> looking at, and then make the following qualification based on
> _that_ set. And in the set of insects, this specific insect
> is big, although it's still a small animal.

But neither "insect" nor "elephant" are qualified types of
"animal" -- instead, they are specific instances of animal.

By way of analogy, if the Smith family tends to be taller
than the Jones family, you might argue that a "small Smith"
is bigger than a "large Jones." Smith and Jones are both
specific instances of "person." But it would be nonsense to
argue that a "small left-handed person" is larger than a
"large right-handed person." "Left-handed" and "Right-handed"
are both qualifiers of "person."

If we use "flying animal" instead of insect and "quadriped
animal" instead of elephant, then your example breaks down;
I would indeed expect a "big flying animal" to be larger
than a "small quadriped animal."

There's never an English teacher around when you need one...

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tst9p$ub5@library1.airnews.net>,
  "Bill Wade" <bill.wade@stoner.com> wrote:
[Re "unambiguous public base"]
>
> At other places in the standard the word order is reversed,
> making the meaning clear:
>
> 5.2.7p5: "accessible unambiguous base class"
>
> or "and" is used between the adjectives making the meaning clear
>
> 5.5p2 "unambiguous and accessible base class"

Well, I still don't understand how "unambiguous public base"
can be misinterpreted. But some people have a problem with this
wording, and Bill has shown us different wording used elsewhere
in the standard with apparently the same effect.

Since some people want to change the wording to clarify the
meaning, and I suspect that everyone else will agree that the
alternate wording used elsewhere in the standard has exactly
the same meaning, then this "controversy" seems like a
no-brainer: go ahead and change it!

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38020D87.FE6C9FC0@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>For me, there is. OTOH, English is not my native language,
>so I might no see a fine distinction that might exist
>in English to disambiguate the phrase.

It is certainly possible to misinterpret the phrase.  However there is a
principle that removing private should not change the meaning of valid
code (well, I believe there are now a few cases where this is no longer
true).  This allows us to use the classic get out, 'a close and careful
reading shows that ...'.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW wrote:
>
> In article <38020D87.FE6C9FC0@physik.tu-muenchen.de>,
>   Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> > ...a "big insect" is a small animal compared to a "small elephant".
> > That is, by saying "insect" you are restricting the set you are
> > looking at, and then make the following qualification based on
> > _that_ set. And in the set of insects, this specific insect
> > is big, although it's still a small animal.
>
> But neither "insect" nor "elephant" are qualified types of
> "animal" -- instead, they are specific instances of animal.

Oh, you want to tell me that there can exist only one
elephant?
An elephant is an "elephant-like animal". An instance of
"elephant" might be "Bimbo".  But "elephant" is _not_
an instance of animal (there's no single animal to which
you could point and say "this is _the_ elephant").

Or in C++ terms: it's "class Elephant: public Animal { ... };"
not "Animal elephant;"

>
> By way of analogy, if the Smith family tends to be taller
> than the Jones family, you might argue that a "small Smith"
> is bigger than a "large Jones." Smith and Jones are both
> specific instances of "person." But it would be nonsense to
> argue that a "small left-handed person" is larger than a
> "large right-handed person." "Left-handed" and "Right-handed"
> are both qualifiers of "person."

The only reason why I wouldn't argue that is that there is
no evidence that there's any difference in the size of
left-handed and right-handed persons. There's no logical
reason why this could not be the case. For example, assume
that the hormon for growing would also affect the handedness,
so that left-handed persons would generally be much smaller
than right-handed ones. In that case, a large left-handed
person would not necessarily be a large person, and in the
extreme could be smaller than a small right-handed person.

Now in the real world, handedness and size seem not to be
correlated, and that's the reason why your example _appears_
to work.
In the C++ case, you can easily make up examples where
accessibility and ambiguity are highly correlated - just
make one accessible and one unaccessible base class A.
Now if you ask for the accessible A, there's no ambiguity:
There's only one accessible A. Now if you ask for a base
class A, and then check if it is accessible, then you get
ambiguity: There are two A in the class, one of which is
accessible.

>
> If we use "flying animal" instead of insect and "quadriped
> animal" instead of elephant, then your example breaks down;
> I would indeed expect a "big flying animal" to be larger
> than a "small quadriped animal."

Well, I don't know what "quadriped" means, but it's a matter
of fact that today even large flying animals are small
animals. I'd surely call a flying animal large if it is
about half as large as I am. I wouldn't consider it a large
animal, though.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper Jr." wrote:
>
> wmm@fastdial.net wrote:
> ....
> > Given that fact, "unambiguous public base" means either "a public base
> > that is unambiguous" or "an unambiguous base that is public."  Neither
> > of those readings allows "a public base that is ambiguous (with
> > non-public bases)."  I don't see any other way to read it.
>
> The issue is whether it needs to be unambiguous before or after
> restricting the set of possibilities to public bases. In other words, is
> it an unambiguous base that happens to be public, or a base that is
> unambiguous after restricting the possibilities to public bases.

As other's have pointed out, making something private doesn't make it
unambiguous.  Access control is about the last thing checked for in
resolution.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paragraph 8 of 5.2.7 Dynamic Cast reads, in part

Otherwise, if ... the most derived object has an unambiguous public base
class of type T ...

It should be made clear which of the following meanings is intended
  1) the object has exactly one base class of type T, and that base is
public.
  2) the object has exactly one public base of type T.  The existance of
other non-public bases of type T has no bearing.

I believe the intent is (1), but I am not sure the current wording is
unambiguous.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:

> Paragraph 8 of 5.2.7 Dynamic Cast reads, in part
>
> Otherwise, if ... the most derived object has an unambiguous public base
> class of type T ...
>
> It should be made clear which of the following meanings is intended
>   1) the object has exactly one base class of type T, and that base is
> public.
>   2) the object has exactly one public base of type T.  The existance of
> other non-public bases of type T has no bearing.

It is already clear that the intent is (1): the base
is both public and unambiguous.

--

Valentin Bonnard


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tj79j$ako@library1.airnews.net>,
  "Bill Wade" <bill.wade@stoner.com> wrote:
> Paragraph 8 of 5.2.7 Dynamic Cast reads, in part
>
> Otherwise, if ... the most derived object has an unambiguous public
base
> class of type T ...
>
> It should be made clear which of the following meanings is intended
>   1) the object has exactly one base class of type T, and that base is
> public.
>   2) the object has exactly one public base of type T.  The existance
of
> other non-public bases of type T has no bearing.
>
> I believe the intent is (1), but I am not sure the current wording is
> unambiguous.

This was reported earlier as a potential defect, and I have already
added it to the core language issues list.

Speaking for myself, I have tried and I cannot find any way to read
"unambiguous public base" with your meaning #2.  Ambiguity and access
are orthogonal concepts; it is possible for a base to be either public
or non-public without saying anything about its ambiguity, and either
ambiguous or unambiguous without saying anything about its access.

Given that fact, "unambiguous public base" means either "a public base
that is unambiguous" or "an unambiguous base that is public."  Neither
of those readings allows "a public base that is ambiguous (with
non-public bases)."  I don't see any other way to read it.

--
William M. Miller, wmm@fastdial.net


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote:
....
> Given that fact, "unambiguous public base" means either "a public base
> that is unambiguous" or "an unambiguous base that is public."  Neither
> of those readings allows "a public base that is ambiguous (with
> non-public bases)."  I don't see any other way to read it.

The issue is whether it needs to be unambiguous before or after
restricting the set of possibilities to public bases. In other words, is
it an unambiguous base that happens to be public, or a base that is
unambiguous after restricting the possibilities to public bases.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]