Re: dynamic_cast
{ Please format your article in no less than 80 columns,
preferably in 72 columns or so. -mod }
On 21 Nov., 12:36, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
I think you are mistaken. dynamic_cast is an execution time action which
includes cross-casting. As such a dynamic_cast is always well formed.
Surprised?
Not really ;-) , but if you are right - and I highly respect your
opinion - than I
would strongly propose to rework the current wording, because at least
for
me (being a non-native speaker of English) the wording differentiates
two
different modes, one static and one run-time, both somewhat orderly
interweaved, but still logical separable. And *not* all run-time tests
require polymorphic types, v.i.
1) Static decision modes: P. 3 is a statically selected decision:
"If the type of v is the same as the required result type[..]"
IMO p. 5 describes also a static decision, otherwise the example
code broken down to the essential of
"B* bp = dynamic_cast<B*>(dp); // equivalent to B* bp = dp;"
is misleading. P. 7 distinguishes a static and a run-time test. The
static
test is initialized with "If T is "pointer to cv void," but proceeds
with a
following run-time test, as described in (2)
2) Run-time modes: P. 4 is a run-time test (null pointer value test),
but does
not require a polymorphic type (this requirement follows later). Need
for a
polymorphic type is expressed from p. 6 on. The run-time decision part
of
p. 7 seems to start with:
"[..] Otherwise, a run-time check is applied to see if the object
pointed or
referred to by v can be converted to the type pointed or referred to
by T."
Summarizing, I agree, that dynamic_cast is provided to perform
run-time tests, but some stages of this process (depending on
statically
known source and destination types) are partially done statically,
and
partially done run-time. The run-time part partially needs a
polymorphic
type, partially it is required to use static information (e.g.
"If T is "pointer to cv void,").
Given
struct A {}
struct B {}
bool foo(A* a_ptr){
B* b_ptr(dynamic_cast<B*> a_ptr);
....
}
The compiler cannot know that somewhere a programmer will write:
struct C: A, B {}
This is not the use-case of the OP and is not the point I was
discussing, because in the OP's use-case the source type is
a *derived* type and the destination type is the *base* type.
According to my understanding of p. 5 the initial check for this
decision block bases on the static type information. In your
example above this use-case does not apply, so the following
p. 6 (run-time check) will be performed - according to the
opinion of both you and me, right?
Now sonsider the code:
void bar(C c_ptr){
bool test( foo(c_ptr) );
....
}
The call to foo() is well formed and the dynamic_cast will succeed.
Absolutely correct, but I don't think that this addresses the OP's
use-case, am I wrong?
Now add into the mix that private is a compile time feature which is
not, IIRC, available during execution and the result is that not only is
the original code well-formed but should return a pointer to the A base
class.
Be ensured that I'm absolutely in line with *your* example, but
currently I still think that the OP's use-case should be based on
a static compiler decision and a non-polymorphic run-time decision
(e.g. the null pointer value test).
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]