«

The other class is by the way
class Beacon : public Packet, public Serializable

is it possible that multiple inheritance makes things harder in this case?

Andrea Crotti <> writes:

> The other class is by the way
> class Beacon : public Packet, public Serializable
>
> is it possible that multiple inheritance makes things harder in this case?

Ok apparently I got it, if I don't implement something it doesn't work

With this is fine
virtual void writeBuffer() {}

With this stupid example I clarified my mind

class Base
{
public:
Base() {}
virtual void printOut();
};

class Extended : public Base
{
public:
Extended() {}
void printOut() { cout << "hello"; }
};

(like this it doesn't work).

Would be best to have
virtual void writeBuffer() = 0

to make it abstract, BUT then I have a static function that would
construct an object of subclass of Packet. IF there is a pure function
in the class definition than I'm not allowed to return a Packet (even if
I know that it will be always a subclass of it).

Now way to force the compiler about that?

And also, why the hell just declaring it and implementing it in every
subclass doesn't work?
I mean the compiler should see it's actually implemented everywhere, so
what's the problem?

* Andrea Crotti, on 10.11.2010 18:22:
> Andrea Crotti<> writes:
>
>> > The other class is by the way
>> > class Beacon : public Packet, public Serializable
>> >
>> > is it possible that multiple inheritance makes things harder in this case?
> Ok apparently I got it, if I don't implement something it doesn't work

That seems to be a correct assessment. Non-implemented features don't work.


> With this is fine
> virtual void writeBuffer() {}

If you say so.


> With this stupid example I clarified my mind
>
> class Base
> {
> public:
> Base() {}
> virtual void printOut();
> };
>
> class Extended : public Base
> {
> public:
> Extended() {}
> void printOut() { cout<< "hello"; }
> };

Good. A clear mind is very nice.


> (like this it doesn't work).

Parse error. Something is like something, and something does not work. What are
you talking about?


> Would be best to have
> virtual void writeBuffer() = 0

Sure, but where and for what?


> to make it abstract, BUT then I have a static function that would
> construct an object of subclass of Packet. IF there is a pure function
> in the class definition than I'm not allowed to return a Packet (even if
> I know that it will be always a subclass of it).

Right, you can't have an object where the most derived type is abstract.


> Now way to force the compiler about that?

No.


> And also, why the hell just declaring it and implementing it in every
> subclass doesn't work?

Parse error again.


> I mean the compiler should see it's actually implemented everywhere, so
> what's the problem?

Well, that's what I'm wondering: what is the problem you're talking about?

Possibly I could find out by looking at your original posting.

But I don't think it's fair that I and other out to help you should do a lot of
work to figure out what you're talking about. Please try to convey what you're
talking about. "It doesn't work" out of context says nothing, in particular, "It
doesn't work" doesn't say what "It" is.


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

"Alf P. Steinbach /Usenet" <alf.p.steinbach+> writes:
> Well, that's what I'm wondering: what is the problem you're talking about?
>
> Possibly I could find out by looking at your original posting.
>
> But I don't think it's fair that I and other out to help you should do
> a lot of work to figure out what you're talking about. Please try to
> convey what you're talking about. "It doesn't work" out of context
> says nothing, in particular, "It doesn't work" doesn't say what "It"
> is.


Sorry you're right I was not clear, I was just continuing the
conversation with myself that's why...

Anyway I rephrase, first question is why this below doesn't find the
reference to the vtable?

class Base
{
public:
virtual void printOut();
};

class Extended : public Base
{
public:
void printOut() { cout << "hello"; }
};

The only subclass actually implements the method I want, so should not
that be enough?
Or maybe it complains because the vtable is constructed at runtime
(giving the possibility of bad crashes if nothing is found)?

The second question was if it was possible to do something like

class Extended;

class Base
{
public:
virtual void printOut() = 0;
static Base getLower() {
Extended e;
return e;
}
};

