If I declare a function pure virtual:

class A
{
virtual void myfunc() = 0;
}

and I derive a class from A:

class B : public A
{
void anotherfunc();
}

when I compile this program,
the compiler doesn't complain that there is no method myfunc() implemented
in B.
Is there a way to enforce such a compiler error/warning?

Regards

R4DIUM

A.Gallus wrote:
> If I declare a function pure virtual:
>
> class A
> {
> virtual void myfunc() = 0;
> }
;

>
> and I derive a class from A:
>
> class B : public A
> {
> void anotherfunc();
> }

;
>
> when I compile this program,
> the compiler doesn't complain that there is no method myfunc()
> implemented in B.
> Is there a way to enforce such a compiler error/warning?

Yes. Try to instantiate your 'B' class or at least declare a function
that returns 'B' by value.

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

Bingo, that did the job, thx!




"Victor Bazarov" <v.Abazarov@comAcast.net> schrieb im Newsbeitrag
news:gcdmkq$ld7$1@news.datemas.de...
> A.Gallus wrote:
>> If I declare a function pure virtual:
>>
>> class A
>> {
>> virtual void myfunc() = 0;
>> }
> ;
>
>>
>> and I derive a class from A:
>>
>> class B : public A
>> {
>> void anotherfunc();
>> }
>
> ;
>>
>> when I compile this program,
>> the compiler doesn't complain that there is no method myfunc()
>> implemented in B.
>> Is there a way to enforce such a compiler error/warning?
>
> Yes. Try to instantiate your 'B' class or at least declare a function
> that returns 'B' by value.
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
> Bingo, that did the job, thx!

>> class A
>> {
>> virtual void myfunc() = 0;
>> };

