pimpl or precompiled headers?

[Asfand Yar Qazi]

Hi,

Now that GCC 3.4 has precompiled headers, I'm thinking I can stop
using pimpls to speed up development time, as it may make life
easier (declaring pimpls takes a long time...)

What are the views of the experienced users of various C++
implementations? Do precompiled headers allow pimpls to be
avoided while maintaining the same speed up of development time?

 

[Phlip]

Now that GCC 3.4 has precompiled headers, I'm thinking I can stop
using pimpls to speed up development time, as it may make life
easier (declaring pimpls takes a long time...)

What are the views of the experienced users of various C++
implementations? Do precompiled headers allow pimpls to be
avoided while maintaining the same speed up of development time?

"Pimpl" is an idiom that one refactors into existing code to compile faster.

Refactors change design while leaving behavior the same. The Pimpl refactor
leaves logical design the same while tweaking physical design, so
translation units needn't see the details of other classes. That prevents
excessive recompiles when you change a highly reused class.

But Pimpl is for emergencies, after a design is committed. C++ was designed
to permit compilation firewalls based on abstract types; Pimpl abstracts a
concrete type.

Robert C. Martin's "Dependency Inversion Principle" describes this design
goal.

http://www.objectmentor.com/resources/articles/dip.pdf

It implies that only classes with a few pure-virtual methods should be
widely re-used. This is both a valid design technique and a system that, in
C++, prevents runaway re-compiles.

 

[Alf P. Steinbach]

It implies that only classes with a few pure-virtual methods should be
widely re-used. This is both a valid design technique and a system that, in
C++, prevents runaway re-compiles.

You've posted this rubbish before. So in your opinion the standard library
is all wrong. Duh, idiot.

 

[Philipp Bachmann]

Now that GCC 3.4 has precompiled headers, I'm thinking I can stop

"Pimpl" is an idiom that one refactors into existing code to compile faster.

"Pimpl" has at least an additional advantage as discussed by Herb Sutter:
It can lead to exception safe assignment. No precompiled header system
can do this.

C++ was designed
to permit compilation firewalls based on abstract types;

In my opinion, this only holds if you supplement your concrete, derived class
with a factory function - otherwise you've to include the header file
of your derived class into each file, where you create an instance, though
besides this creation step you only need the declaration of the base class.

Personally, I'd prefer Pimpl over precompiled headers because of two
reasons:
- The precompiled header system of many compilers is limited and would
cause additional considerations on usage.
- Often it is sufficient to reduce compile time not to include unnecessary header
files. With precompiled headers commenting out inclusion somewhere doesn't
necessarily causes a compile error, if the file is needed, so you have less
support by your compiler.

Cheers,
Philipp.

 

[Siemel Naran]

Now that GCC 3.4 has precompiled headers, I'm thinking I can stop
using pimpls to speed up development time, as it may make life
easier (declaring pimpls takes a long time...)

What are the views of the experienced users of various C++
implementations? Do precompiled headers allow pimpls to be
avoided while maintaining the same speed up of development time?

If you want reference counting, then surely you have to use the pimpl.

In principle your question is good, but I haven't done measurements so can't
say. Let's see what others say. In principle, it should be faster, so as
soon as the code is stable, we can start to use pre-compiled headers.

 

[Alf P. Steinbach]

If you want reference counting, then surely you have to use the pimpl.

In principle your question is good, but I haven't done measurements so can't
say. Let's see what others say. In principle, it should be faster, so as
soon as the code is stable, we can start to use pre-compiled headers.

The pimpl idiom is not necessary for speeding up compiles; all that's needed
for that is Lakos-style external include guards.

The pimpl idiom is not necessary for reference counting; it isn't even related.

I think perhaps pimpl is being used above in two different senses, both of them
different from the usual C++ meaning of class-with-only-pointer-to-implementation
in header file, class-with-implementation (plus header file dependencies for that
implementation) in the implementation file.

 

[Siemel Naran]

message


The pimpl idiom is not necessary for speeding up compiles; all that's needed
for that is Lakos-style external include guards.

If C.h includes B.h includes A.h, and you change A.h by adding new data
members, then you have to compile not only A.cpp and B.cpp and C.cpp. Had
you used pimpl, you'd have to compile the same or fewer files, the number
depending on whether you changed A.cpp only (to add new data members and use
them in the implementation) or A.h also (to add new public/protected member
functions to expose the new data members), depending on whether B.h includes
A.h or only B.cpp includes A.h, etc. In the common case of adding data
members only to A.cpp, for optimization or whatever reasons, you now don't
have to compile B.cpp and C.cpp.

The Lakos style redundant include guards are, they say, no longer necessary
in today's modern compilers.

The pimpl idiom is not necessary for reference counting; it isn't even

related.

It is similar. In traditional pimpl you declare a struct Class::Imp in the
header file, and Class contains a std::auto_ptr<Imp> or Imp*, and you define
Class::Imp in the cpp file. To add reference counting, just change the