Gennaro Prota wrote:
.
> there's one other issue which is occurring to me: what is an "external
> declaration" (or definition)?

It is a declaration or definition of an identifier with external
linkage (see section 3.5). The typedef example provided by Greg
Herlihy therefore doesn't qualify.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Thu, 22 Feb 2007 12:21:06 CST, kuyper@....net wrote:

>Gennaro Prota wrote:
>.
>> there's one other issue which is occurring to me: what is an "external
>> declaration" (or definition)?
>
>It is a declaration or definition of an identifier with external
>linkage (see section 3.5).

Hmm... are we looking at the same draft? I can't see any definition
for "external declaration" in n2134.
--
Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Thu, 22 Feb 2007 12:21:06 CST, kuyper@....net wrote:
>
> >Gennaro Prota wrote:
> >.
> >> there's one other issue which is occurring to me: what is an "external
> >> declaration" (or definition)?
> >
> >It is a declaration or definition of an identifier with external
> >linkage (see section 3.5).
>
> Hmm... are we looking at the same draft? I can't see any definition
> for "external declaration" in n2134.

I don't have a copy of the draft. I'm referring to C++98. It doesn't
define "external definition"; but it does define "external linkage",
and "definition", and makes frequent use of the phrase "external
definition" in ways that  are consistent with simply combining those
two definitions in the way that seems, at least to me, to be obvious.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Fri, 23 Feb 2007 22:54:20 CST, kuyper@....net wrote:

>> Hmm... are we looking at the same draft? I can't see any definition
>> for "external declaration" in n2134.
>
>I don't have a copy of the draft. I'm referring to C++98. It doesn't
>define "external definition"; but it does define "external linkage",
>and "definition", and makes frequent use of the phrase "external
>definition"

Sorry to insist, but are you sure you aren't referring to the C
standard? (C99, at least, defines these expressions.)

In the case of the #include restriction we are discussing it seems
obvious that the intent is to require #includes to appear "outside of
everything" (outermost scope). But I think this is not captured by the
concept of "definition of an identifier with external linkage":

  // at global scope
  static void f()
  {
# include <cstddef> // ok?
  }

  static void g()
  {
# include <stddef.h> // ok?
  }

--
Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Feb 22, 7:21 pm, kuy...@wizard.net wrote:
> Gennaro Prota wrote:

> > there's one other issue which is occurring to me: what is an "external
> > declaration" (or definition)?

> It is a declaration or definition of an identifier with external
> linkage (see section 3.5). The typedef example provided by Greg
> Herlihy therefore doesn't qualify.

Does this mean that his example is legal C++?  No implementation
I'm aware of will accept it, and I'm pretty sure that it wasn't
the intent to allow it.  I don't know what the standard claims
to mean by "external declaration" in this case, but it seems
obvious to me that the include must be outside of any statement
whatsoever.

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Sat, 24 Feb 2007 13:13:46 CST, James Kanze wrote:

>On Feb 22, 7:21 pm, kuy...@wizard.net wrote:
>> Gennaro Prota wrote:
>
>> > there's one other issue which is occurring to me: what is an "external
>> > declaration" (or definition)?
>
>> It is a declaration or definition of an identifier with external
>> linkage (see section 3.5). The typedef example provided by Greg
>> Herlihy therefore doesn't qualify.
>
>Does this mean that his example is legal C++?  No implementation
>I'm aware of will accept it, and I'm pretty sure that it wasn't
>the intent to allow it.  I don't know what the standard claims
>to mean by "external declaration" in this case, but it seems
>obvious to me that the include must be outside of any statement
>whatsoever.

Note, too, that this affects an important point in the explicit
namespaces proposal (n1691):

    Those seeking to conveniently enable argument-dependent
    lookups for all operators within an explicit namespace
    could easily create a header file that does so:

    namespace mymath::
    {
        #include "using_ops.hpp"
    }

--
Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Fri, 23 Feb 2007 22:54:20 CST, kuyper@....net wrote:
>
> >> Hmm... are we looking at the same draft? I can't see any definition
> >> for "external declaration" in n2134.
> >
> >I don't have a copy of the draft. I'm referring to C++98. It doesn't
> >define "external definition"; but it does define "external linkage",
> >and "definition", and makes frequent use of the phrase "external
> >definition"
>
> Sorry to insist, but are you sure you aren't referring to the C
> standard? (C99, at least, defines these expressions.)

