By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,304 Members | 3,172 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,304 IT Pros & Developers. It's quick & easy.

Interfaces in C++

P: n/a
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

Oct 6 '08 #1
Share this Question
Share on Google+
23 Replies


P: n/a
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
Oct 6 '08 #2

P: n/a
Bingo, that did the job, thx!


"Victor Bazarov" <v.********@comAcast.netschrieb im Newsbeitrag
news:gc**********@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
Oct 6 '08 #3

P: n/a
On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
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
Oct 6 '08 #4

P: n/a
Maik wrote:
On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
>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
Oct 7 '08 #5

P: n/a
On Oct 7, 8:07 am, anon <a...@no.invalidwrote:
Maik wrote:
On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
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:ja*********@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

Oct 7 '08 #6

P: n/a
On 2008-10-07 02:07:33 -0400, anon <an**@no.invalidsaid:
Maik wrote:
>On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
>>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)

Oct 7 '08 #7

P: n/a
On 7 Okt., 08:07, anon <a...@no.invalidwrote:
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
Oct 7 '08 #8

P: n/a
In article <12***************@vasbyt.isdsl.net>,
Chris Becke <ch*********@gmail.comwrote:
>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

Oct 9 '08 #9

P: n/a
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.
Oct 9 '08 #10

P: n/a
On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.comwrote:
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:ja*********@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

Oct 10 '08 #11

P: n/a
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.comwrote:
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:ja*********@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
Oct 10 '08 #12

P: n/a
Pete Becker wrote:
On 2008-10-07 02:07:33 -0400, anon <an**@no.invalidsaid:
>Maik wrote:
>>On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
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.
Oct 10 '08 #13

P: n/a
Maik wrote:
>
member functions. But for interfaces virtual inheritance is most
likely the way to go.
Why?

It depends how you design your interfaces.
Oct 10 '08 #14

P: n/a
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" <ja*********@gmail.comwrote in message news:0c**********************************@a19g2000 pra.googlegroups.com...
On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.comwrote:
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:ja*********@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

Oct 10 '08 #15

P: n/a
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
Oct 10 '08 #16

P: n/a
On Oct 10, 11:09 am, anon <a...@no.invalidwrote:
Pete Becker wrote:
On 2008-10-07 02:07:33 -0400, anon <a...@no.invalidsaid:
Maik wrote:
On 6 Okt., 21:12, "A.Gallus" <u...@rz.uni-karlsruhe.dewrote:
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"
We're talking here about a very general case of an interface
which extends another interface. The correct "default" is to
use virtual inheritance, since it is always "correct"; with
non-virtual inheritance, you artificially restrict the ways the
client code can use the interface.
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...itanceexplains my
understanding of the virtual inheritance.
You haven't said what are differences in virtual and
non-virtual inheritance meanings.
He probably supposed that that was known.
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.
Certainly, it depends on the design. If I'm inheriting a
concrete implementation class directly from a single interface,
and the concrete implementation class is not designed to serve
further as a base class, then I don't bother with virtual
inheritance. If I'm extending an interface (in the sense that
Java uses the word "extends"), then I do, systematically. If
I'm providing a concrete implementation class which uses the
template method pattern to allow for further client
customization, it depends, but virtual inheritance has the
advantage of allowing more flexibility to the client.

--
James Kanze (GABI Software) email:ja*********@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
Oct 10 '08 #17

P: n/a
On Fri, 10 Oct 2008 11:09:31 +0200, Chris Becke wrote:
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.

I'm sure your making some important and interesting point here but I can't
read it because it scrolls of the screen about 20 feet.

Try using

%!fmt in vim or some other wrapping convention in the editor of your
choice so we can all share in the wealth of good ideas you present

Ruben

"James Kanze" <ja*********@gmail.comwrote in message news:0c**********************************@a19g2000 pra.googlegroups.com...
On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.comwrote:
>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.
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium

Oct 10 '08 #18

P: n/a
Outlook express is being really funny.
Its never been the worst news client, but this version has gone sideways.

"Ruben" <ru***@www2.mrbrklyn.comwrote in message news:pa****************************@www2.mrbrklyn. com...
On Fri, 10 Oct 2008 11:09:31 +0200, Chris Becke wrote:
>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.

I'm sure your making some important and interesting point here but I can't
read it because it scrolls of the screen about 20 feet.

Try using

%!fmt in vim or some other wrapping convention in the editor of your
choice so we can all share in the wealth of good ideas you present

Ruben

>"James Kanze" <ja*********@gmail.comwrote in message news:0c**********************************@a19g2000 pra.googlegroups.com...
On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.comwrote:
>>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.
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998

http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."

"I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."

© Copyright for the Digital Millennium
Oct 10 '08 #19

P: n/a
Chris Becke wrote:
Outlook express is being really funny.
Its never been the worst news client, but this version has gone sideways.
It must have if it keeps forcing you to top-post.

--
Ian Collins
Oct 10 '08 #20

P: n/a
Chris Becke wrote:
Outlook express is being really funny.
Its never been the worst news client, but this version has gone sideways.
I had been using it for a decade without top-posting. If
you want to stick to it, look at this:
http://home.in.tum.de/~jain/software/oe-quotefix/
[...]
Schobi
Oct 10 '08 #21

P: n/a
LR
James Kanze wrote:
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.
I believe that the current Cobol standard supports inheritance although
I haven't seen a recent standard. However, a visit to
http://www.cobolstandard.info/wg4/document.html offers plenty of
evidence that Cobol supports inheritance, MI and even some analogue of
template classes.

LR
Oct 10 '08 #22

P: n/a
Its not forcing me to top post. That I have been doing for a decade. and far prefer to the alternative.

It has gone sideways in that it isn't quoting correctly. And apparently screwing up line wrapping on sent documents.

"Ian Collins" <ia******@hotmail.comwrote in message news:6l************@mid.individual.net...
Chris Becke wrote:
>Outlook express is being really funny.
Its never been the worst news client, but this version has gone sideways.
It must have if it keeps forcing you to top-post.

--
Ian Collins
Oct 12 '08 #23

P: n/a
Chris Becke wrote:
Its not forcing me to top post. That I have been doing for a decade. and far prefer to the alternative.
You might want to think about this. At least in
technical groups, you're rather alone with this
preference.
[...]
Schobi
Oct 14 '08 #24

This discussion thread is closed

Replies have been disabled for this discussion.