Allan W wrote:

[...]

> By the way, I like the new begin_xxx and end_xxx keywords much better
> than the ones you first proposed: begin and end. Those names already
> have meaning in the standard library.

Having worked in two languages that name their end constructs (Fortran
and VB), I'd prefer to have an end without necessarily a corresponding
begin.  I'm not sure how (or if) it could coexist with the language as
it currently exists, but it's much cleaner than having extraneous
"begin"s scattered all over the place.

---
[ 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 dont understand what is wrong with the current { }.. set your editor to a
font and size that makes it distinguishable from ( ), and indent your code
nicely, and it is very obvious when a } has been missed.

Chris
"Craig Powers" <enigma@hal-pc.org> wrote in message
news:3D8F918A.C32EFC24@hal-pc.org...
> Allan W wrote:
>
> [...]
>
> > By the way, I like the new begin_xxx and end_xxx keywords much better
> > than the ones you first proposed: begin and end. Those names already
> > have meaning in the standard library.
>
> Having worked in two languages that name their end constructs (Fortran
> and VB), I'd prefer to have an end without necessarily a corresponding
> begin.  I'm not sure how (or if) it could coexist with the language as
> it currently exists, but it's much cleaner than having extraneous
> "begin"s scattered all over the place.
>
> ---
> [ 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                       ]
>
>

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

On Thu, 19 Sep 2002 17:39:01 +0000 (UTC)
david.abrahams@rcn.com ("David Abrahams") wrote:

>
> ""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
> news:3E9i9.357007$_91.457828@rwcrnsc51.ops.asp.att.net...
> > "Steve Richter" <srichter@autocoder.com> wrote...
>
> > > This business of making sure your open braces
> > > have a corresponding closing brace
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > gets tedious some times.
>
>
> > > [...]
> > > Could the good standards committee people provide an optional
> > > literal alternative to the brace?
> >
> >
> > Trigraph sequences should be available.  { => ??<    } => ??>
> > So, you don't really need any special literal...
>
> You people aren't reading the OP's question. He wants to program in
> Python: www.python.org

My Cmm programme can let you write C++ code without braces. It uses the
indentation to figure out where braces should go, allowing a python-like
code style such as:

    class Foo
        int x;
    ;

    namespace
        void InternalFn()
            return;

    int main()
        std::cout << "Hello world\n";
        for ( int x=0; x<10; ++x)
            std::cout << x << "\n";
        return 0;

E.g.
 cmm -autoblocks -c <infile> <outfile> ""
- will convert <infile> to C++ and output to <outfile>.

See http://www.op59.net/cmm/readme.html .

- Julian

--
http://www.op59.net

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

srichter@autocoder.com (Steve Richter) wrote
> > > If you are visually challenged like I am and mistake a ) for a }

> allan_w@my-dejanews.com (Allan W) wrote
> > That happens to everyone. Larger fonts help, but then you have less code
> > on the screen -- like everything else, it's a trade-off.

> what is the trade off when a begin_class, begin_namespace, end_method,
> ... is allowed as an alternative to { and }?  esp when a pragma:
>
> pragma sensible_literal_alternative_to_the_squigle_enabled
>
> can be used to prevent any name clash problems.

The name "#pragma" is specified in the standard, but neither the syntax
nor the semantics of anything following it; in other words, it's
specifically designed to allow compilers to do this right now.

However, the tradeoff I was referring to was a non-language
issue: if you use smaller fonts, you can see more context for the
code, but larger fonts make it easier to distinguish between {}
and ().

By the way, I like the new begin_xxx and end_xxx keywords much better
than the ones you first proposed: begin and end. Those names already
have meaning in the standard library.

> The literal squigle will prevent the error dump. When the compiler
> sees "end_class", then any open member functions are missing an end.
>
> This is the "value add" to what I am proposing.

When I first read your proposal, I thought you were arguing for a
compile-time alternative to { and }, and the alternative would have
been valid anywhere. The idea of matching begin_xxx with end_xxx
is much more intriguing.

begin_namespace would have to match end_namespace, and begin_block
would have to match end_block, and so on, right? Yes, I can see how
that would reduce the number of errors -- as a variation on what you
point out, if you get to end_class or end_function while there are
still open blocks, it means you missed an end_block. I like the
concept.

I wonder, though, how the two constructs should interact. (Obviously
you can't expect people to stop using { } overnight!). What would
happen with code like this:

    namespace myspace begin_namespace
        class myclass {
            void foo(int x) begin_function
                if (x>5) {
                    std::cout << "x>5" << std::endl;
                end_block // Does end_block match { instead of begin_block?
            } // Used } instead of end_function -- valid?
        end_class // And so on...
    } // and so on?

In other words, would a given construct be allowed to mix keywords
with "squiggles," or would you have to choose one or the 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                       ]

allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0209212349.507cece@posting.google.com>...
>
> I wonder, though, how the two constructs should interact. (Obviously
> you can't expect people to stop using { } overnight!). What would
> happen with code like this:
>
>     namespace myspace begin_namespace
>         class myclass {
>             void foo(int x) begin_function
>                 if (x>5) {
>                     std::cout << "x>5" << std::endl;
>                 end_block // Does end_block match { instead of begin_block?
>             } // Used } instead of end_function -- valid?
>         end_class // And so on...
>     } // and so on?
>
> In other words, would a given construct be allowed to mix keywords
> with "squiggles," or would you have to choose one or the other?
>

I would vote that if it is not ambiguous to the compiler, the symbolic
and literal brace can be mixed. I would propose the following scoping
indicators:

begin_scope  // generic begin of scope.  same as "{".
begin_namespace
begin_class
begin_function
begin_try
begin_catch
begin_block
begin_if
begin_for, begin_while.  or maybe just begin_loop

the begin_if would not look very nice, but its corresponding end_if
would be an ugly, yet still error catching value add.
  if ( a == b )
   {
   foo( 123 ) ;
   end_if

Not sure if a ; should be allowed, required after the literal end
brace.

Symbolic names associated with the scoping directives add more error
catching plus a coding enhancement ...  break and continue from a
named scope.
  for( ; ; )
     begin_for outer_loop
     foo( 1 ) ;
     foo( 2 ) ;
     for( ; ; )
       begin_for inner_loop
       foo( 3 ) ;
       foo( 4 ) ;
       break outer_loop ;     // will break out of both for loops.
     end_for  inner_loop
  end_for  outer_loop

Steve Richter

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

""Victor Bazarov"" <vAbazarov@dAnai.com> wrote in message
news:3E9i9.357007$_91.457828@rwcrnsc51.ops.asp.att.net...
> "Steve Richter" <srichter@autocoder.com> wrote...

> > This business of making sure your open braces
> > have a corresponding closing brace
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > gets tedious some times.


> > [...]
> > Could the good standards committee people provide an optional literal
> > alternative to the brace?
>
>
> Trigraph sequences should be available.  { => ??<    } => ??>
> So, you don't really need any special literal...

You people aren't reading the OP's question. He wants to program in Python:
www.python.org

Dave
--
-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com



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

"Pete Becker" <petebecker@acm.org> wrote in message
news:3D890F98.B70C92DF@acm.org...
> Steve Richter wrote:
> >
> > Could the good standards committee people provide an optional literal
> > alternative to the brace?
> >
>
> No. But you can write some macros.

    Or he can use trigraphs -- ugly as they are...

class foo
??<
 ...
??>;

int main(int, char **)
??<
 std::cout<<"Hello cruel world!"<<endl;
 return 0;
??>


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

On Wed, 18 Sep 2002 22:59:48 +0000 (UTC), srichter@autocoder.com
("Steve Richter") wrote in comp.std.c++:

> This business of making sure your open braces have a corresponding closing
> brace gets tedious some times.
>
> namespace Receivables {
> class Money {
>
> void GetPaid( )
>  { Beg( ) ; Whine( ) ; CallHitMan( ) ; }
> } ;
> } ;
>
> If you are visually challenged like I am and mistake a ) for a } your MSVC
> 6.0 compiler will sometimes get real stupid and spit out hundres of
> misleading compile errors. And if you are also short term memory challenged
> ( again, thats me ) and have trouble remembering what you were programming 5
> minutes ago, correcting the problem is not always, as they say in the
> software world, "easy".
>
> Could the good standards committee people provide an optional literal
> alternative to the brace?
>
> namespace Receivables begin
>
> class Money begin
>
> void GetPaid( )
>  begin Lie( ) ; Steal( ) ; Cheat( ) ; end
>
> end class ;
> end namespace ;
>
> This way, if the closing brace of a header defined member function is
> missing the compiler can better localize the error message.
>
> Steve Richter

Perhaps I'm slow tonight, but why do you think that alternate
spellings for these keywords would make any difference?  The most
likely implementation would be for compiler writers to have the
preprocessor map them to the same PP tokens.  This is how the other
alternative spellings, <% and %> are handled.

On top of that, suddenly making common words like begin and end into
keywords would probably wreak massive breakage on existing code.

Leaving that aside, however, let's tackle the issue of adding a label
of some type to a terminating token.  There are some languages that
had such a feature (PL/1 comes to mind), I don't remember it helping
all that much.  You could always add the token as a comment following
the closing brace yourself.

This would involve a major change to the language for relatively
little benefit.  There are several other ways to reduce the occurrence
and effects of this problem.

For example you could use a coding standard that makes matching
braces:

namespace Receivables
{
   class Money
   {
      void GetPaid( )
      {
         Beg( ) ;
         Whine( ) ;
         CallHitMan( ) ;
      } // GetPaid()
   } ; // class Money
} ;  // namespace Receivables

Quite a few experienced code inspectors suggest this brace style
anyway, as they find it sometimes helps to take a pencil and rule to
hard copies and draw lines connecting the opening and closing braces.

And you can use intelligent editing tools.  I know of one IDE that
actually stops with a warning if the overall number of {} or () in a
file is mis-matched whenever you go to save the file, including the
automatic save of changes when asking for a compile or make.
Admittedly it happens to be an IDE for a C only compiler (lcc-win32).

And virtually every decent editor or IDE today allows you to place the
cursor on an opening or closing brace and use some menu button or key
combination to either jump to or highlight to the matching mate.

This doesn't have to be a particularly difficult problem, and IMHO is
certainly not worth making a very significant change to the language.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

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

Steve Richter wrote:

> This business of making sure your open braces have a corresponding closing
> brace gets tedious some times.

....
> If you are visually challenged like I am and mistake a ) for a } your MSVC
> 6.0 compiler will sometimes get real stupid and spit out hundres of
> misleading compile errors. And if you are also short term memory challenged
> ( again, thats me ) and have trouble remembering what you were programming 5
> minutes ago, correcting the problem is not always, as they say in the
> software world, "easy".


     Go to Tools->Options->Format and change the font in the VC++ editor.
There are options much more readable than the default.  Look around for
high-readability fonts.

     The only language standards issue here is that the syntax of
C++ does lead to parsers that recover badly.  There are few
keywords or tokens that can only appear at an outer scope,
so the parser tends not to recover to a ground state once it
gets lost.  Pascal, in contrast, has a number of keywords,
like "procedure" and "function", that can force the parser
back on track.

     There was serious R&D work on parser recovery back in the
batch era, but it's not something that people worry about
much now, when recompiles are a keypress away.

     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                       ]

srichter@autocoder.com ("Steve Richter") wrote
> This business of making sure your open braces have a corresponding closing
> brace gets tedious some times.
>
> namespace Receivables {
> class Money {
>
> void GetPaid( )
>  { Beg( ) ; Whine( ) ; CallHitMan( ) ; }
> } ;
> } ;

Proper indentation helps A LOT. In fact, one sign that a programmer
is not a professional, is the lack of proper indentation.
    namespace Receivables {
        class Money {
            void GetPaid() {
                Beg();
                Beg();
                Beg();
            }
        };
    };

A lot of people also add trailing comments; while I don't always
do this in my own code, I always consistently continue the practice
if it's already happening:
    namespace Receivables {
        class Money {
            void GetPaid() {
                Beg();
                Beg();
                Beg();
            } // void GetPaid()
        }; // class Money
    }; // namespace Receivables

> If you are visually challenged like I am and mistake a ) for a }

That happens to everyone. Larger fonts help, but then you have less code
on the screen -- like everything else, it's a trade-off.

> your MSVC
> 6.0 compiler will sometimes get real stupid and spit out hundres of
> misleading compile errors.

This can happen to almost any compiler, in almost any programming
language. I hope you never see what can happen if you leave out a
single period in COBOL. (Sometimes the compiler can't catch this,
and it causes logic errors -- other times it spits out an error, or
two, or 2000!)

The usual advice: the FIRST error message is usually the most
meaningful one, and sometimes the only meaningful one. Fix that error
first, and then if the others look suspect, recompile and look at the
new error list.

> And if you are also short term memory challenged
> ( again, thats me ) and have trouble remembering what you were programming 5
> minutes ago, correcting the problem is not always, as they say in the
> software world, "easy".

If you're being literal about the 5-minute problem, you probably ought
to see a doctor. But more to the point: in the worst case, you just have
to repeat the edit-compile cycle once for each warning or error message.

> Could the good standards committee people provide an optional literal
> alternative to the brace?
>
> namespace Receivables begin
> class Money begin
> void GetPaid( )
>  begin Lie( ) ; Steal( ) ; Cheat( ) ; end
> end class ;
> end namespace ;
>
> This way, if the closing brace of a header defined member function is
> missing the compiler can better localize the error message.

You can do this yourself, of course. I would recommend NOT using lowercase
names as macros, but one way is to do this:
    #define BEGIN {
    #define END(x) }

    namespace Receivables BEGIN
        class Money BEGIN
            void GetPaid() BEGIN
                Lie(); Steal(); Cheat();
            END(GetPaid);
        END(class)
    END(namespace)

Note that I still use indentation!

