kanze@gabi-soft.de (James Kanze) wrote
> fjh@cs.mu.OZ.AU (Fergus Henderson) wrote
> > I don't think this can be phrased as a requirement, since the only
> > effect of recognizing include guards is faster compilation time, and
> > the C++ standard does not place any requirements on compile time.
>
> I fear that you are right.  Although opening and reading a file are
> "observable behavior".

The only place where the standard uses the phrase "observable behavior"
is section 1.9 "Program execution" [intro.execution]. In particular,
1.9/5 begins with "A conforming implementation executing a well-formed
program shall produce the same observable behavior as..."

In other words, the whole "abstract machine" and "observable behavior"
doctrine applies to the program being compiled, not to the compiler itself.

---
[ 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                       ]

On Sat, 26 Oct 2002 22:55:46 +0000 (UTC), kanze@gabi-soft.de (James Kanze) wrote:

>alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
>news:<3db1a48b.462131296@news.bluecom.no>...
>
>> Reason for this opinion: at the time of the original idea, header file
>> inclusion had been proven a problem (Lakos).  Now its no longer a
>> practical problem.
>
>Says who?  Machines have speeded up considerably.  CPU time for
>compilation is down, and the programs we write are bigger.  With more
>templates, which increase the size of header files outrageously.
>
>But Ethernet isn't really any faster than it ever was.  In fact, with
>the radical increase of traffic due to networked solutions, it is if
>anything slower.
>
>As a result, opening and reading include files (which will almost never
>be on the local disk) represents a much larger percentage of compile
>time than ever.

Of course, it is a practical problem if one chooses to not use include
guards, or if one uses a compiler that doesn't recognize include guards
and at the same time one fails to use a compiler #pragma or the Lakos
technique of external include guards (IMO the latter is best).

But that's another discussion, since failure to take the simplest
precautions can't be rectified by some new language feature  --  probably
one would then find some similar reason not to use that feature, too...

Cheers,

- Alf


PS: Another way to reduce compile times might be to copy the files to local
disk storage, set the include path accordingly, and use a source control
system that to the degree possible automagically updates everything.


---
[ 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                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
news:<3dbb231e.39764515@news.bluecom.no>...
> On Sat, 26 Oct 2002 22:55:46 +0000 (UTC), kanze@gabi-soft.de (James
> Kanze) wrote:
> >alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
> >news:<3db1a48b.462131296@news.bluecom.no>...
> >> Reason for this opinion: at the time of the original idea, header
> >> file inclusion had been proven a problem (Lakos). Now its no longer
> >> a practical problem.

> >Says who?  Machines have speeded up considerably.  CPU time for
> >compilation is down, and the programs we write are bigger.  With more
> >templates, which increase the size of header files outrageously.

> >But Ethernet isn't really any faster than it ever was.  In fact, with
> >the radical increase of traffic due to networked solutions, it is if
> >anything slower.

> >As a result, opening and reading include files (which will almost
> >never be on the local disk) represents a much larger percentage of
> >compile time than ever.

> Of course, it is a practical problem if one chooses to not use include
> guards,

The compiler still has to open and read the file, even with include
guards.

> or if one uses a compiler that doesn't recognize include guards

That is, most existing compilers.

I've lost some of the context, but if I recall correctly, the contention
was that this is no longer necessary.

> and at the same time one fails to use a compiler #pragma or the Lakos
> technique of external include guards (IMO the latter is best).

The Lakos technique is a pain to use.  At present, it is the only
solution, but that doesn't make it any less painful.

> But that's another discussion, since failure to take the simplest
> precautions can't be rectified by some new language feature --
> probably one would then find some similar reason not to use that
> feature, too...

Just requiring compilers to recognize include guards would be a nice
first step.

All of the rest of the suggestions have involved correcting the somewhat
broken semantics of include, so that some #define in one included file
doesn't break the contents of another one.

> PS: Another way to reduce compile times might be to copy the files to
> local disk storage, set the include path accordingly, and use a source
> control system that to the degree possible automagically updates
> everything.

So write one.  Although I am sceptical.  One of the seemingly involate
laws of data processing is that two identical copies aren't.  No matter
how hard you try, differences creep in.  Even more of a problem is the
fact that I often have to switch between maintaining the delivered
version, and developping the next version -- the sources are obviously
on different branches.  For large projects, the only workable solution
is ClearCase, precisely *because* it avoids the copies.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) writes:

>The compiler still has to open and read the file, even with include
>guards.

Only once, not once for each time the file is included.

Some (lesser-quality) compilers may open and read the same file
multiple times, even when it is has an include guard.  But it's
certainly not necessary.

>> or if one uses a compiler that doesn't recognize include guards
>
>That is, most existing compilers.

What evidence do you have for that statement?

>Just requiring compilers to recognize include guards would be a nice
>first step.

