Dave Moore wrote:
> Depends what you mean .. I know of at least one compiler, the Visual
> Age C++ compiler from IBM, that kept all code in a big repository.
> Thus there were none of the issues related to having separate
> translation units, like those associated with template instantiation.
> I never used the compiler however, so I don't know if there were
> other, potentially more irritating, issues induced by the repository
> model.

I'm beginning to believe this should be a two path approach. You could chose
to either use the compartmeted approach in you 'translation unit', or the
traditional approach.  Clearly there needs to be a means of interfacing the
product of both approaches.  The ability for code built in compartments to
use libraries and other code implemented using translation units (TU) will
be far more important than the reverse.

Perhaps there could be some means of creating a compartment to hold only TU
based code, and present an interface to other compartments that conforms to
the compartmental structure.

>> For one
>> thing, it doesn't make sense to me to have two methods of determining
>> what
>> is actually introduced into the translation unit.  IOW, what is actually
>> available to a scope within a translation unit is the intersection of
>> what
>> #include <header> statements introduce, and whatever using directives and
>> using declarations have been introduced, as well as explicit scope
>> resolution of a symbol where it is used. The latter three methods seem
>> congruent.  The use of the #include statements seems to be an unnecessary
>> inherited artifact.
>>
>
> Interesting point ...

So perhaps we stuff all the current headers in a compartment that provides
its contents to the local compartment through the use of some kind of
directives such as for example:
/*

THIS IS A SKETCH! IT IS NOT A DESIGN!

*/

// in a directory /path/to/c++/std/

/*
  This is how we convert the Standard Library std:: to compartments
*/

compartment std {
  translation unit{
#include "to_your_heart's_content"
#include <valarray>
  } //
  head {
  public:
    /* the following resolves to std::numeric::valarray */
    alias std::valarray compartment numeric::valaray;
  private:
  protected:
  }
}
// EOF

// in a directory /path/to/c++/iso/

compartment iso {
  head {
  public:
    compartment math;// == compartment ::iso::math
    // iso::math is now available to the world;
  }
}

// in a directory /path/to/c++/iso/math
compartment iso::math {
  head {
  public:
    compartment multivariable; // == compartment ::iso::math::multivariable
  }
}

// in a directory /path/to/c++/iso/math/mulitvariable
compartment multivariable {

  head {
    // Expectation is the IDE can provide a signature
    // list by resolving the names listed;

  public: // Externally visible declarations(does not change what is
internally visible)

    class orthnormal3D;

  private:   // Visible only within the compartment
    f1;

  protected:   // Visible within the compartment and it's subcompartments
    f2;

  } // end head

  body {
    define{
      // one class per define block or multiple 'free' functions

      class orthnormal3D{
        //same as we currently do it
        orthnormal3D();
        orthnormal3D(const int& param );
      };

      orthnormal3D(){
        // orthnormal3D:: is superfluous here
      }

      orthnormal3D(const int& param ){ //  }

      }

    } // end define orthnormal3D

    define{
      // define some functions

      int f1() {
        // No need to have declarations separate from implementation
        // there may still be a need for forward declarations???
        return 1;
      }

      int f2(){ return 2; }

    } //end define some functions
  } // body
} // multivariable

// in a directory /home/username/projects/my_projec/src/my_work
compartment my_work {
  needs iso::math::multivariable::orthnormal3D;
  needs all org::w3c::dom;
} // end my_work


> Ok .. so it seems like you want to make all of the header files
> currently specified with <> directly accessible to the compiler.  This
> seems like a idea that is worthwhile and fairly straightforward to
> implement.  But doesn't getting rid of #include directives in general
> pose some other difficulties as well?

I'm not proposing they be immediately or completely abolished.

> For example, how would you tell
> the compiler about other libraries in a platform independent way?

Us the current mechanism and wrap it up in a compartmental solution.

> Also, how would you support the current .hpp/.cpp scheme for
> separation of declaration and definition?

See above.

> Without devoting too much
> thought to this, it seems like your proposal is akin the the export
> keyword for templates in C++ ... a good idea on the face of it, but a
> hell of a lot of work for compiler developers.

