"C++ with Interfaces" (article in CUJ vol 22 no 9)

[Victor Bazarov]

Interesting article. However, it starts with an example which I find
rather misleading. I hope the author (Christopher Diggins) wouldn't
mind if I post a quote from the article. I know he probably reads or
even writes to c.l.c++.m sometimes.

Christopher gives this [pseudo-]code (yes, it's not C++):

interface IFuBar {
contract:
void FuBar();
};

struct BaseFuBar {
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() {
DerivedFuBar d;
BaseFuBar& b = d;
IFuBar i = b;
i.FuBar(); // outputs BaseFuBar
}

and then claims that "the common way to approximate this design
in standard C++ is:"

struct AbcFuBar {
virtual void FuBar() = 0;
};

// vb: missing #include <iostream>

struct BaseFuBar : public AbcFuBar { // vb: public is unnecessary
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}

Well, simple superfluosity of 'public', the missing <iostream>, and the
absense of 'main' return value type aside, the code seems logical, yes?

I submit that by changing a single character on the line marked with
asterisks, the desired behaviour can be _correctly_ implemented:

BaseFuBar b = d;

contrary to what the author implies.

Now, I am thinking: should I really read the rest of the article after
seeing that and

main() {
...

in a supposedly _standard_ C++ program?

Christopher is a developer of Heron, another language. I am wondering,
do we really need another language developed because somebody hasn't got
around to learning existing ones well enough? Nah, that can't be it...

Anyway...

Victor

[Alf P. Steinbach]

* Victor Bazarov:

struct AbcFuBar {
virtual void FuBar() = 0;
};

// vb: missing #include <iostream>

struct BaseFuBar : public AbcFuBar { // vb: public is unnecessary
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}

Well, simple superfluosity of 'public', the missing <iostream>, and the
absense of 'main' return value type aside, the code seems logical, yes?

I submit that by changing a single character on the line marked with
asterisks, the desired behaviour can be _correctly_ implemented:

BaseFuBar b = d;

contrary to what the author implies.

Haven't read the article (do you have a link?), but:

What is the desired behavior?

Judging from what you write it is to get a call of BaseFuBar::FuBa r?

That's easy to achieve as you've shown; there are also other ways.

Btw. you're posting in clc++, not clc++m... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alexander Terekhov]

"Alf P. Steinbach" wrote:
[...]

What is the desired behavior?

Virtual dispatch with Warp 9.9999 velocity and zero space overhead.

Lieutenant Commander Data is full of such things.

regards,
alexander.

[Victor Bazarov]

Alf P. Steinbach wrote:

* Victor Bazarov:

struct AbcFuBar {
virtual void FuBar() = 0;
};

// vb: missing #include <iostream>

struct BaseFuBar : public AbcFuBar { // vb: public is unnecessary
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}

Well, simple superfluosity of 'public', the missing <iostream>, and the
absense of 'main' return value type aside, the code seems logical, yes?

I submit that by changing a single character on the line marked with
asterisks, the desired behaviour can be _correctly_ implemented:

BaseFuBar b = d;

contrary to what the author implies.

Haven't read the article (do you have a link?), but:

No, I don't have a link. I just have my copy of the magazine.
What is the desired behavior?
As I understood from the pseudo-code it's to make the BaseFuBar subobject
to do its thing, but not the DerivedFuBar.
Judging from what you write it is to get a call of BaseFuBar::FuBa r?
I thought so.
That's easy to achieve as you've shown; there are also other ways.
You should post your versions.
Btw. you're posting in clc++, not clc++m... ;-)

I know. I rarely post in c.l.c++.m. Too 'm' for my taste.

V

[Alf P. Steinbach]

* Victor Bazarov:

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}

What is the desired behavior?

As I understood from the pseudo-code it's to make the BaseFuBar subobject
to do its thing, but not the DerivedFuBar.

Judging from what you write it is to get a call of BaseFuBar::FuBa r?

I thought so.

That's easy to achieve as you've shown; there are also other ways.

You should post your versions.

Well one unsafe way to avoid copying is

a.BaseFubar::Fu Bar();

and one more safe way to capture the the essence of having two diffent
behaviors of same virtual function on same object is to provide an
interface- getter in BaseFuBar

AbcFuBar a& = b.theBaseAndBas eOnlyFuBarInter face();

which can be implemented e.g. on a contained object in BaseFuBar,

but I question the wisdom of the whole thing, because when the object
is really a DerivedFuBar then doing the BaseFuBar thing might break
the class invariant of DerivedFuBar (I think that's also the main reason
why public virtual functions are frowned on by purists).

Btw. you're posting in clc++, not clc++m... ;-)

I know. I rarely post in c.l.c++.m. Too 'm' for my taste.

I meant, are you sure the author of that article is reading _this_ group?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Victor Bazarov]

Alf P. Steinbach wrote:

* Victor Bazarov:

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}
What is the desired behavior?
As I understood from the pseudo-code it's to make the BaseFuBar subobject
to do its thing, but not the DerivedFuBar.

Judging from what you write it is to get a call of BaseFuBar::FuBa r?

I thought so.

That's easy to achieve as you've shown; there are also other ways.

You should post your versions.

Well one unsafe way to avoid copying is

a.BaseFubar::Fu Bar();

Why is it unsafe?
and one more safe way to capture the the essence of having two diffent
behaviors of same virtual function on same object is to provide an
interface- getter in BaseFuBar

AbcFuBar a& = b.theBaseAndBas eOnlyFuBarInter face();

which can be implemented e.g. on a contained object in BaseFuBar,

but I question the wisdom of the whole thing, because when the object
is really a DerivedFuBar then doing the BaseFuBar thing might break
the class invariant of DerivedFuBar (I think that's also the main reason
why public virtual functions are frowned on by purists).