class Extended : public Base
{
public:
void printOut() { cout << "hello"; }
};

Apparently not if I understand, then I'll find some other ways..

* Andrea Crotti, on 10.11.2010 19:08:
> "Alf P. Steinbach /Usenet"<alf.p.steinbach+> writes:
>> Well, that's what I'm wondering: what is the problem you're talking about?
>>
>> Possibly I could find out by looking at your original posting.
>>
>> But I don't think it's fair that I and other out to help you should do
>> a lot of work to figure out what you're talking about. Please try to
>> convey what you're talking about. "It doesn't work" out of context
>> says nothing, in particular, "It doesn't work" doesn't say what "It"
>> is.
>
>
> Sorry you're right I was not clear, I was just continuing the
> conversation with myself that's why...
>
> Anyway I rephrase, first question is why this below doesn't find the
> reference to the vtable?
>
> class Base
> {
> public:
> virtual void printOut();
> };
>
> class Extended : public Base
> {
> public:
> void printOut() { cout<< "hello"; }
> };
>
> The only subclass actually implements the method I want, so should not
> that be enough?
> Or maybe it complains because the vtable is constructed at runtime
> (giving the possibility of bad crashes if nothing is found)?

The compiler doesn't know that you're not creating any pure Base instances.

And it doesn't care.

A virtual member function, except a pure virtual member (that's a one with "= 0"
at the end) must have an implementation, so that the compiler can very
mechanically put the address of that implementation in the vtable, or use it in
whatever scheme it uses as an alternative to vtables.


> The second question was if it was possible to do something like
>
> class Extended;
>
> class Base
> {
> public:
> virtual void printOut() = 0;
> static Base getLower() {
> Extended e;
> return e;
> }
> };
>
> class Extended : public Base
> {
> public:
> void printOut() { cout<< "hello"; }
> };
>
> Apparently not if I understand, then I'll find some other ways..

Problems with the above include

* 'getLower' attempts to return an object of abstract class.

* A local variable is declared with incomplete type 'Extended'.

* If those obstacles weren't in the way, 'getLower' would perform
a *slicing*, returning only the Base part of 'e', and then of type
'Base'.

It's not clear what you're attempting, but it may be that you want a Meyers'
singleton:

class Base
{
public:
virtual void printOut() = 0;
static Base& getLower();
};

class Extended: public Base
{
public:
void printOut() { cout << "hello"; }
};

Base& Base::getLower()
{
static Extended e;
// Whatever code you were intending to have here, then:
return e;
}

Note that with this scheme you always get the same object -- a singleton --
from 'getLower'.

Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

On Nov 10, 5:22*pm, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> Ok apparently I got it, if I don't implement something it doesn't work
>
> With this is fine
> * * virtual void writeBuffer() {}
>
> With this stupid example I clarified my mind
>
> class Base
> {
> public:
> * * Base() {}
> * * virtual void printOut();
>
> };
>
> class Extended : public Base
> {
> public:
> * * Extended() {}
> * * void printOut() { cout << "hello"; }
>
> };
>
> (like this it doesn't work).
>
> Would be best to have
> * * virtual void writeBuffer() = 0
>
> to make it abstract, BUT then I have a static function that would
> construct an object of subclass of Packet. *IF there is a pure function
> in the class definition than I'm not allowed to return a Packet (even if
> I know that it will be always a subclass of it).
>
> Now way to force the compiler about that?
>
> And also, why the hell just declaring it and implementing it in every
> subclass doesn't work?
> I mean the compiler should see it's actually implemented everywhere, so
> what's the problem?

I think part of the problem is that, if you want to return a Base by
value, it has to actually be a Base and not an Extended. Likewise, if
you want to pass it by reference it needs to really be of the type you
say it is. However, and this may be what you're looking for, you can
pass a *pointer* to a Base that actually points to an Extended. Then
it doesn't matter whether you can actually create a Base or not.

Paul.

