Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #99884 > unrolled thread

gcc needs a curly bracket matching/counting function

Back to article view | Back to comp.lang.c

Contents

  gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 20:38 -0500
    Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 01:59 +0000
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-19 22:30 -0500
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 11:46 +0100
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 13:20 +0000
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 13:30 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 05:35 -0800
            Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:07 +0100
              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 12:46 +0000
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 15:10 +0100
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:10 +0000
                    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 19:50 +0100
                      Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 20:15 +0000
                        Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-21 22:36 +0000
                          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 23:46 +0000
                            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 01:54 +0000
                              Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 12:16 +0000
                                Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 13:06 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 05:25 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 13:34 +0000
                                      Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:16 -0800
                                        Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-22 09:30 -0800
                                          Re: gcc needs a curly bracket matching/counting function luser droog <luser.droog@gmail.com> - 2016-12-22 09:40 -0800
                            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:33 -0800
                              Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 05:41 -0800
                                Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 14:53 +0000
                                  Re: gcc needs a curly bracket matching/counting function asetofsymbols@gmail.com - 2016-12-22 08:11 -0800
                                  Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 08:27 -0800
                                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-22 16:48 +0000
                                      Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 09:27 -0800
                                        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-22 20:12 +0000
                                          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 12:18 -0800
                Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:04 -0800
                  Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 17:24 +0000
                    Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 09:41 -0800
                    Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-22 18:10 +1300
                      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:50 +1300
                        Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:07 -0800
                          Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2017-01-02 11:16 +0100
                      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:40 -0800
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-21 08:52 -0800
                Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 20:16 +0100
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-22 09:41 +0100
        Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:04 +0000
          Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:46 +0000
            Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 21:55 +0000
          Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:52 -0500
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:09 +0000
            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 19:14 +0000
              Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:16 -0800
                Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-20 20:53 +0000
                  Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 13:51 -0800
                    Re: gcc needs a curly bracket matching/counting function Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:49 +0000
                    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:36 -0800
                      Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-29 12:44 +0100
                Re: gcc needs a curly bracket matching/counting function bart4858@gmail.com - 2016-12-20 13:25 -0800
                  Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 13:39 -0800
                    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 21:58 +0000
                      Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 14:05 -0800
                      Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 22:17 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:03 +0000
                      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 14:31 -0800
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 23:21 +0000
                          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 15:51 -0800
                            Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-21 00:38 +0000
                        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2017-01-26 19:11 +0000
      Re: gcc needs a curly bracket matching/counting function mark.bluemel@gmail.com - 2016-12-20 00:50 -0800
    gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-19 18:11 -0800
      Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 03:00 -0800
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:50 -0800
          Re: gcc needs a curly bracket matching/counting function fir <profesor.fir@gmail.com> - 2016-12-20 05:20 -0800
      Re: gcc needs a curly bracket matching/counting function DFS <nospam@dfs.com> - 2016-12-20 13:46 -0500
        Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 18:59 +0000
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 19:02 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 12:13 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 20:25 +0000
        Re: gcc needs a curly bracket matching/counting function Robert Spanjaard <spamtrap@arumes.com> - 2016-12-20 20:35 +0100
    Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-20 08:56 +0100
    Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:26 -0800
      Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 10:41 +0000
        Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:52 -0800
          Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:00 +0000
            Re: gcc needs a curly bracket matching/counting function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 03:19 -0800
              Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 11:31 +0000
              Re: gcc needs a curly bracket matching/counting function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-20 17:21 +0000
                Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:49 +0000
                  Re: gcc needs a curly bracket matching/counting function David Brown <david.brown@hesbynett.no> - 2016-12-21 12:25 +0100
                  Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 01:14 -0800
      Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:07 -0800
        Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:14 +0000
          Re: gcc needs a curly bracket matching/counting function Keith Thompson <kst-u@mib.org> - 2016-12-20 09:33 -0800
            Re: gcc needs a curly bracket matching/counting function Richard Heathfield <rjh@cpax.org.uk> - 2016-12-20 17:39 +0000
            Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 09:45 -0800
        Re: gcc needs a curly bracket matching/counting function gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-20 17:56 +0000
          Re: gcc needs a curly bracket matching/counting function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-20 10:01 -0800
      Re: gcc needs a curly bracket matching/counting function Ian Collins <ian-news@hotmail.com> - 2016-12-21 07:44 +1300
    Re: gcc needs a curly bracket matching/counting function BartC <bc@freeuk.com> - 2016-12-20 10:46 +0000
    Re: gcc needs a curly bracket matching/counting function Ike Naar <ike@iceland.freeshell.org> - 2016-12-20 22:00 +0000
      Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:39 -0800
    Re: gcc needs a curly bracket matching/counting function Ken Brody <kenbrody@spamcop.net> - 2016-12-22 12:12 -0500
    Re: gcc needs a curly bracket matching/counting function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-12-22 12:59 -0700
    Re: gcc needs a curly bracket matching/counting function Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:10 -0800

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#100037