Consider that the example shown above was written using emacs C++-mode, and
it parsed about as well as real C++ code.


> I really like this idea .. it is much nicer (IMHO) than the current
> mechanism of using declarations, where you can make available only an
> entire namespace or a single symbol to the current scope.  However, it
> kind of requires your proposed re-ordering of the libraries if it is
> going to be non-intrusive, that is, not require changes to existing
> library code.

One implementations of the stl I have on my system already jumps through
more hoops than any dog I've seen.  I suspect something along the lines of
what is shown above really wouldn't take that much effort.

BTW, /compartment/ could be shortened to /part/, but I *really* mean
*compartment*.  The original motivation for the word compartment came from
the terminology used in the electronics systems I worked on in the early
80's.  A few days ago I was trying to find a good analogy for the problem I
see in the current header/namespace system.  The RMS Titainic came to mind
so I googled for it:

http://members.aol.com/KEN63728/bulks.htm

The date I did that just happened to be April 14.

Today I looked up the term used in shipbuilding for the partitioned spaces
that should have been more effectively isolated when the ship was
constructed.  I am pretty sure the technical term is /compartment/.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>  The use of the #include statements seems to be an unnecessary
>> inherited artifact.
>
> Select any large C++ project, run each file through
>     sed -e 's/include//', and then attempt to build the project. :-)

How much does your horse eat in a week? ;-)

> I think that if it was unnecessary it would have been gotten rid of
>     long ago.

The functionality the C-preprocessor provides is necessary.  But I feel
confident there are better ways of accomplishing the various duties it
currently handles.  I really have to wonder if it's necessary to tape
together all the different files in the way the current translation unit
does.

>> I would like people to consider the implications of implementing library
>> namespaces directly, rather than through the use of headers. As a first
>> draft, I will propose the following structure for the Standard Library:
>> std
>> std::algorithm
> [snip]
>
> Ugh. Putting the standard names in std caused enough headaches. Now
>     you want to put us through another 5-year period of tediously
>     adding proper qualification, using declarations, and using
>     directives to code that worked just fine before the standard
>     changed, and compiliers changed to match?

Something tells me backward compatibility wouldn't be that hard to achieve.
Simply flatten out the namespace in the preprocessing phase, and treat it
like you always have.  Deprecation warnings? AFAIC, the current C++
reliance on cpp is a huge deprecation warning.

