David Abrahams <dave@boost-consulting.com> writes:
> At least Metrowerks has an option to search subtrees.

Ah, a real data point.  Having one only makes me crave more, of
course.  I wonder if Metrowerks has tracked the effect of this feature
on their support calls and/or sales.


..
> guenther@mho.com (Philip Guenther) writes:
> > Did they find that it simplified
> > matters or did it complicate things?
>
> It simplified things at first, but it didn't scale up well because
> eventually you end up with two files of the same name and you can't
> tell from looking at the code which one is getting included.

Well, the same could be said of build setups where multiple -I options
are used to include many directories in the include search path.
Putting include files in per-library/package directories that were
used in the #include filename would seem to solve that for both,
depending on how the recursive search was defined.


..
> Ultimately, even if recursive search did scale up well, it isn't very
> portable, and I care about writing portable code.  So I stopped using
> it long ago.

The curse of all extensions.

..
> > really wise for the standard to jump in and "make law"?  That we
> > haven't seen feedback from anyone using a compiler with such behavior,
> > or even confirmation that such a compiler exists makes me wonder how
> > many users really want this.
>
> Too late, now you have.

While your feedback has reduced my wonder, it has only increased my
suspicion about the idea.  More data is always welcome.


Philip Guenther

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

guenther@mho.com (Philip Guenther) wrote in message news:<29cd73f.0406160015.40fe38ce@posting.google.com>...
> nagle@animats.com (John Nagle) wrote in message news:<JJ0zc.1610$pq7.93@newssvr27.news.prodigy.com>...
> ..
> >     I suggest
> >
> >  using "filename";
> >
> > I'd also suggest that search be Perl-like, so that
> > entire subtrees are searched.  (If Perl can afford to do that
> > at run time, C++ can afford to do it at compile time.
>
> Perl does *not* recursively search subtrees, but rather--like most
> implementations of the C preprocessor--has a ordered list of directory
> prefixes and a mapping that is applied to the argument to get a path
> suffix to try.  For details, please see my previous posting:
>
> http://groups.google.com/groups?selm=29cd73f.0404181403.128a8677%40posting.google.com
>
>
> > A few C++ compilers reportedly already do this.)
>
> Your use of the word 'reportedly' would seem to imply that this hasn't
> actually been verified.  If it *is* true, I would think that the
> experiences of the users of said compilers would be valuable input
> into this discussion.  How many of them know about this behavior?
> Have they *knowingly* used it?  Did they find that it simplified
> matters or did it complicate things?  Was there an option to disable
> the behavior that the user knew about?  If so, did they try it and/or
> prefer it over the recursive behavior?

Metrowerks CodeWarrior recursively searches for headers. It works
quite well and simplifies working with files quite a bit. It makes it
very easy to move files around, which is sometimes an issue early in a
project when the file/directory hierarchy has not yet been frozen.

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                       ]

Philip Guenther <guenther@mho.com> wrote:
> David Abrahams <dave@boost-consulting.com> writes:
> > At least Metrowerks has an option to search subtrees.
>
> Ah, a real data point.  Having one only makes me crave more, of
> course.  I wonder if Metrowerks has tracked the effect of this feature
> on their support calls and/or sales.

  I wouldn't know, but I can tell you that I
  hate the feature. We do have what I consider
  medium sized source trees that combine code
  from several libraries and projects (both
  our own and 3rd-party stuff) and it is a
  PITA to make sure there aren't two headers
  with equal names somewhere in there.
  (However, to be fair, I have to admit that
  I'm using VC and rarely ever work with CW
  myself. Our development on the Mac is done
  in CW, though.)

> [...]
>
> Philip Guenther

  Schobi

--
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
  Scott Meyers


---
[ 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:<MNidnZTDv67pF1XdRVn-sA@speakeasy.net>...
> James Kuyper wrote:
>
> > hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message
> > news:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>... ..
> >> #include header files.  If I'm not mistaken, the concept of header file
> >> #is
> >> not part of the C++ Standard, and only appears in reference to C
> >> compatability discussions in Annex C.
> >
> > You are incorrect. See section 16.2.
>
> It doesn't explicitly mention "header files".  It may seem pathologically
> pedantic, but that seems to be the nature of the game.  In previous
> discussions I have been assured that the use of "header" in 16.2 is in
> reference to "standard header" as distinct from "header file".

I'm sorry - I missed the distinction you were making, which is
embarrassing, because I seem to remember being (one of) the person(s)
who told you that.

Still, I'm not sure of the point you intend by making that
distinction. You wrote:

> Currently, just about every significant program written in C++ uses the
> #include directive to include Standard Headers (the caps indicate the
> formal nature of the Standard Headers as opposed to 'header files') and to
> #include header files.  If I'm not mistaken, the concept of header file is
> not part of the C++ Standard, and only appears in reference to C
> compatability discussions in Annex C.

In this context, you seem to be using the term "header file" to refer
to what the standard itself calls a "source file" in 16.2p1. The
concept of "source file" is very definitely part of the C++ standard
(section 2, paragraph 1), and appears in many locations. While it is
not defined in the C++ standard, the term "header file" basically
means nothing more or less than a C++ source file that's designed to
be the subject of a #include directive.

