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.