In article <6n88o6$5c0$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> The relevant sentence is in 17.4.3.1.3/5: "Each name declared as an object
> with external linkage in a header is reserved  to  the implementation to
> designate that library object with external linkage,23) both in namespace
> std and in the global namespace." This would seem to imply that an
> implementation is free to declare the names.

Cool!  This means that it would, indeed, be possible to make a compiler that
worked this way.  I like that a lot.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <6n88o6$5c0$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:
> > The relevant sentence is in 17.4.3.1.3/5: "Each name declared as an object
> > with external linkage in a header is reserved  to  the implementation to
> > designate that library object with external linkage,23) both in namespace
> > std and in the global namespace." This would seem to imply that an
> > implementation is free to declare the names.
>
> Cool!  This means that it would, indeed, be possible to make a compiler that
> worked this way.  I like that a lot.
>

Hi,
look at
http://www.software.ibm.com/ad/visualage_c++/version4/paper.html#reduced_drudgery


Ryszard Kabatek
--
Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3593AACC.41C6@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> AllanW@my-dejanews.com wrote:
> >
> > In article <359253EB.41C6@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > >
> > > AllanW@my-dejanews.com wrote:
> > > ...
> > > >     If a program failed to include a required #include statement,
> > > >         there would be no diagnostic.  This makes porting to other
> > >
> > > ...
> > > > What, if anything, would make this illegal for a compiler vendor?
> > >
> > > The absence of required diagnostics.
> >
> > Is that always required in the FDIS?  Can you quote the section to me?
>
> I don't have a copy of the FDIS, only of CD2. However, at this level I
> doubt that there have been any significant changes. The most directly
> relevant item is in section 17.3.2.1, paragraph 3:
>
> | A translation unit shall include a header only outside of any external
> | declaration or definition, and  shall  include  the  header  lexically
> | before the first reference to any of the entities it declares or first
> | defines in that translation unit.

This is a requirement on the progtam, not on the implementation.  If you
don't inlucde the header firle, the program isn't legal, and msy fail.

The relevant sentence is in 17.4.3.1.3/5: "Each name declared as an object
with external linkage in a header is reserved  to  the implementation to
designate that library object with external linkage,23) both in namespace
std and in the global namespace." This would seem to imply that an
implementation is free to declare the names.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientee objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <359253EB.41C6@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> >
> > AllanW@my-dejanews.com wrote:
> > ...
> > >     If a program failed to include a required #include statement,
> > >         there would be no diagnostic.  This makes porting to other
> >
> > ...
> > > What, if anything, would make this illegal for a compiler vendor?
> >
> > The absence of required diagnostics.
>
> Is that always required in the FDIS?  Can you quote the section to me?

I don't have a copy of the FDIS, only of CD2. However, at this level I
doubt that there have been any significant changes. The most directly
relevant item is in section 17.3.2.1, paragraph 3:

| A translation unit shall include a header only outside of any external
| declaration or definition, and  shall  include  the  header  lexically
| before the first reference to any of the entities it declares or first
| defines in that translation unit.

However, I'm not sure what I need to quote, because I'm not sure what it
is that you're unsure of - possibly relevant paragraphs are scattered
throughout the standard. The standard header files define macros,
provide function prototypes, and declare a small number of global
variables. Almost any use of any of those symbols without appropriate
definitions or declarations in scope is required to produce a
diagnostic. An implementation that implicitly #includes all standard
headers before processing will accept without diagnostics code that
didn't explicitly contain the #include's necessary for its proper
compilation. That code would necessarily have a produced at least one
diagnostic under any conforming implementation.

> Assuming you're right (it sounds reasonable), the compiler would still
> process conforming programs perfectly well.  So wouldn't this be a
> good idea anyway?  Especially if the compiler provided an option to
> turn this part off, so that missing #include files would generate at
> least a warning?

A compiler could be conforming only when that option was used, and it
would have to generate diagnostics, not just warnings.

In addition to being non-conforming, there's a more subtle problem. Many
of the symbols defined or declared in standard headers are reserved only
if the corresponding header is #included. Conforming code can provide
and use incompatible alternate definitions or declarations of those
symbols. Code that takes advantage of that freedom may be a bad idea,
but it is legal, and will break under your proposal.

Including all standard headers (even under C, and particularly under
C++) would create a huge symbol table. That symbol table could end up
occupying a significant amount of memory that the compiler would
otherwise have better uses for, and searching that table could
significantly slow down the compilation. Of course, that is purely a
quality-of-implementation issue, not a standards issue.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
[Question about "optional" includes.]

One can easily configure Metrowerks CodeWarrior (Mac or Windows) to operate
this way. Simply precompile a header that includes all the standard C++
headers and use said precompiled header as a prefix file.

Doing this for operating system headers is common practice in the MacOS
community. It significantly improves compile times but tends to result in
code that is very non-portable, even to a different compiler, because the
include dependencies are often left out of the code. (Which I consider a
great evil.)