---
[ 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:<JMOdnY-SyKyCH1vdRVn-hg@speakeasy.net>...
> Bjarne Stroustrup wrote:
>
> > llewelly.at@xmission.dot.com (llewelly) wrote in message
> > news:<86n03earnu.fsf@Zorthluthik.local.bar>...
>
> > Not much of a change. The hardest part of the preprocessor to do
> > without is #include. If you don't have an alternative for that - and
> > we don't have an acceptably complete alternative - we need protection
> > from macros defined in headers that we #include.
>
> Can the vital facilities provided by the #include directive be enumerated?
> Perhaps they have been, and I simply need to read the book.  In either
> case, if they were simply listed as requirements for the language with no
> expectation that the preprocessor would be responsible for providing them,

Well, the standard provide no grounds for such an expectation. It
defines preprocessing directives, and a preprocessing phase, but it
never even mentions a preprocessor. The critical feature of
pre-processing isn't the fact that it is done by a seperate
pre-processor - that has never been required, and isn't even the case
with many implementations. The key feature is that it is "pre". Both
the strengths and the weaknesses of preprocessing directives come from
the fact that they occur before translation phases 5-9.


> My understanding of the current model is that everything visible within a
> given scope must be declared within the translation unit.  That is
> accomplished by loading the source file and every file directly or
> indirectly #included by it into memory, and then parsing it to find the
> items relevant to our code.  The last step uses the internal C++ grammar to
> resolve names. The preprocessor was used as an external means of locating
> and loading these resources. On my system, that means telling the OS to go
> fetch some files and load them into memory.
>
> The reason we use the #include is because the C++ grammar, proper, does not
> know about header names and/or file names.  Suppose rather than
> having /#include/ /<vector>/, we simply said /using/ /std::vector/, and
> told the implementation to go figure it out?

How do intend this concept to be extended to apply to user-defined or
third-party libraries? How would you convey to the Compiler what
location to use?

---
[ 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) wrote in message news:<JJ0zc.1610$pq7.93@newssvr27.news.prodigy.com>...
<snip>

>     We really should have one by now.
>
>     I suggest
>
>  using "filename";
>
> I'd also suggest that search be Perl-like, so that
> entire subtrees are searched.  (If Perl can afford to do that
> at run time, C++ can afford to do it at compile time.
> A few C++ compilers reportedly already do this.)
>
> Disambiguation should be provided with syntax like
>
>  using "sys/types";
>
> which would only match file specifications ending in that form.
> This allows full file specifications if desired, but does
> not require them.

<snip>

Presumabely both these requirements could be met by a preprocessor's
implementation of #include and still be fully standard compliant given
that the mapping from the string after the #include to a particular
file is implementation defined?

Cheers,

Dave

---
[ 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:
> [snip]
>> I may be off the mark, but I am inclined to view the preprocessor as
>> something of a metalanguage in relationship to C++.
>
> It has no facility for describing or manipulating C++ constructs such
>     as scopes, types, etc, etc. At most, it is a meta-langauge on the
>     set of valid C++ tokens - *not* on the C++ language as a whole.

Oh, I didn't intend that it is either powerful or complete.  My only reason
for introducing the concept of a metalanguage is to emphasize that the
preprocessor seems external to C++ proper.  My concepts of language and
metalanguage go far beyond the real of computer science, and the effort to
justify my use of the term would therefore take this discussion too far
afield to remain topical.

> The closest thing C++ has to a builtin meta-langauge is templates -
>     which are terribly clumsy.

I would actually regard the facility for defining classes as the primary
recursive meta-language of C++.  But as I say, it would be a digression to
persue this topic at length.

> [snip]
>> I have a sense there is a very clean, orderly, powerful language chained
>> up
>> by the current use of the preprocessor.  I would very much like to see
>> what that language looks like.
>
> The preprocessor is a big factor in making C++ a mess. But (a) We
>     have no replacement for #include, and (b) a widely practiced set
>     of traditions which make the problems caused by the preprocessor
>     managable,

At some level of complexity.  I've found all most uses of the preprocessor I
have encountered, other than the careful use of a #include for header
files, to provide me very little direct advantage. Usually it means I have
to search the documentation and/or the source tree to find where things are
defined and to try and understand what impact they have on my code. IOW,
it's a big waste of time and a significant distraction (read /aggravation/,
if you will.)

One qualification I have to make on this is that I use Qt quite often and
that makes heavy use of the preprocessor, usually to my benefit.

>     and (c) removal of the preprocessor would not be
>     sufficient to make C++ clean or orderly;
I note the word /necessary/ is not in your sentence.
>     the declarator syntax,
>     certain promotions of builtin types, the disunity of overloading,
>     function templates, and default arguments, and other problems
>     would remain.

These seem less problematic than the ... butchery I've seen done with the
preprocessor.  Dr. Stroustrup has already proposed one approach to
addressing the problem of reducing the impact of the preprocessor.  That
is, create an inherent C++ mechanism to provide the same functionality the
preprocessors provides, particularly for the use #include with header files
(and headers).

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

James Kuyper wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message
> news:<MNidnZTDv67pF1XdRVn-sA@speakeasy.net>...
>> James Kuyper wrote:

> I'm sorry - I missed the distinction you were making, which is
> embarrassing, because I seem to remember being (one of) the person(s)
> who told you that.
>
> Still, I'm not sure of the point you intend by making that
> distinction.

Though not my primary point, this confusion demonstrates that the Standard
lacks clarity. Perhaps a tort lawyer might find satisfaction in such
semantic tort, but for the purposes of an engineering standard, I find it
inappropriately arcane.

--
STH
Hatton's Law: "There is only One inviolable Law"

---
[ 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) wrote in message news:<JJ0zc.1610$pq7.93@newssvr27.news.prodigy.com>...
..
>     I suggest
>
>  using "filename";
>
> I'd also suggest that search be Perl-like, so that
> entire subtrees are searched.  (If Perl can afford to do that
> at run time, C++ can afford to do it at compile time.

Perl does *not* recursively search subtrees, but rather--like most
implementations of the C preprocessor--has a ordered list of directory
prefixes and a mapping that is applied to the argument to get a path
suffix to try.  For details, please see my previous posting:

http://groups.google.com/groups?selm=29cd73f.0404181403.128a8677%40posting.google.com


> A few C++ compilers reportedly already do this.)

Your use of the word 'reportedly' would seem to imply that this hasn't
actually been verified.  If it *is* true, I would think that the
experiences of the users of said compilers would be valuable input
into this discussion.  How many of them know about this behavior?
Have they *knowingly* used it?  Did they find that it simplified
matters or did it complicate things?  Was there an option to disable
the behavior that the user knew about?  If so, did they try it and/or
prefer it over the recursive behavior?

Finally, I haven't seen anyone claim that such behavior is prohibited
by the current standard.  Indeed, the standard leaves the whole topic
to the implementation, which seems wise given both the variety of and
rate of change in compiler options that, for example, gcc provides to
control how include files are located.  Given that compiler writers
are still experimenting to determine what their users desire, is it
really wise for the standard to jump in and "make law"?  That we
haven't seen feedback from anyone using a compiler with such behavior,
or even confirmation that such a compiler exists makes me wonder how
many users really want this.


>     "using" should imply "include once".  (There's an ongoing grumble
>about "what if the file system can't distingush unique files
>with different names due to links."  "#pragma once" has been
>in GCC for years and nobody has reported that as a problem.
>So it isn't a real problem.)

You obviously didn't follow the history of "#pragma once" (and
"#import") in GCC too closely.  They did have bugs, GCC emitted
warnings for them as deprecated/obsolete for years (more than 10,
IIRC), the implementation in GCC was based on path comparison (*not*
file identity), and (mostly because of the failure modes, I think) the
GCC maintainers wanted to remove them, almost doing so in GCC 3.4.
What saved them was a solid chunk of work by a one person, coupled
with or driven by #import's presence in the closest-thing-to-official
Objective-C documentation.

Oh, and the final implementation *still* doen't use anything like
inode numbers to try to detect file identity, as that is impossible to
do sanely in the precompiled header case.

So, while you can assert that GCC has an implementation of "#pragma
once", it hasn't had a *correct* one until GCC 3.4, released two
months ago.  That doesn't mean that a new 'using "filename"' directive
shouldn't have once-only semantics, it just means that we need to be
careful about underestimating the effort required to get it right and
about double-checking the precedents that we cite.


Philip Guenther

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

>> It has no facility for describing or manipulating C++ constructs such
>>     as scopes, types, etc, etc. At most, it is a meta-langauge on the
>>     set of valid C++ tokens

Actually, pp-tokens.  12x is not a C++ token ;-)

