Topic: Why does 15.3 require a public base?
Author: Scott Meyers <smeyers@aristeia.com>
Date: Sun, 11 Feb 2001 17:53:24 CST Raw View
On Thu, 8 Feb 2001 14:18:13 GMT, Jim Hyslop wrote:
> void f()
> {
> try {
> throw std::string("Boo"); // (a)
> }
> catch (std::string &s) // (b)
> {
> }
> }
>
> I meant the copying that happens at point (b), not the copying that
> happens at point (a).
There should be no copying at point b. s is caught by reference.
Scott
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Jim Hyslop <jim.hyslop@leitch.com>
Date: Wed, 7 Feb 2001 15:51:37 GMT Raw View
In article <200102060125.UAA03793@edg1.edg.com>,
"J. Stephen Adamczyk" <jsa@edg.com> wrote:
> In article <95n8mm$lbf$1@nnrp1.deja.com> Jim Hyslop writes:
> >"A handler is a match for a throw expression with an object of type E
if
> >... the handler is of type cv1 T* cv2 and E is a pointer type that
can
> >be converted to the type of the handler by ... a standard pointer
> >conversion (4.10) not involving conversions to pointers to private or
> >protected or ambiguous classes...."
> >
> >Why are private and protected base classes explicitly prohibited from
> >matching? Why not just allow a standard pointer conversions that is
> >accessible and unambiguous?
>
> Because this is (almost) the only place in the standard where access
> checking must be done at runtime. As the example points out, access
> checking is potentially very complicated;
Which example are you referring to, the one I posted, or example 15.3 in
the standard? If the latter, I see no mention of complexity of access
checking.
[snip]
> Implementing full access checking at runtime would
> involve keeping a lot of information that's not otherwise needed
> at runtime.
>
> To avoid that, the standard instead calls for a simple-minded form
> of access control that is easier to implement.
OK, let me rephrase this, to see if I understand it properly.
Given an exception handler
catch(base &b)
in order to know whether or not a derived class could be implicitly
converted to a base class would require a runtime check against a
potentially large list of conversions involving a potentially large list
of friends, relatives, in-laws and outlaws.
So, to prevent this, and still allow polymorphic handling, the decision
was to limit conversions to public base classes. Some runtime checking
may still be required, but the list is much more limited.
OK, now it makes sense - thanks.
--
Jim
To suppress Deja's product links, add this header:
x-no-productlinks: yes
Sent via Deja.com
http://www.deja.com/
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Jim Hyslop <jim.hyslop@leitch.com>
Date: Wed, 7 Feb 2001 15:51:30 GMT Raw View
In article <3A806E80.EEE5671@ballfam.net>,
mike@ballfam.net wrote:
>
>
> Jim Hyslop wrote:
>
> > No, para 17 in 15.3 requires the copy constructor and the dtor to be
> > accessible within the scope of the context handler.
>
> That has to do with copying, which is unequivocally in the scope of
> the
> handler. The other has to do with choosing the handler, so the
> analogy
> is poor.
No, it is exactly appropriate to Ron's reply. Ron mentioned that the
conversion happened during the unwinding phase, and my point (which I
admit I didn't make very clearly) was that the conversion happens during
the copying phase, which happens *after* the handler is chosen..
> The real reason was described in detail by Steve Adamczyk.
> He was there when the decision was made.
[snip]
> Why speculate when the answer is already there?
Steve Adamczyk did not mention that he was present at the meetings. As
far as I knew, his response was an "expert opinion", just as Ron
Natalie's was. Thank you for pointing that out.
--
Jim
To suppress Deja's product links, add this header:
x-no-productlinks: yes
Sent via Deja.com
http://www.deja.com/
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Ron Natalie <ron@spamcop.net>
Date: Wed, 7 Feb 2001 16:00:17 GMT Raw View
Jim Hyslop wrote:
>
> No, it is exactly appropriate to Ron's reply. Ron mentioned that the
> conversion happened during the unwinding phase, and my point (which I
> admit I didn't make very clearly) was that the conversion happens during
> the copying phase, which happens *after* the handler is chosen..
No the conversion DOES NOT happen during the copying phase. The copy is
exactly what was thrown.
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Mike Ball <mike@ballfam.net>
Date: Wed, 7 Feb 2001 21:36:01 GMT Raw View
Jim Hyslop wrote:
> > That has to do with copying, which is unequivocally in the scope of
> > the
> > handler. The other has to do with choosing the handler, so the
> > analogy
> > is poor.
> No, it is exactly appropriate to Ron's reply. Ron mentioned that the
> conversion happened during the unwinding phase, and my point (which I
> admit I didn't make very clearly) was that the conversion happens during
> the copying phase, which happens *after* the handler is chosen..
That's right, the conversion does happen there, but the check for legality
of the conversion is done at runtime. One is a compiletime check, the
other is a runtime check. I misunderstood the thrust of your observation.
Matching and copying are two different phases and two different operations.
Exactly what the context for the matching would be has never been specified.
If we had allowed the conversions you mention, we would have had to specify
it, but since it had no material effect, we didn't bother.
> > The real reason was described in detail by Steve Adamczyk.
> > He was there when the decision was made.
> [snip]
> > Why speculate when the answer is already there?
>
> Steve Adamczyk did not mention that he was present at the meetings. As
> far as I knew, his response was an "expert opinion", just as Ron
> Natalie's was. Thank you for pointing that out.
Sorry. Since I knew that Steve was there for essentially ALL the meetings,
I guess I just assumed that everyone did. :-) (What's the emoticon for
a sheepish grin?).
-Mike Ball-
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Mike Ball <mike@ballfam.net>
Date: Wed, 7 Feb 2001 22:41:35 GMT Raw View
Mike Ball wrote:
> That's right, the conversion does happen there, but the check for legality
> of the conversion is done at runtime. One is a compiletime check, the
> other is a runtime check. I misunderstood the thrust of your observation.
in the paragraph above, read "copy" for "conversion". This wrong word
will cause confusion. Sorry.
-Mike-
>
> Matching and copying are two different phases and two different operations.
> Exactly what the context for the matching would be has never been specified.
> If we had allowed the conversions you mention, we would have had to specify
> it, but since it had no material effect, we didn't bother.
>
> > > The real reason was described in detail by Steve Adamczyk.
> > > He was there when the decision was made.
> > [snip]
> > > Why speculate when the answer is already there?
> >
> > Steve Adamczyk did not mention that he was present at the meetings. As
> > far as I knew, his response was an "expert opinion", just as Ron
> > Natalie's was. Thank you for pointing that out.
>
> Sorry. Since I knew that Steve was there for essentially ALL the meetings,
> I guess I just assumed that everyone did. :-) (What's the emoticon for
> a sheepish grin?).
>
> -Mike Ball-
>
> ---
> [ 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://www.research.att.com/~austern/csc/faq.html ]
> [ Note that the FAQ URL has changed! Please update your bookmarks. ]
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: Jim Hyslop <jim.hyslop@leitch.com>
Date: Mon, 5 Feb 2001 23:56:04 GMT Raw View
In comp.lang.c++, Sergei (sergei@summertime.mtu-net.ru) posted this code
snippet:
#include <iostream>
using namespace std;
struct b { };
struct d : private b {
void f() throw(d) {
try {
throw d();
}
catch (b&) {
cout << "Base" << endl;
}
catch (...) {
cout << "Ellipsis" << endl;
}
}
};
His expectation (and mine, until I read the standard more closely) was
that the output would be "Base" - yes, it involves private inheritance,
but the conversion from derived to base takes place *within* a derived
class member function.
However, the output is "Ellipsis" - because 15.3 states
"A handler is a match for a throw expression with an object of type E if
... the handler is of type cv1 T* cv2 and E is a pointer type that can
be converted to the type of the handler by ... a standard pointer
conversion (4.10) not involving conversions to pointers to private or
protected or ambiguous classes...."
Why are private and protected base classes explicitly prohibited from
matching? Why not just allow a standard pointer conversions that is
accessible and unambiguous?
--
Jim
To suppress Deja's product links, add this header:
x-no-productlinks: yes
Sent via Deja.com
http://www.deja.com/
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]
Author: "J. Stephen Adamczyk" <jsa@edg.com>
Date: Tue, 6 Feb 2001 11:11:53 GMT Raw View
In article <95n8mm$lbf$1@nnrp1.deja.com> Jim Hyslop writes:
>"A handler is a match for a throw expression with an object of type E if
>... the handler is of type cv1 T* cv2 and E is a pointer type that can
>be converted to the type of the handler by ... a standard pointer
>conversion (4.10) not involving conversions to pointers to private or
>protected or ambiguous classes...."
>
>Why are private and protected base classes explicitly prohibited from
>matching? Why not just allow a standard pointer conversions that is
>accessible and unambiguous?
Because this is (almost) the only place in the standard where access
checking must be done at runtime. As the example points out, access
checking is potentially very complicated; it can involve knowledge not
only of inheritance relationships among classes and the access
associated with the kind of inheritance, but also friend declarations
(for both classes and functions) and the location of the code doing
the access. Implementing full access checking at runtime would
involve keeping a lot of information that's not otherwise needed
at runtime.
To avoid that, the standard instead calls for a simple-minded form
of access control that is easier to implement.
(For the curious, the other case that involves runtime access
checking is dynamic_cast, which also uses a simplified scheme.)
Steve Adamczyk
Edison Design Group
---
[ 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://www.research.att.com/~austern/csc/faq.html ]
[ Note that the FAQ URL has changed! Please update your bookmarks. ]