To be honest, I struggled to understand whey the author wanted the
"base" (intermediate) version of the function called in the first
place. That was completely unclear from the article. Perhaps it's
just the thing: I didn't get the fact that the whole "interface"
discussion is academical.

What's your take on it?

Btw. you're posting in clc++, not clc++m... ;-)

I know. I rarely post in c.l.c++.m. Too 'm' for my taste.

I meant, are you sure the author of that article is reading _this_ group?

No. Nor do I really care. I posted to express my opinion (possibly in
a too convoluted way), not to bring something to his attention. CUJ
publishes e-mail addresses of authors in case somebody wants to contact
them. I didn't. I am, on the other hand, interested in the opinions of
the community at large, especially considering that rarely topics from
c.l.c++.m trickle down to c.l.c++ so folks here participate.

Victor

[Alf P. Steinbach]

* Victor Bazarov:

* Alf:

Well one unsafe way to avoid copying is

a.BaseFubar::Fu Bar();
Why is it unsafe?

First, should be 'b' not 'a' there.

It's unsafe because

when the object
is really a DerivedFuBar then doing the BaseFuBar thing might break
the class invariant of DerivedFuBar

e.g. DerivedFooBar might add an update of some cached information
which is assumed to always be in synch with the rest and valid.

I didn't get the fact that the whole "interface"
discussion is academical.

What's your take on it?

Don't know because I don't know what the discussion is... :-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Aguilar, James]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:bE******** *******@newsrea d1.dllstx09.us. to.verio.net...

[snip]

Interfaces can be useful. Here's an example:

Suppose I have a system in which there are bunches of objects graphically
drawn on the screen (yes, I know that can't be done in STL, it's just an
example). Suppose I want to implement a drag and drop UI. I want some
objects to be able to be able to have other objects dropped on them, but I
want other objects not to have that functionality. Hence, I create an
interface:

class DropTargetable
{
public:
virtual bool canAcceptDrop(D rawnObj info) = 0;
virtual void acceptDrop(Draw nObj info) = 0;
}

Methods that dealt with a dropping would simply call canAcceptDrop on
whatever they were trying to drop something on, and if it could, they would
call accept drop, where info would be whatever the user had clicked on.

That example is probably more practical than looking at a FooBar example.

Yours,

James

PS, if I missed the point, sorry. =) This is just what I understood to be
your question about interfaces.

[Alexander Terekhov]

Victor Bazarov wrote:
[...]

I meant, are you sure the author of that article is reading _this_ group?

No. Nor do I really care. I posted to express my opinion (possibly in
a too convoluted way), not to bring something to his attention. CUJ
publishes e-mail addresses of authors in case somebody wants to contact
them. I didn't. I am, on the other hand, interested in the opinions of
the community at large, especially considering that rarely topics from
c.l.c++.m trickle down to c.l.c++ so folks here participate.

Bazarov, Bazarov. Community at large really loved the idea. Tons
of kudos.

http://google.com/groups?threadm=qVi....videotron.net
(Subject: C++ with interfaces)

regards,
alexander.

[David Hilsee]

"Victor Bazarov" <v.********@com Acast.net> wrote in message
news:bE******** *******@newsrea d1.dllstx09.us. to.verio.net...

Interesting article. However, it starts with an example which I find
rather misleading. I hope the author (Christopher Diggins) wouldn't
mind if I post a quote from the article. I know he probably reads or
even writes to c.l.c++.m sometimes.

Christopher gives this [pseudo-]code (yes, it's not C++):

interface IFuBar {
contract:
void FuBar();
};

struct BaseFuBar {
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() {
DerivedFuBar d;
BaseFuBar& b = d;
IFuBar i = b;
i.FuBar(); // outputs BaseFuBar
}

and then claims that "the common way to approximate this design
in standard C++ is:"

struct AbcFuBar {
virtual void FuBar() = 0;
};

// vb: missing #include <iostream>

struct BaseFuBar : public AbcFuBar { // vb: public is unnecessary
void FuBar() { std::cout << "BaseFuBar" ; }
};

struct DerivedFuBar : public BaseFuBar {
void FuBar() { std::cout << "DerivedFuB ar"; }
};

main() { // vb: where is 'int'?
DerivedFuBar d;
BaseFuBar& b = d; /// *************** *********
AbcFuBar& a = b;
a.FuBar(); // output DerivedFuBar
}

Well, simple superfluosity of 'public', the missing <iostream>, and the
absense of 'main' return value type aside, the code seems logical, yes?

I submit that by changing a single character on the line marked with
asterisks, the desired behaviour can be _correctly_ implemented:

BaseFuBar b = d;

contrary to what the author implies.

After reading up a little bit on these interfaces, I think I understand what
the author was trying to point out. While it is true that you _can_ get
the same output as the code that uses interfaces, you have to create another
instance of AbcFuBar to do it. IFuBar, on the other hand, does not perform
any slicing and is operating on the DerivedFooBar instance created in the
main function.

Also, if I understand correctly, the following code will display
"DerivedFuB ar" without slicing as well:

IFuBar i2 = d;
i2.FuBar(); // outputs DerivedFuBar

Under the covers, the interface is maintaining a pointer to the object and
invoking the FuBar method. This means that the interface is usable by any
class that implements the required methods, not just those that choose to
inherit from it, and it can invoke methods on objects without using the
standard dynamic dispatching mechanisms used by the second example. It also
means that the same interface could invoke base class functions or derived
class functions on the same object, if they both have the same name and are
not virtual, which is something that you can't do with virtual methods in
ABCs.

I don't know if this functionality is necessary, but it sounds neat.

--
David Hilsee