>  - *not* on the C++ language as a whole.

> Oh, I didn't intend that it is either powerful or complete.

Ah, but it is powerful!  See http://www.boost.org/libs/preprocessor --
and that's just the dumb version we have to use because most
preprocessors are broken.  With a conforming preprocessor you can do
much better.  I wish I could post a link, but the authors of the more
advanced libraries haven't put them on the web AFAIK.


> > The closest thing C++ has to a builtin meta-langauge is templates -
> >     which are terribly clumsy.

Which is why we have the MPL (http://www.boost.org/libs/mpl).

> I would actually regard the facility for defining classes as the
> primary recursive meta-language of C++.  But as I say, it would be a
> digression to persue this topic at length.

I think it's important to note that templates aren't complete either.
There are certainly things you can do with the preprocessor that
aren't possible with templates.  I wouldn't regard one as being more
"fundamental" than the other -- they fill orthogonal roles.

-Dave

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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

guenther@mho.com (Philip Guenther) writes:

>> I'd also suggest that search be Perl-like, so that
>> entire subtrees are searched.  (If Perl can afford to do that
>> at run time, C++ can afford to do it at compile time.
>
> Perl does *not* recursively search subtrees, but rather--like most
> implementations of the C preprocessor--has a ordered list of directory
> prefixes and a mapping that is applied to the argument to get a path
> suffix to try.  For details, please see my previous posting:
>
> http://groups.google.com/groups?selm=29cd73f.0404181403.128a8677%40posting.google.com
>
>
>> A few C++ compilers reportedly already do this.)
>
> Your use of the word 'reportedly' would seem to imply that this hasn't
> actually been verified.

At least Metrowerks has an option to search subtrees.

> If it *is* true, I would think that the
> experiences of the users of said compilers would be valuable input
> into this discussion.  How many of them know about this behavior?

I knew, I guess.

> Have they *knowingly* used it?

Yes.

> Did they find that it simplified
> matters or did it complicate things?

It simplified things at first, but it didn't scale up well because
eventually you end up with two files of the same name and you can't
tell from looking at the code which one is getting included.

> Was there an option to disable
> the behavior that the user knew about?  If so, did they try it and/or
> prefer it over the recursive behavior?

Ultimately, even if recursive search did scale up well, it isn't very
portable, and I care about writing portable code.  So I stopped using
it long ago.

> Finally, I haven't seen anyone claim that such behavior is prohibited
> by the current standard.

It isn't.

> Indeed, the standard leaves the whole topic
> to the implementation, which seems wise given both the variety of and
> rate of change in compiler options that, for example, gcc provides to
> control how include files are located.  Given that compiler writers
> are still experimenting to determine what their users desire, is it
> really wise for the standard to jump in and "make law"?  That we
> haven't seen feedback from anyone using a compiler with such behavior,
> or even confirmation that such a compiler exists makes me wonder how
> many users really want this.

Too late, now you have.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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 may be off the mark, but I am inclined to view the preprocessor as
> something of a metalanguage in relationship to C++.

It has no facility for describing or manipulating C++ constructs such
    as scopes, types, etc, etc. At most, it is a meta-langauge on the
    set of valid C++ tokens - *not* on the C++ language as a whole.

The closest thing C++ has to a builtin meta-langauge is templates -
    which are terribly clumsy.

[snip]
> I have a sense there is a very clean, orderly, powerful language chained up
> by the current use of the preprocessor.  I would very much like to see what
> that language looks like.

The preprocessor is a big factor in making C++ a mess. But (a) We
    have no replacement for #include, and (b) a widely practiced set
    of traditions which make the problems caused by the preprocessor
    managable, and (c) removal of the preprocessor would not be
    sufficient to make C++ clean or orderly; the declarator syntax,
    certain promotions of builtin types, the disunity of overloading,
    function templates, and default arguments, and other problems
    would remain.

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

> The preprocessor is a big factor in making C++ a mess. But (a) We
>     have no replacement for #include

    We really should have one by now.

    I suggest

 using "filename";

I'd also suggest that search be Perl-like, so that
entire subtrees are searched.  (If Perl can afford to do that
at run time, C++ can afford to do it at compile time.
A few C++ compilers reportedly already do this.)

Disambiguation should be provided with syntax like

 using "sys/types";

which would only match file specifications ending in that form.
This allows full file specifications if desired, but does
not require them.

     "using" should imply "include once".  (There's an ongoing grumble
about "what if the file system can't distingush unique files
with different names due to links."  "#pragma once" has been
in GCC for years and nobody has reported that as a problem.
So it isn't a real problem.)

     Related to this, "using" should be usable at top level
only.  This allows systems where "using" understands
precompiled header files.

     Suffixes remain a problem.  I'd prefer that "using"
accept any suffix that the compiler recognizes as a header
file, but the existence of "string" and "string.h" in the
standard headers probably prevents that.

    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                       ]

llewelly.at@xmission.dot.com (llewelly) writes:
[snip]
> The closest thing C++ has to a builtin meta-langauge is templates -
>     which are terribly clumsy.
[snip]

I intended to say: '... are terribly clumsy for the purpose of
    meta-programming'. For the construciton of typesafe generic
    contianers and functions I find templates to be reasonably
    expressive.

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

[...]

| Decades ago, I read a book called G=F6dle, Escher, Bach, by Douglass R.

It seems to be popular.

[...]

| I may be off the mark, but I am inclined to view the preprocessor as
| something of a metalanguage in relationship to C++.

Problem is: It is not.

[...]

| Some functionality currently found in preprocessor metaprogramming may =
best
| be left to a metaprocessor.

examples?

| C++ itself should be as simple as possible,

Everybody wants a simple language -- and with ones little
modification/extensions.=20

--=20
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

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

| James Kuyper wrote:
|
| > hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message
| > news:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>... ..
| >> #include header files.  If I'm not mistaken, the concept of header file
| >> #is
| >> not part of the C++ Standard, and only appears in reference to C
| >> compatability discussions in Annex C.
| >
| > You are incorrect. See section 16.2.
|
| It doesn't explicitly mention "header files".

True.

|  It may seem pathologically
| pedantic, but that seems to be the nature of the game.  In previous
| discussions I have been assured that the use of "header" in 16.2 is in
| reference to "standard header" as distinct from "header file".

The standard text uses "header" and "source file".  The standard text
considers that a directive of the form

   #include <h-char-sequence-> new-line

names a *header* -- notice the absence of "file" qualification.
Whether that header is a file or a source file is implementation
defined.  Furthermore, the standard text defines a set of headers
collectively known as standard headers.

Moreover, the standard text also considers that a directive of the
form

    #incldue "q-char-sequence" new-line

names a source file, *if* some search is supported, otherwise it acts
like inclusion of a header.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

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

Bjarne Stroustrup wrote:

> llewelly.at@xmission.dot.com (llewelly) wrote in message
> news:<86n03earnu.fsf@Zorthluthik.local.bar>...

> Not much of a change. The hardest part of the preprocessor to do
> without is #include. If you don't have an alternative for that - and
> we don't have an acceptably complete alternative - we need protection
> from macros defined in headers that we #include.

Can the vital facilities provided by the #include directive be enumerated?
Perhaps they have been, and I simply need to read the book.  In either
case, if they were simply listed as requirements for the language with no
expectation that the preprocessor would be responsible for providing them,
it might not be too difficult to come up with a solution - at least at the
conceptual level.

The following may be in need of significant refinement, but it seems like a
useful perspective from which to consider this problem. The first two of
the following paragraphs are not essential to my proposal. They simply
provide some background.

I suspect the entire corpus of declarations available to the implementation
could be represented as a tree using the naming system of C++.  That is, if
we assume every library and project component is in uncompiled source, and
load it all into memory, every declaration would be identifiable by a
unique name.  There will be an identifiable root of that tree for any given
program.  That would probably be the function /main/.  For any give program
we are only interested in a small subset of the available entities. As we
write our program, we add new symbols to that tree, and we make different
subtrees available in the current scope.

My understanding of the current model is that everything visible within a
given scope must be declared within the translation unit.  That is
accomplished by loading the source file and every file directly or
indirectly #included by it into memory, and then parsing it to find the
items relevant to our code.  The last step uses the internal C++ grammar to
resolve names. The preprocessor was used as an external means of locating
and loading these resources. On my system, that means telling the OS to go
fetch some files and load them into memory.

The reason we use the #include is because the C++ grammar, proper, does not
know about header names and/or file names.  Suppose rather than
having /#include/ /<vector>/, we simply said /using/ /std::vector/, and
told the implementation to go figure it out?

> I can write my code without #define

What about conditional compilation?  That is one of the features people have
been concerned about losing if the preprocessor were removed.  For example,
making code portable, or switching between debug and release builds?

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

bjarne@gmail.com (Bjarne Stroustrup) wrote in message news:<1fd97be1.0406081523.574b91c3@posting.google.com>...

> ... I can write my code
> without #define (except for #include guards) ...
>
> This is in line with my policy of first making damaging features
> redundant rather than trying to ban them.

#define still provides:

 - stringification and an approximation of call-by-name (both
typically used by assert())

 - The ability to generate multiple C++ declarations (for instance an
auto variable paired with a static variable) from a simple, single
declaration.

I'd argue that these capabilities are useful.  It would certainly be
possible to implement these capabilities at a later translation level
(one that was scope-aware).  Any takers?

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

dave@boost-consulting.com (David Abrahams) wrote in message news:<u65a137ab.fsf@boost-consulting.com>...
> bjarne@gmail.com (Bjarne Stroustrup) writes:
>
> > One way of seeing the #scope proposal is as a ways of limiting the
> > impact of macros and thus demonstrating how to do without them.
> >
> > This is in line with my policy of first making damaging features
> > redundant rather than trying to ban them.
>
> Seems to me it doesn't make any of the PP features redundant; it just
> limits their potential for damage.  Did I miss something important?

Probably. I found that the main opposition to ideas about a "proper
include directive" - that is, a facility in the language rather than
in the preprocessor and protecting its contents against undesired
semantic changes caused by the context of inclusion - were claims
about how macros were essential. #nospam - or whatever we call it -
would allow us to experiment and develop ways of protecting
information in headers - and with preventing macros escape from
contexts from which we didn't want them to escape. My hope is that
eventually this will lead to a body of evidence that will allow us to
design and gain a consensus for "a proper include directive". In the
meantive, I'd be able to write my code, especially header code, in a
less paranoid style.


> I guess you could argue that it makes #undef redundant, but that's a
> stretch I think.

Yes, and that wasn't what I was thinking about

  -- Bjarne Stroustrup; http://www.research.att.com/~bs

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

Dietmar Kuehl wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") wrote:
>> I've seen a quote from D&E where is advocated
>> abolishing the C preprocessor from the C++ language.
>
> Although I personally reduce the use of the preprocessor to a minimum,
> I think that its removal would probably be a serious error. It is a
> reasonable tool for things like code configuration. Here is a list of
> things I'm using the preprocessor for and which are, at least currently,
> not doable using other language constructs:
>
> - Includes and include guards. Well, if we remove the preprocessor in
>   favour of some other approach to the same thing, we would probably
>   no longer use these. Of course, I would consider this step to be
>   moving to an entirely new language...

Perhaps that new language would be the first real C++ - the way it was meant
to be?

Ironically, this common idiom is not a part of the formal language
specification.  This leads me to ask what an anthropological approach to
defining C++ would produce.  That is, what would the language definion
based on actual usage look like. But this is a different topic.

I have been considering alternative approaches to how the traditional use of
#includes for header files might be formalized in C++.  One approach might
be to have an interface declaration block, and an implementation block.
The Standard would then specify the behavior of translation units holding
those blocks.  Separating the declaration and implementation sections into
separate files - if desired - would be an implementation detail, and could
be supported through the use of file names, etc.

The #inclusion of external resources such as declarations in libraries could
be handled by the implementation.  The only responsibility the language
specification would have is to describe the mapping between names and
definitions in abstract terms.

What I'm envisioning is a means of looking up declarations as the source is
processed.  If there were some kind of database of available declarations,
with references to their implementation, I believe that would suffice to
compile the translation unit and create object code. A test could be made
to determin if the declaration referenced a pre-compiled resource, or if
the resourced also needs to be compiled.  If all declarations were placed
in these hypothetical declaration blocks, then the database of declarations
might consist of only what appears in the declaration blocks with a
platform specific 'address' of the implementation of the declared items in
the interface.

I know of another language that produces the equivalent of this declaration
block automatically from the compiled byte code stored in .class files.
This seems to have a significant impact on compile times.  There have even
been situations in which I thought the compilation had failed because it
completed in a matter of second, while I was expecting it to take the
better part of an hour.

> - Transparent passing of __FIlE__ and __LINE__. For things like logging
>   information about the call site is quite useful. This might be
>   replaced by making the whole call stack including line information is
>   available (to applications using it; it can be remove for applications
>   not using it to avoid burdening them).

This kind of thing is done for languages without a preprocessor. It sounds
like something the language implementation could, and should provide.

> - Conditional compilation. Although I reduce conditional compilation to
>   a minimum, it is necessary when implementing code for different
>   platforms. Of course, the conditional parts just implement some
>   abstraction but they are still there.

I had suggested that the Standard should specify that unreachable source
code not result in the compiler emitting object code.  We could then use a
constant defined at one point, and accessed at every place where the
condition needed to be considered.  I later realized this was a bad idea.
Unreachable code often represents a design flaw, and should not be used
intentionally without some additional means of explicitly specifying
intent.


> - Control structures. There is no way in C++ to create new control
>   structure although some typical uses can be approximated using macros.
>   For example, a "for_each" loop could be an example. The corresponding
>   standard library function, although conceptually preferable, does not
>   yield the same convenience because it is impossible to pass blocks to
>   a C++ function (I'm personally still using the functions but I think
>   accept that other people prefer a macro yielding more convenience).

I'm not sure what you mean here.  I haven't been exposed to this design
approach. Is there an example in TC++PL(SE). Josuttis's 'library' book, or
Vandevoorde and Josuttis's template book?

> - Return processing. Sometimes processing of return statements is rather
>   boilerplate (e.g. when using COM) but it is impossible implement this
>   code differently than through a macro or repeating it. This is
>   somwhat related to the previous issue e.g. when it comes down to
>   changing exceptions into return codes.

Is it good to have the C++ Standard require support for 'code generation'?
I'm inclined to have such preprocessing done outside of what the Standard
addresses.  I've seen this done with other languages.  An example is the
ozone database. http://www.ozone-db.org/frames/home/what.html

The problem, as I see it, with supporting such functionality within the
language is that it makes standard C++ less predictable and grammatically
consistent.

> I think this is a result of the realization that the preprocessor will
> not go away in C++. Thus, it should at least be equipped with nicer
> handling of typical uses. The #scope stuff (I guess you are refering to
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1614.pdf>)
Indirectly, yes.  I had only seen a sentence about this somewhere.  Thank's
for the reference.
> is
> one of the things which could be done to make the preprocessor more
> behaved.

