|  | Non static members | | |
| | | Guest |  |
|  Posted: Mon Aug 11, 2008 12:38 pm Post subject: Non static members |  |
Hi,
$9.3.1/2 (N2691) states "If a non-static member function of a class X
is called for an object that is not of type X, or of a type derived
from X, the behavior is undefined."
I tried the following code
struct A{
virtual void f(){}
};
struct B : A{
void f(){}
};
int main(){
void (B::*pf)() = &B::f;
A *a;
(a->*pf)();
}
After trying several variations, I am not able to proceed beyond
getting a compilation error in VS2008. It appears to me that trying to
attempt such a code leads to an ill-formed program. I am unable to
simulate a code which would lead to "undefined" behaviour.
Does undefined behaviour always mean that the code will at least
compile/link and form an executable?
Dabs.
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Ulrich Eckhardt | |
| | Posted: Mon Aug 11, 2008 10:58 pm Post subject: Re: Non static members | |
| |  | |
rkldabs@gmail.com wrote:
| Quote: | $9.3.1/2 (N2691) states "If a non-static member function of a class X
is called for an object that is not of type X, or of a type derived
from X, the behavior is undefined."
I tried the following code
|
[snip]
You're thinking too complicated:
struct A
{};
struct B: A
{
void foo() {}
};
int main() {
A a;
// Note: this upcast is wrong because 'a' is not a 'B'
B& b = static_cast<B&>(a);
// ..therefore this call yields UB
b.foo();
}
| Quote: | Does undefined behaviour always mean that the code will at least
compile/link and form an executable?
|
Always, no. Typically, yes. There are few cases where compilers simply
refuse to compile code that can only yield UB, the only example I'm aware
of now is a function that has a returnvalue but under no circumstance
returns anything and also doesn't throw or terminate.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Tonni Tielens | |
| | Posted: Mon Aug 11, 2008 10:58 pm Post subject: Re: Non static members | |
| | | |
On Aug 11, 2:38 pm, rkld...@gmail.com wrote:
| Quote: | Hi,
$9.3.1/2 (N2691) states "If a non-static member function of a class X
is called for an object that is not of type X, or of a type derived
from X, the behavior is undefined."
I tried the following code
struct A{
virtual void f(){}
};
struct B : A{
void f(){}
};
int main(){
void (B::*pf)() = &B::f;
A *a;
(a->*pf)();
}
After trying several variations, I am not able to proceed beyond
getting a compilation error in VS2008. It appears to me that trying to
attempt such a code leads to an ill-formed program. I am unable to
simulate a code which would lead to "undefined" behaviour.
Does undefined behaviour always mean that the code will at least
compile/link and form an executable?
|
{ Edits: removed quoted signature and clc++m banner. The banner is appended
automatically to every article, including this one, and does not need to be
quoted. -mod }
Aren't you doing the opposite? You're trying to call a function of a
derived type on an object that is more generic. pf points to a
function of B and you're trying to call it on an object of A.
The following code compiles in VC6:
struct A
{
virtual void f(){}
};
struct B : A
{
void f(){}
};
int main(int argc, char* argv[])
{
void (A::*pf)() = &A::f;
B *b;
(b->*pf)();
return 0;
}
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Guest | |
| | Posted: Thu Aug 21, 2008 1:28 pm Post subject: Re: Non static members | |
On Aug 12, 4:33 pm, "Roman.Perepeli...@gmail.com"
<Roman.Perepeli...@gmail.com> wrote:
| Quote: | I believe this static_cast yields UB, therefore you can't
get UB on the next line.
|
If the program still executes past the 'static_cast' then the
reference is the result of UB and is *obviously not* a valid 'B'
object except in the furthest bastardizations of UB, therefore making
the example valid in pretty much all cases. As far as I know, UB
doesn't necessarily mean that "the program must degrade into mayhem
from that point forward." I believe the rule is meant to apply free
of the contexts required to get to the point in which it's applicable.
Kevin P. Barry
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
|
|