On Nov 10, 8:27 pm, "Alf P. Steinbach /Usenet"
<alf.p.steinbach+use...@gmail.com> wrote:
> * Andrea Crotti, on 10.11.2010 19:08:

[...]
> > Anyway I rephrase, first question is why this below doesn't find the
> > reference to the vtable?

> > class Base
> > {
> > public:
> > virtual void printOut();
> > };

> > class Extended : public Base
> > {
> > public:
> > void printOut() { cout<< "hello"; }
> > };

> > The only subclass actually implements the method I want, so
> > should not that be enough? Or maybe it complains because
> > the vtable is constructed at runtime (giving the possibility
> > of bad crashes if nothing is found)?

> The compiler doesn't know that you're not creating any pure
> Base instances.

Also, during the constructor and destructor of Base, the dynamic
type is Base, and any calls to the virtual function go to
Base:rintOut.

> And it doesn't care.

> A virtual member function, except a pure virtual member
> (that's a one with "= 0" at the end) must have an
> implementation, so that the compiler can very mechanically put
> the address of that implementation in the vtable, or use it in
> whatever scheme it uses as an alternative to vtables.

Yes. And if the dynamic resolution results in a call to a pure
virtual function (e.g. because the call is made while in the
constructor of Base), the behavior is undefined. Generally, the
compiler will generate code which will cause the program to
crash with an error message (although IIRC, early versions of
g++ didn't have the error message, and some versions of VC++ do
something else, and don't even crash).

> > The second question was if it was possible to do something like

> > class Extended;

> > class Base
> > {
> > public:
> > virtual void printOut() = 0;
> > static Base getLower() {
> > Extended e;
> > return e;
> > }
> > };

> > class Extended : public Base
> > {
> > public:
> > void printOut() { cout<< "hello"; }
> > };

> > Apparently not if I understand, then I'll find some other ways..
>
> Problems with the above include

> * 'getLower' attempts to return an object of abstract class.

> * A local variable is declared with incomplete type 'Extended'.

> * If those obstacles weren't in the way, 'getLower' would perform
> a *slicing*, returning only the Base part of 'e', and then of type
> 'Base'.

> It's not clear what you're attempting, but it may be that you
> want a Meyers' singleton:

> class Base
> {
> public:
> virtual void printOut() = 0;
> static Base& getLower();
> };

> class Extended: public Base
> {
> public:
> void printOut() { cout << "hello"; }
> };

> Base& Base::getLower()
> {
> static Extended e;
> // Whatever code you were intending to have here, then:
> return e;
> }

> Note that with this scheme you always get the same object --
> a singleton -- from 'getLower'.

Just for the record, that's *not* a Meyers' singleton, or any
other type of singleton. (The first condition to be a singleton
is that there is no way of getting more than one instance. In
a Meyers' singleton, this is done by making the object
noncopyable, and the constructor private. Which, of course,
excludes derivation, unless you make the derived class
a friend.)

However, what you've just shown *is* the closest working
approximation of what he seems to be trying to do. Unless he
actually wants more than one instance---it's not really clear.
For more than one instance, he'd need a factory function, e.g.

class Base
{
public:
virtual void printOut() = 0;
static std::auto_ptr<Base> getLower();
};

class Extended: public Base
{
public:
void printOut() { cout << "hello"; }
};

std::auto_ptr<Base> Base::getLower()
{
return std::auto_ptr<Base>( new Extended );
}

--
James Kanze

Paul N <> writes:

> I think part of the problem is that, if you want to return a Base by
> value, it has to actually be a Base and not an Extended. Likewise, if
> you want to pass it by reference it needs to really be of the type you
> say it is. However, and this may be what you're looking for, you can
> pass a *pointer* to a Base that actually points to an Extended. Then
> it doesn't matter whether you can actually create a Base or not.
>
> Paul.

I see, thanks, but if I want to follow the "standard" procedure passing
a pointer already pointing to some allocated memory, I'm in the same
problem again.

Because I don't know what I should do outside of the function, if

Packet *p = new <Beacon | Route> ...

The only way then is to have the "new" inside this function, and then
remember to free that memory again I guess...

"Alf P. Steinbach /Usenet" <alf.p.steinbach+> writes:

> Problems with the above include
>
> * 'getLower' attempts to return an object of abstract class.
>
> * A local variable is declared with incomplete type 'Extended'.

What do you incomplete type?
Because I had the forward declaration maybe?

>
> * If those obstacles weren't in the way, 'getLower' would perform
> a *slicing*, returning only the Base part of 'e', and then of type
> 'Base'.
>
> It's not clear what you're attempting, but it may be that you want a
> Meyers' singleton:
>
> class Base
> {
> public:
> virtual void printOut() = 0;
> static Base& getLower();
> };
>
> class Extended: public Base
> {
> public:
> void printOut() { cout << "hello"; }
> };
>
> Base& Base::getLower()
> {
> static Extended e;
> // Whatever code you were intending to have here, then:
> return e;
> }
>
> Note that with this scheme you always get the same object -- a singleton --
> from 'getLower'.
>
> Cheers & hth.,
>
> - Alf

Anyway thanks but no, I don't think that's what I need, the simplest
solution is just to avoid the pure function so I don't have an abstract
class anymore and I can actually return something of that type.

The other solution I guess is to use a pointer as Paul suggested.
Thanks

On Nov 11, 10:22*am, Andrea Crotti <andrea.crott...@gmail.com> wrote:
> "Alf P. Steinbach /Usenet" <alf.p.steinbach+use...@gmail.com> writes:
>
> > Problems with the above include
>
> > * * 'getLower' attempts to return an object of abstract class.
>
> > * * A local variable is declared with incomplete type 'Extended'.
>
> What do you incomplete type?
> Because I had the forward declaration maybe?

No, the type Extended was incomplete at the source-line
Extended e;

because only the forward declaration had been seen by the compiler and
not yet the complete definition.
A C++ compiler only does a very limited amount of look-ahead.
Basically, the only things you can refer to, which come later in the
source file, are members of a class while you are in the body of a
member-function of that same class.

>
> > * * If those obstacles weren't in the way, 'getLower' would perform
> > * * a *slicing*, returning only the Base part of 'e', and then of type
> > * * 'Base'.
>
> > It's not clear what you're attempting, but it may be that you want a
> > Meyers' singleton:
>
> > * class Base
> > * {
> > * public:
> > * * * virtual void printOut() = 0;
> > * * * static Base& getLower();
> > * };
>
> > * class Extended: public Base
> > * {
> > * public:
> > * * * void printOut() { cout << "hello"; }
> > * };
>
> > * Base& Base::getLower()
> > * {
> > * * * static Extended e;
> > * * * // Whatever code you were intending to have here, then:
> > * * * return e;
> > * }
>
> > Note that with this scheme you always get the same object *-- *a singleton *--
> > from 'getLower'.
>
> > Cheers & hth.,
>
> > - Alf
>
> Anyway thanks but no, I don't think that's what I need, the simplest
> solution is just to avoid the pure function so I don't have an abstract
> class anymore and I can actually return something of that type.

You should be careful with the possibility of slicing.
This code

#include <iostream>
using namespace std;

class Base
{
public:
virtual void printOut() { cout<< "Base" << endl; }
static Base getLower();
};

class Extended : public Base
{
public:
void printOut() { cout<< "Extended" << endl; }
};

static Base Base::getLower() {
Extended e;
return e;
}

int main()
{
Base::getLower().printOut();
}

is guaranteed to always print "Base".
The Base::getLower function returns an object of type Base, not of
some derived type.

>
> The other solution I guess is to use a pointer as Paul suggested.
> Thanks

Or to use a smart pointer (like auto_ptr) as James suggested.

Bart v Ingen Schenau