P
Pascal J. Bourguignon
James Kanze said:
Well of course. But I meant to dismiss errors that are signaled by a
compiler that would not be errors with a more dynamic language.
Well of course. But I meant to dismiss errors that are signaled by a
compiler that would not be errors with a more dynamic language.
S
SG
Regarding separating interface from implementation (.hpp/.cpp): The
Java folks don't seem to have a problem with the lack of header files.
They can write "interface XXX {...}" and/or just let the javadoc tool
generate some nice HTML documentation from the source code.
Cheers!
SG
B
Bo Persson
Jeff said:
Why not?
Discussing why interface and implementation is so much better than
header and implementation, sounds fun.
Bo Persson
W
woodbrian77
Ho ho ho.
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. 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. If the guts of your code include tons of tiny functions,
though, then making changes ought to be easy, not hard. 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>:
: 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;
}
This is, of course, an extremely simple case. In practice, the mess is
far worse.- Hide quoted text -
I tend to agree with you, but am glad that C++ permits both forms.
From a code generation perspective, being able to keep hand-written
interfaces separate from computer-written implementations is helpful
It would be a headache for me if I were trying to add computer-
written code to a file that had hand-written code. I wonder if
there are some Java developers out there who attempt that.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
J
James Kanze
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.
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.
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.
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.
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.
interface. One of the worst ways ever invented, but still
better than nothing.
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.
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.
template<class Coordinate>
point<Coordinate>:
: m_x( x )
, m_y( 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.
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.
N
Noah Roberts
Jeff said:Ho ho ho.
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).
I often purposfully set it up so that I can write entire sets of classes
within cpp files only. The "interface" of the class in these cases is
already defined as an abstract base in a header. Then I simply have to
add a way to register the class with a factory of some sort upon program
startup, usually with a "bool register()" and some macros so I'm not
writing "namespace { bool b = factory::register(new object); }" all the
time.
It's a misnomer to assume that every class has its own public interface.
Some simply implement one that is shared by many others.
When the class being implemented does have a public interface of its own
though, I usually do separate it into cpp and h files unless it's some
sort of utility file I want to have as header only.
J
Jorgen Grahn
I don't think I have heard RTTI and exceptions being accused of
causing code bloat before. People usually complain about the standard
containers and iostreams.
But keep in mind that "embedded systems" often translates to "a
full-blown computer running Linux, but with a bit of flash memory
instead of disk" these days. Some people call it "embedded" as soon
as there is custom hardware involved -- even if there are gigabytes of
RAM and disk, and a few hundred CPUs, and it runs Unix.
GCC rules in that market, of course.
/Jorgen
J
James Kanze
Exceptions do tend to increase code size considerably, at least
with the most efficient implementations. (On the other hand,
I've not found std::vector making my programs any bigger than
they would have been otherwise.)
There are many different levels of "embedded": I've worked on
"embedded" systems which ran on a Sun Sparc, under Solaris, with
a moderate sized disk. I've also worked on embedded systems
with only 64 bytes of RAM and 2 KBytes of ROM. On the first, we
used full C++, with all the bells and whistles the compiler
supported at the time. On the second, we used assembler---even
C resulted in too much code bloat (or rather, too much RAM being
used).
Or the native C++ of the platform. (I've seen more HP CC and
Sun CC than G++ in this field.)
B
Balog Pal
figure out why.
Because the compiler coverage is still weak. I thought in 2009 this can't be
the case but it is...
I.e. I currently make a project on PIC24 family, that have only 4 compilers
at all, 3 C and only one having C++. The last one starts at some 2000 GBP
and doubtful evaluation...
While the chip is pretty low on resources (like it has 16K ram in all, for
everything).
Going back to C is a pain in the ass, but buying in the monopoly did not
seem feasible.
Too bad we don't have some really standalone C++ -> C converter, I would
definitely use that for some portions. (I checked out Cameau they reserve
any custiom tailoring, and do not allow intermediate files of stock version
used like that...)
The 'native' compiler for the chip by MPLAB is based on gcc, I don't really
get why then it can't have C++ too either directly or indirectly -- but that
is the case. (unless I missed something on the road).
T
Tony
James said:
I would say that headers are the C way and that pure ABCs are the C++ way.
T
Tony
James said:
But he said he wanted a Masters in C++. Maybe he wants to actually do
something with the language instead of becoming a language lawyer.
B
Bo Persson
Tony said:
No, ABCs are the OO fundamentalist way - everything is dynamically
allocated, polymorphic, and all functions are virtual?
C++ doesn't stop you from doing that, but it isn't a good way to use
C++.
Bo Persson
T
Tony
Bo said:
Do I note a bit of agenda in your tone? C'mon, say what you really want to.
Use of interfaces (aka, pure ABCs) doesn't mean that at all.
Ha!
J
joshuamaurice
For example, the STL. I would consider it a (mostly) excellent
interface to useful libraries. There is little to no virtual in it,
and basically no abstract base classes either. OO is cool, but virtual
functions, runtime dynamic dispatch, class inheritance, etc., is not
always the best way to solve something.
Sometimes you don't want an implementation class, and a factory;
sometimes you just want a concrete class. Maybe for runtime
efficiency. Maybe for for sanity.
For example, I once saw some production code where OO took over and
ran amok. For some editor class, it had:
- An interface X
- an impl Ximpl
- an interface and impl class for every function in X to implement the
named parameter idiom.
- a factory for every single impl class.
It should have been one concrete top level class, and maybe a concrete
nested inner class per function for the named parameter idiom. Their
use of "good OO" was total overkill. It more than 4x'd the lines of
code for basically no good reason, adding maintenance cost and runtime
cost.
(Their argument was that it was to allow mocking the implementations
for unit testing. I called bull on that. Each class was only ~200
lines. There was no good reason to mock it. You could thoroughly test
it as is, and it's simple and concrete enough that mocking it to test
other components in unit tests is overkill. Way too much developer
time wasted when writing simple acceptance tests without mock would
have actually had higher coverage. PS: To this day, they haven't
actually mocked it to write those unit tests.)