philippe_mori@hotmail.com ("Philippe Mori") wrote
> I like and dislike the namespace idea but I think that having
> keyword in std namespace (or in std::keyword namespace) is
> a good idea. All keywords (existing and new) would be in that
> namespace (for consistency) and there would be an implicit
> using directive so that keyword do not need qualification. The
> qualification would be required only if there is a possible
> conflict with an existing identifier.

You're saying you would use a "not-using" declaration?

    not using std::mutable;
    int mutable=0; // Now legal

> Also, I do think that in many case, keyword can be contextual
> so that there would be less possible conflicts. If a keyword
> cannot be used at a given position, we consider the word to
> be an identifier. For example, proposed final keyword would
> be a keyword when deriving if followed by another identifier.
> It would be similar for member functions.

Not only would that dramatically change the way that the language
is parsed... I suspect it would also decrease the quality of our
error messages.
    auto const register int i=5;
Does the compiler complain that "register" is a reserved word? Or
does it try to parse it as an identifier, then complain when it
sees another word "int" afterwards?

> I do not want to have to qualify new keyword with a namespace
> except maybe if case where there is an ambiguity that cannot
> be resolved.

   int int=5, if=10, break=int;
   for (int for=int; for<if; ++for) {
      if (if==for) {
         break=break;
      } else {
         break;
      }
   }

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

> allan_w@my-dejanews.com (Allan W) writes:
>
>
>>ken@spamnot.codeweavers.com (Ken Thomases) wrote
>>
>>>One of the most common objections to suggestions for new features of C++
>>>is that the proposed feature requires adding a new keyword to the
>>>language.  The new keyword would conflict with any uses of that word in
>>>existing C++ code, thus breaking it.
>>>
>>>Since this is essentially a
>>>namespace conflict, and C++ has a mechanism for resolving namespace
>>>conflicts, why not use it?  And, since std is the namespace over which
>>>the standards committee has control, it seems obvious to put new
>>>keywords there.
>>>
>>How about this, instead? ALL C++ keywords (as opposed to library
>>entities) must from now on be preceded by a dollar-sign.


    This is a joke, right?

    Leading and trailing underscore proliferation is
also getting out of hand.  I'd like to suggest that leading,
trailing, and double underscores NOT be used in any component
of the standard.

    I do enough porting and conversion that if symbol name clashes
were an unmanageable problem, I'd notice it.  They're not.
But the tendency to stick gratutious underscores ("_sprintf",
for example) on commonly used symbols is a real pain.

     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                       ]

> >>>One of the most common objections to suggestions for new features of
C++
> >>>is that the proposed feature requires adding a new keyword to the
> >>>language.  The new keyword would conflict with any uses of that word in
> >>>existing C++ code, thus breaking it.
> >>>
> >>>Since this is essentially a
> >>>namespace conflict, and C++ has a mechanism for resolving namespace
> >>>conflicts, why not use it?  And, since std is the namespace over which
> >>>the standards committee has control, it seems obvious to put new
> >>>keywords there.
> >>>
> >>How about this, instead? ALL C++ keywords (as opposed to library
> >>entities) must from now on be preceded by a dollar-sign.
>
>
>     This is a joke, right?
>
>     Leading and trailing underscore proliferation is
> also getting out of hand.  I'd like to suggest that leading,
> trailing, and double underscores NOT be used in any component
> of the standard.
>

I like and dislike the namespace idea but I think that having
keyword in std namespace (or in std::keyword namespace) is
a good idea. All keywords (existing and new) would be in that
namespace (for consistency) and there would be an implicit
using directive so that keyword do not need qualification. The
qualification would be required only if there is a possible
conflict with an existing identifier.

Also, I do think that in many case, keyword can be contextual
so that there would be less possible conflicts. If a keyword
cannot be used at a given position, we consider the word to
be an identifier. For example, proposed final keyword would
be a keyword when deriving if followed by another identifier.
It would be similar for member functions.

I do not want to have to qualify new keyword with a namespace
except maybe if case where there is an ambiguity that cannot
be resolved.


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

> allan_w@my-dejanews.com (Allan W) writes:
> > How about this, instead? ALL C++ keywords (as opposed to library
> > entities) must from now on be preceded by a dollar-sign.

nagle@animats.com (John Nagle) wrote
>     This is a joke, right?

I also wrote (and you snipped):
> > Mostly not kidding. This is a pretty radical change, and I doubt
> > it would ever be implemented... but what's wrong with it?
> > Anything?

>     Leading and trailing underscore proliferation is
> also getting out of hand.  I'd like to suggest that leading,
> trailing, and double underscores NOT be used in any component
> of the standard.

I think it should remain where it is: in the section on reserved
names. (17.4.3.1.2)

You mean, "we sholdn't define any C++ keywords that use underscores."
I agree, with two exceptions:
   * Existing types that use underscores, such as wchar_t.
   * Names designed for compatibility with C, such as _Bool.

>     I do enough porting and conversion that if symbol name clashes
> were an unmanageable problem, I'd notice it.  They're not.
> But the tendency to stick gratutious underscores ("_sprintf",
> for example) on commonly used symbols is a real pain.

Hmmm... A very popular C compiler used to take *ALL* C identifiers
and prepend an underscore. For instance, foo() became _foo.
This was invisible to the C programmer, unless she (a) looked at
the linker map, or (b) tried to link C to some other language such
as Assembly language. Put it another way: if you wanted to call the
C library's "sprintf" routine from assembly language, you would
push all the parameters and then call _sprintf.