Another way would be more specific to the group you're defining:
    #define NAMESPACE(n) namespace n {
    #define ENDNAMESPACE(n) }
    #define CLASS(c) class c {
    #define ENDCLASS(c) }
    #define FUNCTION(f) f {
    #define ENDFUNCTION(f) }

    NAMESPACE(Receivables)
        CLASS(Money:public MoneyParent)
            void FUNCTION(GetPaid())
                Lie(); Steal(); Cheat();
            ENDFUNCTION(GetPaid);
        ENDCLASS(Money)
    ENDNAMESPACE(Receivables)

There are good reasons to dislike the precompiler for this type of
stuff (hey! you're trying to make C++ look like Pascal!), but there
are alternatives. Use digraphs or trigraphs!

    namespace Receivables <%
        class Money <%
            void GetPaid() <%
                Beg();
                Beg();
                Beg();
            %>;
        %>;
    %>;

I don't think that %> is ever going to look like ) in any editor.

---
[ 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 Hagan wrote:
> Well, we have two alternatives already. The first is a little dirty...
>
>     #define begin {
>     #define end {

That one is really dirty.  I mean the end being also an opening brace.
;-)

A

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


> > If you are visually challenged like I am and mistake a ) for a }
>
> That happens to everyone. Larger fonts help, but then you have less code
> on the screen -- like everything else, it's a trade-off.

what is the trade off when a begin_class, begin_namespace, end_method,
... is allowed as an alternative to { and }?  esp when a pragma:

pragma sensible_literal_alternative_to_the_squigle_enabled

can be used to prevent any name clash problems.


> > your MSVC
> > 6.0 compiler will sometimes get real stupid and spit out hundres of
> > misleading compile errors.
>
> This can happen to almost any compiler, in almost any programming
> language. I hope you never see what can happen if you leave out a
> single period in COBOL. (Sometimes the compiler can't catch this,
> and it causes logic errors -- other times it spits out an error, or
> two, or 2000!)

The literal squigle will prevent the error dump. When the compiler
sees "end_class", then any open member functions are missing an end.

This is the "value add" to what I am proposing.

Steve Richter

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

This business of making sure your open braces have a corresponding closing
brace gets tedious some times.

namespace Receivables {
class Money {

void GetPaid( )
 { Beg( ) ; Whine( ) ; CallHitMan( ) ; }
} ;
} ;

If you are visually challenged like I am and mistake a ) for a } your MSVC
6.0 compiler will sometimes get real stupid and spit out hundres of
misleading compile errors. And if you are also short term memory challenged
( again, thats me ) and have trouble remembering what you were programming 5
minutes ago, correcting the problem is not always, as they say in the
software world, "easy".

Could the good standards committee people provide an optional literal
alternative to the brace?

namespace Receivables begin

class Money begin

void GetPaid( )
 begin Lie( ) ; Steal( ) ; Cheat( ) ; end

end class ;
end namespace ;

This way, if the closing brace of a header defined member function is
missing the compiler can better localize the error message.

Steve Richter


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

Steve Richter wrote:
>
> Could the good standards committee people provide an optional literal
> alternative to the brace?
>

No. But you can write some macros.

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

"Steve Richter" <srichter@autocoder.com> wrote...
> This business of making sure your open braces have a corresponding closing
> brace gets tedious some times.
> [...]
> Could the good standards committee people provide an optional literal
> alternative to the brace?


Trigraph sequences should be available.  { => ??<    } => ??>
Is it easier to distinguish them from parentheses?  I say, yes:

    namespace NS ??<
        class Class ??<
            void foo() ??<
            bar();
            ??>
        ??>;
    ??>

So, you don't really need any special literal...

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                       ]

""Steve Richter"" <srichter@autocoder.com> asked...
> Could the good standards committee people provide an optional literal
> alternative to the brace?
>
> namespace Receivables begin
>
> class Money begin
>
> void GetPaid( )
>  begin Lie( ) ; Steal( ) ; Cheat( ) ; end
>
> end class ;
> end namespace ;

Well, we have two alternatives already. The first is a little dirty...

    #define begin {
    #define end {
    class Money begin
        void GetPaid() begin Lie(); Steal(); Cheat(); end
    end /*class*/;

You might want to change the actual literals in question, since "begin"
and "end" are already used in the standard library, amongst other places.
The second alternative is to use digraphs or trigraphs

class Money <%
    void GetPaid() <% Lie(); Steal(); Cheat(); %>
%> /*class*/;

(The trigraphs are ??< and ??>.  Which is uglier? You decide. :)

If you are visually challenged, you might also want to look up the literal
keywords for operators && & || | ! ~ ^ and assignment variants thereof.
Perhaps you have, and this was the motivation for your question.


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

>
> Could the good standards committee people provide an optional
literal
> alternative to the brace?
>

#define begin {
#define end }

--
Petter

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