Compiler Firewall Idiom
Bill Seymour
I've found a few references in DejaNews; but they're all
either suggestions to use the idiom or statements that the
author uses the idiom. I was unable to find a description.
Thanks,
--Bill Seymour
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Biju Thomas
>
> Could someone please explain the "compiler firewall idiom?"
> I've found a few references in DejaNews; but they're all
> either suggestions to use the idiom or statements that the
> author uses the idiom. I was unable to find a description.
>
I think that 'compiler firewall idiom' is another name for 'pimpl
idiom', which should be a familiar term for most people here.
--
Biju Thomas
blargg
> Bill Seymour wrote:
> >
> > Could someone please explain the "compiler firewall idiom?"
> > I've found a few references in DejaNews; but they're all
> > either suggestions to use the idiom or statements that the
> > author uses the idiom. I was unable to find a description.
>
> I think that 'compiler firewall idiom' is another name for 'pimpl
> idiom', which should be a familiar term for most people here.
Insulating interface - insulate users from implementation details. The
reason is to totally insulate users from any changes you might make to
your implementation. This allows binary compatibility - compiled code
using your interface doesn't have to be recompiled when the implementation
changes, this allowing updates to your implementation at the binary level.
It gives you total freedom in your implementation. Another benefit is
greatly reduced header file (interface) dependencies, thus speeding
compilation for users. This isn't just a convenience thing "wow I can
compile 20 seconds faster" - for some systems, the compilation time saved
can be measured in *days*. In these systems it's a necessity.
// interface - fully insulating
class Foo {
struct Impl;
Impl* p_impl;
// have to provide these if we are fully insulating
Foo( Foo const& );
Foo& operator = ( Foo const& );
public:
Foo();
~Foo();
// ...
};
// implementation
struct Foo::Imp {
// ...
// member data *and* functions
};
Foo::Foo() : p_impl( new Impl ) { }
Foo::~Foo() { delete p_impl; }
alan_gr...@my-deja.com
Bill Seymour <bs...@pobox.com> wrote:
> Could someone please explain the "compiler firewall idiom?"
> I've found a few references in DejaNews; but they're all
> either suggestions to use the idiom or statements that the
> author uses the idiom. I was unable to find a description.
Not by the same name, but...
http://www.octopull.demon.co.uk/c++/implementation_hiding.html
--
Alan Griffiths (alan.gr...@experian.com, +44
115 934 4517)
Senior Systems Consultant, Experian
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Dave Brosius
Biju Thomas wrote in message <37BA2FDD...@ibm.net>...
>Bill Seymour wrote:
>>
>> Could someone please explain the "compiler firewall idiom?"
>> I've found a few references in DejaNews; but they're all
>> either suggestions to use the idiom or statements that the
>> author uses the idiom. I was unable to find a description.
>>
>
>I think that 'compiler firewall idiom' is another name for 'pimpl
>idiom', which should be a familiar term for most people here.
>
>--
>Biju Thomas
Harry Erwin
> Could someone please explain the "compiler firewall idiom?"
> I've found a few references in DejaNews; but they're all
> either suggestions to use the idiom or statements that the
> author uses the idiom. I was unable to find a description.
>
Is there a FAQ available?
--
Harry Erwin, <http://mason.gmu.edu/~herwin>, Sr SW Analyst,
PhD cand (informatics/computational sci) modeling how bats
echolocate (def Sept), and Adj Prof of CS (data struct/adv C++).
ash...@my-deja.com
> > >
> > > Could someone please explain the "compiler firewall idiom?"
> > > I've found a few references in DejaNews; but they're all
> > > either suggestions to use the idiom or statements that the
> > > author uses the idiom. I was unable to find a description.
> >
> > idiom', which should be a familiar term for most people here.
>
> reason is to totally insulate users from any changes you might make to
> your implementation. This allows binary compatibility - compiled code
> using your interface doesn't have to be recompiled when the
implementation
> changes, this allowing updates to your implementation at the binary
level.
That is quite a strong statement you have made. And, I feel it has a
few assumptions, that the code generated is in DLL's (Windows) or
libraries (Unix).
Like for example if I write a class 'CfiClass' which supports this idiom
and a client of this class compiles the whole thing together into a
single a.out (with no libraries). Thus, when I change the implementation
of CfiClass the client will have to recompile the whole thing ...right.
On the other hand, if my implementation is present in a library then
when I change the implementation of CfiClass, the client of my class
will not have to recompile the whole code but just recompile the library
which contains the implementation of CfiClass.
BTW CfiClass = Compiler Firewall Idiom Class
I hope my understanding is correct here. If I am wrong, can someone
correct me.
I completely agree with the other advantages that you have mentioned.
Ash
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
blargg
> In article <user-18089...@aus-as5-132.io.com>,
> postmast.ro...@iname.com (blargg) wrote:
[compiler firewall idiom?]
> > Insulating interface - insulate users from implementation details. The
> > reason is to totally insulate users from any changes you might make to
> > your implementation. This allows binary compatibility - compiled code
> > using your interface doesn't have to be recompiled when the
> > implementation changes, this allowing updates to your implementation
> > at the binary level.
>
> That is quite a strong statement you have made.
It was general, so you can certainly find specific cases where it is not
the case on a particular system.
> And, I feel it has a
> few assumptions, that the code generated is in DLL's (Windows) or
> libraries (Unix).
Nope. It works even in a "closed" program - changes to the implementation
don't require recompilation of user code. This carries over to the
library/DLL situation.
> Like for example if I write a class 'CfiClass' which supports this idiom
> and a client of this class compiles the whole thing together into a
> single a.out (with no libraries). Thus, when I change the implementation
> of CfiClass the client will have to recompile the whole thing ...right.
No. Only the implementation module of CfiClass will have to be recompiled.
(I'm renaming CfiClass to Insulated because I don't know what the hell
"CfiClass" is supposed to mean)
// insulated.h
class Insulated {
struct Impl;
Impl* impl;
Insulated( Insulated const& );
Insulated& operator = ( Insulated const& );
public:
Insulated();
~Insulated();
};
// insulated.cpp
struct Insulated::Impl {
// ...
};
Insulated::Insulated() : impl( new Impl ) { }
Insulated::~Insulated() { delete impl; }
// user.cpp
#include "insulated.h"
int main() {
Insulated ins;
}
Any changes to the implementation of Insulated will only require changes
to its source file "insulated.cpp". Because of this, only the source file
will have to be recompiled when the implementation is changed.
> On the other hand, if my implementation is present in a library then
> when I change the implementation of CfiClass, the client of my class
> will not have to recompile the whole code but just recompile the library
> which contains the implementation of CfiClass.
I don't see the difference. Either way *only* the implementation file has
to be recompiled. The user source never has to be recompiled in either
case.
Clearly in the case of static linking (all code in the program - no use of
shared libraries) the program will have to be regenerated (linked) if the
implementation of Insulated changes, since the compiled code will have to
change (duh :-).
> BTW CfiClass = Compiler Firewall Idiom Class
Ahhhh. For this example code, I think such a name is an overkill :-)
> I hope my understanding is correct here. If I am wrong, can someone
> correct me.
>
> I completely agree with the other advantages that you have mentioned.
I recommend to everyone Lakos "Large-Scale C++ Software Design".
John Potter
: Could someone please explain the "compiler firewall idiom?"
: I've found a few references in DejaNews; but they're all
: either suggestions to use the idiom or statements that the
: author uses the idiom. I was unable to find a description.
Maybe "idiom" is the problem. The responses have claimed that the
pimpl idiom is the compiler firewall idiom. I accept the pimple
idiom as _a_ compiler firewall, but an ABC can also function as
a compiler firewall.
Assume include guards
// consumer.h
class Consumer {
public :
virtual ~Consumer () { }
virtual void consume (SomeThing&) = 0;
};
// consumera.h
#include "consumer.h"
class ConsumerA : public Consumer {
public :
void consume (SomeThing&);
};
// producera.h
#include "consumer.h"
class ProducerA {
public :
ProducerA (Consumer&);
};
// main.cpp
#include "producera.h"
#include "consumera.h"
int main () {
ConsumerA con;
ProducerA pro(con);
}
The main can be changed to use another consumer/producer and be
recompiled and linked with the existing objects. The implementation
of a producer can be changed, compiled and linked with the existing
main and consumer. The implementation of a consumer can be changed,
compiled and linked with the existing main and producer.
The real firewall here is the fact that the producer knows nothing
about any of the concrete consumer classes, and the consumer classes
know nothing about a producer at all. This is a pusher pattern, but
the puller pattern would work as well with an ABC Producer.
Lacking any accepted reference with a deffinition of "compiler
firewall idiom", I conclude that a "compiler firewall" is any
practice which isolates changes to one translation unit from other
translation units. More than one idiom exists.
John