>> class B : public A
>> {

You should consider to prefer
class B : public virtual A
to avoid being bitten by:
http://www.parashift.com/c++-faq-lit....html#faq-25.8
which will most likely happen if one uses the interface pattern.

Best,
-- Maik

Maik wrote:
> On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
>> Bingo, that did the job, thx!
>
>>> class A
>>> {
>>> virtual void myfunc() = 0;
>>> };
>
>>> class B : public A
>>> {
>
> You should consider to prefer
> class B : public virtual A
> to avoid being bitten by:
> http://www.parashift.com/c++-faq-lit....html#faq-25.8
> which will most likely happen if one uses the interface pattern.

I think that is worse performance wise then just this:
class B : public A
At least thats what I read here:
http://www.agner.org/optimize/#optimize

You cant do that. On many platforms interfaces are a binary interop used and supported by languages other than c++.

In order to interop however, the vtable for the interface MUST be contiguous.

Clearly if you are working in a ahomogonous c++ only environment you can use virtual like that. But, despite the c++ standards body being unwilling to acknoledge it, c++ vtables *are* used for binary interop rendering this keyword worse than useless.

"Maik" <Beckmann.Maik@googlemail.com> wrote in message news:f4375d51-1d59-4371-95bd-e7a437664ce3@c60g2000hsf.googlegroups.com...
On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
> Bingo, that did the job, thx!

>> class A
>> {
>> virtual void myfunc() = 0;
>> };

>> class B : public A
>> {

You should consider to prefer
class B : public virtual A
to avoid being bitten by:
http://www.parashift.com/c++-faq-lit....html#faq-25.8
which will most likely happen if one uses the interface pattern.

Best,
-- Maik

On 7 Okt, 10:46, "Chris Becke" <chris.be...@gmail.com> wrote:
[Top-posted in reply to an example of virtual inheritance]
> You cant do that. On many platforms interfaces are a binary interop used and supported by languages other than c++.
>
> In order to interop however, the vtable for the interface MUST be contiguous.
>
> Clearly if you are working in a ahomogonous c++ only environment you can use virtual like that. But, despite the c++ standards body being unwilling to acknoledge it, c++ vtables *are* used for binary interop rendering this keyword worse than useless.

Platform / vendor-specific issues are mostly irrelevant here. Virtual
inheritance is part of the C++ language. Perhaps you intended to
write: "I advise you not to do that"?

On Oct 7, 10:46 am, "Chris Becke" <chris.be...@gmail.com> wrote:
> You cant do that. On many platforms interfaces are a binary
> interop used and supported by languages other than c++.

In which case, you must declare them ``extern "whatever"'', and
obey the contraints of that language. Or use some external
language (e.g. Corba) to define them. That's a completely
different problem, and largely irrelevant for most uses.

> In order to interop however, the vtable for the interface MUST
> be contiguous.

That depends entirely on the other language(s). In most cases,
you can't use virtual functions at all, without some sort of
intermediate code.

> Clearly if you are working in a ahomogonous c++ only
> environment you can use virtual like that. But, despite the
> c++ standards body being unwilling to acknoledge it, c++
> vtables *are* used for binary interop rendering this keyword
> worse than useless.

That is, of course, complete bullshit. *IF* you're writing to
some other language, then obviously, you have to respect the
contraints of that language, and work with a common subset.
(The most frequent case of this is, of course, C, since almost
all operating systems today define their API in C.) But except
for the OS API, that's really a rare case, and certainly not
something that most developers (or the standards committee)
need to take into consideration. (Also, FWIW: virtual
inheritance was around long before the standard.)

--
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 Oct 7, 8:07 am, anon <a...@no.invalid> wrote:
> Maik wrote:
> > On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
> >> Bingo, that did the job, thx!

> >>> class A
> >>> {
> >>> virtual void myfunc() = 0;
> >>> };

> >>> class B : public A
> >>> {

> > You should consider to prefer
> > class B : public virtual A
> > to avoid being bitten by:
> > http://www.parashift.com/c++-faq-lit...html#faq-25..8
> > which will most likely happen if one uses the interface pattern.

> I think that is worse performance wise then just this:
> class B : public A
> At least thats what I read
> here:http://www.agner.org/optimize/#optimize

Another site to avoid. If you have a performance problem,
measure and see. Until then, using virtual inheritance when
inheriting from an interface is probably a good idea; in
general, virtual inheritance should probably be the default.

--
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 2008-10-07 02:07:33 -0400, anon <anon@no.invalid> said:

> Maik wrote:
>> On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
>>> Bingo, that did the job, thx!
>>
>>>> class A
>>>> {
>>>> virtual void myfunc() = 0;
>>>> };
>>
>>>> class B : public A
>>>> {
>>
>> You should consider to prefer
>> class B : public virtual A
>> to avoid being bitten by:
>> http://www.parashift.com/c++-faq-lit....html#faq-25.8
>> which will most likely happen if one uses the interface pattern.
>
> I think that is worse performance wise then just this:
> class B : public A
> At least thats what I read here:
> http://www.agner.org/optimize/#optimize

And int is faster than double, so I won't use floating-point.
Unfortunately, that often gives the wrong answer.

Seriously: virtual and non-virtual inheritance have rather different
meanings, and performance concerns (whether real or imaginary) never
overrule correct semantics.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On 7 Okt., 08:07, anon <a...@no.invalid> wrote:
> Maik wrote:
> > You should consider to prefer
> > class B : public virtual A
> > to avoid being bitten by:
> > http://www.parashift.com/c++-faq-lit....html#faq-25.8
> > which will most likely happen if one uses the interface pattern.
>
> I think that is worse performance wise then just this:
> class B : public A
> At least thats what I read here:http://www.agner.org/optimize/#optimize

Hi! Virtual inheritance has worse performance, thats right. But as
long as an interface lookup at runtime triggers an much bigger chuck
of operations (say matrix operations or stl action) the over all
performance drop is small.

For performance critical parts I would even consider to avoid virtual
member functions. But for interfaces virtual inheritance is most
likely the way to go.

Best,
-- Maik

On 7 Okt., 10:46, "Chris Becke" <chris.be...@gmail.com> wrote:
> You cant do that. On many platforms interfaces are a binary interop used and supported by languages other than c++.
>
> In order to interop however, the vtable for the interface MUST be contiguous.
>
> Clearly if you are working in a ahomogonous c++ only environment you can use virtual like that. But, despite the c++ standards body being unwilling to acknoledge it, c++ vtables *are* used for binary interop rendering this keyword worse than useless.
>

The C++ interfaces pattern uses the C++ compiler and runtime library
to make a C++ developers life easier.

In case of closed source software an extra C-API might be sufficient
to support a big set of C/C++ compilers in different versions.

Heterogeneous software projects need other tools (SWIG, CORBA,
XPCom,... ).


Best,
-- Maik

PS: Top-Posting is evil

XPCom is little more than a pillage of Microsoft COM. Both, at their base level consist of declaring a C++ class containing pure virutal methods and compiling with a compatible compiler. Ensuring that even c++ interfaces intended to be used only by homogeneous (c++) code are nonetheless compatible at a binary level means that code can easilly move from a homogeneous to a heterogeneous environment.

Which is just good software engineering practice.

Not everyone uses c++. .so and .dll files are (depending on your platform) common ways to glue binary files (from teams with different toolsets) together .

The virtual keyword prevents that interface and any derived interfaces ever being exported in a binary compatible way (on compilers that otherwise produce interfaces in a way that DOES conform to COM/XPComs binary interface requirements). If you are developing reusable code you can never know how its going to need to be used in the future. don't shoot yourself in the foot and rely on this broken mechanism. It might be good "c++". but its bad computer science. It violates the earliest principals computer science students are taught about avoiding coupling.


"Maik" <Beckmann.Maik@googlemail.com> wrote in message news:88a7b48c-d154-4a8d-8ac8-49e05f15251f@w13g2000prm.googlegroups.com...
On 7 Okt., 10:46, "Chris Becke" <chris.be...@gmail.com> wrote:
> You cant do that. On many platforms interfaces are a binary interop used and supported by languages other than c++.
>
> In order to interop however, the vtable for the interface MUST be contiguous.
>
> Clearly if you are working in a ahomogonous c++ only environment you can use virtual like that. But, despite the c++ standards body being unwilling to acknoledge it, c++ vtables *are* used for binary interop rendering this keyword worse than useless.
>

The C++ interfaces pattern uses the C++ compiler and runtime library
to make a C++ developers life easier.

In case of closed source software an extra C-API might be sufficient
to support a big set of C/C++ compilers in different versions.

Heterogeneous software projects need other tools (SWIG, CORBA,
XPCom,... ).


Best,
-- Maik

PS: Top-Posting is evil

In article <1223538478.762256@vasbyt.isdsl.net>,
Chris Becke <chris.becke@gmail.com> wrote:
>XPCom is little more than a pillage of Microsoft COM. Both, at their
>base level consist of declaring a C++ class containing pure virutal
>methods and compiling with a compatible compiler. Ensuring that even c++
>interfaces intended to be used only by homogeneous (c++) code are
>nonetheless compatible at a binary level means that code can easilly
>move from a homogeneous to a heterogeneous environment.

Fine. But it has costs. For example:
- potential bugs due to multiple inheritance.
- slower development. Instead of using native C++ techniques, you
waste time jumping through hoops to ensure universal binary level
compatibility.

>Which is just good software engineering practice.

If it is needed.
You gorget a number of other "good software engiinering practices"
such as KISS, YAGNI and TANSTAAFL.

>Not everyone uses c++. .so and .dll files are (depending on your
>platform) common ways to glue binary files (from teams with different
>toolsets) together .

True. But two things: not everyone need C++ to offer binary level
compatibility with other languages. And most importantly, switch of
languages like that should be at (large) module boundaries. These
modules boundaries should have narrow and very well defined
interfaces. So it is a relatively trivial job to ensure that
interface that are meant to be used accross different language do
offer an appropriate binary compatible interface but for the rest, you
should use safe coding practices.

>The virtual keyword prevents that interface and any derived interfaces
>ever being exported in a binary compatible way (on compilers that
>otherwise produce interfaces in a way that DOES conform to COM/XPComs
>binary interface requirements). If you are developing reusable code you
>can never know how its going to need to be used in the future. don't
>shoot yourself in the foot and rely on this broken mechanism. It might
>be good "c++". but its bad computer science. It violates the earliest
>principals computer science students are taught about avoiding coupling.

Bull*****. That is not "avoiding coupling" you are preaching at all.
What you are saying is that no interface should use std::string, we
should all revert back to the good old days of bare buffer pointers
because maybe someone somewhere might possibly want to reuse our code
in a way that is not C++ compatible and won't be able to access
std::string. Who cares about buffer overflow, crashing applications
and speed of development, we must only use universally compatible
constructs in all interfaces that exist!

Facts:
- Not using virtual inheritance is dangerous in the case of multiple
inheritance
- Using virtual inheritance can break XPCOM binary requirements.

Solution:

Use virtual inheritance by default and use non-virtual in public,
exported to other language, XPCOM interfaces.

That seems very clear and simple to me.

Yannick

Chris Becke wrote:

Please stop top-posting and learn to quote correctly.

> Not everyone uses c++. .so and .dll files are (depending on your platform) common ways to glue binary files (from teams with different toolsets) together .

And the common means of doing that is to use C language wrappers.

--
Ian Collins.

On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.com> wrote:
> XPCom is little more than a pillage of Microsoft COM. Both, at
> their base level consist of declaring a C++ class containing
> pure virutal methods and compiling with a compatible compiler.
> Ensuring that even c++ interfaces intended to be used only by
> homogeneous (c++) code are nonetheless compatible at a binary
> level means that code can easilly move from a homogeneous to a
> heterogeneous environment.

> Which is just good software engineering practice.

So I shouldn't use classes, because some other component might
be written in C. For that matter, I shouldn't use struct,
because some other component might end up written in Fortran.

This is just plain stupid. You're code has (or should have)
well defined interfaces. Which support what they support. If
one of the requirements is that it be callable from another
language, then you use appropriate tools for this, depending on
which and how many languages are concerned. (Often, ``extern
"C"'' is all that is required.) But such interfaces normally
only occur at the component level, and represent a separate
interface from those used internally. And represent but a small
percent of your interfaces.

> Not everyone uses c++.

Of course, not. Cobol, and probably PHP, are more widely used,
for example.

> .so and .dll files are (depending on your platform) common
> ways to glue binary files (from teams with different toolsets)
> together .

Plugins are one technology, and of course, you're plugin
interface should be designed to support as many languages as
possible: no classes, for example, and possibly no struct's.

> The virtual keyword prevents that interface and any derived
> interfaces ever being exported in a binary compatible way (on
> compilers that otherwise produce interfaces in a way that DOES
> conform to COM/XPComs binary interface requirements).

The use of classes prevents this already. The question is
simply one of your requirements. If an interface has to support
multiple languages, you really can't present more than a POD at
the interface level. Most interfaces don't have such
constraints, however, and when you have such constraints, you
generally implement them using the facade pattern, so you can
use all of C++ in your implementation.

> If you are developing reusable code you can never know how its
> going to need to be used in the future.

That is, of course, bullshit. Code can only be used for that
for which it was designed for. If you don't provide an
interface callable from Cobol, or from PHP, your code can't be
called from those languages.

> don't shoot yourself in the foot and rely on this broken
> mechanism. It might be good "c++". but its bad computer
> science. It violates the earliest principals computer science
> students are taught about avoiding coupling.

I don't think you really understand software engineering. You
program to a requirements specification, and not to some
imaginary, mythical future use. Premature genericity is just as
bad a sin as premature optimization: you don't know what the
future will bring, or need. And implementing all of your
interfaces in ``extern "C"'', with just PODs (because that is
really what you've just said) is just plain stupid.

--
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 Oct 9, 11:36 am, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
> In article <1223538478.762...@vasbyt.isdsl.net>,
> Chris Becke <chris.be...@gmail.com> wrote:
> >XPCom is little more than a pillage of Microsoft COM. Both,
> >at their base level consist of declaring a C++ class
> >containing pure virutal methods and compiling with a
> >compatible compiler. Ensuring that even c++ interfaces
> >intended to be used only by homogeneous (c++) code are
> >nonetheless compatible at a binary level means that code can
> >easilly move from a homogeneous to a heterogeneous
> >environment.
>
> Fine. But it has costs. For example:
> - potential bugs due to multiple inheritance.
> - slower development. Instead of using native C++ techniques, you
> waste time jumping through hoops to ensure universal binary level
> compatibility.

I'm having problems figuring out what virtual inheritance has to
do with all this. Certainly, some languages might not support
it. But then, many of the most widely used languages outside of
C++ (e.g. Cobol, C) don't even support inheritance to begin
with.

If there is really a requirement that your component be usable
from other languages, then the best (most flexible) solution is
to define an interface for it using Corba, or something similar.
But that's normally just a facade, used to map your internal
interfaces (which are pure C++) to the outside world.

If your not really concerned about portability, and limit
yourself to the Unix/Windows world, and you're 100% sure that
the interface will never be called from another process
(possibly running on another machine), you can probably get away
with just making everything "C compatible".

And special cases require special solutions; if your component
must be called from Java, you'll implement the interface
according to JNI.

(I'm not familiar with COM, since I've never seen anyplace which
actually used it, but I think it falls somewhere between the
last two cases---probably closer to JNI than anything else.)

> >Which is just good software engineering practice.

> If it is needed. You gorget a number of other "good software
> engiinering practices" such as KISS, YAGNI and TANSTAAFL.

Not to mention that you'll want to test it. Until you've tested
that the component really can be called from Cobol, you have to
suppose that it can't be called from Cobol, regardless of the
"rules" you've supposedly followed.

Rejecting multiple inheritance on the grounds that by doing so,
your code will somehow miraculously be callable from another
language is just plain ignorant. The basic premise is false.

> >Not everyone uses c++. .so and .dll files are (depending on
> >your platform) common ways to glue binary files (from teams
> >with different toolsets) together .

> True. But two things: not everyone need C++ to offer binary
> level compatibility with other languages.

And no one has to offer it at all levels. At the most, you
offer it at the component level, for a pre-defined subset of
languages, using a pre-defined technology (e.g. Corba). And you
implement it using the facade pattern. (But I see you've more
or less hit on that on what followed.)

> And most importantly, switch of languages like that should be
> at (large) module boundaries. These modules boundaries should
> have narrow and very well defined interfaces. So it is a
> relatively trivial job to ensure that interface that are meant
> to be used accross different language do offer an appropriate
> binary compatible interface but for the rest, you should use
> safe coding practices.

> >The virtual keyword prevents that interface and any derived
> >interfaces ever being exported in a binary compatible way
> >(on compilers that otherwise produce interfaces in a way that
> >DOES conform to COM/XPComs binary interface requirements). If
> >you are developing reusable code you can never know how its
> >going to need to be used in the future. don't shoot yourself
> >in the foot and rely on this broken mechanism. It might be
> >good "c++". but its bad computer science. It violates the
> >earliest principals computer science students are taught
> >about avoiding coupling.

> Bull*****. That is not "avoiding coupling" you are preaching
> at all.

It's actually imposing an artificial coupling. Your code is
100% coupled to one particular technique of communicating
between components. Not a widely used one, either, from what I
can see.

> What you are saying is that no interface should use
> std::string, we should all revert back to the good old days of
> bare buffer pointers because maybe someone somewhere might
> possibly want to reuse our code in a way that is not C++
> compatible and won't be able to access std::string. Who
> cares about buffer overflow, crashing applications and speed
> of development, we must only use universally compatible
> constructs in all interfaces that exist!

> Facts:
> - Not using virtual inheritance is dangerous in the case of multiple
> inheritance
> - Using virtual inheritance can break XPCOM binary requirements.

> Solution:

> Use virtual inheritance by default and use non-virtual in
> public, exported to other language, XPCOM interfaces.

> That seems very clear and simple to me.

Exactly. Design and develop your component cleanly, then
provide whatever facades are needed to interface with whatever
is required.

--
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

I do not in any way wish to imply that c++ features should not be used.

I do think however that this is an area in which there is no "right" answer. It is perfectly valid sometimes to use virutal interfaces. But sometimes it is not.

The problem is, in *my* experience. Which is limited to my environment that is mostly Win32 development. In my experience, as soon as the interface pattern is considered for a c++ object, the level of abstraction that an interface implies makes it a very suitable canditate to be located in an external binary module.

At the same time, I do in fact prefer using PODs for data in interfaces. Again, in the environment im exposed to we have c++ code written a long time ago before the STL was stable, as well as a need to interop with other c++ frameworks that have their own ideas as to what constitutes a string (For eg). Interfaces, being very abstract, are the mechanism by which these different codebases (even when in the same compiled module) interop, and thus PODs as a least common denominator are the most convenient to work with. And frankly a lot easier to deal with.


"James Kanze" <james.kanze@gmail.com> wrote in message news:0c00706c-4ecd-47d3-92ea-1c5f0fd1bd54@a19g2000pra.googlegroups.com...
On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.com> wrote:
> XPCom is little more than a pillage of Microsoft COM. Both, at
> their base level consist of declaring a C++ class containing
> pure virutal methods and compiling with a compatible compiler.
> Ensuring that even c++ interfaces intended to be used only by
> homogeneous (c++) code are nonetheless compatible at a binary
> level means that code can easilly move from a homogeneous to a
> heterogeneous environment.

> Which is just good software engineering practice.

So I shouldn't use classes, because some other component might
be written in C. For that matter, I shouldn't use struct,
because some other component might end up written in Fortran.

This is just plain stupid. You're code has (or should have)
well defined interfaces. Which support what they support. If
one of the requirements is that it be callable from another
language, then you use appropriate tools for this, depending on
which and how many languages are concerned. (Often, ``extern
"C"'' is all that is required.) But such interfaces normally
only occur at the component level, and represent a separate
interface from those used internally. And represent but a small
percent of your interfaces.

> Not everyone uses c++.

Of course, not. Cobol, and probably PHP, are more widely used,
for example.

> .so and .dll files are (depending on your platform) common
> ways to glue binary files (from teams with different toolsets)
> together .

Plugins are one technology, and of course, you're plugin
interface should be designed to support as many languages as
possible: no classes, for example, and possibly no struct's.

> The virtual keyword prevents that interface and any derived
> interfaces ever being exported in a binary compatible way (on
> compilers that otherwise produce interfaces in a way that DOES
> conform to COM/XPComs binary interface requirements).

The use of classes prevents this already. The question is
simply one of your requirements. If an interface has to support
multiple languages, you really can't present more than a POD at
the interface level. Most interfaces don't have such
constraints, however, and when you have such constraints, you
generally implement them using the facade pattern, so you can
use all of C++ in your implementation.

> If you are developing reusable code you can never know how its
> going to need to be used in the future.

That is, of course, bullshit. Code can only be used for that
for which it was designed for. If you don't provide an
interface callable from Cobol, or from PHP, your code can't be
called from those languages.

> don't shoot yourself in the foot and rely on this broken
> mechanism. It might be good "c++". but its bad computer
> science. It violates the earliest principals computer science
> students are taught about avoiding coupling.

I don't think you really understand software engineering. You
program to a requirements specification, and not to some
imaginary, mythical future use. Premature genericity is just as
bad a sin as premature optimization: you don't know what the
future will bring, or need. And implementing all of your
interfaces in ``extern "C"'', with just PODs (because that is
really what you've just said) is just plain stupid.

--
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

Pete Becker wrote:
> On 2008-10-07 02:07:33 -0400, anon <anon@no.invalid> said:
>
>> Maik wrote:
>>> On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
>>>> Bingo, that did the job, thx!
>>>
>>>>> class A
>>>>> {
>>>>> virtual void myfunc() = 0;
>>>>> };
>>>
>>>>> class B : public A
>>>>> {
>>>
>>> You should consider to prefer
>>> class B : public virtual A
>>> to avoid being bitten by:
>>>
>>> http://www.parashift.com/c++-faq-lit....html#faq-25.8
>>> which will most likely happen if one uses the interface pattern.
>>
>> I think that is worse performance wise then just this:
>> class B : public A
>> At least thats what I read here:
>> http://www.agner.org/optimize/#optimize
>
> And int is faster than double, so I won't use floating-point.
> Unfortunately, that often gives the wrong answer.
>

What I suggested is "do not use it, unless you have to"

> Seriously: virtual and non-virtual inheritance have rather different
> meanings, and performance concerns (whether real or imaginary) never
> overrule correct semantics.
>

http://en.wikipedia.org/wiki/Virtual_inheritance explains my
understanding of the virtual inheritance.

You haven't said what are differences in virtual and non-virtual
inheritance meanings.

Whether I am going to use a virtual inheritance depends on the design,
and I would not suggest to people to use it because it might prevent a bug.

Maik wrote:
>
> member functions. But for interfaces virtual inheritance is most
> likely the way to go.

Why?

It depends how you design your interfaces.

anon wrote:
> You haven't said what are differences in virtual and non-virtual
> inheritance meanings.
>
> Whether I am going to use a virtual inheritance depends on the design,
> and I would not suggest to people to use it because it might prevent a bug.

The problem with multiple inheritance is that if the classes you are
inheriting from have a common base class and you *want* to use virtual
inheritance in order to merge those base classes into one, the only way
to do that is to go and modify these classes you are inheriting from.
You can't do it from your multiple-inherited class directly. Modifying
the base classes may not always be an option (eg. because they are in
precompiled libraries you don't have access to).

On Fri, 10 Oct 2008 11:09:31 +0200, Chris Becke wrote:

[...]

Please don't top-post and please learn to quote correctly.

--
Lionel B

Juha Nieminen wrote:
> anon wrote:
>> You haven't said what are differences in virtual and non-virtual
>> inheritance meanings.
>>
>> Whether I am going to use a virtual inheritance depends on the design,
>> and I would not suggest to people to use it because it might prevent a bug.
>
> The problem with multiple inheritance is that if the classes you are
> inheriting from have a common base class and you *want* to use virtual
> inheritance in order to merge those base classes into one, the only way
> to do that is to go and modify these classes you are inheriting from.
> You can't do it from your multiple-inherited class directly. Modifying
> the base classes may not always be an option (eg. because they are in
> precompiled libraries you don't have access to).

Great explanation! I never thought of that

On Oct 10, 11:09 am, anon <a...@no.invalid> wrote:
> Pete Becker wrote:
> > On 2008-10-07 02:07:33 -0400, anon <a...@no.invalid> said:

> >> Maik wrote:
> >>> On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.de> wrote:
> >>>> Bingo, that did the job, thx!

> >>&