Sutter's Pimples: Good, Bad, or Ugly?

[Steven T. Hatton]

Pete Vilder mentioned this a few days back. This is the "Compiler-Firewall
Idiom", or pimple. It's similar to an approach taken in some Java designs.
AAMOF, when I saw it in Java, my first reaction was "Oh by Þor! It's
freakin' headers all over again!"

My greatest misgiving about the approach is that it seems overly
complicated. I /feel/ as if there is a better more 'conventional' way of
dealing with the separation of interface and implementation. OTOH, it's
clear to me that the people who have advocated it are not stupid.*

Here's the discussion: http://www.gotw.ca/publications/mill05.htm

What do you make of it?

*(Sutter does serve the Dark Lord, but that's a different story. Lippman,
too has passed into darkness.)

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

Alf P. Steinbach wrote:

* "Steven T. Hatton" <su******@setid ava.kushan.aa> schriebt:

Phlip wrote:

> 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.

That was the kind of answer I was looking for.

I'm hereby giving up on you. You chose the only response that was all
dress
and no actual content. That fancy dressed "girl" is a boy, Steven.

I didn't say it was the correct answer. All I intended was that it seems to
suggest there are better ways to address some or most circumstances in
which the CFI would be used. I have to say the concern about compile time
makes me a bit uneasy. If anything, I would say the long compile times are
a symptom not the disease.

So, I was looking at Martin's book, but I bought these instead:
http://www.josuttis.com/libbook/index.html
http://www.oreilly.com/catalog/cpluspluspr/

Have I gained any redemption?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Phlip]

Alf P. Steinbach wrote:

Steven T. Hatton schriebt:

Phlip wrote:

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.

That was the kind of answer I was looking for.

I'm hereby giving up on you. You chose the only response that was all dress and no actual content. That fancy dressed "girl" is a boy, Steven.

Did I step into the middle of something?

I don't see how a synopsis of DIP in C++ terms, to avoid Pimpl, scores as
"no actual content". Defend your statement.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Phlip]

Steven T. Hatton wrote:

I didn't say it was the correct answer. All I intended was that it seems to suggest there are better ways to address some or most circumstances in
which the CFI would be used. I have to say the concern about compile time
makes me a bit uneasy. If anything, I would say the long compile times are a symptom not the disease.
The implication is a healthy design in C++ naturally firewalls compilation
without extra effort.
So, I was looking at Martin's book, but I bought these instead:
http://www.josuttis.com/libbook/index.html
http://www.oreilly.com/catalog/cpluspluspr/

Have I gained any redemption?

No. Get Martin's book too. And /Design & Evolution of C++/ by Bjarne.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Alf P. Steinbach]

* "Phlip" <ph*******@yaho o.com> schriebt:

Alf P. Steinbach wrote:

Steven T. Hatton schriebt:

Phlip wrote: 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. That was the kind of answer I was looking for.

I'm hereby giving up on you. You chose the only response that was all

dress

and no actual content. That fancy dressed "girl" is a boy, Steven.

Did I step into the middle of something?

Nope, you just gave meaningless advice.

I don't see how a synopsis of DIP in C++ terms, to avoid Pimpl, scores as
"no actual content". Defend your statement.

It's really you who should defend why DIP ("Dependency Inversion Principle",
a silly elevation of the common notion of abstract interface to acronym
status) is a description of pimpl -- which it isn't. Now you state that
is a way to avoid pimpl. Well, it isn't that either.

It is an alternative to pimpl in the case where you don't need implementation
inheritance, as I noted & described in one short sentence in my first posting
in this thread -- read that single sentence instead of Mr Martins ramblings.

Mr Martin uses umpteen pages of text and a lot of impenetrable language and
trivialities, including inventing new terminology, to try to get across the
simple, trivial point of how an abstract interface works (which I did in one
sentence), without quite managing it, and does not even mention pimpl as far
as I can see. Nor did it seem like he mentioned implementation inheritance.
But I just skimmed the thing right now to see roughly what he was trying to
write this time, in case your response meant he actually wrote something.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Phlip]

Alf P. Steinbach wrote:

Mr Martin uses umpteen pages of text and a lot of impenetrable language and trivialities, including inventing new terminology, to try to get across the simple, trivial point of how an abstract interface works (which I did in one sentence), without quite managing it, and does not even mention pimpl as far as I can see. Nor did it seem like he mentioned implementation inheritance. But I just skimmed the thing right now to see roughly what he was trying to write this time, in case your response meant he actually wrote something.

Okay. I thought you might have a point, or might have understood ours. No
such luck.

To anyone else who has followed this far: Both Lakos and Martin advise to
break a dependency cycle with an abstract bases class, even if there's no
other reason for one to exist.