I think namespaces are a great idea. Nonetheless, I would like a means of
'closing' them. But that's a different topic.

I've been asking myself what C++ would look like if there were no header
files separated from implementation files. I have found the #include
mechanism to be one of the most problematic aspects of learning C++.  The
fact that #includes can be nested to arbitrary depth is downright offensive
to my sense of order.

>> Some weeks back, I proposed the Standard Library could be organized in a
>> deeper namespace hierarchy.
>
> I don't think this would fly - at least not without a modification of
> name lookup rules: argument dependent lookup searches certain namespaces
> and makes generic programming viable if functions are found a related
> namespace. However, calling 'find(c, 17)' where 'c' is a
> 'std::containers::vector<int>' would not look in 'std::algorithm' for
> the appropriate algorithm (well, there is no algorithm 'find()' taking
> a container anyway - yet). An alternative could be the replacement of
> argument dependent lookup by some form of qualifying function call in
> generic code with concepts but this would effectively again result in
> moving towards an entirely new language.

I'm not really sure what the problem is.  Other than the fact that you would
have to be more explicit about what was introduced into your scope, how
does this impact the potential for generic programming?  I'm not
challenging your conclusion.  I simply don't have a solid enough
understanding of the context to think about this at the same level as you.
I guess I'll leave it to others to address.

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