There are more sophisticated techniques for improving compile speed BTW.
E.g. prebuilding symbol tables for each header file and noting which header
files are either dependent or conflict. (Perhaps lazily evaluated so the
precompiled version gets built the first time a file is included.) The
compiler can the look at a list of include directives "whole hog" and
compose a symbol table quickly by merging the prebuilt ones. It seems
Microsoft Visual C++ automatic precompilation of headers might do something
like that.

(Any solution of this sort will have to give up in certain situations
because macros can be used to control conditional compilation and as the
target of an include.)

-Z-
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1Btk1.1989$sV4.510331@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
>
> >Take this a step further, we could bring in all of namespace std
> >before we even start compiling.  Then statements like
> >    #include <iostream>
> >would be no-ops, because every symbol that it was required to make
> >visible would already be visible.
>
> The first thing that comes to mind is that such a compiler would need to
> extend the language to add something like #dontinclude <std> or a
> command-line option to disable the automatic inclusion of std. Don't ask
> why. As soon as you implement something like that, someone will find a
> reason to need to disable it.

But yes, I do ask why.  My whole point is to ask if there is any harm in
making every identifier from namespace std visible all of the time.  If
anyone can give a good example of harm, then the whole idea is a bad one.
Otherwise, I think it might be a really great idea.

Would I really have to implement it before someone could find a reason to
need to disable it?  If the user is allowed to extend namespace std in
incompatible ways, then this is already a good reason not to make all of
the standard names visible.  But it's my impression that it's illegal for
a programmer to expand namespace std at all; is this true?  Also, if the
user wanted to find out if their programs were 100% conforming, this
system would not work because missing #includes would not be detected.
But as I already pointed out, most vendors probably wouldn't want to help
programmers port FROM their system, focusing instead on helping
programmers to port TO their system.

If anyone can find a section of the standard that prohibits this idea,
then by definition the idea is one that breaks the standard.  But in that
case, it still might be a good idea, especially with a compiler option to
turn it off.


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <359253EB.41C6@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> AllanW@my-dejanews.com wrote:
> ...
> >     If a program failed to include a required #include statement,
> >         there would be no diagnostic.  This makes porting to other
>
> ...
> > What, if anything, would make this illegal for a compiler vendor?
>
> The absence of required diagnostics.

Is that always required in the FDIS?  Can you quote the section to me?

Assuming you're right (it sounds reasonable), the compiler would still
process conforming programs perfectly well.  So wouldn't this be a
good idea anyway?  Especially if the compiler provided an option to
turn this part off, so that missing #include files would generate at
least a warning?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Suppose a few major compiler vendors took to heart what C++ has been
saying for a long time: The standard #include headers don't literally
need to be header files.  For instance, an implementation is free to
interpret
    #include <iostream>
by enabling symbols cout, endl, ios, etc., without neccesarily having
to read any particular disk file.

Now let's take that a step further.  The following program is
non-conforming:
    // #include <iostream>
    int main() { std::cout << "Hello, world!" << std::endl; }
Since the #include is commented out, nothing declared std::cout or
std::endl before their first use, which makes the program
non-conforming.  And since it's non-conforming, there's nothing in the
spec that requires the compiler to do anything in particular with it.
So a particular implementation could decide to make it work anyway, by
bringing in all of namespace std.  Right?

Take this a step further, we could bring in all of namespace std
before we even start compiling.  Then statements like
    #include <iostream>
would be no-ops, because every symbol that it was required to make
visible would already be visible.

The ramifications would be:
    The compiler might take longer to start up, and might need more
        memory during the compiles.
    The compiler would work much faster once it started.
    If a program failed to include a required #include statement,
        there would be no diagnostic.  This makes porting to other
        platforms harder (not usually a big concern for vendors
        that want you to port TO their platforms, not FROM them...)
    Non-conforming programs would never need the #include statement
        for standard C++ headers.  Everything would work fine
        without them.

What, if anything, would make this illegal for a compiler vendor?
(Assume we don't want to issue special compiler options, but just
want to "do the right thing" whenever possible.)  The only thing
I could come up with is that the user can currently create her own,
conflicting symbols in namespace std.  For instance:
    #include <iostream>
    namespace std {
        int strcpy(char*a,const char*b) {
            cout << a << b << endl;
            return 0;
        }
    }
    int main() { return std::strcpy("Hello, ", "world!"); }

I'm assuming that this isn't legal C++ because the user is not
allowed to arbitrarily extend namespace std.  (It's okay to replace
certain library functions, but it's not okay to extend the
namespace.)  If this is legal C++, then my idea is shot because the
version of strcpy() above takes the same parameters as the standard
one, but returns a different argument type, thus breaking the rules
of overloading if the "normal" strcpy() is visible.


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
...
>     If a program failed to include a required #include statement,
>         there would be no diagnostic.  This makes porting to other

...
> What, if anything, would make this illegal for a compiler vendor?

The absence of required diagnostics.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>Take this a step further, we could bring in all of namespace std
>before we even start compiling.  Then statements like
>    #include <iostream>
>would be no-ops, because every symbol that it was required to make
>visible would already be visible.


The first thing that comes to mind is that such a compiler would need to
extend the language to add something like #dontinclude <std> or a
command-line option to disable the automatic inclusion of std. Don't ask
why. As soon as you implement something like that, someone will find a
reason to need to disable it.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]