C++98 section 3.5p2 defines 'external linkage'. Section 1.8p1 defines
'definition'. If I had been confused, and using the C99 standard, I
would have cited sections 6.2.2p2 and 6.7p5, respectively. Of course,
I wouldn't have had to, because C99 explicitly defines 'external
definition' in section 6.9p5, rather than following the C++ route and
requiring that it be derived by the application of ordinary English
grammar rules to the other two definitions.

However, my comment about 'external definition' being frequently used
does seem to have been incorrect. 17.4.2.1p3 seems to be the only
place where either 'external declaration' or 'external ... definition'
is used anywhere in the C++ standard. However, I don't believe I made
that mistake by looking at the wrong standard; I think I was
remembering the large number of hits I found with a search for
'external', and forgetting that those hits were mostly for 'external
linkage'. My apologies for that mistake.

> In the case of the #include restriction we are discussing it seems
> obvious that the intent is to require #includes to appear "outside of
> everything" (outermost scope). But I think this is not captured by the
> concept of "definition of an identifier with external linkage":

I agree that "outside of everything" is not captured by that phrase.
Most implementations of standard headers seem to use ordinary source
code files which, where they can be, are implemented using ordinary C+
+ code, except for the use of identifiers reserved to the
implementation, and avoidance of identifiers reserved for users. I
find it rather hard to imagine how such an implementation could work
as it's supposed to if the header is #included in the middle of a
definition with static linkage or no linkage. Nonetheless, that is
what the standard seems to require.

>   // at global scope
>   static void f()
>   {
> # include <cstddef> // ok?
>   }

I see no plausible way in which 'external definition'  could be
interpreted as applying to a definition with internal linkage. Can you
suggest one?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Mon, 26 Feb 2007 11:23:38 CST, kuyper@....net wrote:

>Gennaro Prota wrote:
>> On Fri, 23 Feb 2007 22:54:20 CST, kuyper@....net wrote:
>>
>> >> Hmm... are we looking at the same draft? I can't see any definition
>> >> for "external declaration" in n2134.
>> >
>> >I don't have a copy of the draft. I'm referring to C++98. It doesn't
>> >define "external definition"; but it does define "external linkage",
>> >and "definition", and makes frequent use of the phrase "external
>> >definition"
>>
>> Sorry to insist, but are you sure you aren't referring to the C
>> standard? (C99, at least, defines these expressions.)
>
>[...]
>
>However, my comment about 'external definition' being frequently used
>does seem to have been incorrect. 17.4.2.1p3 seems to be the only
>place where either 'external declaration' or 'external ... definition'
>is used anywhere in the C++ standard. However, I don't believe I made
>that mistake by looking at the wrong standard; I think I was
>remembering the large number of hits I found with a search for
>'external', and forgetting that those hits were mostly for 'external
>linkage'. My apologies for that mistake.

No problem :-) That's what led me to think that you might be
remembering the C99 standard. No intent to imply "confusion" or
misinformation, of course; I know you very well from your posts :-)

>> In the case of the #include restriction we are discussing it seems
>> obvious that the intent is to require #includes to appear "outside of
>> everything" (outermost scope). But I think this is not captured by the
>> concept of "definition of an identifier with external linkage":
>
>I agree that "outside of everything" is not captured by that phrase.
>Most implementations of standard headers seem to use ordinary source
>code files which, where they can be, are implemented using ordinary C+
>+ code, except for the use of identifiers reserved to the
>implementation, and avoidance of identifiers reserved for users. I
>find it rather hard to imagine how such an implementation could work
>as it's supposed to if the header is #included in the middle of a
>definition with static linkage or no linkage. Nonetheless, that is
>what the standard seems to require.
>
>>   // at global scope
>>   static void f()
>>   {
>> # include <cstddef> // ok?
>>   }
>
>I see no plausible way in which 'external definition'  could be
>interpreted as applying to a definition with internal linkage. Can you
>suggest one?

