Re: Applications of C++
On May 9, 5:39 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
Bo Persson wrote:
Jeff Schwab wrote:
SG wrote:
Discussing why interface and implementation is so much
better than header and implementation, sounds fun. :-)
The point is that "headers" are the C++ way of specifying an
interface. One of the worst ways ever invented, but still
better than nothing.
If you write lots of small classes and functions, then
maintaining separate declarations and definitions causes an
absurd amount of source code bloat (nearly 2x). There is also
the maintenance headache of keeping function signatures up to
date.
There are tools that can help. But the point is that it should
require a significant amount of work to change the signature of
a function. Changing the signature breaks client code, and
shouldn't be done lightly.
For high-level interfaces, there's no problem, because the
interfaces are meant to be stable; arguably, changes to the
overall interface of an application ought to be difficult.
Exactly.
If the guts of your code include tons of tiny functions,
though, then making changes ought to be easy, not hard.
There's no way you can avoid having to modify client code. If a
function is used in a hundred different places in client code,
you have to modify a hundred different places in your code base
anytime you change it. That's a lot of work at the coding
level, and in anything but the smallest projects, it also
involves significant manageerial work, in order to synchronize
the changes (in different groups).
Obviously, this only applies to classes and functions which are
"exported"---made available to client code. For classes which
are private, the only real argument for not putting the function
bodies in the class is readability, and that really doesn't
apply if the classes and the functions are simple enough. And
of course, for the most private classes, those with block scope,
you don't have a choice anyway.
For
example, I vastly prefer this:
template<class Coordinate>
class point
{
Coordinate m_x;
Coordinate m_y;
public:
typedef Coordinate coordinate;
point(coordinate x, coordinate y )
: m_x( x )
, m_y( y ) { }
coordinate x() const {
return m_x;
}
coordinate y() const {
return m_y;
}
};
To that:
template<class Coordinate>
class point
{
Coordinate m_x;
Coordinate m_y;
public:
typedef Coordinate coordinate;
point(coordinate x, coordinate y );
coordinate x() const;
coordinate y() const;
};
template<class Coordinate>
point<Coordinate>::point(coordinate x, coordinate y)
: m_x( x )
, m_y( y ) { }
template<class Coordinate>
typename point<Coordinate>::coordinate
point<Coordinate>::x() const {
return m_x;
}
template<class Coordinate>
typename point<Coordinate>::coordinate
point<Coordinate>::y() const {
return m_y;
}
Templates are a bit tricky, unless you have a compiler which
supports export. What I'd really prefer is the second, but with
the template exported, and the function definitions in another
file, which isn't visible to the client.
This is, of course, an extremely simple case. In practice,
the mess is far worse.
Rather, this is an extremely simple case, where your solution
works (the class is really nothing more than a struct anyway).
But your solution doesn't scale.
In fact, of course, a lot depends on context. In some of the
more basic modules I write, where templates are involved, I'll
use a mixture. At the application level, however, anything that
is exported will not contain the implementation in a header
file.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34