So I've had to take over a project that used an old compiler.
May not be able to step up to a newer compiler because the
project uses a library that has equivalent of the following in it.

#include <iostream>
class A
{
public:
A();
virtual void tryit(long val) = 0;
};

class B: public A
{
public:
virtual void tryit(long val);
long m_val;
};

A::A()
{
tryit(17);
}

void B::tryit(long val)
{
m_val = val;
}

int main()
{
B myB;
std::cout << myB.m_val << std::endl;
}

I don't think this should work in a compliant compiler. When class A
tries to find tryit, it should not. I get a linker error in my more
recent
compiler.

But the old compiler I'm using for the project happily compiles and
links, and behaves as though the class A is finding the entry in
class B for the function tryit.

Am I missing something? This shouldn't work should it?
Socks

Puppet_Sock wrote:
> So I've had to take over a project that used an old compiler.
> May not be able to step up to a newer compiler because the
> project uses a library that has equivalent of the following in it.
>
> #include <iostream>
> class A
> {
> public:
> A();
> virtual void tryit(long val) = 0;
> };
>
> class B: public A
> {
> public:
> virtual void tryit(long val);
> long m_val;
> };
>
> A::A()
> {
> tryit(17);

This is a call to a pure virtual function. The behaviour is U.

> }
>
> void B::tryit(long val)
> {
> m_val = val;
> }
>
> int main()
> {
> B myB;
> std::cout << myB.m_val << std::endl;
> }
>
> I don't think this should work in a compliant compiler. When class A
> tries to find tryit, it should not. I get a linker error in my more
> recent
> compiler.
>
> But the old compiler I'm using for the project happily compiles and
> links, and behaves as though the class A is finding the entry in
> class B for the function tryit.
>
> Am I missing something? This shouldn't work should it?

It should not.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Apr 9, 7:42 am, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> Puppet_Sock wrote:
> > So I've had to take over a project that used an old compiler.
> > May not be able to step up to a newer compiler because the
> > project uses a library that has equivalent of the following in it.
>
> > #include <iostream>
> > class A
> > {
> > public:
> > A();
> > virtual void tryit(long val) = 0;
> > };
>
> > class B: public A
> > {
> > public:
> > virtual void tryit(long val);
> > long m_val;
> > };
>
> > A::A()
> > {
> > tryit(17);
>
> This is a call to a pure virtual function. The behaviour is U.
>
>
>
> > }
>
> > void B::tryit(long val)
> > {
> > m_val = val;
> > }
>
> > int main()
> > {
> > B myB;
> > std::cout << myB.m_val << std::endl;
> > }
>
> > I don't think this should work in a compliant compiler. When class A
> > tries to find tryit, it should not. I get a linker error in my more
> > recent
> > compiler.
>
> > But the old compiler I'm using for the project happily compiles and
> > links, and behaves as though the class A is finding the entry in
> > class B for the function tryit.
>
> > Am I missing something? This shouldn't work should it?
>
> It should not.
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

It should not work as when A's constructor is executing it does not
have complete knowledge of it's VTable
as which functions have been overriden as the object construction has
not completed yet. So as a rule of thumb
never expect virtual calls inside constructor to call child class's
implementation.

On Apr 8, 11:35 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
> So I've had to take over a project that used an old compiler.
> May not be able to step up to a newer compiler because the
> project uses a library that has equivalent of the following in
> it.

> #include <iostream>
> class A
> {
> public:
> A();
> virtual void tryit(long val) = 0;
> };

> class B: public A
> {
> public:
> virtual void tryit(long val);
> long m_val;
> };

> A::A()
> {
> tryit(17);
> }

> void B::tryit(long val)
> {
> m_val = val;
> }

> int main()
> {
> B myB;
> std::cout << myB.m_val << std::endl;
> }

> I don't think this should work in a compliant compiler. When
> class A tries to find tryit, it should not. I get a linker
> error in my more recent compiler.

It's undefined behavior. With most compilers, you'll get a
runtime error, at least with optimization turned off.

> But the old compiler I'm using for the project happily
> compiles and links, and behaves as though the class A is
> finding the entry in class B for the function tryit.

> Am I missing something? This shouldn't work should it?

Since it is undefined behavior, anything which the compiler does
is "correct".

I'm curious, though. Suppose you drop the "= 0" on A::tryit,
and provide an implementation for the function. In that case,
the code is well defined, and a conforming compiler *must* call
A::tryit in the constructor. What does your old compiler do?
(And what compiler is it? This hasn't changed since the
earliest days of C++.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Apr 8, 5:35pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
[snip]
> Am I missing something? This shouldn't work should it?

Apologies. I was missing something. The code as I posted
it was not equivalent to the case I had. The function call
was being made from inside a virtual function of class A,
not from the ctor of A, and was always happening from an
instance of B.

#include <iostream>

class A{
public:
virtual void tryit(long val) = 0;
virtual void init(long val);
};

class B: public A
{
public:
virtual void tryit(long val);
long m_val;
};

void A::init(long val)
{
tryit(val);
}

void B::tryit(long val)
{
m_val = val;
}

int main()
{
B *pMyB;
pMyB = new B;
pMyB->init(19);
std::cout << pMyB->m_val << std::endl;
B otherB;
otherB.init(42);
std::cout << otherB.m_val << std::endl;
}


The output is:

19
42

Sigh. You think you understand the language, then you
read somebody else's code.
Socks