Topic: #include and tokenization
Author: Christopher Eltschka <celtschk@web.de>
Date: Tue, 31 Jul 2001 18:41:48 GMT Raw View
gennaro_prota@my-deja.com (Gennaro Prota) writes:
> On Wed, 25 Jul 2001 00:01:02 GMT, Mike Lundy <lundy@osgltd.com> wrote:
>
> >
> >Hi Gennearo,
> >
> >Please see my inserts below. This is puzzling situation in that it cannot come to conclusion.
>
> How it this possible? Does the standard leave it unspecified? And if
> so, how can the book you recommended me take my doubt away? :-)
>
> >
> >
> >Gennaro Prota wrote:
> >>
> >> On Tue, 24 Jul 2001 09:48:38 GMT, Mike Lundy <lundy@osgltd.com> wrote:
> >>
> >> [snip...]
>
> >> Well...the fact that it behaves as expected with a specific compiler
> >> doesn't decree that the code is correct (standard compliant) ;-)
> >> The result of the innermost join is (without quotes)
> >> "myFiles/copyright" which cannot be a single token.
> >
> >
> >Hmmm, the preprocessor used is an ASNI tokenizing model providing explicit token pasting, as required. Have you experimented
> >with your preprocessor using files containing directives of interest to gather results prior to posting your inquiry?
> >
> With the compiler I used,
>
> #define BUILD_NAME(name) <folder/name>
>
> have it's replacement-list parsed as a sequence of tokens (so, NOT a
> header-name). This allows the macro-parameter to be replaced as
> expected. My question is: where does the standard say that it HAS to
> be parsed that way? Does it say that <h-char-sequence> is parsed as a
> header-name preprocessing token ONLY if it appears in a #include
> directive? There's something similar to that in 2.8p1...but I'm not
> sure whether it means that you should never write a <h-char-sequence>
> outside a #include directive, or that if you do so the compiler parses
> it differently.
>
> Genny.
Well, I have only access to CD2. But if this didn't change until the
final standard, I think there's a defect.
First the relevant CD2 text:
----8<----8<----8<----8<----
2.4 Preprocessing tokens [lex.pptoken]
preprocessing-token:
header-name
identifier
pp-number
character-literal
string-literal
preprocessing-op-or-punc
each non-white-space character that cannot be one of the above
[...]
3 If the input stream has been parsed into preprocessing tokens up to a
given character, the next preprocessing token is the longest sequence
of characters that could constitute a preprocessing token, even if
that would cause further lexical analysis to fail.
----8<----8<----8<----8<----
And
----8<----8<----8<----8<----
2.8 Header names [lex.header]
[...]
1 Header name preprocessing tokens shall only appear within a #include
preprocessing directive (_cpp.include_). The sequences in both forms
of header-names are mapped in an implementation-defined manner to
headers or to external source file names as specified in
_cpp.include_.
----8<----8<----8<----8<----
Note that CD2, 2.8 [lex.header]/1 does _not_ say that header name
preprocessing tokens are only lexed inside #include directives, but
only that they shall not appear outside of #include directives.
Given f.ex. the expression
x<1||x>3
the grammar rules say that <1||x>> is a valid header name, therefore
according to CD2, 2.8 [lex.pptoken] is a valid preprocessing token.
CD2, 2.8 [lex.pptoken]/3 tells that always the longest possible
character sequence is used for forming a token, even if this causes
further lexical analysis to fail. There are two preprocessing tokens
starting with '<' which are possible in the above snippet: The forst
is the less-than preprocessing token ("<"), the second is a header
name preprocessing token ("<1||x>"). The latter is certainly the
longer, and therefore this one would have to be taken. Since this
expression is most certainly not part of an #include directive,
according to CD2, 2.8 [lex.header]/1 the program is ill-formed.
This is of course not what was intended (besides others, it would make
about every template code ill-formed), and it is not what real
compilers implement.
Unfortunately I don't have the real standard, so I cannot check if
this error was corrected. If not, I think it should be.
As resolution I would propose changing 2.8 [lex.header]/1 (or if it
has moved, the corresponding paragraph in the standard), by replacing
"Header name preprocessing tokens shall only appear within..." with
"Header name preprocessing tokens are formed only within...".
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: gennaro_prota@my-deja.com (Gennaro Prota)
Date: Wed, 1 Aug 2001 18:45:39 GMT Raw View
On Tue, 31 Jul 2001 18:41:48 GMT, Christopher Eltschka
<celtschk@web.de> wrote:
>> With the compiler I used,
>>
>> #define BUILD_NAME(name) <folder/name>
>>
>> have it's replacement-list parsed as a sequence of tokens (so, NOT a
>> header-name). This allows the macro-parameter to be replaced as
>> expected. My question is: where does the standard say that it HAS to
>> be parsed that way? Does it say that <h-char-sequence> is parsed as a
>> header-name preprocessing token ONLY if it appears in a #include
>> directive? There's something similar to that in 2.8p1...but I'm not
>> sure whether it means that you should never write a <h-char-sequence>
>> outside a #include directive, or that if you do so the compiler parses
>> it differently.
>>
>> Genny.
>
>Well, I have only access to CD2. But if this didn't change until the
>final standard, I think there's a defect.
>
It didn't change.
> [snip...]
>Note that CD2, 2.8 [lex.header]/1 does _not_ say that header name
>preprocessing tokens are only lexed inside #include directives, but
>only that they shall not appear outside of #include directives.
>
>Given f.ex. the expression
>
> x<1||x>3
>
> [snip..]
>
>There are two preprocessing tokens
>starting with '<' which are possible in the above snippet: The forst
>is the less-than preprocessing token ("<"), the second is a header
>name preprocessing token ("<1||x>"). The latter is certainly the
>longer, and therefore this one would have to be taken. Since this
>expression is most certainly not part of an #include directive,
>according to CD2, 2.8 [lex.header]/1 the program is ill-formed.
>
>This is of course not what was intended (besides others, it would make
>about every template code ill-formed), and it is not what real
>compilers implement.
>
>
>As resolution I would propose changing 2.8 [lex.header]/1 (or if it
>has moved, the corresponding paragraph in the standard), by replacing
>"Header name preprocessing tokens shall only appear within..." with
>"Header name preprocessing tokens are formed only within...".
>
I agree with you. Actually, since nobody replied to my post (before
you...) I searched through the standard to put some light on the
subject. Well. here's a quote from clause 3 which confirms, if needed
:-), that the intent of 2.8p1 was the one you suggest.
"The process of dividing a source file's characters into preprocessing
tokens is context-dependent. [Example: see the handling of < within a
#include preprocessing directive. ]"
But since that "handling of <" is, as far as I know, not specified
elsewhere I think a correction is needed.
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.research.att.com/~austern/csc/faq.html ]
Author: Sean Parent <sparent@adobe.com>
Date: Fri, 27 Jul 2001 21:32:41 GMT Raw View
To accomplish this with for a quoted include the following seems to work
with CodeWarrior 7 preview release. From my understanding of the
pre-processor it appears to be legit.
#define MAKE_STR(path) #path
#define INTERFACES(file) MAKE_STR(interfaces/##file)
#include INTERFACES(value.h)
I found it surprising that string concatenation doesn't work in the
preprocessor so the following fails:
#define INTERFACES(file) "interfaces/" #file
#include INTERFACES(value.h)
I haven't pored over the spec on this topic yet but I thought the challenge
of a solution with quotes was interesting.
--
Sean Parent
Sr. Engineering Manager
Adobe Workgroup Services
sparent@adobe.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.research.att.com/~austern/csc/faq.html ]
Author: gennaro_prota@my-deja.com (Gennaro Prota)
Date: Wed, 25 Jul 2001 17:42:07 GMT Raw View
On Wed, 25 Jul 2001 00:01:02 GMT, Mike Lundy <lundy@osgltd.com> wrote:
>
>Hi Gennearo,
>
>Please see my inserts below. This is puzzling situation in that it cannot come to conclusion.
How it this possible? Does the standard leave it unspecified? And if
so, how can the book you recommended me take my doubt away? :-)
>
>
>Gennaro Prota wrote:
>>
>> On Tue, 24 Jul 2001 09:48:38 GMT, Mike Lundy <lundy@osgltd.com> wrote:
>>
>> [snip...]
>> Well...the fact that it behaves as expected with a specific compiler
>> doesn't decree that the code is correct (standard compliant) ;-)
>> The result of the innermost join is (without quotes)
>> "myFiles/copyright" which cannot be a single token.
>
>
>Hmmm, the preprocessor used is an ASNI tokenizing model providing explicit token pasting, as required. Have you experimented
>with your preprocessor using files containing directives of interest to gather results prior to posting your inquiry?
>
With the compiler I used,
#define BUILD_NAME(name) <folder/name>
have it's replacement-list parsed as a sequence of tokens (so, NOT a
header-name). This allows the macro-parameter to be replaced as
expected. My question is: where does the standard say that it HAS to
be parsed that way? Does it say that <h-char-sequence> is parsed as a
header-name preprocessing token ONLY if it appears in a #include
directive? There's something similar to that in 2.8p1...but I'm not
sure whether it means that you should never write a <h-char-sequence>
outside a #include directive, or that if you do so the compiler parses
it differently.
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.research.att.com/~austern/csc/faq.html ]
Author: Mike Lundy <lundy@osgltd.com>
Date: Tue, 24 Jul 2001 09:48:38 GMT Raw View
"Andrew F. Vesper" wrote:
>
> Mike Lundy wrote:
>
> > The following preprocessor directives expand to
> > #include <myFiles/copyright.h>
> > on line 4
> >
> > #define JOIN1(A, B) JOIN2(A, B)
> > #define JOIN2(A, B) A ## B
> > #define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
> > #include HEADER(copyright.h)
>
> Since ## is meant to join two tokens into one new token, I don't believe
> this is guaranteed to work correctly. Even if <myFiles/copyright.h> is
> one token, the results of the innermost JOIN1 "myFiles/copyright.h" is
> certainly not.
oh... ?
naturally i tested this prior to posting using cygwin tools with the command:
cpp -Wall -nostdinc -ifoutput -H -P -C >test_out.txt <test_in.txt
and the output was as stated. perhaps our binaries differ.
"Gennaro Prota" wrote :
> I see three possible tokenizations of "folder1/folder2/myFile.h" here:
- as a single string-literal
- as a single header-name
- as a sequence of tokens.
it will be the first as it is a quoted literal, and my cpp application also says so on output.
> how can *name* be identified as a parameter if "folder/name" is
> actually a single token?
it can't, it's treated a single token. again, because it's quoted. try and you will see....
-mike-
>
> --
> Andy V (OpenGL Alpha Geek)
> "In order to make progress, one must leave the door to the unknown ajar."
> Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html ]
======================================= MODERATOR'S COMMENT:
Please do not quote moderation banners and signatures when
posting.
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: gennaro_prota@my-deja.com (Gennaro Prota)
Date: Tue, 24 Jul 2001 17:20:18 GMT Raw View
On Tue, 24 Jul 2001 09:48:38 GMT, Mike Lundy <lundy@osgltd.com> wrote:
>
>
>"Andrew F. Vesper" wrote:
>>
>> Mike Lundy wrote:
>>
>> > The following preprocessor directives expand to
>> > #include <myFiles/copyright.h>
>> > on line 4
>> >
>> > #define JOIN1(A, B) JOIN2(A, B)
>> > #define JOIN2(A, B) A ## B
>> > #define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
>> > #include HEADER(copyright.h)
>>
>> Since ## is meant to join two tokens into one new token, I don't believe
>> this is guaranteed to work correctly. Even if <myFiles/copyright.h> is
>> one token, the results of the innermost JOIN1 "myFiles/copyright.h" is
>> certainly not.
>
>
>oh... ?
>
>naturally i tested this prior to posting using cygwin tools with the command:
>
>cpp -Wall -nostdinc -ifoutput -H -P -C >test_out.txt <test_in.txt
>
>and the output was as stated. perhaps our binaries differ.
Well...the fact that it behaves as expected with a specific compiler
doesn't decree that the code is correct (standard compliant) ;-)
The result of the innermost join is (without quotes)
"myFiles/copyright" which cannot be a single token.
>
>"Gennaro Prota" wrote :
>
>> I see three possible tokenizations of "folder1/folder2/myFile.h" here:
>
> - as a single string-literal
> - as a single header-name
> - as a sequence of tokens.
>
>it will be the first as it is a quoted literal, and my cpp application also says so on output.
>
>> how can *name* be identified as a parameter if "folder/name" is
>> actually a single token?
>
>it can't, it's treated a single token. again, because it's quoted. try and you will see....
>
Ok...i see the problem with quotes; but what if you replace quotes
with < >?
Suppose you have
#define HEADER(x) <myfiles/x>
#include HEADER(file.h)
how do you answer all the previous questions? (string-literal is now
excluded as a possible parsing, of course! :-) )
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.research.att.com/~austern/csc/faq.html ]
Author: Mike Lundy <lundy@osgltd.com>
Date: Wed, 25 Jul 2001 00:01:02 GMT Raw View
Hi Gennearo,
Please see my inserts below. This is puzzling situation in that it cannot come to conclusion.
Gennaro Prota wrote:
>
> On Tue, 24 Jul 2001 09:48:38 GMT, Mike Lundy <lundy@osgltd.com> wrote:
>
> >
> >
> >"Andrew F. Vesper" wrote:
> >>
> >> Mike Lundy wrote:
> >>
> >> > The following preprocessor directives expand to
> >> > #include <myFiles/copyright.h>
> >> > on line 4
> >> >
> >> > #define JOIN1(A, B) JOIN2(A, B)
> >> > #define JOIN2(A, B) A ## B
> >> > #define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
> >> > #include HEADER(copyright.h)
> >>
> >> Since ## is meant to join two tokens into one new token, I don't believe
> >> this is guaranteed to work correctly. Even if <myFiles/copyright.h> is
> >> one token, the results of the innermost JOIN1 "myFiles/copyright.h" is
> >> certainly not.
> >
> >
> >oh... ?
> >
> >naturally i tested this prior to posting using cygwin tools with the command:
> >
> >cpp -Wall -nostdinc -ifoutput -H -P -C >test_out.txt <test_in.txt
> >
> >and the output was as stated. perhaps our binaries differ.
>
> Well...the fact that it behaves as expected with a specific compiler
> doesn't decree that the code is correct (standard compliant) ;-)
> The result of the innermost join is (without quotes)
> "myFiles/copyright" which cannot be a single token.
Hmmm, the preprocessor used is an ASNI tokenizing model providing explicit token pasting, as required. Have you experimented
with your preprocessor using files containing directives of interest to gather results prior to posting your inquiry?
If you happen the oppertunity to come across the book "Practical C++" by Mark A. Terribile, (ISBN 0-07-06378-5), perhaps read
his section 'ANSI C/C++ Preprocessor and Standard Headers', Appendix A, section A.3, where the features of the tool are covered
near completely. I beleive most of your concerns would be addressed in that guide.
Take care,
-mike-
>
> >
> >"Gennaro Prota" wrote :
> >
> >> I see three possible tokenizations of "folder1/folder2/myFile.h" here:
> >
> > - as a single string-literal
> > - as a single header-name
> > - as a sequence of tokens.
> >
> >it will be the first as it is a quoted literal, and my cpp application also says so on output.
> >
> >> how can *name* be identified as a parameter if "folder/name" is
> >> actually a single token?
> >
> >it can't, it's treated a single token. again, because it's quoted. try and you will see....
> >
>
> Ok...i see the problem with quotes; but what if you replace quotes
> with < >?
>
> Suppose you have
>
> #define HEADER(x) <myfiles/x>
> #include HEADER(file.h)
>
> how do you answer all the previous questions? (string-literal is now
> excluded as a possible parsing, of course! :-) )
>
> 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.research.att.com/~austern/csc/faq.html ]
Author: Mike Lundy <lundy@osgltd.com>
Date: Sun, 22 Jul 2001 11:44:03 GMT Raw View
Hi Gennaro,
The following preprocessor directives expand to
#include <myFiles/copyright.h>=20
on line 4
#define JOIN1(A, B) JOIN2(A, B)
#define JOIN2(A, B) A ## B
#define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
#include HEADER(copyright.h)
to have the 'quote' character substituted for the '<' and '>' may require=
some creativity though.
HTH
-mike-
Gennaro Prota wrote:
>=20
> Hi everybody,
>=20
> I have a simple question about tokenization: if I write
>=20
> # define MY_HEADER(name) <path/name>
>=20
> is the macro's replacement list parsed as a single header-name token?
> According to my understanding of the standard the answer should be yes,=
even
> if (=A72.8) this leads to an ill-formed program (a header-name prep-tok=
en
> appears not within a #include directive)
> Anyhow, name can be identified as a macro formal parameter only if nam=
e is
> tokenized as a separate identifier, right?
>=20
> If the right behaviour is the first one you can do something like:
>=20
> #define HEADER_NAME "file.h"
> #include HEADER_NAME
>=20
> or
>=20
> #define HEADER_NAME "myfiles/file.h"
> #include HEADER_NAME /* implementation defined behaviour, but correct
> (=A716.2, bullet 4)*/
>=20
> but NOT
>=20
> #define HEADER(x) "myfiles/x"
> #include HEADER(file.h).
>=20
> Thanks for the help!
> Genny.
>=20
> ---
> [ 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.research.att.com/~austern/csc/faq.html =
]
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: "Andrew F. Vesper" <andy.vesper@acm.org>
Date: Mon, 23 Jul 2001 12:01:05 GMT Raw View
Mike Lundy wrote:
> The following preprocessor directives expand to
> #include <myFiles/copyright.h>
> on line 4
>
> #define JOIN1(A, B) JOIN2(A, B)
> #define JOIN2(A, B) A ## B
> #define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
> #include HEADER(copyright.h)
Since ## is meant to join two tokens into one new token, I don't believe
this is guaranteed to work correctly. Even if <myFiles/copyright.h> is
one token, the results of the innermost JOIN1 "myFiles/copyright.h" is
certainly not.
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: gennaro_prota@my-deja.com (Gennaro Prota)
Date: Mon, 23 Jul 2001 15:43:10 GMT Raw View
On Mon, 23 Jul 2001 12:01:05 GMT, "Andrew F. Vesper"
<andy.vesper@acm.org> wrote:
>Mike Lundy wrote:
>
>> The following preprocessor directives expand to
>> #include <myFiles/copyright.h>
>> on line 4
>>
>> #define JOIN1(A, B) JOIN2(A, B)
>> #define JOIN2(A, B) A ## B
>> #define HEADER(x) JOIN1( JOIN1(<, JOIN1(myFiles/,x ) ),>)
>> #include HEADER(copyright.h)
>
>Since ## is meant to join two tokens into one new token, I don't believe
>this is guaranteed to work correctly. Even if <myFiles/copyright.h> is
>one token, the results of the innermost JOIN1 "myFiles/copyright.h" is
>certainly not.
>
>--
[TO THE MODERATOR: On 20 Jul 2001 I posted a message with
substantially the same contents of the present one...I receveid the
automatic robomoderator mail but neither an "accepted"/"refused"
notification... :-)]
Thanks for your replies! I agree about the last statement.....anyhow
my question was different...:
in a macro definition like #HEADER "h-char-sequence" how is the
replacement-list parsed?
Let's have, for instance:
#HEADER "folder1/folder2/myFile.h"
I see three possible tokenizations of "folder1/folder2/myFile.h" here:
- as a single string-literal
- as a single header-name
- as a sequence of tokens.
Which one?
Now, a further step with function-like macros: :-)
According to my (mis)understanding of the standard, in order to have
them correctly replaced, macro's parameters must be parsed as separate
tokens, right? For instance in:
#define SIGN(x) (( x)>0? (+1) : ((x)<0? ( -1) : (0) )
x yelds a single prep-token (identifier, =A72.10); but in the case of
#define BUILD_NAME(name) "folder/name",
how can *name* be identified as a parameter if "folder/name" is
actually a single token?
Thanks for your help!
Genny.
=20
---
[ 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.research.att.com/~austern/csc/faq.html ]
Author: "Gennaro Prota" <gennaro_prota@my-deja.com>
Date: Wed, 18 Jul 2001 16:59:14 GMT Raw View
Hi everybody,
I have a simple question about tokenization: if I write
# define MY_HEADER(name) <path/name>
is the macro's replacement list parsed as a single header-name token?
According to my understanding of the standard the answer should be yes, even
if ( 2.8) this leads to an ill-formed program (a header-name prep-token
appears not within a #include directive)
Anyhow, name can be identified as a macro formal parameter only if name is
tokenized as a separate identifier, right?
If the right behaviour is the first one you can do something like:
#define HEADER_NAME "file.h"
#include HEADER_NAME
or
#define HEADER_NAME "myfiles/file.h"
#include HEADER_NAME /* implementation defined behaviour, but correct
( 16.2, bullet 4)*/
but NOT
#define HEADER(x) "myfiles/x"
#include HEADER(file.h).
Thanks for the help!
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.research.att.com/~austern/csc/faq.html ]