Re: C++ Object model
On Jun 11, 7:28 pm, Noah Roberts <u...@example.net> wrote:
Jerry Coffin wrote:
In article <066658ab-70b5-4d70-9a51-01dbd471d5c3
@r37g2000prm.googlegroups.com>, sumsin...@gmail.com says...
[ ... ]
Ok, lets we don't talk about virtual member functions. So
if I add any normal function then will it force the
recompilation?
Most of these questions are almost entirely theoretical, and
even in theory don't have much in the way of solid answers.
In practice, you use make, which only looks at the last
modified time on the _file_ -- if you make _any_ change in a
header (even something like adding a comment that can't
possibly have any real effect) it'll re- compile everything
that you've said depends on that file, unless you use touch
(or something similar) to prevent if from doing so.
This isn't the only reason. This compilation issue is caused
by the object model itself. Nobody's really touched on this.
That's what everyone has been talking about. Change a
non-static member, and you have to recompile everything.
Imagine:
class Object
{
int x;
public:
bool f() const; // implementation in .cpp file
};
Now, you need to change the implementation of Object so that x
is no longer an int. You're not actually changing ANYTHING
about the interface; you're not adding functionality. The
changes to f() occur inside the .cpp file so that it does what
it did but with x being a double now. No other object should
need to know that x has changed its type...you've followed
correct design and there is no coupling in your design here.
This is a known "weakness" of C++. It's the price we pay for
being able to allocate objects on the stack (and still use the
usual tools for linking, etc.), rather than being forced to
allocate everything dynamically.
If you really, really know the compiler, you can sometimes play
tricks (although I wouldn't do so except for quick and dirty
tests). If you change the int to a float, for example, there
are a number of compilers where you can get away with
back-dating the header and reinvoking make. I actually did this
once: faced with a six hour build time if I followed the rules,
and knowing that the only data in the class was a pointer, and
that all I'd done was add some private non-virtual functions and
changed the type of the pointer (in fact, the entire
representation of the class was changed, but that was hidden
behind the pointer), I back-dated the header, rebuilt, and ran a
few tests. After they worked, I touched the header again,
started the build, and went home (it was late Saturday
afternoon).
This requires pretty good knowledge about the compiler, however,
and even then, shouldn't be done in a production
environment---it's not worth the risk.
[...]
Personally, I feel that the pimpl idiom is actually more
important as a fix to exception safety issues and the
compilation time save is just a bonus. There are several
instances where exception safety can only be provided through
the use of a pimpl.
I presume you are talking globally about exception safety; using
the pimpl idiom doesn't affect exception safety in the
constructors, but it certainly makes it easier in the assignment
operator.
As for compile times... You must work on very small projects if
it doesn't make a significant difference. In the case
mentionned above (admittedly, some time ago, on significantly
older equipment), it made a difference between something like
six hours, and less than a minute. (The total code base on the
project was something over a million lines, and every single
module used the class I'd just modified.)
--
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