What is the difference from
a;b;
and
a,b;

You say are different...
I remember that first than 'b'
it is executed 'a'

[toc] | [prev] | [next] | [standalone]

#100044

asetofsymbols@gmail.com writes:
> What is the difference from
> a;b;
> and
> a,b;
>
> You say are different...
> I remember that first than 'b'
> it is executed 'a'

Bart already explained that.  In
    a;b;
a and b must be statements.  In
    a,b;
a and b must be expressions.  Any expression can be turned into
a statement by adding a semicolon, but not all statements can be
turned into expressions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#100045

On Thursday, December 22, 2016 at 11:30:35 AM UTC-6, Keith Thompson wrote:

> Bart already explained that.  In
>     a;b;
> a and b must be statements.  In
>     a,b;
> a and b must be expressions.  Any expression can be turned into
> a statement by adding a semicolon, but not all statements can be
> turned into expressions.
> 

Agreed. And the saving grace (before you say it)
is that *many* statements can be turned into
expressions by wrapping them in a function and
calling the function in the expression.

-- 
note the weasel word

[toc] | [prev] | [next] | [standalone]

#100029

BartC wrote:
>  if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;

Doesn't C also handle this thusly:

    if (a,b)
       (c, d, e);
    else if (f)
        g;
    else if (h)
        (i, j);
    else
        k;

...which could be rewritten:

    if (a,b) (c, d, e); else if (f) g; else if (h) (i, j); else k;

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#100031

BartC wrote: 
>  if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;

Or rather:

    if ((a,b))   // Result from b used for conditional
       (c, d, e); 
    else if (f) 
        g; 
    else if (h) 
        (i, j); 
    else 
        k; 

You can't put flow statements in there, but by calling a function and
using return values, the equivalent is possible, and with much clear
syntax for debugging and maintenance.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#100035

On 22/12/2016 13:41, Rick C. Hodgin wrote:
> BartC wrote:
>>  if (a,b) {c;d;e;} else if (f) g; else if (h) {i;j;} else k;
>
> Or rather:
>
>     if ((a,b))   // Result from b used for conditional
>        (c, d, e);
>     else if (f)
>         g;
>     else if (h)
>         (i, j);
>     else
>         k;
>
> You can't put flow statements in there, but by calling a function and
> using return values, the equivalent is possible, and with much clear
> syntax for debugging and maintenance.

As I mentioned in my reply to asetofsymbols, a,b,c etc are just 
placeholders for actual expressions and statements.

In general, you can't write 3 statements as (c,d,e). Only if they happen 
to be expressions. But 3 expressions could be written as {c;d;e;}.

We want to reduce the number of possibilities not increase them!

c,d,e as expressions in a block context could be written as::

     c, d, e;
    (c, d, e);
    {c; d; e;}
    {c, d, e;}
    {c, d; e;}  // etc

Plus there are any number of ways of splitting them across multiple 
lines. Or adding extra {} and ().

When I worked on my lightweight translator I had to insist on source 
code looking like this:

   if (a) then
     ....
   else
     ....
   fi      // or endif

Even if there was just one statement in each branch. But it paid off 
since you knew the input was always going to be written consistently, so 
it looked good and was easy to detect, and the resultant C wasn't too 
bad either, as it would use the same {,} placement scheme. And there 
would always be {,}.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#100036

What you write remember me
 Axiom all is parentizated using
indentation...
As in
if a=1 then
        r.1:=1
        r.2:=2