No; which was my point :-) To the latter of the standard the above is
legal (and I see that there's no misunderstanding, as you also say
"that is what the standard seems to require"). But of course it's
quite difficult that it might work, or that the intent is for it to
work (#including <stddef.h> instead may well compiler correctly, on
some implementations --but again, that it is required to work portably
seems unlikely).

--
Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Hi,

I'm perplexed by this requirement in the current standard draft:

 17.4.2.1 [using.headers] A translation unit shall include a header
 only outside of any external declaration of definition [...]

Logically speaking, declarations and definitions are recognized much
later than #include directives, so how can one say whether the include
directive is within a definition?

Note too, that the wording employs a "shall" but not "no diagnostic is
required".

Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On 20 Feb., 19:06, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> I'm perplexed by this requirement in the current standard draft:
>
>  17.4.2.1 [using.headers] A translation unit shall include a header
>  only outside of any external declaration of definition [...]
>
> Logically speaking, declarations and definitions are recognized much
> later than #include directives, so how can one say whether the include
> directive is within a definition?

Just a guess: This rule exists to forbid something like this:

1) Inside definition:

struct curious {
#include <utility>
  std::pair<int, double> m;
};

2) Inside declaration:
void foo(
#include <utility>
  std::pair<int, double> arg);


> Note too, that the wording employs a "shall" but not "no diagnostic is
> required".

Two weeks ago I have learned that "shall" usually implies that any
violation would require a diagnostics - despite those cases, where
the standard explicitely says otherwise and some other
exceptions ;-).
This seems to be something like a metastandard (to use James Kanze's
words). See the thread

"detecting, at compile-time, whether a type is complete"

started at Jan. 30th, 10:38. Here James' reply to my question:

http://tinyurl.com/yw2vlh

Grettings from Bremen,

Daniel


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Tue, 20 Feb 2007 15:28:21 CST, Daniel Kr   gler wrote:

>> Note too, that the wording employs a "shall" but not "no diagnostic is
>> required".
>
>Two weeks ago I have learned that "shall" usually implies that any
>violation would require a diagnostics - despite those cases, where
>the standard explicitely says otherwise and some other
>exceptions ;-).

FWIW, I think I posted a reply in that thread. My question here is
exactly how can an implementation assure a diagnostic without
Herculean efforts.

Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On 20 Feb., 23:55, Gennaro Prota <gennaro.pr...@yahoo.com> wrote:
> On Tue, 20 Feb 2007 15:28:21 CST, Daniel Kr   gler wrote:
> >> Note too, that the wording employs a "shall" but not "no diagnostic is
> >> required".
>
> >Two weeks ago I have learned that "shall" usually implies that any
> >violation would require a diagnostics - despite those cases, where
> >the standard explicitely says otherwise and some other
> >exceptions ;-).
>
> FWIW, I think I posted a reply in that thread. My question here is
> exactly how can an implementation assure a diagnostic without
> Herculean efforts.

You are absolutely right and I also noted your former answer.
I mentioned James Kanze in this context, because I really liked his
notion of a meta-standard ;-)

Concerning our current discussion: I misread your sentence above and
did not properly recognize that your intention was just the opposite
of
what I had understood.
I agree, that it seems to be a rather cumbersome work for a compiler
to
guarantee this - e.g. many headers would produce reasonable code, if
#include'd inside a namespace definition - so UB would seem a more
reasonable choice.

Greetings,

Daniel






---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Feb 20, 10:06 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
> I'm perplexed by this requirement in the current standard draft:
>
>  17.4.2.1 [using.headers] A translation unit shall include a header
>  only outside of any external declaration of definition [...]
>
> Logically speaking, declarations and definitions are recognized much
> later than #include directives, so how can one say whether the include
> directive is within a definition?

One can determine whether an #include directive is inside of a
definition by simple inspection: if an #include directive appears
somewhere after the start - but before the end - of a single
definition, then it must be the case that the #include directive
appears inside of a definition.

For example:

    typedef
    #include <string>
    std::string cstring;

I would think that in practice most C++ programmers would have no
trouble recognizing similar cases.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On 2/20/07 11:02 PM, in article
1172040684.930965.183060@k78g2000cwa.googlegroups.com, "Greg Herlihy"
<greghe@pacbell.net> wrote:

> On Feb 20, 10:06 am, gennaro.pr...@yahoo.com (Gennaro Prota) wrote:
>> I'm perplexed by this requirement in the current standard draft:
>>
>>  17.4.2.1 [using.headers] A translation unit shall include a header
>>  only outside of any external declaration of definition [...]
>>
>> Logically speaking, declarations and definitions are recognized much
>> later than #include directives, so how can one say whether the include
>> directive is within a definition?
>
> One can determine whether an #include directive is inside of a
> definition by simple inspection: if an #include directive appears
> somewhere after the start - but before the end - of a single
> definition, then it must be the case that the #include directive
> appears inside of a definition.
>
> For example:
>
>     typedef
>     #include <string>
>     std::string cstring;
>
> I would think that in practice most C++ programmers would have no
> trouble recognizing similar cases.

(My original post was truncated for some reason, so I am re-posting the rest
of what I originally wrote in this message).

>>Note too, that the wording employs a "shall" but not "no diagnostic is
>>required".

The Library does not issue diagnostics - so no diagnostic message is ever
required for a program that violates a Library rule. Diagnostic messages are
issued only for "syntactic and semantic" violations of the C++ Language. And
since an #include directive within a definition breaks a Library - and not a
Language - rule, it falls to the programmer both to detect and to fix this -
and any other other - Standard Library rule violation on their own.

Greg

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Feb 21, 8:02 am, "Greg Herlihy" <gre...@pacbell.net> wrote:
> One can determine whether an #include directive is inside of a
> definition by simple inspection: if an #include directive appears
> somewhere after the start - but before the end - of a single
> definition, then it must be the case that the #include directive
> appears inside of a definition.

The problem is, that #include preprocessing is done in phase 4,
while token analysis occurs in step 7. And the description of (4)
says (2.1/1):

"A #include preprocessing directive causes the named header
or source file to be processed from phase 1 through phase 4,
recursively. All preprocessing directives are then deleted."

If I correctly understand the interaction between preprocessor
and compiler, your requirement would enforce an additional
"pre-preprocessing" step.

> For example:
>
>     typedef
>     #include <string>
>     std::string cstring;
>
> I would think that in practice most C++ programmers would have no
> trouble recognizing similar cases.

I doubt so, but I'm not a preprocessor expert, so lets see what
others have to comment on this.

Greetings from Bremen,

Daniel Kr   gler


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:

> On Tue, 20 Feb 2007 15:28:21 CST, Daniel Kr=FCgler wrote:
>=20
>>> Note too, that the wording employs a "shall" but not "no diagnostic i=
s
>>> required".
>>
>>Two weeks ago I have learned that "shall" usually implies that any
>>violation would require a diagnostics - despite those cases, where
>>the standard explicitely says otherwise and some other
>>exceptions ;-).
>=20
> FWIW, I think I posted a reply in that thread. My question here is
> exactly how can an implementation assure a diagnostic without
> Herculean efforts.

E.g., you could have each header in the standard library start with the l=
ine

  __block_inclusion_in_forbidden_places;

Subsequent passes of the compiler will then parse this magic token just f=
or
generating error messages.


Best

Kai-Uwe Bux

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
>
> The Library does not issue diagnostics - so no diagnostic message is ever
> required for a program that violates a Library rule. Diagnostic messages are
> issued only for "syntactic and semantic" violations of the C++ Language.

No, it's not that narrow. The library portion of the language definition
is as much a part of the language definition as the rest, and the same
rules of construction apply. There are many violations of library
requirements that must be diagnosed. Just a silly example: string
value(1, 2, 3, 4, 5); requires a diagnostic, since it does not match the
signature of any of the string constructors.

--

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr   gler wrote:
> On Feb 21, 8:02 am, "Greg Herlihy" <gre...@pacbell.net> wrote:
> > One can determine whether an #include directive is inside of a
> > definition by simple inspection: if an #include directive appears
> > somewhere after the start - but before the end - of a single
> > definition, then it must be the case that the #include directive
> > appears inside of a definition.
>
> The problem is, that #include preprocessing is done in phase 4,
> while token analysis occurs in step 7. And the description of (4)
> says (2.1/1):
>
> "A #include preprocessing directive causes the named header
> or source file to be processed from phase 1 through phase 4,
> recursively. All preprocessing directives are then deleted."
>
> If I correctly understand the interaction between preprocessor
> and compiler, your requirement would enforce an additional
> "pre-preprocessing" step.