bjarne@gmail.com (Bjarne Stroustrup) writes:

> llewelly.at@xmission.dot.com (llewelly) wrote in message news:<86n03earnu.fsf@Zorthluthik.local.bar>...
>> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
[snip]
>> Something of a change from his past opinions as well. The last
>>     chapter of D&E advocates abolishing the preprocessor.
>
> Not much of a change. The hardest part of the preprocessor to do
> without is #include. If you don't have an alternative for that - and
> we don't have an acceptably complete alternative - we need protection
> from macros defined in headers that we #include. I can write my code
> without #define (except for #include guards), but when I include
> someone else's header, I am at the mercy of their ideas of macro use.
> One way of seeing the #scope proposal is as a ways of limiting the
> impact of macros and thus demonstrating how to do without them.
>
> This is in line with my policy of first making damaging features
> redundant rather than trying to ban them.

I can see that now; I didn't before becuase I was expecting that
    something inline with abolishing the preprocessor would try to
    make more of it redundant (for example, a proposal to add
    something like Ada's packages).

I didn't realize the preprocessor should be made safer during the
    long time it will likely be before a replacement for #include
    is availible (are there even any designs on the table?), let
    alone predominant.

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

wade@stoner.com (Bill Wade) writes:

| bjarne@gmail.com (Bjarne Stroustrup) wrote in message news:<1fd97be1.0406081523.574b91c3@posting.google.com>...
|
| > ... I can write my code
| > without #define (except for #include guards) ...
| >
| > This is in line with my policy of first making damaging features
| > redundant rather than trying to ban them.
|
| #define still provides:
|
|  - stringification and an approximation of call-by-name (both
| typically used by assert())
|
|  - The ability to generate multiple C++ declarations (for instance an
| auto variable paired with a static variable) from a simple, single
| declaration.
|
| I'd argue that these capabilities are useful.  It would certainly be
| possible to implement these capabilities at a later translation level
| (one that was scope-aware).  Any takers?

The fundamental point is whether those features out to be provided by
a dumb text processor or be part of the language with an integrated
understanding of the other languages functionalities.

The stringification offered by #define is rather baroque, compared to
modern facilities like compile-time reflection (have a look at
reification in Template Haskell).  If we believe call-by-name is a
sound programming technique then we rather have it integrated to the
language.  If we believe generation of declarations is a sound
programming technique we want to support, we rather have it done in
a way that supports and respects other language functionalities.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

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

James Kuyper wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message
> news:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>... ..
>> #include header files.  If I'm not mistaken, the concept of header file
>> #is
>> not part of the C++ Standard, and only appears in reference to C
>> compatability discussions in Annex C.
>
> You are incorrect. See section 16.2.

It doesn't explicitly mention "header files".  It may seem pathologically
pedantic, but that seems to be the nature of the game.  In previous
discussions I have been assured that the use of "header" in 16.2 is in
reference to "standard header" as distinct from "header file".

I would very much appreciate better wording, and clearer distinctions than
currently exist in the Standard.  Stroustrup offers a solution to problems
of this nature in TC++PL(SE), Chapter 2.

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

Gabriel Dos Reis wrote:

> The fundamental point is whether those features out to be provided by
> a dumb text processor or be part of the language with an integrated
> understanding of the other languages functionalities.
>=20
> The stringification offered by #define is rather baroque, compared to
> modern facilities like compile-time reflection (have a look at
> reification in Template Haskell).  If we believe call-by-name is a
> sound programming technique then we rather have it integrated to the
> language.  If we believe generation of declarations is a sound
> programming technique we want to support, we rather have it done in
> a way that supports and respects other language functionalities.

I wish I had more grounding in all of this.  The most appropriate role I =
can
play in these discussions is advocate for the beginner. With that
qualification being noted, please consider this philosophical observation.

Decades ago, I read a book called G=F6dle, Escher, Bach, by Douglass R.
Hofstadter.  In that book there is much discussion about language verses
metalanguage, their mutual relationship, and the problems that arise when
we fail to maintain or recognize the distinctions between them.

I may be off the mark, but I am inclined to view the preprocessor as
something of a metalanguage in relationship to C++.  There are certainly
powerful and valuable behaviors which can be produced by manipulating
source code written in 'pure' C++ using external mechanisms such as the
preprocessor.  OTOH, C++ proper should not depend on the presence of such=
 a
metalanguage in order to behave as a fully functional, general purpose
programming language.=20

Some functionality currently found in preprocessor metaprogramming may be=
st
be left to a metaprocessor.  C++ itself should be as simple as possible,
but no simpler (to borrow an expression from a Swiss patten clerk).

C++ was considered a hard language to learn in 1995.  That was before mos=
t
people considered templates to be an integral part of the language.  For
those who have been a part of the advancement of the language, it may not
be appearant that it has become ever more challenging for the beginner.  =
My
objective in bringing up this topic was to determine what might be done t=
o
isolate the actual C++ language from the metalanguage of the preprocessor
so that C++ would be more accessible to the beginner, and so that it woul=
d
be easier for implementations and IDE developers to process.

I have a sense there is a very clean, orderly, powerful language chained =
up
by the current use of the preprocessor.  I would very much like to see wh=
at
that language looks like.

--=20
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                       ]

