🚀 go-pugleaf

In article <9511302342.AA18036@mercedes.iscp.bellcore.com>,
   rp@iscp.bellcore.com (Robert Pearlman) wrote:
>simply that changing a header --in any way-- makes every dependent code file 
>recompile.  That includes adding the occasional forgotten
>function, used only when coding the public methods of the class.  

Yet it must... for instance, adding a non-public member function might change 
the vtable, and adding a non-public member variable will change the size of 
objects of the class.  Client code must be completely in sync.

>So one is often faced with a nasty choice -- write a
>tiny function and pay (half hour, hour, more?) or write ungood code.

Or use good version control (e.g. the releaseable/versioned class categories 
in Bob Martin's book), and let clients move to newer versions when they want. 
 That way they can always use new functionality when it's needed, and they 
can control when they need to rebuild rather than being forced to do it every 
time the component changes.  This gives you the best of both worlds.

>One can touch back the header, but that's also unclean.  Also, some
>integrated environments, certainly Borland's, don't always respect the touch.

Yikes!  Even if it did, that's one sure path to errors and 'undefined 
behaviour' (see my first paragraph above, and Matt's "Undefined versus 
unspecified" article posted yesterday -- BTW, Matt, yes, I think there's a 
huge difference, because to me 'undefined' implies an incorrect program and 
'unspecified' implies a correct program with a platform dependency).

Herb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Suite 102       voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]