I don't think this can be phrased as a requirement, since the only
effect of recognizing include guards is faster compilation time,
and the C++ standard does not place any requirements on compile time.

It could however be phrased as implementation advice in the standard
(using "should" rather than "shall").

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ 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                       ]

fjh@cs.mu.OZ.AU (Fergus Henderson) wrote in message
news:<apqgm6$n6n$1@mulga.cs.mu.OZ.AU>...
> kanze@gabi-soft.de (James Kanze) writes:

> >The compiler still has to open and read the file, even with include
> >guards.

> Only once, not once for each time the file is included.

> Some (lesser-quality) compilers may open and read the same file
> multiple times, even when it is has an include guard.  But it's
> certainly not necessary.

I know that.  I'm not too sure of the total context anymore, but I had
the impression that what I was replying to was claiming that this sort
of optimization just wasn't necessary any more.  It is, and it should be
standard.

> >> or if one uses a compiler that doesn't recognize include guards

> >That is, most existing compilers.

> What evidence do you have for that statement?

The fact that if I don't use the Lakos style guards, my build times go
up by almost an order of magnitude with all compilers I use except g++.

> >Just requiring compilers to recognize include guards would be a nice
> >first step.

> I don't think this can be phrased as a requirement, since the only
> effect of recognizing include guards is faster compilation time, and
> the C++ standard does not place any requirements on compile time.

I fear that you are right.  Although opening and reading a file are
"observable behavior".

At present, I'm not even 100% sure that the optimization is legal.  What
happens if the file is changed between the two times it is read?
(Actually, I don't think that the standard says anything about this
case.  Perhaps a small note saying that if a file is included twice, and
the contents change between the inclusions, behavior is undefined.  On
the other hand, some common sense should apply.  There's nothing in the
standard which explicitly allows your program to stop running just
because someone unplugged the machine, either.)

> It could however be phrased as implementation advice in the standard
> (using "should" rather than "shall").

Probably a good idea.

What I don't understand is that, given that the advantage is so great,
and that the technique has been know for so long (g++ hasn't exactly
kept it a secret), why not all compilers do it.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Nicola Musatti wrote:
> John Nagle wrote:
> [...]

>> - Files referenced via "using" can only contain declarations.
>
> What about templates?

Broadening this slightly to allow declarations and defintions for which
the ODR does not apply would solve this... and would allow inline
functions in using'd headers too.

--
Richard Smith

---
[ 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                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote
> If I remember correctly module support was also in Bjarne's list of
> wished-for C++0x language features.

Bjarne who?   :-)