else r.1:=0
     r.2:=1

One can write that in one line as

if a=1 then(r.1:=1;r.2:=2)else(r.1:=0;r.2:=1)

[toc] | [prev] | [next] | [standalone]

#100038

Bartc wrote:
> In general, you can't write 3 statements as (c,d,e). Only if they happen
> to be expressions.

What do you mean?  Apart from declarators and flow control ... what
can't you put in there?

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#100039

On 22/12/2016 16:27, Rick C. Hodgin wrote:
> Bartc wrote:
>> In general, you can't write 3 statements as (c,d,e). Only if they happen
>> to be expressions.
>
> What do you mean?  Apart from declarators and flow control ... what
> can't you put in there?

Statements such as while, for, if, return, goto, label and switch.

Unless you're using gcc or clang and you put statements inside ({...}).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#100043

On Thursday, December 22, 2016 at 11:48:34 AM UTC-5, Bart wrote:
> On 22/12/2016 16:27, Rick C. Hodgin wrote:
> > Bartc wrote:
> >> In general, you can't write 3 statements as (c,d,e). Only if they happen
> >> to be expressions.
> >
> > What do you mean?  Apart from declarators and flow control ... what
> > can't you put in there?
> 
> Statements such as while, for, if, return, goto, label and switch.
> 
> Unless you're using gcc or clang and you put statements inside ({...}).

({...}) looks like a three-eyed alien primate of some kind. :-)

This missing ability in C is why I defined casks in CAlive.  Here is
a utility cask, which is an arbitrary block of code execution block
that can be defined and injected anywhere.  It is surrounded by ~| on
the left, and |~ on the right:

    ~| /*any code goes here*/ |~

Those can be injected anywhere in code, and are executed wherever they
are inserted, even in the middle of otherwise syntactically correct
expressions:

    if (x == ~|printf("Hi, mom!\n");|~ z)
    {
        // Code here
    }

In this case, it would break out fundamental un-optimized operations as:

    load z
    push "Hi, mom!\n"
    call printf()
    load x
    compare [x, z]
    jump to after the block if not equal
    Whatever is in the block goes here

Other casks are:

    (|reference casks|)      // Refers to existing things
    [|definition casks|]     // Defines new things, or augments others
    <|logic casks|>          // Used where logic yields true/false results
    // And there are others

More here if interested:

    https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc.odt

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#100047

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

<snip>
> This missing ability in C...

<snip>
>     if (x == ~|printf("Hi, mom!\n");|~ z)

or you could write

  if (x == (printf("Hello, mother\n"), z))