> I was once a big supporter of having all standard C++ library names
>     in 'std'. But has the years have gone by, I have seen very very
>     few name collision problems in C (which doesn't have namespaces),
>     and many many problems for code moved from an old compiler to a
>     new.

I've seen a fair number of name collisions in Java, which has more
protection by default than C or C++.  But, with Java, all I have to do is
fully qualify the name, and the problem is usually solved. But that's only
one reason to favor increased logical structure. It's the same reason we
divide book into parts, chapters, sections, subsections, paragraphs, etc.
It makes it easier to find things, and easier to identify what components
are logically connected.

> I've come to feel the cost was greater than gain. And to me it seems
>     this aspect of your proposal has less potential gain for greater
>     cost.

Part of the reason I'm suggesting the separation of library naming, and
header file #inclusion is because I believe it would simplify the job of
IDE builders,  I believe there should be a specified interface that defines
how libraries respond to certain kind of queries.  There would certainly
need to be emphasis on the 'as if' requirement. Nonetheless, I believe
there should be certain environment variables such as $LD_LIBRARY_PATH,
$INCLUDEPATH, etc. There should also be certain commands for retrieving
information about what libraries are available in the development
environment, and what the interfaces of the available libraries are.

> But that has only to do with disputation of the standard library
>     names, and nothing to do with the suggested package-like feature that
>     comes with your proposal. Adding packages/modules/etc to C++
>     should IMO be largely independent of the disputation of standard
>     library names.

I simply used the Standard Library as a point of reference.  I don't have a
significant complaint with it, per se.  That is, other than the fact that I
find the online documentation a bit harder to navigate than comperable
documentation for other languages.  The biggest reason for changing the
Standard Library in the way I suggested would be to free it from the heard
file requirement.

> I think a package-like feature could be of great benefit to C++, so
>     long as a typical C++ library (and also, a typical implementation
>     of the standard C++ library) could be re-implemented in terms of
>     it, and yet continue to support the majority of applications
>     using the library. So don't saddle a proposal like this with an
>     unecessary re-arrangement of names which breaks backward
>     compatibility.

I'm under the impression that many environments still support header names
such as, <iostream.h> for backward compatibility with the pre-standard
approach.  I don't see the problem of providing backward compability to be
a show stopper.  But I do have to wonder if there is too much reluctance to
retire old code.

What I'm seeing is there's a good deal of stuff that should either be
reexamined and cleaned up, or quietly replaced. I know for a fact that the
more organized and structured the development environment and library
structure of a project is, the easier it is to maintain, update, refactor,
etc.


--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<aKCdnZTdf769GOPdRVn-hA@speakeasy.net>...
> I find the use of headers in conjunction with using directives and using
> declarations to be an inelegant and confusing approach to providing library
> services to a translation unit.  (I would really like to avoid the entire
> notion of a translation unit, but that is probably out of reach.)

Depends what you mean .. I know of at least one compiler, the Visual
Age C++ compiler from IBM, that kept all code in a big repository.
Thus there were none of the issues related to having separate
translation units, like those associated with template instantiation.
I never used the compiler however, so I don't know if there were
other, potentially more irritating, issues induced by the repository
model.

> For one
> thing, it doesn't make sense to me to have two methods of determining what
> is actually introduced into the translation unit.  IOW, what is actually
> available to a scope within a translation unit is the intersection of what
> #include <header> statements introduce, and whatever using directives and
> using declarations have been introduced, as well as explicit scope
> resolution of a symbol where it is used. The latter three methods seem
> congruent.  The use of the #include statements seems to be an unnecessary
> inherited artifact.
>

Interesting point ...

> I would like people to consider the implications of implementing library
> namespaces directly, rather than through the use of headers. As a first
> draft, I will propose the following structure for the Standard Library:
> std
> std::algorithm
*snip*

Ok .. so it seems like you want to make all of the header files
currently specified with <> directly accessible to the compiler.  This
seems like a idea that is worthwhile and fairly straightforward to
implement.  But doesn't getting rid of #include directives in general
pose some other difficulties as well?  For example, how would you tell
the compiler about other libraries in a platform independent way?
Also, how would you support the current .hpp/.cpp scheme for
separation of declaration and definition?  Without devoting too much
thought to this, it seems like your proposal is akin the the export
keyword for templates in C++ ... a good idea on the face of it, but a
hell of a lot of work for compiler developers.

*snip*
> I also propose the introduction of a new syntax (perhaps not formally part
> of CPP) for introducing the content of the particular library pseudo-file
> into the translation unit. Perhaps something like:
>
> requires std::sstream; // Makes visible the entire sstream library.
>
> and
>
> requires std::iostream::cout;// make visible only the specified symbol
> requires std::iostream::endl;// ditto
>

I really like this idea .. it is much nicer (IMHO) than the current
mechanism of using declarations, where you can make available only an
entire namespace or a single symbol to the current scope.  However, it
kind of requires your proposed re-ordering of the libraries if it is
going to be non-intrusive, that is, not require changes to existing
library code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> llewelly wrote:
[snip]
>> I think that if it was unnecessary it would have been gotten rid of
>>     long ago.
>
> The functionality the C-preprocessor provides is necessary.  But I feel
> confident there are better ways of accomplishing the various duties it
> currently handles.  I really have to wonder if it's necessary to tape
> together all the different files in the way the current translation unit
> does.
[snip]

There are certainly better ways to handle multiple packages - you
    could look at any of Pascal, Ada, Modula-3, Java, Perl, or
    others, to see a better way of supporting packages.

As far as adding explicit package support to C++, I believe that would
    be very good thing. (But also a very difficult thing.) But I
    don't think explicit package support should require that I replace
    every 'std::copy' in my program with 'std::algorithm::copy' . And
    amoung other things, that means we can't get rid of #include,
    even though it doesn't do the right thing.

[snip]
> Something tells me backward compatibility wouldn't be that hard to
> achieve.
[snip]

I'm appologize if I mistook you, but it seemed to me that your
    proposal was ignoring backward compatibility.

> Deprecation warnings? AFAIC, the current C++
> reliance on cpp is a huge deprecation warning.
[snip]

Here we are in agreement; it hides errors that other languages
    dectect easily, it complicates the job of tool builders, it
    requires every programmer to learn an additional language (cpp can
    be viewed as a different language than C++ - after all, it doesn't
    obey any of the rules obeyed by the rest of the language), it
    obfuscates diagnostics ...

But we can't get rid of it.

> The biggest reason for changing the Standard Library in the way I
> suggested would be to free it from the heard file requirement.
[snip]

'heard file'? Do you mean 'header file'? I do agree that C++ would
    benefit from something that supported better diagnostics (and for
    that matter, better seperate compilation) than the combination of
    convention and #paste_here (admit, that's exactly what #include
    does; it's no more advanced than C-y or Ctrl-V or Y whatever your
    favorite editor does) that we have now.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>> I really have to wonder if it's necessary to tape