Bjarne Stroustrup has often warned against the use of macros, and the use of
the preprocessor for accomplishing what can better be accomplished through
the core language.  I've seen a quote from D&E where is advocated
abolishing the C preprocessor from the C++ language.

Currently, just about every significant program written in C++ uses the
#include directive to include Standard Headers (the caps indicate the
formal nature of the Standard Headers as opposed to 'header files') and to
#include header files.  If I'm not mistaken, the concept of header file is
not part of the C++ Standard, and only appears in reference to C
compatability discussions in Annex C.

Somewhere in the list of items recently under discussion for inclusion in
the Standard is a suggestion to has a means of bracketting preprocessor
directives.  I'm not able to find it right now, but I believe the proponent
of the feature was Stroustrup.

I would like to propose a thought experiment that might lead to insight as
to how the C++ Programming Language could be improved.  The exercise is
this:  Abolish the preprocessor, and all that goes with it.  For example
#include directives.  What breaks?  What mechanisms could be used to
provide the same functionality as the preprocessor currently provides?

Some weeks back, I proposed the Standard Library could be organized in a
deeper namespace hierarchy. I've also proposed the mechanism for retrieving
resources from the Library implementation should rely on the structure of
that naming system.  The word often used to describe a storage system with
such a lookup process is 'directory'.

As a motivation, not to be taken literally, suppose we locate library
resources as follows:

library://std/string
library://std/util/pair

ftp://ftp.rfc-editor.org/in-notes/rfc3305.txt
--
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:
> I've seen a quote from D&E where is advocated
> abolishing the C preprocessor from the C++ language.

Although I personally reduce the use of the preprocessor to a minimum,
I think that its removal would probably be a serious error. It is a
reasonable tool for things like code configuration. Here is a list of
things I'm using the preprocessor for and which are, at least currently,
not doable using other language constructs:

- Includes and include guards. Well, if we remove the preprocessor in
  favour of some other approach to the same thing, we would probably
  no longer use these. Of course, I would consider this step to be
  moving to an entirely new language...

- Transparent passing of __FIlE__ and __LINE__. For things like logging
  information about the call site is quite useful. This might be
  replaced by making the whole call stack including line information is
  available (to applications using it; it can be remove for applications
  not using it to avoid burdening them).

- Conditional compilation. Although I reduce conditional compilation to
  a minimum, it is necessary when implementing code for different
  platforms. Of course, the conditional parts just implement some
  abstraction but they are still there.

- Program configuration. All I'm aware of compilers allow defining
  macros on the command line, allowing easy configuration without
  changing any files. Of course, there may be an alternative approach
  to the same functionality.

- Control structures. There is no way in C++ to create new control
  structure although some typical uses can be approximated using macros.
  For example, a "for_each" loop could be an example. The corresponding
  standard library function, although conceptually preferable, does not
  yield the same convenience because it is impossible to pass blocks to
  a C++ function (I'm personally still using the functions but I think
  accept that other people prefer a macro yielding more convenience).

- Return processing. Sometimes processing of return statements is rather
  boilerplate (e.g. when using COM) but it is impossible implement this
  code differently than through a macro or repeating it. This is
  somwhat related to the previous issue e.g. when it comes down to
  changing exceptions into return codes.

Some of the current preprocessor needs can possibly removed by extending
the C++ language. For example, the control structure issue can probably
mostly handled by supporting some form of lambdas and the return
processing might be handled with a special case. Conditional compilation
might be handled by a combination of compile time if (the unreachable
code in an if statement on a constant expression is not checked for
correctness similar to non-instantiated templates) and namespace
templates with their specializations:

  enum System { unix, windows, mac };
  template <System> namespace system_;
  template <> namespace system_<unix> { ... }
  template <> namespace system_<windows> { ... }
  template <> namespace system_<mac> { ... }
  namespace system = system_<system_configuration>;

Or with namespace level if/else statements which are obviously
restricted to use constant expressions for their condition.

> Somewhere in the list of items recently under discussion for inclusion in
> the Standard is a suggestion to has a means of bracketting preprocessor
> directives.  I'm not able to find it right now, but I believe the proponent
> of the feature was Stroustrup.

I think this is a result of the realization that the preprocessor will
not go away in C++. Thus, it should at least be equipped with nicer
handling of typical uses. The #scope stuff (I guess you are refering to
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1614.pdf>) is
one of the things which could be done to make the preprocessor more
behaved.

> Some weeks back, I proposed the Standard Library could be organized in a
> deeper namespace hierarchy.

