Re: namespace issues with old C headers

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

David Schultz <das at freebsd dot org> writes:

| On Sat, Apr 12, 2003, Gabriel Dos Reis wrote:
| > David Schultz <das at freebsd dot org> writes:
| > 
| > | On Sat, Apr 12, 2003, Gabriel Dos Reis wrote:
| > | > David Schultz <das at FreeBSD dot ORG> writes:
| > | > | sure why it is problematic.  In C, it is actually required that
| > | > | standard headers not pollute the namespace with symbols from other
| > | > | headers, lest standard C programs fail to compile.  Perhaps C++
| > | > | differs in this regard, but that doesn't explain why this idea is
| > | > | ``unrealistic.''
| > | > 
| > | > C++ definitely has a different requirement:  It allows a standard
| > | > header (not a C-iniherited one) to include another standard header.
| > | > And in effect, if a standard function implementation needs to use
| > | > (reasonably) another stanadrd function, I don't see why it should not
| > | > be permitted to include the appropriate header. 
| > | 
| > | Avoiding namespace pollution is somewhat helpful for application
| > 
| > #includeing standard headers does not pollute library and application
| >  programmers' namespace -- since the only namespace that gets "affected"
| > is ::std -- so I can't see what you're driving at.
| 
| The explanation was the part you cut when you quoted me.  :-P

I left the explanation part in my previous part.

| I'm not talking about namespace pollution.

If you're not talking about namespace pollution then why did you argue

   Avoiding namespace pollution is somewhat helpful for application
   writers because they don't need to worry about leaving out an [...]

?

| Promiscuous includes
| mean that I can't count on the compiler to catch me when I
| accidentally leave out a #include.

Yes, but that is how C++ works, no matter how you turn it.  Because
the library has high dependencies between headers.  If what is
worrying is to catch when a header is not included then anything you
proposed is *not* a solution of that problem.  Maybe what you proposed
solved a problem, but none that you mentioned.  As I mentioned
earlier, the C++ library has quite different requirements than the C
library.   

| My code might compile on GNU's
| C++ library version foo, but not version bar, and certainly not in
| someone else's libstdc++ implementation. 

Yes, and that is not libstdc++'s problem.  If you want to solve that
problem then you need to take to the C++ standards committees.

| This is a minor point,
| but I think it shows that getting rid of promiscuous includes is
| a moderately good thing, assuming you are willing to cope with
| the added complexity.

As I said it solves no problem because:

  1) as you said, the portability problem is still not solved since
     other implementations may not do what libstdc++ do;
 
 2) some headers need to use entities defined in different  headers
    and the problem you're talking about is -not- that some headers are
    included but that some entities are defined or declared and you
    would want to be caught if the headers you include are not
    sufficient to guanrantee portability of those standard
    declarations or definitions.  In short, you're not addressing the
    problem: You are just adding more problems.  

*your* problem has a quite simple soluition: Learn about the C++
library to know which headers you need, and don't assume more than
they are supposed to provide.

|  Perhaps you are not, and as I have already
| mentioned, I am not prepared to argue this point.

You need to demonstrate that your proposals really solve problems
in libstdc++ -- there are many in libstdc++, but none of what you
proposed addressed them.

| > | > The intent wasn't to shut down all of your proposed solutions.
| > | > I'm more interested in a "real" solution and none of what you proposed
| > | > seems to address the real problem.  I see Loren is working a
| > | > patch that might give real solution.
| > | 
| > | I agree that none of my proposals were perfect;
| > 
| > I'm making a distinction between "perfect" and "real solutions".
| > As I said, none of what you proposed really solved the problem.
| > I'm not speaking of "perfection", it is something on cares about when one
| > has a choice.
| 
| Aah, okay.  Could you perhaps explain how the Loren's patch you
| mentioned solves the problem, since I'm still not sure where
| you're going with this?

Look at the patch

   http://gcc.gnu.org/ml/libstdc++/2003-04/msg00072.html

and read chapter 17 and section D.5 of the C++ standard.  You might
also want to read the Audit trail of PR libstdc++/7680 to have an idea
of the roots of the problems.


| I admittedly do not have a deep interest in libstdc++. 

Ahem.

| You
| probably gathered that much from the fact that I am not familiar
| with the standard or any changes in the language in the last few
| years.  I am, like yourself, opposed to kludgy solutions, which is
| why I posted to this list instead of trying to work around the
| problem.  But I also get the distinct impression that there isn't
| presently a solution that is both good and portable.  In that
| case, getting rid of promiscuous includes sounded like a 99% fix

Your problem does -not- come from the fact that libstdc++ includes
standard headers.  You need to understand that.  Once you understand
that you'll realize that your proposal is not a solution, at least not
a solution to any problem we're interested in on libtsdc++ side.

| for the problem, _and_something_that_ought_to_be_done_anyway_.
| It's fine with me if you reject the idea, but I would like it to
| be because you have a *better* one that doesn't involve waiting
| for Bjarne to publish a new edition of his book.  ;-)

Please, if you want to be taken seriously stop misrepresenting.

-- Gaby