> Consider your proposal, making
>     class C { ... } C;
> equivalent to
>     class C { ... }; // C
>
> Benefit: You don't have to type "//"
> Cost: Breaks every currently-valid program that creates an object or
> typedef with the same name as a class tag.

   You're absolutely right, but my intention was rather to focus on the
problem than trying to solve it in the best possible way (I simply don't
know the C++ standard that much). That was a bad example, but still only
an example - maybe someone could think of a better solution?
   Maybe it could be reusing of keyword for, like:

class c {
  //...
} for c;

   As to the benefits, it's not only saving two '/' hits on a keyboard.
It' also making a compiler help you. If a compiler can check if the code
is what you expected it to be, then why not? Consider someone has used
the style with adding "//MyClass" and during development of the code he
changed name of MyClass to TheClass, but forgot to change the comment.
Seems harmless, but it happened to me few times and made me spend some
time trying to find out "what's wrong with the code?" after such change.
You may ask: "then why sould you add the comment at all"? The answer is
it really helps a lot and clarifies the code - anyone who has used this
style know what I'm talking about... ;-)

Thanx & greetz,
Robert Kawulak

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

tigrisek@interia.pl (Robert Kawulak) wrote in message news:<40C5BE9E.4010000@interia.pl>...
> void MyMessage()
> {
>
>    Hi!
>
>    Does anybody know if the standarisation committee has already started
> working on the next version of C++? If yes, then when will we see the
> new standard, and if no, then when will they start?

Yes, it has started. Google on C++0x.

>    And another thing - I'd like one small change to be introduced in
> C++. Many programmers (including me ;-) add a name of a function or
> class definition in comment after it's body's closing bracket:
>
>    void f()
>    {
>      //body here
>    } //f()
>
>    class c {
>      //member declarations here
>    }; //class c
>
>    namespace n {
>      //declarations
>    } //namespace n

Bad idea, IMO. Aside from the syntactical issues that were mentioned
before, it tries to solve a too small problem. If this information was
really useful, I would prefer it to be supplied automatically by the IDE.
I imagine an IDE which would have a tooltip when you hover over a },
showing the kind of block - i.e. [namespace n {] when you hover over the
last } in your example. Or [if( cond ) {...} else { ].

Regards,
Michiel Salters.

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

Robert Kawulak wrote:

>
>   Does anybody know if the standarisation committee has already started
> working on the next version of C++?

Work has recently started.

> If yes, then when will we see the new standard,

It's years away. Apart from discussion of individual features, we are
still collecting ideas about the "shape" of a new standard. For example:

- How much of existing standard-conforming code should work unchanged
when compiled by a compiler that conforms exactly to the new standard?
How can we accomodate code written to the 1998/2003 standard?

- How ambitious should the new standard be? Major new features or only
minor tweaks? What about library additions?

- What currently unspecified or ignored real-world features should the
standard address? (Examples: multi-threaded code, shared libraries,
details of arithmetic types.)

Regarding new features, see D&E ("Design and Evolution of C++") for a
discussion of the kinds of things to think about when proposing a new
language feature. A cost/benefit analysis is critical to any proposal.

Consider your proposal, making
     class C { ... } C;
equivalent to
     class C { ... }; // C

Benefit: You don't have to type "//"
Cost: Breaks every currently-valid program that creates an object or
typedef with the same name as a class tag.

Doesn't sound like a winner to me. :-)

---
Steve Clamage, stephen.clamage@sun.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                       ]

void MyMessage()
{

   Hi!

   Does anybody know if the standarisation committee has already started
working on the next version of C++? If yes, then when will we see the
new standard, and if no, then when will they start?

   And another thing - I'd like one small change to be introduced in
C++. Many programmers (including me ;-) add a name of a function or
class definition in comment after it's body's closing bracket:

   void f()
   {
     //body here
   } //f()

   class c {
     //member declarations here
   }; //class c

   namespace n {
     //declarations
   } //namespace n

   If we could write the names explicitly (not in comments), the
compiler could check them for us and warn if they do not match the
corresponding bracket (or even consider it as an error). The code might
look something like this:

   void f()
   {
     //body here
   } f; //semicolon for clarity

   //class definition with definitions of objects
   class c {
     //member declarations here
   } c obj1, obj2;

   namespace n {
     //declarations
   } n;

   The idea isn't new, e.g. in Ada such "confirmations" are obligatory.
The new feature would be harmless to existing code, and nobody would be
forced to use it. However, it's very useful, because it clarifies the
source code (especially when there are long bodies and looking at the
closing bracket you don't know what it concerns) and may also help to
find "stupid" mistypings. What do you think about it?

   Greets,
   RK

} MyMessage;

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

Robert Kawulak wrote:
>   And another thing - I'd like one small change to be introduced in C++.
> Many programmers (including me ;-) add a name of a function or class
> definition in comment after it's body's closing bracket:
>
>   void f()
>   {
>     //body here
>   } //f()
>
>   class c {
>     //member declarations here
>   }; //class c
>
>   namespace n {
>     //declarations
>   } //namespace n
>
>   If we could write the names explicitly (not in comments), the compiler
> could check them for us and warn if they do not match the corresponding
> bracket (or even consider it as an error). The code might look something
> like this:
>
>   void f()
>   {
>     //body here
>   } f; //semicolon for clarity
>
>   //class definition with definitions of objects
>   class c {
>     //member declarations here
>   } c obj1, obj2;
>
>   namespace n {
>     //declarations
>   } n;
>
>   The idea isn't new, e.g. in Ada such "confirmations" are obligatory.
> The new feature would be harmless to existing code, and nobody would be
> forced to use it. However, it's very useful, because it clarifies the
> source code (especially when there are long bodies and looking at the
> closing bracket you don't know what it concerns) and may also help to
> find "stupid" mistypings. What do you think about it?

It conflicts too much with existing syntax, and would not be harmless to
existing code.
 class c { } c;
is already legal and has a well-defined meaning.  Your proposal would
change the meaning of the code.  This example may be contrived, but
consider the (unfortunately common) idiom of
 typedef struct foo { /* members */ } foo;
I also think your proposed syntax for
 class c { } c obj1, obje2;
makes an already confusing declaration even more difficult to parse.

You could avoid these class issues by saying that the identifier after
the closing brace is legal only for namespaces and functions, but that
removes a lot of the usefulness of the feature, and, in my opinion,
makes it not worth the effort.

--
David Olsen
qg4h9ykc5m@yahoo.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                       ]