This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update backward/algo.h



> The problem was never installing non-.h headers.  The problem was 
> depending on non-.h headers.  In particular, if you have a foo.cc 
> and a header foo that it depends on, make is very likely to delete 
> your header foo if you SIGINT the make while it is building foo.o.

As far as I understand it, here is a way to explicitly test this. Please 
correct me if I'm mistaken.

1) patch src/ios.cc

Index: src/ios.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/ios.cc,v
retrieving revision 1.22
diff -c -p -r1.22 ios.cc
*** ios.cc	2001/11/28 04:07:10	1.22
--- ios.cc	2001/12/31 19:41:09
***************
*** 31,40 ****
  // ISO C++ 14882: 27.4  Iostreams base classes
  //
  
! #include <bits/std_ios.h>
! #include <bits/std_ostream.h>
! #include <bits/std_istream.h>
! #include <bits/std_fstream.h>
  
  namespace std 
  {
--- 31,40 ----
  // ISO C++ 14882: 27.4  Iostreams base classes
  //
  
! #include <ios>
! #include <ostream>
! #include <istream>
! #include <fstream>
  
  namespace std 
  {


2) control-c during compilation of src/ios.cc

Now, I've done this, and include/std/ios is still present.

> 1. Are you certain you understood the problem in the first place?

Perhaps not. Please specify the steps needed to reproduce it, if I'm in 
error.

> 2. Was there a specific version of gmake where this behavior was fixed?  

As I've never been able to reproduce it, I don't know.

> 3. Are we sure we're using a fixed version of gmake when building, or
>    a non-gmake that doesn't have a matching bug?

Perhaps Loren could tell us? Or, other people who are not using GNU make?

> I don't like seeing a carefully designed structure allowed to rot
> just because nobody can be bothered to understand why it was built,
> and then tearing it down because it was allowed to rot.

Aaah. May I suggest you re-read the parts of "How Buildings Learn" that 
deal with the design of I. M. Pei's Media Lab building at MIT? Suggested 
reading: Chapter 11. Here's a relevant excerpt (p 179)

"The Media Lab is burdened with a number of expensive overspecified 
spaces, such as a pair of rooms designed for wall-size 
rear-projection--research that was no longer even going on when the 
building opened."

The header design is not sacrosanct. It should evolve to be 
minimally-confusing, maximally-flexible. 

I prefer a design not based on an extreme special case that rarely, if 
ever, happens.

best,
benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]