Martin doesn't mention Pimpl because it's not a goal, it's a temporary hack.
Don't write that which you must then retract.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

[Pete Vidler]

Phlip wrote:
[snip]

To anyone else who has followed this far: Both Lakos and Martin advise to
break a dependency cycle with an abstract bases class, even if there's no
other reason for one to exist.
A fully abstract base class seems like a lot of effort just to break a
dependency. Certainly there are many other reasons to use them, but I
don't think I would create one just for this.
Martin doesn't mention Pimpl because it's not a goal, it's a temporary hack.
Don't write that which you must then retract.

I don't see anything temporary (or hackish) about pimpl. Can you clarify?

-- Pete

[Alf P. Steinbach]

* "Phlip" <ph*******@yaho o.com> schriebt:

Okay. I thought you might have a point, or might have understood ours. No
such luck.

What I understand from your writings is that you pass about silly acronyms,
and that you know a quite a few ways to steer a discussion away from the
technical and to the personal while giving the impression of being reasonable.

So it's probably futile to ask whether you have a C++-related point.

Goodbye, phlip.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Claudio Puviani]

"Pete Vidler" <pv*****@mailbl ocks.com> wrote

Phlip wrote:
[snip]

To anyone else who has followed this far: Both Lakos
and Martin advise to break a dependency cycle with
an abstract bases class, even if there's no other reason
for one to exist.
A fully abstract base class seems like a lot of effort just
to break a dependency.

No effort is too great to eliminate unncessary dependencies. It wouldn't be
an exaggeration to say that gratuitous coupling is the software world's
biggest failing.
Certainly there are many other reasons to use them,
but I don't think I would create one just for this.

You would if you worked in an environment that doesn't allow lazy shortcuts.

Martin doesn't mention Pimpl because it's not a goal,
it's a temporary hack. Don't write that which you must
then retract.

I don't see anything temporary (or hackish) about pimpl.
Can you clarify?

Temporary or not, it's definitely a hack that's meant to circumvent C++'s
integration of some implementation details in the interface. There's nothing
elegant about the pimpl idiom. It's just a solution to a certain class of
problems.

Claudio Puviani

[Alf P. Steinbach]

* "Claudio Puviani" <pu*****@hotmai l.com> schriebt:

No effort is too great to eliminate unncessary dependencies.

If only more folks did invest that effort...

Certainly there are many other reasons to use them,
but I don't think I would create one just for this.

You would if you worked in an environment that doesn't allow lazy shortcuts.

What are some examples of lazy shortcuts for this problem (header file
dependency) in C++?

Martin doesn't mention Pimpl because it's not a goal,
it's a temporary hack. Don't write that which you must
then retract.

I don't see anything temporary (or hackish) about pimpl.
Can you clarify?

Temporary or not, it's definitely a hack that's meant to circumvent C++'s
integration of some implementation details in the interface.

No need to resort to name calling. It's a technique. Like most everything
in C++ it's at a lower level than the conceptual abstraction, but it's not
particularly clever or elegant, nor particularly low-level, so it is in no
sense that I recognize a hack, and using a derogatory term for it seems to be
in conflict with your first implied wish that it be used more (not less).

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Phlip]

Pete Vidler wrote:

Phlip wrote:

To anyone else who has followed this far: Both Lakos and Martin advise to break a dependency cycle with an abstract bases class, even if there's no other reason for one to exist.

A fully abstract base class seems like a lot of effort just to break a
dependency. Certainly there are many other reasons to use them, but I
don't think I would create one just for this.

It's better than a Pimpl.

Martin doesn't mention Pimpl because it's not a goal, it's a temporary hack. Don't write that which you must then retract.

I don't see anything temporary (or hackish) about pimpl. Can you clarify?

Define "coupling" as "X must change only because Y changed".

C++ has a special category of coupling, which is "X must recompile only
because Y's header's recompiled". If you have compile-time coupling, the
odds are very high you also have logical coupling. Changing Y requires you
to re-think X. (Contrarily, low-compile time coupling is not evidence of low
logical coupling!)

Cleaning up logical coupling, in C++, typically leads to less compile-time
coupling. But the best way to do that is abstract base classes - which only
contain a bunch of pure virtual methods, and maybe some constants. No
behavior, no extra #include headers, etc. So they are like Pimpl, but they
reflect logical design advances.

By contrast, if you have poor compile times, you might install a Pimpl
without changing the logical coupling.

This is all fuzzy - presence of Pimpl does not imply logical coupling. But
Pimpl is still just a hack, not a design goal. Use it for an iteration, but
incrementally upgrade the design towards DIP.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces