Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Why doesn't this multiple virtual inheritance code compile?

Reply
Thread Tools

Why doesn't this multiple virtual inheritance code compile?

 
 
Marcel Müller
Guest
Posts: n/a
 
      01-03-2012
On 03.01.2012 05:25, Chris Stankevitz wrote:
> I do not want all Shapes to be observerImps. I want all shapes to be
> observers. I suspect what I want is not possible with c++.


What you are going to do is to have a helper class OberserImp that
implements the observer interface independently of the outer class. And
you want to be able to use this helper class down in the class tree not
only at the level of the interface reference in the class Shape.

I know two solution for this in C++.

1. The Java way.
The equivalent of interfaces in Java and .NET are virtual abstract base
classes in C++. If you want the Java behavior you always need to derive
virtual from all interface like C++ classes.
That was your approach except for the missing virtual at class Shape.

2. An template implememtation helper.
template <typename BASE>
class ObserverImp : BASE
{
void Notify() {}
};
class Square : public ObserverImp<Shape>
{
};

#1 has the disadvantage that it always requires another level of
indirection to access interface members at run time, even if this is not
required. And in real life this is required quite rarely.
The performance impact of this indirection is usually no big deal, but
the reduced possibilities for optimization and especially inlining could
be relevant.


Marcel
 
Reply With Quote
 
 
 
 
Joe keane
Guest
Posts: n/a
 
      01-03-2012
In article <(E-Mail Removed)>,
Chris Stankevitz <(E-Mail Removed)> wrote:
> - Create an abstract base class "Shape" that must be an "Observer"
> - Create an class "Square" that is a "Shape" and also an "ObserverImp"


So a 'Shape' is an 'Observer', and a 'Square' is a type of 'Shape'.

Now you want something that is an 'ObserverImp' [and it is square].
Wouldn't it make more sense to call it a 'SquareImp'?
 
Reply With Quote
 
 
 
 
Chris Stankevitz
Guest
Posts: n/a
 
      01-03-2012
On Jan 2, 11:20*pm, Paavo Helde <(E-Mail Removed)> wrote:
> Strange, compiles fine with my MSVC2010 and gcc (though MSVC issues a
> strange warning):


Paavo,

Thank you for your help and for posting the valid source in its
entirety. I have it compiling now. The mistake I made was: missing
"virtual" in the declaration for class Shape. "Virtual" must appear
in the class declarations for "Shape" and "ObserverImp". Apparently I
had trouble parsing people's "english" description of my mistake but I
had no trouble parsing the c++ code in its entirety.

The code that compiles and the g++ invocation appear below.

Thank you again,

Chris

===


struct Observer
{
virtual void Notify() = 0;
};

struct ObserverImp : public virtual Observer
{
void Notify() {}
};

struct Shape : public virtual Observer
{
};

struct Square : public Shape, public ObserverImp
{
};

Shape* ShapeFactory()
{
return new Square;
}

====

$ g++ -Wall -c test.cpp
 
Reply With Quote
 
Chris Stankevitz
Guest
Posts: n/a
 
      01-03-2012
On Jan 3, 12:35*am, Spike <(E-Mail Removed)> wrote:
> Your code was missing one virtual modifier.
>
> Also you need to declare the base classes destructors as virtual.
> Seehttp://en.wikipedia.org/wiki/Virtual_function#Virtual_destructors
> for an explanation.


Spike,

Thank you. I tried to dumb down my example to make the code easier to
understand. My actual code has virtual destructors and, Alf will be
happy to hear, a consistent style that differentiates class names from
function names.

Chris
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-04-2012
On 03.01.2012 22:51, Leigh Johnston wrote:
>
> For good examples of using the same naming convention for both types and
> functions see the C++ standard library.


The standard library operates under conditions that normal code does not:

(a) It is guaranteed to be used a lot by everybody.

