"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:bE9Qc.454$191.314@newsread1.dllstx09.us.to.ve rio.net...[color=blue]
> 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.[/color]
I am pleased that you found it worth-while to post.
[color=blue]
> 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 << "DerivedFuBar"; }
> };
>
> 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 << "DerivedFuBar"; }
> };
>
> 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.[/color]
That line in the strict context of the example (with the fixes you mentioned
applied) would produce the same output, but would not behave the same with
regards to to object allocation/deallocation/assignment/initialization. My
intention though was to show an example for the design technique. I would
have preferred to not use a (pesudo-)code example using FuBar, but some
readers prefer examples.
Nonetheless, I still firmly believe that the code I placed is more accurate
of the general technique of implementing "interfaces" in C++.
[color=blue]
> Now, I am thinking: should I really read the rest of the article after
> seeing that and
>
> main() {
> ...
>
> in a supposedly _standard_ C++ program?[/color]
Not if you don't want to.
[color=blue]
> 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...[/color]
I always forget that the best measure of my work is whether or not I put
"int" in front of "main" when writing a C++ program. Maybe I should place
more importance on the vagaries of the ever changing C++ syntax, rather than
developing new techniques and ideas.
--
Christopher Diggins
http://www.heron-language.com 