Not really. First of all, the way the standard defines things,
#include of a header can be completely magical; there doesn't even
have to be an actual header file, as long as #include <header> causes
the appropriate identifiers to acquire definitions that conform to the
standard's requirements for that header. Even if there is an actual
file for each header, one simple way to implement this would be to
insert a reserved identifier such as __begin_header  at the start of
each standard header. This reserved identifier would be ignored for
all other purposes, except that, at the appropriate point in phase 7,
if it is found inside an external definition, a diagnostic is
generated. There's many other similar ways to achieve the same effect.


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Tue, 20 Feb 2007 15:28:21 CST, Daniel Kr   gler wrote:

> >> Note too, that the wording employs a "shall" but not "no diagnostic is
> >> required".

> >Two weeks ago I have learned that "shall" usually implies that any
> >violation would require a diagnostics - despite those cases, where
> >the standard explicitely says otherwise and some other
> >exceptions ;-).

> FWIW, I think I posted a reply in that thread. My question here is
> exactly how can an implementation assure a diagnostic without
> Herculean efforts.

In practice, I think you'll almost always get an error, without
the implementation making the slightest effort.  I imagine that
most, if not all, header files include a "namespace std {...}"
somewhere, and there are a lot of places where that won't be
legal.  I also got tons of errors from:

    namespace Me {
    #include <list>
    }

although this is one context where "namespace std {...}" would
be legal.

Of course, there's a big difference between "not being to avoid
an error most of the time", and "guaranteeing an error all of
the time".  Given that most of the other violations of
constraints in the standard library are undefined behavior, I
suspect that this is the intent here---maybe a defect report is
in order.

Of course, with a little help from the compiler, it's trivial to
implement: just start every standard header with the line:

    __builtin_generate_error_if_not_at_outer_scope

(You can't do this in your code, of course; using a symbol whose
name starts with two underscores is undefined behavior.  Which
means that a compiler implementor can define it to do whatever
they want.  And of course, there's no guarantee that the
standard headers are even available as files, much less that
they can be compiled with another compiler.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Gennaro Prota" <gennaro.prota@yahoo.com> napisal w wiadomosci news:58cht2pjuj82a6jml66ipij7196f9lhbbt@4ax.com...
> Hi,
>
> I'm perplexed by this requirement in the current standard draft:
>
> 17.4.2.1 [using.headers] A translation unit shall include a header
> only outside of any external declaration of definition [...]
>
> Logically speaking, declarations and definitions are recognized much
> later than #include directives, so how can one say whether the include
> directive is within a definition?

The compiler encounters the #line directive.

Chris


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Wed, 21 Feb 2007 10:22:49 CST, kuyper@....net wrote:

>Daniel Kr   gler wrote:
>[...]
>> If I correctly understand the interaction between preprocessor
>> and compiler, your requirement would enforce an additional
>> "pre-preprocessing" step.
>
>Not really. First of all, the way the standard defines things,
>#include of a header can be completely magical; there doesn't even
>have to be an actual header file, as long as #include <header> causes
>the appropriate identifiers to acquire definitions that conform to the
>standard's requirements for that header. Even if there is an actual
>file for each header, one simple way to implement this would be to
>insert a reserved identifier such as __begin_header  at the start of
>each standard header. This reserved identifier would be ignored for
>all other purposes, except that, at the appropriate point in phase 7,
>if it is found inside an external definition, a diagnostic is
>generated. There's many other similar ways to achieve the same effect.

Very interesting. I didn't think of it but (at least) three of you
point it out, so it seems like "Herculean" is quite a subjective
amount of effort :-) Seriously, I need to think a bit about this... I
suspect that it is possible with some preprocessing "trick" to
eventually eat all the header's content, though I can't off-hand come
up with real code showing that.

Regardless of my suspects and of the Herculean efforts to prove them,
there's one other issue which is occurring to me: what is an "external
declaration" (or definition)?

Genny.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]