Besides the formula for illegal identifiers (can't use two
underscores, can't start with an underscore plus capital letter),
table 3 lists 63 reserved identifiers, and table 4 lists 11 more.
That's a small enough list that collisions are bound to be rare.
The reason they get so much attention is that when they are used,
the impact is likely to be great -- and yet, sometimes they generate
"silent" changes (the code still compiles, but the meaning is
greatly different). This is likely to manifest itself in the middle
of an extremely important sales meeting.

I wouldn't want to see "tax" or "customer" or even "array" become a
new keyword, but I'd agree that adding a few more probably wouldn't
be too painful, especially if the committee used it's usual efforts
to pick English words that are not likely to be used as identifiers
in real programs. (Did anyone use "mutable" as an identifier in any
program before the current standard? That's always possible, but it
isn't very likely.)

Some people (such as Ken Thomases, the OP for this thread) would
like to go further than that. They would like a formal policy about
how new keywords will be phrased, so that we can be absolutely
certain that it won't impact the code we're going to develop between
now and the time compilers implement the keywords -- and preferably
even legacy code written years ago.

One way to handle that is to make all new keywords at least 12
letters long, random letters (perhaps without any vowels), and
maybe with an underscore near the middle.
    lwxch_wmksdfg
probably isn't used as an identifier by ANY existing program.
I trust you can see for yourself the downside to this approach.

What Ken Thomases really wants is a formula for new keywords that
would be illegal for existing keywords. Specifically he proposed
using "std::" in front of new keywords. I have my own reasons for
disliking that (to me it looks worse than the "random letter"
approach above) but at least I understand his motivation. The C
committe took another approach; single underscore followed by
capital letter is already reserved, so they used that. Realizing
that this had some (but not much) of the same ugliness as the
"random letter" approach, they also defined the macro in a header
file.

Personally, I would have preferred that they simply declare "bool"
to be a new keyword. Many compilers implement both C and C++ anyway,
and I'm sure they're already going to have a hard time with a
variable named "bool."

Anyway, dollar signs are not legal in C or C++ identifiers today.
That seemed to make them good candidates for keywords. However, I
know that llewelly is right about some compilers using dollar
sign identifiers as local extensions. For instance, Digital's
VAX/VMS used to make all the system calls available to C in the
form of a library. To "Broadcast" a message, you would call
SYS$BROADCAST and so on...

llewelly also pointed out the biggest problem with using dollar signs:
They don't exist in some character sets. The biggest one would be
EBCDIC, which does have a cents-symbol that ASCII doesn't have;
maybe we could use those, whenever they were available?

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

ken@spamnot.codeweavers.com (Ken Thomases) wrote
> One of the most common objections to suggestions for new features of C++
> is that the proposed feature requires adding a new keyword to the
> language.  The new keyword would conflict with any uses of that word in
> existing C++ code, thus breaking it.

> Since this is essentially a
> namespace conflict, and C++ has a mechanism for resolving namespace
> conflicts, why not use it?  And, since std is the namespace over which
> the standards committee has control, it seems obvious to put new
> keywords there.

How about this, instead? ALL C++ keywords (as opposed to library
entities) must from now on be preceded by a dollar-sign. To support
legacy code, compilers must also accept the non-prefixed forms of
the older keywords, but these are deprecated.

    // $for and $int are keywords
    $for ($int i=0; ; ++i) {
        // std and cout are not keywords
        std::cout << i << ' ';
        $if (i==25) $break;
    }

Now we can introduce as many new keywords as we like, secure
in the knowledge that it (the dollar-sign-prefix version, at least)
will not conflict with any existing identifiers or even macros.

    $struct myClass : $public yourClass {
        $int i, j;
        $const $char *p;
        $constructor() : i(0), j(0), p(0) {}
        $override yourfunc();

        // instead of
        //    virtual ~myClass()=0;
        // followed by out-of-line
        //    myClass::~myClass() { delete p; }
        // we have:
        $virtual $destructor $abstract { $delete p; }
    }

Mostly not kidding. This is a pretty radical change, and I doubt
it would ever be implemented... but what's wrong with it?
Anything?

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

allan_w@my-dejanews.com (Allan W) writes:

> ken@spamnot.codeweavers.com (Ken Thomases) wrote
> > One of the most common objections to suggestions for new features of C++
> > is that the proposed feature requires adding a new keyword to the
> > language.  The new keyword would conflict with any uses of that word in
> > existing C++ code, thus breaking it.
>
> > Since this is essentially a
> > namespace conflict, and C++ has a mechanism for resolving namespace
> > conflicts, why not use it?  And, since std is the namespace over which
> > the standards committee has control, it seems obvious to put new
> > keywords there.
>
> How about this, instead? ALL C++ keywords (as opposed to library
> entities) must from now on be preceded by a dollar-sign. To support
> legacy code, compilers must also accept the non-prefixed forms of
> the older keywords, but these are deprecated.
>
>     // $for and $int are keywords
>     $for ($int i=0; ; ++i) {
>         // std and cout are not keywords
>         std::cout << i << ' ';
>         $if (i==25) $break;
>     }
>
> Now we can introduce as many new keywords as we like, secure
> in the knowledge that it (the dollar-sign-prefix version, at least)
> will not conflict with any existing identifiers or even macros.
>
>     $struct myClass : $public yourClass {
>         $int i, j;
>         $const $char *p;
>         $constructor() : i(0), j(0), p(0) {}
>         $override yourfunc();
>
>         // instead of
>         //    virtual ~myClass()=0;
>         // followed by out-of-line
>         //    myClass::~myClass() { delete p; }
>         // we have:
>         $virtual $destructor $abstract { $delete p; }
>     }
>
> Mostly not kidding. This is a pretty radical change, and I doubt
> it would ever be implemented... but what's wrong with it?
> Anything?

Three things come to mind.

$ does not currently occur in the basic source character set. It may
    be (I don't know) that there are significant environments that
    don't have and can't easily fake having $. Someone might want a
    digraph for it, or some such.

In other languages (perl, sh, make, etc) $ has a very different
    meaning. Migrators might be confused. Of course they already face
    similar confusion.

There is/was a segment of the C community that depends on having
    dollar signs in identifiers. I don't see this as a big problem;
    that use wasn't important enough to make it into C89, C99, or
    C++98.

I don't see any of these, or even all 3 of them together, as show
    stoppers - but I thought they should be mentioned.

This has the advantage of being easy to specify (I think), and easy to
    implement. There is some readability cost.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly.@@xmission.dot.com (llewelly) wrote in message news:<86adibtsfm.fsf@Zorthluthik.foo>...
> allan_w@my-dejanews.com (Allan W) writes:
> [snip]
> > But that's almost as bad, because it's complicated. People don't want to
> > remember if keywords are old or new.
>
> People don't want code to break because their long-used identifier has
>     suddenly become a keyword. People don't want weird and confusing
>     characters sequences like '=0' to indicate new features.

In that case, if 'new keywords' would become keywords in a -bounded-
namespace, that namespace would denote the area for another language
(let's say, C++ instead of C, or extended C++ instead of C++).
That relation is interesting for multilanguages extensions (in
progress research), but that's not the essence of namespace, which
only applies for identifiers, not syntax.
Because, if would, it should have 'inheritance' (new namespaces would
inherit old namespaces).
In that case, they should be named 'languagespace' or 'keywordspace'
rather than 'namespace', in the same sense we embed assembly language
inside C or C++ with the asm{} construct.
Their, you do have a different language (therefore lexical rules)
embedded in C or C++.
But, suppose you have an ANSI C++ compliant with the standard of a
given year (let's say '98), and another piece for a newer one...then
you would have a puzzle of pieces of different versions all along your
program!

I prefer (and suggest) #pragmas instead of something{} (i.e.
namespace).

 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.jamesd.demon.co.uk/csc/faq.html                       ]

danielgutson@hotmail.com (danielgutson@hotmail.com) writes:

> llewelly.@@xmission.dot.com (llewelly) wrote in message news:<86adibtsfm.fsf@Zorthluthik.foo>...
> > allan_w@my-dejanews.com (Allan W) writes:
> > [snip]
> > > But that's almost as bad, because it's complicated. People don't want to
> > > remember if keywords are old or new.
> >
> > People don't want code to break because their long-used identifier has
> >     suddenly become a keyword. People don't want weird and confusing
> >     characters sequences like '=0' to indicate new features.
>
> In that case, if 'new keywords' would become keywords in a -bounded-
> namespace, that namespace would denote the area for another language
> (let's say, C++ instead of C, or extended C++ instead of C++).

I did not suggest a user would normally program inside the namespace
    containing new keywords (as opposed to a namespace new keywords
    were merely imported into using 'using', or a similar
    construct). To the contrary I suggested 'std', which implies the
    set of things a user could add to the namespace containing the new
    keywords would be very limited.

> That relation is interesting for multilanguages extensions (in
> progress research),

Something which is IMO a much bigger leap than adding a few extensions
    to C++, and quite a distortion of what I was supporting since I
    was only describing a style to be applied to features which
    appeared in the next *C++* standard - that's the C++ standard, not
    some unrelated language.

An interesting area of research, as you say, but not what I was
    discussing. A mole hill is not equivalent to a mountain.

> but that's not the essence of namespace, which
> only applies for identifiers, not syntax.
> Because, if would, it should have 'inheritance' (new namespaces would
> inherit old namespaces).
> In that case, they should be named 'languagespace' or 'keywordspace'

*shrug*. Whatever one chooses to call it, using '::' as its resolution
    operator is still consistent with the rest of C++. (However,
    languagespace, would be a wild exageration; no-one expects the
    next C++ standard to differ as much from C++98 as C++98 does from
    C - probably the core language will change less than the
    difference between ARM C++ and C++98.) (And let's please not cram
    together words that aren't already crammed together;
    keyword_space is more readable than keywordspace.)

> rather than 'namespace', in the same sense we embed assembly language
> inside C or C++ with the asm{} construct.

And here you assume adding few features to C++ is creating an entirely
    new langauge - nothing I have suggested differs from existing C++
    as much as assembler does.

> Their, you do have a different language (therefore lexical rules)
> embedded in C or C++.

It is my impression that new keywords usually only require minor
    changes to C++'s lexical conventions.

> But, suppose you have an ANSI C++ compliant with the standard of a
> given year (let's say '98), and another piece for a newer one...then
> you would have a puzzle of pieces of different versions all along your
> program!

Again, I did not suggest this - but it would be no more a puzzle than
    the existing different semantics for class definitions and
    function definitions. The pieces would clearly delineated by {}. A
    reasonable contribution to backwards compatibility. IMO much
    cleaner than #including a header for new features, as the #include
    affects the rest of the translation unit.

> I prefer (and suggest) #pragmas instead of something{} (i.e.
> namespace).
[snip]

A bounded something{} can be used within a header file without
    affecting users of that header file. A bounded something can be
    used within a segment of a file without affecting the rest of the
    file. A #pragma is either (a) unable to these things, (b) forced
    to rely on strange rules, or (c) make a nesting construct out of
    multiple #pragmas.

Furthermore - a bounded something{} is forced to respect beginings and
    endings of other {} using constructs like namespaces, classes,
    function definitions, etc. A #pragma has no obvious connection to
    these things, and, when specified as #pragmas always have been,
    will tromp all over them.

The preprocessor is (currently) totally ignorant of, and inconsistent
    with, the rest of the language. It has been repeatedly shown that
    this ignorance and inconsistency make preprocessor use
    error-prone. Adding more error-prone features to C++ is *not* a
    good thing.

Finally - C++ already uses {} to denote bounded regions with very
    different semantics; those constructs legal within a function's {}
    bounds are different from (but overlapping) those within a class's
    {} bounds. In some sense, class definition requires a different
    language than a function definition. C++ can be seen as containing
    both these languages, using {} to define their bounds, and to
    allowing them to nest inside each other.

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

    I have mixed feelings about this idea, but it sure beats
adding various numbers of underscores on the front and back of
symbols.

    (Today's headache: finding the place where, in a purchased
commercial library,  somebody wrote "_cplusplus" instead
of "__cplusplus".)

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
>     (Today's headache: finding the place where, in a purchased
> commercial library,  somebody wrote "_cplusplus" instead
> of "__cplusplus".)
>

Finding it is simple. Figuring out that you need to look for it is the
hard part.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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                       ]

danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
[snip]
> Ok, let's make it short.
[snip]

Ok.

Putting keywords in a namespace is *not* equivalent to new
    language areas.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly.@@xmission.dot.com (llewelly) wrote in message news:<86r8b7lpbr.fsf@Zorthluthik.foo>...
> danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
>
> > llewelly.@@xmission.dot.com (llewelly) wrote in message news:<86adibtsfm.fsf@Zorthluthik.foo>...
> > > allan_w@my-dejanews.com (Allan W) writes:
> > > [snip]
> > > > But that's almost as bad, because it's complicated. People don't want to
> > > > remember if keywords are old or new.
> > >
> > > People don't want code to break because their long-used identifier has
> > >     suddenly become a keyword. People don't want weird and confusing
> > >     characters sequences like '=0' to indicate new features.
> >
> > In that case, if 'new keywords' would become keywords in a -bounded-
> > namespace, that namespace would denote the area for another language
> > (let's say, C++ instead of C, or extended C++ instead of C++).
>

Ok, let's make it short.
Let's call W the set of all English words.
Let's call Li the subset of W which contains the reserved keywords in
a given version i.
Let's assume that Li+1 contains Li, so Li < Li+1.

Now, you would have a something_i {} for each i.

suppose you have a program:

something0
{
};

something1
{
};

Then:
 - which are the possible relations between different something_i ?
(can they be nested? or just sequential?)
 - can something_i share datatypes with other something_j, i <> j?
 - can something_i invoke functions of something_j?
 - or should they be *exported* with strings in the 'extern' keyword?
 - what about linking? Code generation is not needed to have the same
format among different something_i blocks, and more probably would get
impact in the linker files...

Remember that those something_i will no have 'syntactic' differences
only, but also semantic differences.

I mentioned the #pragma because it would act at the file level, which
is easier to handle bytecode generation than an heterogeneous file.

Your argument that operator {} denotes different semantic areas (such
as declarational or imperative) is not strong enough as far as this is
a basic 'double faced' imperative language attribute: you have
declarations or imperative areas, and of course you must differentiate
them somehow.
But your argument leads to a tree of possibilities of areas:
+areas
  +-declarative
  |     +version_i
  |     |  ...
  |     +version_j
  |
  +-imperative
        +version_i
        |  ...
        +version_j

and then the problem becomes combinatorial when you must mix them:
declarations of version_i used in statements in version_j, and so on.

I think that this would blow the already delicate mental health of the
programmers. Companies have money to migrate programs to a stronger
version of languages. Otherwise, they will keep on using old compiler
versions.

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.jamesd.demon.co.uk/csc/faq.html                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0301141508.7bae1145@posting.google.com>...
[snip]
> One C++ compiler -- I think it was Borland, back in the 16-bit days --
> actually used to use something like this on Microsoft Windows. As you
> might know, Microsoft Windows forces each on-screen element (such as
> a Window) to have a "window proc." Whenever anything interesting
> happens, the window proc gets a message -- the window ID, a message
> number, and 2 parameters whose type depends on the message number.
> Standard programming technique has the window proc look up the
> in-memory object, then call the correct virtual function depending on
> the message number. (Virtual, so that you could derive from Window and
> add your own customization.) Borland saw the obvious similarities
> between message dispatch and virtual function dispatch, and tried to
> combine the two. So, if the message number was 1, they would call the
> first function in the virtual table, and so on.
>
> If I remember correctly, the correct syntax for specifying the
> virtual function number was exactly what you suggest:
>     virtual long WmInit() = WM_INIT; // Handle WM_INIT messages
>
> Anyone know if Borland still does that? I'm guessing it wouldn't
> translate very well to the 32-bit world, with 4 billion possible
> legal message numbers.
>
This syntax is not used any more.

The VCL (and new CLX) library completely hides the messages dispatch
algorithm from the user - your functions are automagically called when
message is received.

/Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly.@@xmission.dot.com (llewelly) wrote in message news:<86adibtsfm.fsf@Zorthluthik.foo>...
[snip]
> However - I believe namespaced keywords are easier to understand
> than tricks of syntax that avoid the introduction of new keywords
> entirely. I believe they will not break conforming code ...
[snip]

I agree with your points.

There may be one non-technical problem with namespaced keywords:
suddenly it would become _much_ easier to add new keywords to C++.
Pressure to Standardization Comittee and compiler implementors would
grow up and C++ may get fragmented.

/Pavel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly.@@xmission.dot.com (llewelly) wrote
> allan_w@my-dejanews.com (Allan W) writes:
> [snip]
> > But that's almost as bad, because it's complicated. People don't want to
> > remember if keywords are old or new.
>
> People don't want code to break because their long-used identifier has
>     suddenly become a keyword.

True. I suspect that the problem wouldn't be 1/10th as bad as people
seem to worry about, but it *is* a real problem.

> People don't want weird and confusing
>     characters sequences like '=0' to indicate new features.

Also true. If you can't quickly understand what it means, it's going
to be difficult to teach, to use, etc.

> It's often impossible to introduce a new feature and satisify all
>     three of those wants. A compromise is necessary.

Agreed.

> Namespacing
>     keywords is such a compromise. It does complicate parsing. It does
>     complicate explaining certain parts of the languages. *However* -
>     it enables new features to use comprehensible words for their
>     syntaxes, instead of line garbage.

I understand that, and I even agree. There's something about this
particular solution, though, that strikes a wrong chord with me.
It makes me want to add statements like:
    typedef std::pure pure; // Use "pure" without the namespace
But this isn't true; std::pure is NOT a type, so I shouldn't be able
to typedef it.

Also, by putting a keyword in a NAMED namespace (specifically "std"),
it seems obvious that I can create my own keywords in my own namespace.

    namespace Espanol {
        typedef std::auto   automovil; // auto in Spanish
        typedef std::for    para;      // for
        typedef std::if     si;        // if
        typedef std::static estatico;  // static
    }
    void foo() {
        Espanol::para(int i=0; i<10; ++i)
            Espanol::si(EstaPrimero(i)) std::cout << "i\n";
        std::cout << '\n';
    }

> Your argument seems to be that bare keywords are easier to understand
>     than namespaced keywords. I agree.

That's part of it. My biggest objection is the imbalance between the
"old" syntax for existing keywords (which surely you would not
propose changing!) and the "new" syntax for the new ones. At the
very least, I would want to be able to prepend std:: to existing
keywords.
    std::int * x = std::new std::int(10);

I was only half facetious about prepending std:: to non-text keywords
such as the operators. (Okay, so you're only proposing we use std::
for text keywords, that's not so bad.)

> However - I believe namespaced
>     keywords are easier to understand than tricks of syntax that avoid
>     the introduction of new keywords entirely. I believe they will not
>     break conforming code (so far as I interpret the standard
>     correctly) - something bare keywords risk.

Perhaps. Honestly, I'm running out of rational reasons. Maybe I would
get used to it, but something about it I don't like.

> I believe they are
>     cleaner than C99's _Bool, #include<bool.h>, #define bool _Bool,
>     etc.

(probably "typedef _Bool bool" instead of the #define, right?)

I like this a lot for C, and in a similar situation I think that C++
could use something similar. Really, the only drawback to this technique
is that it's not extensible. Suppose auto, float, and const didn't already
exist in the C language and they were going to add them now. Would there
be 4 different header files? Or would there be 1 header file, called
"C99.h" which works for all of them?

At first blush, the technique doesn't even seem to work for non-type
keywords such as auto or const. But in fact it certainly could work.
The keywords could have been _Auto and _Const. The C standard doesn't
have to dictate what would have been in "auto.h" -- all it has to say
is that once you've included it, you can use the "auto" keyword. So it
could be
    #define auto _Auto
or it could be
    #pragma auto(on)
or whatever.

> Namespaced keywords are not perfect. They are a compromise between
>     those who want new features to be readable, and those who fear new
>     keywords will break their code. If you say that the best solution
>     is to simply introduce a new (unadorned) keyword, then I'd be
>     tempted to agree. (I've twice worked on a project which was moved
>     from C to C++, and I did not find C++'s long list of additional
>     keywords to be a big problem.) However there are many who are
>     downright hostile to new keywords, and I'm not willing to pretend
>     their fears are unreasonable. 15 years ago, when there was far
>     less C++ code than there is now, Bjarne Stroustrup introduced
>     pure virtual functions (and thus ABCs) without a new keyword,
>     principly because he feared breaking code, and hostility to new
>     keywords.
>
> > Imagine just for a moment that both
>
> Imagine just for a moment that pure virtual functions are added to
>     C++, in a cool form that required no new keywords. Now explain
>     that.

I really did get your point. It's just that the prefix doesn't look
much better to me.

(FWIW, if Stroustrup had asked me for advice, I would have suggested
some other syntax. Maybe I would have used "pure" with virtual:
    pure virtual void foo() const;
Or maybe not... who knows?)

> And don't forget to answer the guy in the back who asks 'So,
>     what does 'virtual void foo() = 2' mean?

One C++ compiler -- I think it was Borland, back in the 16-bit days --
actually used to use something like this on Microsoft Windows. As you
might know, Microsoft Windows forces each on-screen element (such as
a Window) to have a "window proc." Whenever anything interesting
happens, the window proc gets a message -- the window ID, a message
number, and 2 parameters whose type depends on the message number.
Standard programming technique has the window proc look up the
in-memory object, then call the correct virtual function depending on
the message number. (Virtual, so that you could derive from Window and
add your own customization.) Borland saw the obvious similarities
between message dispatch and virtual function dispatch, and tried to
combine the two. So, if the message number was 1, they would call the
first function in the virtual table, and so on.

If I remember correctly, the correct syntax for specifying the
virtual function number was exactly what you suggest:
    virtual long WmInit() = WM_INIT; // Handle WM_INIT messages

Anyone know if Borland still does that? I'm guessing it wouldn't
translate very well to the 32-bit world, with 4 billion possible
legal message numbers.

> > How does that lecture go?
> >
> >     list of all the C++ keywords.
>
> And here is where the lecture goes wrong. C++ (already) has several
>     different categories of names. The category of the name determines
>     whether it needs namespace qualification. Your example lecture
>     never mentions that keywords, macros, and standard library
>     identifiers are three different kinds of names. Your example
>     lecture is a disaster with or without namespaced keywords.

Yes, you're right -- I was going for humor here.
I still think this problem would get worse if keywords had a namespace.

> The last half of your example is entirely about confusions which
>     already exist. (I must say I appreciate the humorous ending,
>     however.)

Glad you appreciate it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> v.Abazarov@attAbi.com ("Victor Bazarov") writes:
> > Keywords cannot be namespace-specific.

llewelly.@@xmission.dot.com (llewelly) wrote
> Why do you say this? (I know reserved keywords are not
>     namespace-specific in the current standard, but I know of no reason
>     they could not be made namespace-specific in a future standard.)

The word "namespace" has several meanings. Dictionary.com says it means
"A set of names in which all names are unique." The first time I saw it
was in a discussion of how structures, types, labels and (IIRC) functions
could all share a name in C:

    typedef struct { int bar; } foo;
    struct foo { float bar; };
    int foo(foo*f) { // Takes the struct with an int, not a float!
      if (f->bar>0) goto foo;
    foo:
    }

This works because the context of each name gives it a different
namespace.

Another meaning of the namespace is a convention. Identifiers that
start with an underscore and capital letter, or that start with
two underscores, are reserved for the implementation. If you sold
any sort of library before about 1997, you probably prefixed all of
your class names and free functions with a name. For instance, all
of the Rogue Wave classes and function names start with RW:
    rwstring
    rwarray
    rwdate
and so on. You could be reasonably (but not 100%) sure that if some
other third-party package had a date type, it wouldn't be called
rwdate.

The formal namespaces introduced into C++ was a major step forward.
For the first time (that at least I know about), namespaces could have
names of their own. "std" is the most obvious.

But note that the new type of namespaces apply to user-defined
identifiers: classes such as string, objects such as nothrow,
free functions such as strcpy. Keywords such as "auto" and "operator"
have been reserved in ALL namespaces. You're simply not supposed to
be able to name a variable "sizeof" no matter how clever you are with
namespaces.

One ramification of this is a freedom given to compilers. After the
initial tokenization, the keyword "&&" can be treated identically to
the keyword "and". I am not sure if compilers commonly use this freedom
or not.

However, tokenization is an example of some of the complexities involved
in this ostensibly-simple suggestion. Are the three tokens "std :: auto"
to be considered equivalent to the single token "auto"?

What happens if someone tries to qualify the namespace for the token "::" ?
I can see someone typing "std::::". Put that in context and you get
std::std::::auto. Do the same for "std" and you get std::std std:::: auto.
Recurse, and you get std::std std:::: std::std std::std std:::: std:::: auto.
Yes, I'm getting absurd here. Yes, the premise is wrong -- you wouldn't
explicitly give the namespace for non-letter tokens such as ::. In
fact, you probably wouldn't give explicit namespace for any of the old
tokens, just the new proposed ones such as pure and overrides.

But that's almost as bad, because it's complicated. People don't want to
remember if keywords are old or new. Imagine just for a moment that both
of these new keywords make it into the language, subject to the provision
that we always qualify them with std::. A year or two goes by, and now
we're trying to teach C++ to people that have never used it before.
You're in charge of the lecture entitled "when to use the std::prefix and
when not to." How does that lecture go?

    Always use std:: in front of names that come from the standard
    library... unless you've used the "using" directive, in which case
    you don't have to (but you still could if you wanted to). Never
    use std:: in front of the using directive itself. Always use it
    for keyword pure or overrides, but never for virtual or auto.
    Hmmm... this is getting complicated... maybe I better just make a
    list of all the C++ keywords. To start, here are the A's:
        asm -- never
        auto -- never
    There, now that wasn't so bad! Yes, a question from the back...
    and? Sorry, I forgot that one because it's in Table 4, not Table 3.
    You never use std:: with and. Any other questions? Yes, you there...
    \a? From Table 5. I see. Well, you'd never use std:: with \a, either.
    assert? No, you never use std:: with assert. Why it isn't on the
    list? Well, because assert is a macro, not a keyword. What? Well
    that means you can never use it in any namespace anyway. Besides,
    you can't use it at all unless you #include <cassert> or
    <assert.h>. What? Well, an #include brings in library declarations
    so that you can use them. Like if you #include <cstdio> then you
    can use std::printf(), which is the library code that... well,
    you always have to use std:: in front of a library name unless
    you've got a using directive. No, that's a using declaration, I'm
    talking about a using directive like this:
        using namespace std;
    which means you don't have to put std:: in front of names like
    printf anymore. No, that doesn't apply to assert because assert is
    a macro, not a function. Yes it does apply to printf, but only if
    you've #included <stdio.h>, no wait I mean <cstdio> which is the
    same thing except for the ... STOP IT! STOP IT!
    Look, maybe the rule should be, always use std:: in front of every
    bloody name in your whole program, unless you get an error message,
    then try taking it out, but if you get a different error then try
    putting it back and look for some other error in your code, and if
    you still can't find it, go ask teacher for help, but some other
    teacher because I QUIT! ARRGH!
    YES! I DO INDEED MEAN std::ARRGH! SO THERE!!! MWA HA HA HA HA HA!

...like I said, it's too complicated. (And we didn't even get to the B's!)

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

allan_w@my-dejanews.com (Allan W) writes:
[snip]
> But that's almost as bad, because it's complicated. People don't want to
> remember if keywords are old or new.

People don't want code to break because their long-used identifier has
    suddenly become a keyword. People don't want weird and confusing
    characters sequences like '=0' to indicate new features.

It's often impossible to introduce a new feature and satisify all
    three of those wants. A compromise is necessary. Namespacing
    keywords is such a compromise. It does complicate parsing. It does
    complicate explaining certain parts of the languages. *However* -
    it enables new features to use comprehensible words for their
    syntaxes, instead of line garbage. It enables new features to use
    comprehensible words without breaking code that uses those words
    as identifiers. It avoids the introduction syntaxes like
    'operator++(int)', which are harder to read and explain than
    namespaced keywords.

Your argument seems to be that bare keywords are easier to understand
    than namespaced keywords. I agree. However - I believe namespaced
    keywords are easier to understand than tricks of syntax that avoid
    the introduction of new keywords entirely. I believe they will not
    break conforming code (so far as I interpret the standard
    correctly) - something bare keywords risk. I believe they are
    cleaner than C99's _Bool, #include<bool.h>, #define bool _Bool,
    etc.

Namespaced keywords are not perfect. They are a compromise between
    those who want new features to be readable, and those who fear new
    keywords will break their code. If you say that the best solution
    is to simply introduce a new (unadorned) keyword, then I'd be
    tempted to agree. (I've twice worked on a project which was moved
    from C to C++, and I did not find C++'s long list of additional
    keywords to be a big problem.) However there are many who are
    downright hostile to new keywords, and I'm not willing to pretend
    their fears are unreasonable. 15 years ago, when there was far
    less C++ code than there is now, Bjarne Stroustrup introduced
    pure virtual functions (and thus ABCs) without a new keyword,
    principly because he feared breaking code, and hostility to new
    keywords.

> Imagine just for a moment that both

Imagine just for a moment that pure virtual functions are added to
    C++, in a cool form that required no new keywords. Now explain
    that. And don't forget to answer the guy in the back who asks 'So,
    what does 'virtual void foo() = 2' mean?

> of these new keywords make it into the language, subject to the provision
> that we always qualify them with std::. A year or two goes by, and now
> we're trying to teach C++ to people that have never used it before.
> You're in charge of the lecture entitled "when to use the std::prefix and
> when not to." How does that lecture go?
>
>     Always use std:: in front of names that come from the standard
>     library... unless you've used the "using" directive, in which case
>     you don't have to (but you still could if you wanted to). Never
>     use std:: in front of the using directive itself. Always use it
>     for keyword pure or overrides, but never for virtual or auto.
>     Hmmm... this is getting complicated... maybe I better just make a
>     list of all the C++ keywords.

And here is where the lecture goes wrong. C++ (already) has several
    different categories of names. The category of the name determines
    whether it needs namespace qualification. Your example lecture
    never mentions that keywords, macros, and standard library
    identifiers are three different kinds of names. Your example
    lecture is a disaster with or without namespaced keywords. (Yes, I
    realize that real people who are paid to 'teach' C++ 'teach' this
    way. However I believe existing weird syntaxes cause these people
    more problems than namespaced keywords would - try having one of
    them explain what 'pair<T,U> my_pair(T(),U());' does. This problem
    could have been avoided by an appropriate keyword.)

>     To start, here are the A's:
>         asm -- never
>         auto -- never
>     There, now that wasn't so bad! Yes, a question from the back...
>     and? Sorry, I forgot that one because it's in Table 4, not Table 3.
>     You never use std:: with and. Any other questions? Yes, you there...
>     \a? From Table 5. I see. Well, you'd never use std:: with \a, either.
>     assert? No, you never use std:: with assert. Why it isn't on the
>     list? Well, because assert is a macro, not a keyword. What? Well
>     that means you can never use it in any namespace anyway.

We already have *that* problem. We already have a standard library
    that has some names in std, and others outside of std. I doubt
    Namespaced would appreciably exaberate it.

>     Besides,
>     you can't use it at all unless you #include <cassert> or
>     <assert.h>. What? Well, an #include brings in library declarations
>     so that you can use them. Like if you #include <cstdio> then you
>     can use std::printf(), which is the library code that... well,
>     you always have to use std:: in front of a library name unless
>     you've got a using directive. No, that's a using declaration, I'm
>     talking about a using directive like this:
>         using namespace std;
>     which means you don't have to put std:: in front of names like
>     printf anymore. No, that doesn't apply to assert because assert is
>     a macro, not a function. Yes it does apply to printf, but only if
>     you've #included <stdio.h>, no wait I mean <cstdio> which is the
>     same thing except for the ... STOP IT! STOP IT!
>     Look, maybe the rule should be, always use std:: in front of every
>     bloody name in your whole program, unless you get an error message,
>     then try taking it out, but if you get a different error then try
>     putting it back and look for some other error in your code, and if
>     you still can't find it, go ask teacher for help, but some other
>     teacher because I QUIT! ARRGH!
>     YES! I DO INDEED MEAN std::ARRGH! SO THERE!!! MWA HA HA HA HA
>     HA!

The last half of your example is entirely about confusions which
    already exist. (I must say I appreciate the humorous ending,
    however.)

> ...like I said, it's too complicated. (And we didn't even get to the B's!)
[snip]

*laugh*. If you think that's complicated, pick five different uses of
    static and explain those. Or explain the difference between a
    local function declaration and a local object definition.

All useful C++ lectures require careful preparedness, and your example
    lecture is no different. The key here is to prepare list of the
    kinds of names, some example names from each category, (complete
    lists for the small categories), and to prepare an explanation of
    how the kinds of names differ.








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

musiphil@bawi.org (KIM Seungbeom) writes:

> llewelly wrote:
> >
> > v.Abazarov@attAbi.com ("Victor Bazarov") writes:
> > > Keywords cannot be namespace-specific.
> >
> > Why do you say this? (I know reserved keywords are not
> >     namespace-specific in the current standard, but I know of no reason
> >     they could not be made namespace-specific in a future standard.)
>
> I'm not Victor Bazarov, but adopting namespace-specific keywords
> would require too radical changes to the lexical analysis.
>
> >From the perspective of compilers, the source code is first
> scanned for lexical analysis and then its result is used for
> syntatic analysis. Namespace-specific keywords would require
> the lexical analysis be dependent upon the syntatic analysis.
>
> Parser: Okay, what's the next token?
> Lexer:  I got "pure", but I'm not sure whether
>         it's a KEYWORD or an IDENTIFIER.
> Parser: Oh, then how could I parse the source code?

I believe this can be handled akin to the way typedefs are. (That is,
    with difficulty ...:-)
[snip]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:
>
> v.Abazarov@attAbi.com ("Victor Bazarov") writes:
> > Keywords cannot be namespace-specific.
>
> Why do you say this? (I know reserved keywords are not
>     namespace-specific in the current standard, but I know of no reason
>     they could not be made namespace-specific in a future standard.)

I'm not Victor Bazarov, but adopting namespace-specific keywords
would require too radical changes to the lexical analysis.

>From the perspective of compilers, the source code is first
scanned for lexical analysis and then its result is used for
syntatic analysis. Namespace-specific keywords would require
the lexical analysis be dependent upon the syntatic analysis.

Parser: Okay, what's the next token?
Lexer:  I got "pure", but I'm not sure whether
        it's a KEYWORD or an IDENTIFIER.
Parser: Oh, then how could I parse the source code?

So far as I know. Let me know if it is not a big deal.

--
KIM Seungbeom <musiphil@bawi.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                       ]

v.Abazarov@attAbi.com ("Victor Bazarov") writes:

[snip]
> Keywords cannot be namespace-specific.

Why do you say this? (I know reserved keywords are not
    namespace-specific in the current standard, but I know of no reason
    they could not be made namespace-specific in a future standard.)


[snip]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

One of the most common objections to suggestions for new features of C++
is that the proposed feature requires adding a new keyword to the
language.  The new keyword would conflict with any uses of that word in
existing C++ code, thus breaking it.  Since this is essentially a
namespace conflict, and C++ has a mechanism for resolving namespace
conflicts, why not use it?  And, since std is the namespace over which
the standards committee has control, it seems obvious to put new
keywords there.

I'm sure I'm not the first to think of such a thing.

In another thread ("Feature-Wish for next C++"), Francis Glassborow wrote:
http://groups.google.com/groups?selm=ZSkTQrFcLnb9EwHG%40robinton.demon.co.uk
 > My wish is that we had had the foresight to build in a feature of
 > keyword substitution coupled with a keyword namespace. So that we
 > could have:
 >   keywords {
 >    pure;
 >
 > // etc.
 > }
 >
 > int foo()keyword::pure;
 >
 > but also have
 >
 > using keyword::pure;
 > int bar()pure;
 >
 > ON second thoughts that might have just have made it too easy to add
 > keywords:-)

Similarly, I also saw that llewelly wrote (in thread "C# style
"override" keyword"):
http://groups.google.com/groups?selm=86k7i010hz.fsf%40Zorthluthik.foo
>     void function1( int x ) std::overrides void BaseFromLibrary::function1(int x);
>
> And it would not conflict with any existing conforming program's use
>     of 'overrides' as an identifier.

which implicitly assumes that keywords can be scoped within namespaces.

This leads me to think that this idea has been relatively widely
discussed elsewhere (in threads I don't happen to read), but I couldn't
find such discussion via Google.  In any case, it can't hurt to create a
thread specifically for it.

So, what do people think?

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

"Ken Thomases" <ken@spamnot.codeweavers.com> wrote...
> One of the most common objections to suggestions for new features of C++
> is that the proposed feature requires adding a new keyword to the
> language.  The new keyword would conflict with any uses of that word in
> existing C++ code, thus breaking it.  Since this is essentially a
> namespace conflict, and C++ has a mechanism for resolving namespace
> conflicts, why not use it?  And, since std is the namespace over which
> the standards committee has control, it seems obvious to put new
> keywords there.

Yechhh...

Keywords cannot be namespace-specific.  A better solution would
be to make them begin with _X where X is a capital letter (like
C99 declares _Bool, _Complex, and _Imaginary).  Such keyword[s]
cannot conflict with any _user_ identifier because names that
begin with an underscore and a capital letter are reserved.

Victor
--
Please remove capital A's from my address when replying by mail


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