>> together all the different files in the way the current translation unit
>> does.
> [snip]
>
> There are certainly better ways to handle multiple packages - you
>     could look at any of Pascal, Ada, Modula-3, Java, Perl, or
>     others, to see a better way of supporting packages.
>
> As far as adding explicit package support to C++, I believe that would
>     be very good thing. (But also a very difficult thing.) But I
>     don't think explicit package support should require that I replace
>     every 'std::copy' in my program with 'std::algorithm::copy' . And
>     amoung other things, that means we can't get rid of #include,
>     even though it doesn't do the right thing.

I'm not sure getting rid of #includes is even desirable. But I believe a
better way of connecting the different parts of a program should be
devised.


>> Deprecation warnings? AFAIC, the current C++
>> reliance on cpp is a huge deprecation warning.
> [snip]
>
> Here we are in agreement; it hides errors that other languages
>     dectect easily, it complicates the job of tool builders, it
>     requires every programmer to learn an additional language (cpp can
>     be viewed as a different language than C++ - after all, it doesn't
>     obey any of the rules obeyed by the rest of the language), it
>     obfuscates diagnostics ...
>
> But we can't get rid of it.

But can module support be introduced in a way that coexists with the current
package mechanism, and doesn't require #includes? A frequently presented
argument for the use of header files is they separate the interface from
the implementation. Perhaps they do, but from what I've seen, they don't do
it well. This discussion of the "compiler firewall idiom" aka "pimpl idiom"
suggests to me headers really don't completely accomplish that separation.

Is it possible to provide a mechanism that extracts the interface
description from the source file?  Perhaps the source file could have a
section specified as an interface definition.  Or perhaps the interface
could be directly extracted from the implementation.

> I do agree that C++ would
>     benefit from something that supported better diagnostics (and for
>     that matter, better seperate compilation) than the combination of
>     convention and #paste_here (admit, that's exactly what #include
>     does; it's no more advanced than C-y or Ctrl-V or Y whatever your
>     favorite editor does) that we have now.

I believe the first step in accomplishing the goal is to clearly define what
needs to happen in order to convert a collection of source file
implementations into a program.  One thing I find disconcerting with the
current situation, in so much as I understand it, is (using the example of
my GNU/Linux system) the complete autonomy between headers #included for
compilation, and libraries used for linking.  I can use a set of header
files which enable the translation units to be compiled, and link the
resulting object files to completely unrelated libraries.