and start using it today (since it's then just C).  Maybe you intended
to give an example that can't be written in standard C.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#100049

On Thursday, December 22, 2016 at 3:12:47 PM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> <snip>
> > This missing ability in C...
> 
> <snip>
> >     if (x == ~|printf("Hi, mom!\n");|~ z)
> 
> or you could write
> 
>   if (x == (printf("Hello, mother\n"), z))
> 
> and start using it today (since it's then just C).  Maybe you intended
> to give an example that can't be written in standard C.

Yeah.  You mentioned that before.  I was unaware of it at that time.
And that does replicate similar functionality to the example I gave,
but it is woefully short of the full ability of the ~|utility|~ cask,
let alone the other ones.

Should I ever get CAlive completed, Ben, you know you never have to
use it, right?  You're completely free to not use it.  It won't affect
me either way.  In fact, if you did use it even one time ... I think
I'd probably faint (or is it feint? ... it would depend on how
adversarial we are at that point LOL).

Ben, (may I call you "Ben?") ... hi. :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#99993

BartC <bc@freeuk.com> writes:
> On 21/12/2016 11:07, David Brown wrote:
>> On 20/12/16 14:35, Rick C. Hodgin wrote:
>>> On Tuesday, December 20, 2016 at 8:20:47 AM UTC-5, Bart wrote:
>>>> On 20/12/2016 03:30, DFS wrote:
>>>>
>>>>> I'd rather the compiler do at least a quick count for me.
>>>>
>>>> The compiler is handicapped by the language. This has the right number
>>>> of { and } braces and compiles fine:
>>>>
>>>>      if (a) {
>>>>          if (b)
>>>>              puts("B1");
>>>>              puts("B2");
>>>>          }
>>
>> C gives you the ability to write code in an ugly, confusing and
>> error-prone manner.  So do all programming languages I have ever seen.
>
> In the syntax I normally use, this example is impossible to write 
> without invoking an error.

That would be some other language than C, right?

>> The details of how you can write confusing and bad code with legal
>> syntax varies from language to language, but it is always possible.
>>
>> You avoid this particular problem with a simple rule - a for, if or
>> while statement should always have brackets.
>
> Unfortunately that doesn't always work, as the language won't not cooperate.

Sure it does.  It doesn't always diagnose failures to follow that rule,
but it doesn't get in the way of following it yourself.

> If you forget the braces, it won't tell you as it knows nothing about 
> your rule, unless it can't match them. You can also put in extra braces, 
> and that's OK provided the extra brace is matched elsewhere.

So don't do that.

> It doesn't help that the same } brace can close an if-block, for-block, 
> while-block, do-block, switch-block, function-block, a data-block, and 
> just a block-block.

I've never found that to be a problem, as long as I use braces
consistently -- which is not at all difficult to do.  (I sometimes have
some difficulty when I'm working on code written by others.  Such is
life.)

> So it's a language design issue; it's not true that all languages are 
> the same. Not regarding this block-delimiting anyway.

Did anybody say that all languages are the same?

Perl, for example, requires braces on all compound statements.
(Personally, that's one thing I like about Perl.)  But if Perl
didn't require braces, I'm entirely capable of using them anyway,
just as I do in C.

> And people aren't going to follow the rule as it's far too tempting to 
> just write:
>
>      if (!fp) return 0;
>
> (leaving this open to brace-matching and dangling else problems).

In fact, a lot of people *do* follow the rule.  I sometimes (rarely)
omit braces on one-line statements.  It doesn't cause brace-matching or
dangling else problems, because I consistently use braces on multi-line
statements.

>    And you need a consistent
>> bracing and indenting style - I recommend the One True Brace Style as a
>> starting point, but variations are possible.
>
> Yes, everyone uses /their own/ consistent style!

Yes, the lack of consistency of brace styles can be a problem.  Pick a
style and follow it consistently for your own code (I like the 1TBS, but
I don't complain if you prefer something else).  If you're working on
existing code, consistently follow that code's existing style.

Once again, you seem to be inventing problems just so you can complain
about them.

The solution to this particular problem is not "change the language,
breaking decades of existing code, so the compiler will diagnose
missing braces".  The solution is "exercise a bit of discipline
when writing code".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#99996

On 21/12/2016 17:04, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

>> If you forget the braces, it won't tell you as it knows nothing about
>> your rule, unless it can't match them. You can also put in extra braces,
>> and that's OK provided the extra brace is matched elsewhere.
>
> So don't do that.

"So don't make mistakes"

Brilliant!

> Once again, you seem to be inventing problems just so you can complain
> about them.

The problems exist, I don't need to invent them. But people seem to be 
in denial.

There's no solution that involves fixing the language as it's far too 
late. But it would nice if someone would agree once in a while that 
there might be some issues with the design of the language.

> The solution to this particular problem is not "change the language,
> breaking decades of existing code, so the compiler will diagnose
> missing braces".  The solution is "exercise a bit of discipline
> when writing code".

People /will/ make mistakes. But the language design stops some mistakes 
being diagnosed because it is still legal code. This can happen in other 
languages but seems to be particularly easy to do in C.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99998

BartC <bc@freeuk.com> writes:
[...]
> There's no solution that involves fixing the language as it's far too 
> late.

I'm glad you realize that.

>       But it would nice if someone would agree once in a while that 
> there might be some issues with the design of the language.

Apparently you haven't been paying attention.  Yes, there are issues
with the design of the language; nobody denies that.  There are
design decisions that, with the benefit of hindsight, I would have
made differently.  I, and others, have discussed at considerable
length ways to deal with C's very real problems, such as using a
consistent brace style even though the language doesn't require it.

Are you happy now?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#100018

On 12/22/16 06:24 AM, BartC wrote:
> On 21/12/2016 17:04, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> If you forget the braces, it won't tell you as it knows nothing about
>>> your rule, unless it can't match them. You can also put in extra braces,
>>> and that's OK provided the extra brace is matched elsewhere.
>>
>> So don't do that.
>
> "So don't make mistakes"
>
> Brilliant!


It's called writing unit tests...


-- 
Ian

[toc] | [prev] | [next] | [standalone]

#100473

On 12/29/16 01:40 PM, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> On 12/22/16 06:24 AM, BartC wrote:
>>> On 21/12/2016 17:04, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>
>>>>> If you forget the braces, it won't tell you as it knows nothing about
>>>>> your rule, unless it can't match them.  You can also put in extra braces,
>>>>> and that's OK provided the extra brace is matched elsewhere.
>>>>
>>>> So don't do that.
>>>
>>> "So don't make mistakes"
>>>
>>> Brilliant!
>>
>> It's called writing unit tests...
>
> Unit tests aren't going to give any help for code that
> doesn't compile.

But they will if you put a matching brace in the wrong place...

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#100853

Ian Collins <ian-news@hotmail.com> writes:

> On 12/29/16 01:40 PM, Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> On 12/22/16 06:24 AM, BartC wrote:
>>>> On 21/12/2016 17:04, Keith Thompson wrote:
>>>>> BartC <bc@freeuk.com> writes:
>>>>>
>>>>>> If you forget the braces, it won't tell you as it knows nothing about
>>>>>> your rule, unless it can't match them.  You can also put in extra braces,
>>>>>> and that's OK provided the extra brace is matched elsewhere.
>>>>>
>>>>> So don't do that.
>>>>
>>>> "So don't make mistakes"
>>>>
>>>> Brilliant!
>>>
>>> It's called writing unit tests...
>>
>> Unit tests aren't going to give any help for code that
>> doesn't compile.
>
> But they will if you put a matching brace in the wrong place...

This sounds like a joke.  Anyone whose code is so convoluted that
fixing a brace mismatch has any significant chance of putting a
matching brace in the wrong place has much deeper problems than
just where the brace should go.

[toc] | [prev] | [next] | [standalone]

#100855

On 02/01/17 11:07, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> On 12/29/16 01:40 PM, Tim Rentsch wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> On 12/22/16 06:24 AM, BartC wrote:
>>>>> On 21/12/2016 17:04, Keith Thompson wrote:
>>>>>> BartC <bc@freeuk.com> writes:
>>>>>>
>>>>>>> If you forget the braces, it won't tell you as it knows nothing about
>>>>>>> your rule, unless it can't match them.  You can also put in extra braces,
>>>>>>> and that's OK provided the extra brace is matched elsewhere.
>>>>>>
>>>>>> So don't do that.
>>>>>
>>>>> "So don't make mistakes"
>>>>>
>>>>> Brilliant!
>>>>
>>>> It's called writing unit tests...
>>>
>>> Unit tests aren't going to give any help for code that
>>> doesn't compile.
>>
>> But they will if you put a matching brace in the wrong place...
> 
> This sounds like a joke.  Anyone whose code is so convoluted that
> fixing a brace mismatch has any significant chance of putting a
> matching brace in the wrong place has much deeper problems than
> just where the brace should go.
> 

I've seen code that bad.  Mind you, there were no unit tests to help -
it's hard to imagine a combination of disciplined programming with solid
unit tests, and the kind of slap-dash programming where someone has
added a brace "because the code compiles if I put it there".

[toc] | [prev] | [next] | [standalone]

#100609

Ian Collins <ian-news@hotmail.com> writes:

> On 12/22/16 06:24 AM, BartC wrote:
>> On 21/12/2016 17:04, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>>
>>>> If you forget the braces, it won't tell you as it knows nothing about
>>>> your rule, unless it can't match them.  You can also put in extra braces,
>>>> and that's OK provided the extra brace is matched elsewhere.
>>>
>>> So don't do that.
>>
>> "So don't make mistakes"
>>
>> Brilliant!
>
> It's called writing unit tests...

Unit tests aren't going to give any help for code that
doesn't compile.

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web