---
[ 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.@@xmission.dot.com (llewelly) wrote in message news:<86r8ejlswy.fsf@Zorthluthik.foo>...
> nagle@animats.com (John Nagle) writes:
> > I'd suggest roughly the following semantics:
> >
> > - "Filename" never has a suffix.
> >
> > - File search works like Perl, searching a subtree for a matching
> >    file, rather than like #include.  No need to specify paths.
>
> I believe the current standard allows #include to be
>     implemented with the first 2 properties you list; see 16.2 . I
>     don't know of any implementations that do that - but if someone
>     has experience with such an implementation, their comments would
>     be useful in assessing this idea.

CodeWarrior does this. Works great. Among other things, it gives you
the freedom to reorganize your file structure arbitrarily during
development without having to worry about breaking your build.

Bob

---
[ 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                       ]

John Nagle wrote:
> - "using" can only be used outside all other constructs.

Including namespace declarations?  I can see rationale for either choice
-- I'm just trying to make sure it explicit.

Ken

---
[ 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                       ]

alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote in message
news:<3db1a48b.462131296@news.bluecom.no>...

> Reason for this opinion: at the time of the original idea, header file
> inclusion had been proven a problem (Lakos).  Now its no longer a
> practical problem.

Says who?  Machines have speeded up considerably.  CPU time for
compilation is down, and the programs we write are bigger.  With more
templates, which increase the size of header files outrageously.

But Ethernet isn't really any faster than it ever was.  In fact, with
the radical increase of traffic due to networked solutions, it is if
anything slower.

As a result, opening and reading include files (which will almost never
be on the local disk) represents a much larger percentage of compile
time than ever.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Carl Daniel wrote:

> These days, the preferred solutiuon seems to be to make the preprocessor
> able to recognize the "include guard" idiom, and behave as-if something akin
> to #pragma once had been used.  GCC does this, for example.


    I think I was the one who originally suggested that.  But
it's a hack.

    It's time to put header referencing in the language.  I'd
suggest the "using" keyword for this.  Syntax might be

  using "filename";

I'd suggest roughly the following semantics:

- "Filename" never has a suffix.

- File search works like Perl, searching a subtree for a matching
   file, rather than like #include.  No need to specify paths.

- "using" can only be used outside all other constructs.

- Files referenced via "using" can only contain declarations.

- A file is only "used" once.

Some of these restrictions are intended to allow header
preprocessing and cacheing systems.

Comments?

     John Nagle
     Animats

---
[ 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                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:3DB192B7.1090503@animats.com...
> Carl Daniel wrote:
>
> > These days, the preferred solutiuon seems to be to make the preprocessor
> > able to recognize the "include guard" idiom, and behave as-if something
akin
> > to #pragma once had been used.  GCC does this, for example.
>
>
>     I think I was the one who originally suggested that.  But
> it's a hack.
>
>     It's time to put header referencing in the language.  I'd
> suggest the "using" keyword for this.  Syntax might be
>
> Comments?

Sounds great to me.  Almost compatible with Microsoft's Managed C++ #using,
which can name an "assembly" - a "compiled header".

Chances of ever getting a C++ standard that embraces such a feature?
Virtually zero, I'd guess :(

-cd


---
[ 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                       ]

"John Nagle" <nagle@animats.com>, news:3DB192B7.1090503@animats.com...
> [...]
> I'd suggest roughly the following semantics:
>
> - "Filename" never has a suffix.
>
> - File search works like Perl, searching a subtree for a matching
>    file, rather than like #include.  No need to specify paths.

What about files in different directories having the same name? Then one has
to specify paths?

Boris


---
[ 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                       ]

On Sat, 19 Oct 2002 17:33:36 +0000 (UTC), nagle@animats.com (John Nagle) wrote:

>Carl Daniel wrote:
>
>> These days, the preferred solutiuon seems to be to make the preprocessor
>> able to recognize the "include guard" idiom, and behave as-if something akin
>> to #pragma once had been used.  GCC does this, for example.
>
>
>    I think I was the one who originally suggested that.  But it's a hack.
>
>    It's time to put header referencing in the language.

Nope  --  it's time to put module support in the language.



>  I'd suggest the "using" keyword for this.  Syntax might be
>
>  using "filename";
>

In a language with module support the problem(s) with header
includes, if any, would belong to "old C++".

Introducing a new keyword to support header includsion both sends
the wrong signal about preferred language evolution direction (IMHO),
and consumes that keyword so that it's not available for module
support  --  which, again IMHO, is orders of magnitude more important.



>I'd suggest roughly the following semantics:
>
>- "Filename" never has a suffix.
>
>- File search works like Perl, searching a subtree for a matching
>   file, rather than like #include.  No need to specify paths.
>
>- "using" can only be used outside all other constructs.
>
>- Files referenced via "using" can only contain declarations.
>
>- A file is only "used" once.
>
>Some of these restrictions are intended to allow header
>preprocessing and cacheing systems.
>
>Comments?

Modern compilers + Lakos' coding techniques, now well known, make
the whole issue if header include support moot, I think.  As would
future support for modules.  Which this idea clashes with.


Cheers,

- Alf

---
[ 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                       ]

>     It's time to put header referencing in the language.  I'd
> suggest the "using" keyword for this.  Syntax might be
>
> using "filename";
>
> I'd suggest roughly the following semantics:
>
> - "Filename" never has a suffix.

Without file extensions, it would seem to imply that "filename" is some
abstract library, when the real intent is simply to reference a file itself!

---
[ 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                       ]

John Nagle wrote:
[...]
>    It's time to put header referencing in the language.  I'd
> suggest the "using" keyword for this.  Syntax might be
>
>         using "filename";

I agree.

> I'd suggest roughly the following semantics:
>
> - "Filename" never has a suffix.

Dangerous, especially in combination with the following. How can the
compiler be prevented from including an executable?

> - File search works like Perl, searching a subtree for a matching
>   file, rather than like #include.  No need to specify paths.

I'm not convinced this is the best solution. I fear many unwanted
matches may result.

> - "using" can only be used outside all other constructs.

OK.

> - Files referenced via "using" can only contain declarations.

What about templates?

> - A file is only "used" once.

Yessss.

Cheers,
Nicola Musatti

---
[ 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                       ]

Alf P. Steinbach wrote:

> nagle@animats.com (John Nagle) wrote:
>
>>Carl Daniel wrote:
>>>These days, the preferred solutiuon seems to be to make the preprocessor
>>>able to recognize the "include guard" idiom, and behave as-if something akin
>>>to #pragma once had been used.  GCC does this, for example.
>>
>>   I think I was the one who originally suggested that.  But it's a hack.
>>   It's time to put header referencing in the language.
>
> Nope  --  it's time to put module support in the language.


    Actually, I agree, and it should have gone in
with namespaces, but it's too late for that.


> Introducing a new keyword...


     Er, we already have "using" as a keyword.  That's why
I suggested it, in line with the general bias against adding
keywords.

     The real facility I want here is Perl-type search, where
the entire subtree is searched.  (If it works for Perl, where
it has to be done every time you run the program, it can't
be too expensive.)  We might allow subpaths, where you write

 using "foo/bar";

to disambiguate searches when absolutely necessary.
This indicates that "bar" must be found in some directory "foo",
somewhere in the directory trees being searched, not necessarily
at the top.  That would, hopefully, be a seldom-used feature,
for those cases where you have two versions of something and
need to distinguish them.

     Pragma "once" is a hack.  #ifndef guards are a hack.
Automatic recognition of #ifndef guards is a second-level
hack.  The language really should have a feature for this.

     John Nagle
     Animats

---
[ 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                       ]

On Sat, 19 Oct 2002 17:33:36 +0000 (UTC), nagle@animats.com (John Nagle) wrote:

>Carl Daniel wrote:
>
>> These days, the preferred solutiuon seems to be to make the preprocessor
>> able to recognize the "include guard" idiom, and behave as-if something akin
>> to #pragma once had been used.  GCC does this, for example.
>
>
>    I think I was the one who originally suggested that.  But
>it's a hack.
>
>    It's time to put header referencing in the language.  I'd
>suggest the "using" keyword for this.  Syntax might be
>
>  using "filename";
>
>I'd suggest roughly the following semantics:
>
>- "Filename" never has a suffix.
>
>- File search works like Perl, searching a subtree for a matching
>   file, rather than like #include.  No need to specify paths.
>
>- "using" can only be used outside all other constructs.
>
>- Files referenced via "using" can only contain declarations.
>
>- A file is only "used" once.
>
>Some of these restrictions are intended to allow header
>preprocessing and cacheing systems.
>
>Comments?

Yes, I think your original idea was a great one, and the current
one on the absolute opposite end of the scale.  No offence intended.
Reason for this opinion: at the time of the original idea, header
file inclusion had been proven a problem (Lakos).  Now its no
longer a practical problem.  Instead the (related) problem is the more
general one that C++ lacks support for separately compiled modules.

A new "using"-construct for just including header-files would conflict
with both the, in my view, preferred language evolution direction, and
possibly with keywords for later module support.

If I remember correctly module support was also in Bjarne's list of
wished-for C++0x language features.


Cheers,

- Alf

---
[ 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                       ]

nagle@animats.com (John Nagle) writes:

> Carl Daniel wrote:
>
> > These days, the preferred solutiuon seems to be to make the preprocessor
> > able to recognize the "include guard" idiom, and behave as-if something akin
> > to #pragma once had been used.  GCC does this, for example.
>
>
>     I think I was the one who originally suggested that.  But
> it's a hack.
>
>     It's time to put header referencing in the language.  I'd
> suggest the "using" keyword for this.  Syntax might be
>
>   using "filename";
>
> I'd suggest roughly the following semantics:
>
> - "Filename" never has a suffix.
>
> - File search works like Perl, searching a subtree for a matching
>    file, rather than like #include.  No need to specify paths.

I believe the current standard allows #include to be
    implemented with the first 2 properties you list; see 16.2 . I
    don't know of any implementations that do that - but if someone
    has experience with such an implementation, their comments would
    be useful in assessing this idea.

This notion seems to require a description of how a search for a file
    matching a filename is carried out, which makes me wonder if there are
    C++ implementations for platforms that have file systems which are
    not hierarchical structures of directories containting files
    and/or directories. (Are there perl or java implementations for
    such platforms?) The current standard is careful not to require a
    hierarchical directory structure.


>
> - "using" can only be used outside all other constructs.
>
> - Files referenced via "using" can only contain declarations.

This implies a declaration cannot span span files. (A good thing.)

>
> - A file is only "used" once.

Are duplicate using "same_filename" statements ignored?
Do they require a diagnostic?

>
> Some of these restrictions are intended to allow header
> preprocessing and cacheing systems.

The current standard already allows such things. I suppose these
    restrictions would make preprocessing and cacheing systems easier
    to implemnt, or more powerful.

>
> Comments?

The current standard (mostly) avoids mention of 'files' outside of
    chapters 2, 16, and 27.

[snip]

---
[ 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                       ]

In article <3db390b2.588122281@news.bluecom.no>,
 on Mon, 21 Oct 2002 16:04:45 +0000 (UTC),
 alf_p_steinbach@yahoo.no.invalid (Alf P. Steinbach) wrote:

> On Sat, 19 Oct 2002 17:33:36 +0000 (UTC), nagle@animats.com (John
> Nagle) wrote:
>
> >  I'd suggest the "using" keyword for this.  Syntax might be
> >
> >  using "filename";
> >
>
> In a language with module support the problem(s) with header
> includes, if any, would belong to "old C++".
>
> Introducing a new keyword to support header includsion

It's not a new keyword, it's a new use of an existing keyword.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ 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                       ]