(a1) all serious users become familiar with the names. This means
that for the standard library it is more important to reduce typing
effort (having short names) than to reduce interpretation and
recognition effort (having self-describing names). Aiming for the latter
would just be wasted effort.

(a2) since much of it is template based code, short names and terse
coding style help to reduce compile times. look at the code written pjp
(e.g. for visual c++'s standard library). it is horrible by the
standards of ordinary application programming, where clarity is the main
concern, but it it is near ideal for fast compilation.

(a3) bugs are much more likely to surface early and repeatedly, than
with ordinary application code. again this reduced the need for clarity.

(b) It can be and in some parts has to be system- and compiler-specific.
If some particular piece of code is not part of the developers have
aimed to make portable (to reduce the total effort), then it can be
written in any compiler- and system-dependent way, whatever the
developer regards as easiest. This is generally not so for ordinary
application code.

In short, do not look to the standard library for naming and formatting
conventions for ordinary application code.

The standard library is not ordinary application code: it operates under
a totally different set of rules.

Cheers & hth.,

- Alf
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-04-2012
On 01/ 4/12 02:19 PM, Leigh Johnston wrote:
> On 04/01/2012 01:14, Alf P. Steinbach wrote:
>> On 03.01.2012 22:51, Leigh Johnston wrote:
>>>
>>> For good examples of using the same naming convention for both types and
>>> functions see the C++ standard library.

>>
>> The standard library operates under conditions that normal code does not:
>>
>> (a) It is guaranteed to be used a lot by everybody.
>>
>> (a1) all serious users become familiar with the names. This means that
>> for the standard library it is more important to reduce typing effort
>> (having short names) than to reduce interpretation and recognition
>> effort (having self-describing names). Aiming for the latter would just
>> be wasted effort.
>>
>> (a2) since much of it is template based code, short names and terse
>> coding style help to reduce compile times. look at the code written pjp
>> (e.g. for visual c++'s standard library). it is horrible by the
>> standards of ordinary application programming, where clarity is the main
>> concern, but it it is near ideal for fast compilation.
>>
>> (a3) bugs are much more likely to surface early and repeatedly, than
>> with ordinary application code. again this reduced the need for clarity.
>>
>> (b) It can be and in some parts has to be system- and compiler-specific.
>> If some particular piece of code is not part of the developers have
>> aimed to make portable (to reduce the total effort), then it can be
>> written in any compiler- and system-dependent way, whatever the
>> developer regards as easiest. This is generally not so for ordinary
>> application code.
>>
>> In short, do not look to the standard library for naming and formatting
>> conventions for ordinary application code.
>>
>> The standard library is not ordinary application code: it operates under
>> a totally different set of rules.

>
> There can only be one response to the above verbiage: LOL!


Why?

I've worked on a lot of projects with almost as many coding standards
and I don't think the standard library naming conventions would be
acceptable under any of them. All of my current clients have some form
of different naming convention for types rule.

--
Ian Collins
 
Reply With Quote
 
Joe keane
Guest
Posts: n/a
 
      01-04-2012
In article <je096m$l1d$(E-Mail Removed)>,
Alf P. Steinbach <(E-Mail Removed)> wrote:
>The standard library operates under conditions that normal code does not:


c) It has a precise specification, that is more or less set in stone.

Often apps do not have much documentation [especially of internals], and
what there is may be inaccurate or out of date. So it is important for
the code to explain itself.

I would not mind if the standard headers have -no- comments. So long as
it works right...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Virtual inheritace -- when one inheritance of the base is virtual andthe other isn't. pauldepstein@att.net C++ 1 03-14-2009 03:45 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
virtual inheritance and virtual function. Ashwin C++ 2 08-01-2006 12:48 PM
mul. inheritance & overloading operator new/delete solved by virtual base inheritance? cppsks C++ 0 10-27-2004 07:49 PM
Should 'public virtual' always become 'private virtual'? & using private inheritance qazmlp C++ 19 02-04-2004 12:37 AM



Advertisments