It's unlikely that would work for any significantly complex program, but it
does demonstrate a common source of build problems.  Say for example I have
source files with headers located in /cvs-images/project/include.  After I
compile the program, it might be installed to /usr/local/project/{lib, bin,
include}.  Now I might compile something else against the headers
in /cvs-images/project/include and link
against /usr/local/project/lib/*.so.

I would prefer a way to specify a single source of supporting resources for
both header, and implementation.  Possibly I could go to the implementer of
the build system I use and persuade them to design such a solution.  But
that seems like the wrong place to solve the problem.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:
[snip]
> I'm not sure getting rid of #includes is even desirable. But I believe a
> better way of connecting the different parts of a program should be
> devised.

Then we agree, I think.

>
>>> Deprecation warnings? AFAIC, the current C++
>>> reliance on cpp is a huge deprecation warning.
>> [snip]
>>
>> Here we are in agreement; it hides errors that other languages
>>     dectect easily, it complicates the job of tool builders, it
>>     requires every programmer to learn an additional language (cpp can
>>     be viewed as a different language than C++ - after all, it doesn't
>>     obey any of the rules obeyed by the rest of the language), it
>>     obfuscates diagnostics ...
>>
>> But we can't get rid of it.
>
> But can module support be introduced in a way that coexists with the current
> package mechanism, and doesn't require #includes?

I sure hope so. Module support which does not coexist with the
    current mechanism (which is mostly convention, only weakly
    supported by the language) is IMO a definite non-starter.

> A frequently presented
> argument for the use of header files is they separate the interface from
> the implementation.

Convention seperates interface from implementation. #include only
    pastes the declarations into the library user's file.

> Is it possible to provide a mechanism that extracts the interface
> description from the source file?  Perhaps the source file could have a
> section specified as an interface definition.  Or perhaps the interface
> could be directly extracted from the implementation.

I think I prefer that the programmer explicitly specify what is part
    of the interface, and what is not, at least in the common case.
>
>> I do agree that C++ would
>>     benefit from something that supported better diagnostics (and for
>>     that matter, better seperate compilation) than the combination of
>>     convention and #paste_here (admit, that's exactly what #include
>>     does; it's no more advanced than C-y or Ctrl-V or Y whatever your
>>     favorite editor does) that we have now.
>
> I believe the first step in accomplishing the goal is to clearly define what
> needs to happen in order to convert a collection of source file
> implementations into a program.  One thing I find disconcerting with the
> current situation, in so much as I understand it, is (using the example of
> my GNU/Linux system) the complete autonomy between headers #included for
> compilation, and libraries used for linking.  I can use a set of header
> files which enable the translation units to be compiled, and link the
> resulting object files to completely unrelated libraries.
>
> It's unlikely that would work for any significantly complex program, but it
> does demonstrate a common source of build problems.
[snip]

Perhaps the worst example of this is when you distribute an
    application linked against shared libraries, but the customer has
    version X + 1 of some shared lib, which is not compatible with
    the version X you linked the application agaiinst, yet
    nonetheless links 'successfully' with your application, and then
    causes weird runtime behavior. Now imagine you as the developer
    don't have, or worse, don't know about version X + 1, and the
    customer doesn't have a strong grasp of shared library
    issues. This is a problem I've acutally encoutered. (I've never
    encoutered, nor heard verifiable report of, an incident where a
    non-trivial application was compiled against a set of headers,
    and then 'sucessefully' linked against a genuinely unre-lated
    binary library, though it is possible in theory.)

The maintainers of some libraries, including both glibc and libstdc++,
    include much extra-linguistic linker magic to (hopefully) insure
    that this is impossible, unless versions X and X + 1 are genuinely
    compatible.

What I find interesting - and view as a potentially serious
    compatibility issue - is that many of the problems which arise
    from C++'s barely adequate #include-and-link mechanism, is that
    each environment provides various tools/features which can be
    used to solve or migitate the mechanism's weaknesses.

Note that it is *usually* viewed as desireble for a program
    compiled against the headers of library version X to link
    successfully against version X.1, assuming X.1 is perfectly
    backward compatible.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I find the use of headers in conjunction with using directives and using
declarations to be an inelegant and confusing approach to providing library
services to a translation unit.  (I would really like to avoid the entire
notion of a translation unit, but that is probably out of reach.) For one
thing, it doesn't make sense to me to have two methods of determining what
is actually introduced into the translation unit.  IOW, what is actually
available to a scope within a translation unit is the intersection of what
#include <header> statements introduce, and whatever using directives and
using declarations have been introduced, as well as explicit scope
resolution of a symbol where it is used. The latter three methods seem
congruent.  The use of the #include statements seems to be an unnecessary
inherited artifact.

I would like people to consider the implications of implementing library
namespaces directly, rather than through the use of headers. As a first
draft, I will propose the following structure for the Standard Library:
std
std::algorithm
std::iomanip
std::list
std::ostream
std::streambuf
std::bitset
std::ios
std::locale
std::queue
std::string
std::complex
std::iosfwd
std::map
std::set
std::typeinfo
std::deque
std::iostream
std::memory
std::sstream
std::utility
std::exception
std::istream
std::new
std::stack
std::valarray
std::fstream
std::iterator
std::numeric
std::stdexcept
std::vector
std::functional
std::limits

std::C::cassert
std::C::ciso646
std::C::csetjmp
std::C::cstdio
std::C::ctime
std::C::cctype
std::C::climits
std::C::csignal
std::C::cstdlib
std::C::cwchar
std::C::cerrno
std::C::clocale
std::C::cstdarg
std::C::cstring
std::C::cwctype
std::C::cfloat
std::C::cmath
std::C::cstddef

There should be a one-to-on correspondence between a directory-like
filesystem-like hierarchy, and the namespaces such that the individual
file-like contents of a library namespace might be specified by an OS level
expression such as
[path to c++ libs]/std/algorithm
[path to c++ libs]/std/iomanip
...
[path to c++ libs]/std/limits

There should probably be even more depth than shown in the example above.
For example collections should be grouped together, as should I/O
facilities, etc.

I also propose the introduction of a new syntax (perhaps not formally part
of CPP) for introducing the content of the particular library pseudo-file
into the translation unit. Perhaps something like:

requires std::sstream; // Makes visible the entire sstream library.

and

requires std::iostream::cout;// make visible only the specified symbol
requires std::iostream::endl;// ditto

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> I find the use of headers in conjunction with using directives and using
> declarations to be an inelegant and confusing approach to providing library
> services to a translation unit.  (I would really like to avoid the entire
> notion of a translation unit, but that is probably out of reach.) For one
> thing, it doesn't make sense to me to have two methods of determining what
> is actually introduced into the translation unit.  IOW, what is actually
> available to a scope within a translation unit is the intersection of what
> #include <header> statements introduce, and whatever using directives and
> using declarations have been introduced, as well as explicit scope
> resolution of a symbol where it is used. The latter three methods seem
> congruent.  The use of the #include statements seems to be an unnecessary
> inherited artifact.

Select any large C++ project, run each file through
    sed -e 's/include//', and then attempt to build the project. :-)

I think that if it was unnecessary it would have been gotten rid of
    long ago.

>
> I would like people to consider the implications of implementing library
> namespaces directly, rather than through the use of headers. As a first
> draft, I will propose the following structure for the Standard Library:
> std
> std::algorithm
[snip]

Ugh. Putting the standard names in std caused enough headaches. Now
    you want to put us through another 5-year period of tediously
    adding proper qualification, using declarations, and using
    directives to code that worked just fine before the standard
    changed, and compiliers changed to match?

I was once a big supporter of having all standard C++ library names
    in 'std'. But has the years have gone by, I have seen very very
    few name collision problems in C (which doesn't have namespaces),
    and many many problems for code moved from an old compiler to a
    new.

I've come to feel the cost was greater than gain. And to me it seems
    this aspect of your proposal has less potential gain for greater
    cost.

But that has only to do with disputation of the standard library
    names, and nothing to do with the suggested package-like feature that
    comes with your proposal. Adding packages/modules/etc to C++
    should IMO be largely independent of the disputation of standard
    library names.

I think a package-like feature could be of great benefit to C++, so
    long as a typical C++ library (and also, a typical implementation
    of the standard C++ library) could be re-implemented in terms of
    it, and yet continue to support the majority of applications
    using the library. So don't saddle a proposal like this with an
    unecessary re-arrangement of names which breaks backward
    compatibility.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]