namespace issues with old C headers

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| On Tue, Apr 15, 2003 at 10:17:05PM +0200, Gabriel Dos Reis wrote:
| > Before, patches along those lines are applied, you need to consider
| > the following:
| > 
| >   1) it is the header by itself that is problematic of the entities
| >      that it declares?
| 
| It is the entities that are declared.

Great!  We seem to be on the same technical page to have a sound
technical conversation.

Given the high dependency between C++ headers, I do not believe we can
come to a satisfactory answer -- keeping in mind the original issue
raised by David (which was <math.h> vs. <cmath>).

I also posted an example:

  #include <iostream>
  
  int main()
  {
    std::cout << "Hello World\n";
  }


The above program is not portable.  Where should we draw the line?
Should we try hard to make it fail?

|  To be more specific, the problem
| occurs when an entity that is relatively commonly used is "unexpectedly"
| declared.

I believe 

  std::ostream& std::operator<<(std::ostream&, const char*);

falls in that category, so by your reasoning, we should try to make
the above program fail.  Is that really what you want?

[...]

| >   2) if you replace the standard header by an internal header that
| >      nevertheless declares those entities, then the portability
| >      problems mentioned are unlikely solve.  Hence my question:  What
| >      exactly is the problem we are trying to solve?
| > 
| > The above aren't rhetorical questions.
| 
| The problem is that nonportable programs compile no matter how pedantic
| the setting.  For the purpose of this discussion we are restricting
| ourselves to "pragmatic" nonportability (the program is not ISO C++ and
| most other well-known C++ compilers do not compile it).  I don't believe
| that this problem can be entirely solved.  At most, it can be whacked back
| a bit, by being careful to include as few headers as possible.  In cases
| where only a small bit of a particular header is needed, subdivision
| is possible: the standard header might include two internal headers,
| only the first of which is needed to implement the other standard headers
| (so it can be included directly ... include guards would of course be
| used to get the ODR right).  The side benefit is that we might reduce
| compile times a bit, by reducing the amount of cruft needed to compile
| small programs.

I already mentioned that idea some time ago, in private conversation
with Benjamin and Mark, and it was believed that it is unlikely that
fiddling with the headers would bring any estimable wins -- Mark might
recall exactly what he said.  Mark suggested that pre-compiled headers
may probably be better alternatives.  I gradually came to be convinced
that fiddling with the headers didn't reaaly worth it.  If we believe
that  compile time is an issue that, it is unlikely that fiddling with
headers (without export or precompiled headers) will really addres it.

I mentioned the header subdivision idea to Benajmin and Mark, when I
realized that the hello-world program was driving almost all the library.
(Actually, I was working on a valarray<> issue).

-- Gaby