I don't think this would fly - at least not without a modification of
name lookup rules: argument dependent lookup searches certain namespaces
and makes generic programming viable if functions are found a related
namespace. However, calling 'find(c, 17)' where 'c' is a
'std::containers::vector<int>' would not look in 'std::algorithm' for
the appropriate algorithm (well, there is no algorithm 'find()' taking
a container anyway - yet). An alternative could be the replacement of
argument dependent lookup by some form of qualifying function call in
generic code with concepts but this would effectively again result in
moving towards an entirely new language.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---
[ 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:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>...
> Bjarne Stroustrup has often warned against the use of macros, and the use of
> the preprocessor for accomplishing what can better be accomplished through
> the core language.  I've seen a quote from D&E where is advocated
> abolishing the C preprocessor from the C++ language.
>
> I would like to propose a thought experiment that might lead to insight as
> to how the C++ Programming Language could be improved.  The exercise is
> this:  Abolish the preprocessor, and all that goes with it.  For example
> #include directives.  What breaks?

A lot.

It's not just the #include directive. Several libraries, not at least
Boost libraries, relies heavily on the preprocessor, and there's even
a Boost preprocessor library
(http://www.boost.org/libs/preprocessor/doc/index.html).

Other libraries, such as MPL
(http://www.boost.org/libs/mpl/doc/index.html) use this library in the
implementation, to generate parameter lists, blocks of code, etc.

This does tend to make the code very hard to read, though (at least
for the "uninitiated"), and to debug.

It would be possible to do without it (after all, the preprocessor is
a kind of macro processor), but it typically results in a lot of
duplicated code (that is, code which is slightly different, where you
can't factor out the commonality any other way, including using
templates).

In fact, Paul Mensonides (current maintainer of Boost.PP) has said he
thinks there's even _more_ use for the preprocessor in C++ than in C.
:)

Naturally, some things that used to require the preprocessor in C, can
be done in better ways in C++ (const variables, inline functions,
templates, etc.). However, there are several things that still can't
be done in any other way except the preprocessor or "manually".

Paul has also mentioned that there's still a need for a token-level
processor, like the preprocessor. There are also some proposals to
improve the preprocessor, such as allowing vararg parameter lists,
etc.

Regards,

Terje

---
[ 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:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>...
..
> #include header files.  If I'm not mistaken, the concept of header file is
> not part of the C++ Standard, and only appears in reference to C
> compatability discussions in Annex C.

You are incorrect. See section 16.2.

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

> Bjarne Stroustrup has often warned against the use of macros, and the use of
> the preprocessor for accomplishing what can better be accomplished through
> the core language.  I've seen a quote from D&E where is advocated
> abolishing the C preprocessor from the C++ language.
>
> Currently, just about every significant program written in C++ uses the
> #include directive to include Standard Headers (the caps indicate the
> formal nature of the Standard Headers as opposed to 'header files') and to
> #include header files.  If I'm not mistaken, the concept of header file is
> not part of the C++ Standard, and only appears in reference to C
> compatability discussions in Annex C.
>
> Somewhere in the list of items recently under discussion for inclusion in
> the Standard is a suggestion to has a means of bracketting preprocessor
> directives.  I'm not able to find it right now, but I believe the proponent
> of the feature was Stroustrup.

Something of a change from his past opinions as well. The last
    chapter of D&E advocates abolishing the preprocessor.

>
> I would like to propose a thought experiment that might lead to insight as
> to how the C++ Programming Language could be improved.  The exercise is
> this:  Abolish the preprocessor, and all that goes with it.

As long as it's only a thought experiment. :-)

> For example
> #include directives.  What breaks?

Current C++ conventions for seperating implementation from interface.

> What mechanisms could be used to
> provide the same functionality as the preprocessor currently
> provides?
[snip]

Cut and paste. M4. Perl. sed and awk. C++ has fairly good
    alternatives to most uses of #define. But replacing #include
    requires extra-linguistic tools, or significant core language
    extensions.

---
[ 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.at@xmission.dot.com (llewelly) wrote in message news:<86n03earnu.fsf@Zorthluthik.local.bar>...
> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>
> > Bjarne Stroustrup has often warned against the use of macros, and the use of
> > the preprocessor for accomplishing what can better be accomplished through
> > the core language.  I've seen a quote from D&E where is advocated
> > abolishing the C preprocessor from the C++ language.
> >
> > Currently, just about every significant program written in C++ uses the
> > #include directive to include Standard Headers (the caps indicate the
> > formal nature of the Standard Headers as opposed to 'header files') and to
> > #include header files.  If I'm not mistaken, the concept of header file is
> > not part of the C++ Standard, and only appears in reference to C
> > compatability discussions in Annex C.
> >
> > Somewhere in the list of items recently under discussion for inclusion in
> > the Standard is a suggestion to has a means of bracketting preprocessor
> > directives.  I'm not able to find it right now, but I believe the proponent
> > of the feature was Stroustrup.
>
> Something of a change from his past opinions as well. The last
>     chapter of D&E advocates abolishing the preprocessor.

Not much of a change. The hardest part of the preprocessor to do
without is #include. If you don't have an alternative for that - and
we don't have an acceptably complete alternative - we need protection
from macros defined in headers that we #include. I can write my code
without #define (except for #include guards), but when I include
someone else's header, I am at the mercy of their ideas of macro use.
One way of seeing the #scope proposal is as a ways of limiting the
impact of macros and thus demonstrating how to do without them.

This is in line with my policy of first making damaging features
redundant rather than trying to ban them.

  - Bjarne Stroustrup; http://www.research.att.com/~bs

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

bjarne@gmail.com (Bjarne Stroustrup) writes:

> One way of seeing the #scope proposal is as a ways of limiting the
> impact of macros and thus demonstrating how to do without them.
>
> This is in line with my policy of first making damaging features
> redundant rather than trying to ban them.

Seems to me it doesn't make any of the PP features redundant; it just
limits their potential for damage.  Did I miss something important?

I guess you could argue that it makes #undef redundant, but that's a
stretch I think.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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

"Terje Sletteb?" <tslettebo@hotmail.com> wrote in message
news:b0491891.0406080052.7400452c@posting.google.com...
> hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message
news:<Z7-dnQamlrvCVFnd4p2dnA@speakeasy.net>...
> > Bjarne Stroustrup has often warned against the use of macros, and the use of
> > the preprocessor for accomplishing what can better be accomplished through
> > the core language.  I've seen a quote from D&E where is advocated
> > abolishing the C preprocessor from the C++ language.
> >
> > I would like to propose a thought experiment that might lead to insight as
> > to how the C++ Programming Language could be improved.  The exercise is
> > this:  Abolish the preprocessor, and all that goes with it.  For example
> > #include directives.  What breaks?
>
> A lot.
>
> It's not just the #include directive. Several libraries, not at least
> Boost libraries, relies heavily on the preprocessor, and there's even
> a Boost preprocessor library
> (http://www.boost.org/libs/preprocessor/doc/index.html).
>
> Other libraries, such as MPL
> (http://www.boost.org/libs/mpl/doc/index.html) use this library in the
> implementation, to generate parameter lists, blocks of code, etc.
>
> This does tend to make the code very hard to read, though (at least
> for the "uninitiated"), and to debug.

It only makes it hard to the, as you say, uninitiated.  Once you get used to
looking at code from that perspective, it isn't hard.

> It would be possible to do without it (after all, the preprocessor is
> a kind of macro processor), but it typically results in a lot of
> duplicated code (that is, code which is slightly different, where you
> can't factor out the commonality any other way, including using
> templates).

Doing so also locks the implementation.  You cannot hand code the necessary kind
of variability.  Instead, you'd have to lock everything at a large scale which
causes everybody that doesn't need that kind of scale to suffer (in compile
times).  Further, hand coding large amounts of, for example, repetitious code is
not only tedious, but error prone and produces many many more points of
maintenance.  The alternative is using an external code generator which is
better, but still doesn't give the choice of scale to the user unless you force
them to add an extra build step.

> In fact, Paul Mensonides (current maintainer of Boost.PP) has said he
> thinks there's even _more_ use for the preprocessor in C++ than in C.
> :)

This is true, given the nature of much (but not all) modern C++ code.  However,
just to be clear, I'm not talking about replicating language features like
inline functions, templates, and constant variables.  I'm referring to larger
scale code generation that generates type-safe code that is later processed by
the underlying language.  This kind of generation could easily target C and C++
equally, but tends to be used more in C++ given the trend in metaprogramming.

> Naturally, some things that used to require the preprocessor in C, can
> be done in better ways in C++ (const variables, inline functions,
> templates, etc.).

Yes, and they almost always should be.

> However, there are several things that still can't
> be done in any other way except the preprocessor or "manually".

Also true--especially when you start getting into permutations.  The boilerplate
skyrockets quickly as does the number of maintenance points.

> Paul has also mentioned that there's still a need for a token-level
> processor, like the preprocessor.

The preprocessor's greatest weakness is also the preprocessor's greatest
strength.  The syntax and semantics of the core language are a nuisance during
the generation process.  At the same time, because the preprocessor completely
ignores the syntax and semantics of the core language, it can easily break it.
Therefore, great care should be used when using the preprocessor for any
non-trivial purpose.

The preprocessor has many good uses and many bad uses.  That is no different
than any other language feature.  It should be used in situations where its use
is better and not used when its use is not better.  It isn't the preprocessor
that is bad, it is certain uses of the preprocessor.  Those uses, many of them
traditional, such as replicating constant variables, inline functions, and
templates, should be avoided as much as possible in general.

> There are also some proposals to
> improve the preprocessor, such as allowing vararg parameter lists,
> etc.

Which comes from C99, BTW.  This can significantly help C++, especially for
handling C++ types that contain open commas (such as std::pair<int, int>) with
macros--C doesn't contain such types.

Regards,
Paul Mensonides


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

David Abrahams wrote:
> bjarne@gmail.com (Bjarne Stroustrup) writes:
>
>> One way of seeing the #scope proposal is as a ways of limiting the
>> impact of macros and thus demonstrating how to do without them.
>>
>> This is in line with my policy of first making damaging features
>> redundant rather than trying to ban them.
>
> Seems to me it doesn't make any of the PP features redundant; it just
> limits their potential for damage.  Did I miss something important?
>
> I guess you could argue that it makes #undef redundant, but that's a
> stretch I think.

I believe that Mr. Stroustrup is saying that if #scope offers a better way
of introducing macros into C++, the current way of introducing macros
without using #scope will no longer be necessary. Whether this can be argued
as making the current way of introducing macros "redundant", if #scope is
added, may be a question of semantics, ie how one defines "redundant" in
this context.

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