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

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

->=

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

Contents

  ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 14:53 +0000
    Re: ->= Richard Heathfield <rjh@cpax.org.uk> - 2015-11-25 15:12 +0000
      Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 11:51 -0500
        Re: ->= "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-25 09:49 -0800
        Re: ->= supercat@casperkitty.com - 2015-11-25 09:55 -0800
      Re: ->= John Bode <jfbode1029@gmail.com> - 2015-11-25 12:24 -0800
        Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 15:40 -0500
          Re: ->= John Bode <jfbode1029@gmail.com> - 2015-11-27 17:14 -0800
            Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-27 20:28 -0500
    Re: ->= "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-25 07:35 -0800
    Re: ->= "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-25 15:47 -0600
      Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 17:04 -0500
      Re: ->= Nobody <nobody@nowhere.invalid> - 2015-11-26 10:58 +0000
        Re: ->= supercat@casperkitty.com - 2015-11-26 08:55 -0800
    Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-26 00:48 +0000
    Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:15 -0800
      Re: ->= supercat@casperkitty.com - 2015-11-27 14:26 -0800
        Re: ->= BartC <bc@freeuk.com> - 2015-11-27 23:38 +0000
          Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-27 19:37 -0800
            Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-28 06:35 -0800
        Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-27 17:51 -0600
        Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-28 06:53 -0800
          Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 17:12 +0000
            Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-28 10:26 -0800
              Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 19:50 +0000
            Re: ->= BartC <bc@freeuk.com> - 2015-11-28 19:14 +0000
              Re: ->= supercat@casperkitty.com - 2015-11-28 11:48 -0800
                Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 22:33 +0000
              Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 20:18 +0000
                Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-28 18:15 -0600
                  Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 22:44 +0000
                    Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-29 18:25 -0600
                    Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-30 10:21 +0000
              Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-28 13:10 -0800
                Re: ->= BartC <bc@freeuk.com> - 2015-11-28 22:12 +0000
                  Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-29 11:42 +0000
                    Re: ->= BartC <bc@freeuk.com> - 2015-11-29 14:24 +0000
                      Re: "->=" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-29 10:33 -0500
                      Re: "->=" BartC <bc@freeuk.com> - 2015-11-29 17:49 +0000
                      Re: ->= supercat@casperkitty.com - 2015-11-29 11:50 -0800
                        Re: ->= BartC <bc@freeuk.com> - 2015-11-29 22:37 +0000
                  Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-30 00:23 -0800
                Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 23:00 +0000
                  Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-30 00:28 -0800
                  Re: ->= Rosario19 <Ros@invalid.invalid> - 2015-12-13 16:29 +0100
    Re: ->= Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-28 14:59 -0500

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

#77297

On 27-Nov-15 16:26, supercat@casperkitty.com wrote:
> On Friday, November 27, 2015 at 4:15:37 PM UTC-6, Tim Rentsch wrote:
>> I'm surprised how many people responded positively to this.  At
>> best it's no more than syntactic saccharin.  Note also it
>> requires revising the rule stated in the first sentence of
>> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.
> 
> Adding anything to the language would require revising any rule that 
> claims to be an exhaustive list of such things.  Further, I'm not 
> sure why it should necessarily be considered syntactic saccharin any 
> moreso than any of the other compound operators.  Just as
> "foo[i]+=4;" avoids the need to evaluate its lvalue twice, so too
> would "foo->bar->boz->=next" avoid the need to either generate a
> temporary pointer to hold "foo->bar->boz" or risk having the
> dereferencing chain performed twice.

If your compiler doesn't do optimizations as simple as CSE in the case
of "foo->bar->boz = foo->bar->boz->next;", then you likely have bigger
problems than this to worry about.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#77320

supercat@casperkitty.com writes:

> On Friday, November 27, 2015 at 4:15:37 PM UTC-6, Tim Rentsch wrote:
>> I'm surprised how many people responded positively to this.  At
>> best it's no more than syntactic saccharin.  Note also it
>> requires revising the rule stated in the first sentence of
>> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.
>
> Adding anything to the language would require revising any rule
> that claims to be an exhaustive list of such things.

Of course the list of compound assignment operators would have to
be updated.  The point is that the generic semantic description
that applies to all compound assignment operators would also have
to be updated, because the meaning of ->= does not parallel that
of other compound assignment operators.  Also the syntax would
have to be updated, because what forms are allowed on the right
hand side are different for ->= than any other compound assignment
operator.

> Further, I'm not sure why it should necessarily be considered
> syntactic saccharin any moreso than any of the other compound
> operators.  [...]

The form of RHSs allowed for ->= is a lot more limited than what
is allowed for other compound assignment operators.  Also, I
expect cases where ->= would be applicable typically have simple
left hand sides (most often just a single identifier), moreso
than other compound assignment operators.

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

#77327

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> supercat@casperkitty.com writes:
 
(snip)
>> Adding anything to the language would require revising any rule
>> that claims to be an exhaustive list of such things.
 
> Of course the list of compound assignment operators would have to
> be updated.  The point is that the generic semantic description
> that applies to all compound assignment operators would also have
> to be updated, because the meaning of ->= does not parallel that
> of other compound assignment operators.  Also the syntax would
> have to be updated, because what forms are allowed on the right
> hand side are different for ->= than any other compound assignment
> operator.

It is funny how many times I have written it, and only recently
thought about this.

I have previously noted the absence of ||= and &&=, in some 
cases using |= or &= in their place. 
 
>> Further, I'm not sure why it should necessarily be considered
>> syntactic saccharin any moreso than any of the other compound
>> operators.  [...]
 
> The form of RHSs allowed for ->= is a lot more limited than what
> is allowed for other compound assignment operators.  Also, I
> expect cases where ->= would be applicable typically have simple
> left hand sides (most often just a single identifier), moreso
> than other compound assignment operators.

I suppose an array element might also have some use.
In that case, evaluating the index expression would be done 
only once, which might sometimes be useful.

-- glen

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

#77333

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> I have previously noted the absence of ||= and &&=, in some 
> cases using |= or &= in their place. 

Of course you have to be careful with that, since the semantics are
different; | and & are bitwise operators, while || and && are logical
operators, treating all non-zero values as true.

One data point: Perl has ||= and &&= operators.

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

#77343

Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)
>> I have previously noted the absence of ||= and &&=, in some 
>> cases using |= or &= in their place. 
 
> Of course you have to be careful with that, since the semantics are
> different; | and & are bitwise operators, while || and && are logical
> operators, treating all non-zero values as true.

Yes I was careful, because, yes, the values might not have been
appropriate, otherwise.
 
> One data point: Perl has ||= and &&= operators.

That is interesting.

-- glen

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

#77338

On 28/11/2015 17:12, glen herrmannsfeldt wrote:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> supercat@casperkitty.com writes:
>
> (snip)
>>> Adding anything to the language would require revising any rule
>>> that claims to be an exhaustive list of such things.
>
>> Of course the list of compound assignment operators would have to
>> be updated.  The point is that the generic semantic description
>> that applies to all compound assignment operators would also have
>> to be updated, because the meaning of ->= does not parallel that
>> of other compound assignment operators.  Also the syntax would
>> have to be updated, because what forms are allowed on the right
>> hand side are different for ->= than any other compound assignment
>> operator.
>
> It is funny how many times I have written it, and only recently
> thought about this.
>
> I have previously noted the absence of ||= and &&=, in some
> cases using |= or &= in their place.

|| and && are also a little funny compared with normal ops.

&& for example takes two boolean operands and returns a boolean result.

An actual boolean operand would normally be 1 or 0, so that & could be 
used instead.

If an operand of && isn't already boolean 1 or 0, for example some 
arbitrary integer value, then an expression such as (a &&= b) is 
effectively changing how a is being used.

Even if still within the type rules, there's something a bit off about 
it. You wouldn't normally want to change a count into a boolean for example.

The short-circult aspect doesn't help. And it's difficult to visualise 
how &&= would map into a machine in-place operator as & or + would.

If a has a non-zero value, then it will always need to be replaced by 0 
or 1 (depending on b); never just modified.

-- 
Bartc

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

#77342

On Saturday, November 28, 2015 at 1:14:59 PM UTC-6, Bart wrote:
> The short-circult aspect doesn't help. And it's difficult to visualise 
> how &&= would map into a machine in-place operator as & or + would.

I can see uses for operators which say "If the rhs is zero set the lhs to
zero, else leave it alone" or "If the rhs is non-zero, set the lhs to 1,
else leave it alone".  Actually, I think the && and || operators would have
been more useful if instead of yielding 1 for the non-zero case they instead
yielded the last expression evaluated, in which case the latter operation
above would be "If the rhs is non-zero, store it; else leave the lhs alone".
Such operators would be useful, but their semantics would be different from
the normal way short-circuit and compound operators work.

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

#77410

supercat@casperkitty.com wrote:
> On Saturday, November 28, 2015 at 1:14:59 PM UTC-6, Bart wrote:
>> The short-circult aspect doesn't help. And it's difficult to visualise 
>> how &&= would map into a machine in-place operator as & or + would.
 
> I can see uses for operators which say "If the rhs is zero set the lhs to
> zero, else leave it alone" or "If the rhs is non-zero, set the lhs to 1,
> else leave it alone".  Actually, I think the && and || operators would have
> been more useful if instead of yielding 1 for the non-zero case they instead
> yielded the last expression evaluated, in which case the latter operation
> above would be "If the rhs is non-zero, store it; else leave the lhs alone".
> Such operators would be useful, but their semantics would be different from
> the normal way short-circuit and compound operators work.

I didn't completely figure it out, and pretty much don't program
in perl, but it seems that perl does something similar.

-- glen

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

#77346

BartC <bc@freeuk.com> wrote:

(snip, I wrote)
>> I have previously noted the absence of ||= and &&=, in some
>> cases using |= or &= in their place.
 
> || and && are also a little funny compared with normal ops.
 
> && for example takes two boolean operands and returns a boolean result.
 
> An actual boolean operand would normally be 1 or 0, so that & could be 
> used instead.

Yes, but it isn't always.
 
> If an operand of && isn't already boolean 1 or 0, for example some 
> arbitrary integer value, then an expression such as (a &&= b) is 
> effectively changing how a is being used.

Seems to me that &&= and ||= could still do short circuit evaluation
if they existed, though it isn't obvious which way. That is:

   a = a && b;

or

   a = b && a;

I tried to look up how perl did it, but didn't find it.
 
> Even if still within the type rules, there's something a bit off about 
> it. 
> You wouldn't normally want to change a count into a boolean for example.

They would be nice if you have a series of tests to do, each one big
enough to want a separate line.
 
> The short-circult aspect doesn't help. 

Seems like it could, but which direction isn't so obvious.

More obviously, 

   a &&= b; 

would work like:

   a = a && b;

> And it's difficult to visualise 
> how &&= would map into a machine in-place operator as & or + would.

Not so obvious what an in-place operator is. 

Many processors have register to storage operations, so you could
sum or and into a register. But most of the time the operation
works independent of the actual hardware.
 
> If a has a non-zero value, then it will always need to be replaced by 0 
> or 1 (depending on b); never just modified.

-- glen

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

#77358

On 28-Nov-15 14:18, glen herrmannsfeldt wrote:
> BartC <bc@freeuk.com> wrote:
>> If an operand of && isn't already boolean 1 or 0, for example some
>> arbitrary integer value, then an expression such as (a &&= b) is 
>> effectively changing how a is being used.
> 
> Seems to me that &&= and ||= could still do short circuit evaluation 
> if they existed, though it isn't obvious which way. That is:
> 
> a = a && b;
> 
> or
> 
> a = b && a;

Given how other such operators are defined, for it to mean the latter
would violate the Principle of Least Astonishment.

Still, I'm not sure I see the usefulness here; I can't remember the last
time I saved the result of && (or ||) in a variable, much less in one of
its operands.

>> And it's difficult to visualise how &&= would map into a machine
>> in-place operator as & or + would.
> 
> Not so obvious what an in-place operator is.

I'm guessing this refers to two-operand instructions, where the
destination register (or memory location) is also one of the sources.

Some (questionable) sources that say a+=b generates faster machine code
than a=a+b, but I doubt that has been true in decades, if ever.  Today,
it's merely syntactic sugar.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#77412

Stephen Sprunk <stephen@sprunk.org> wrote:

(snip, I wrote)
>> Seems to me that &&= and ||= could still do short circuit evaluation 
>> if they existed, though it isn't obvious which way. That is:
 
>> a = a && b;
 
>> or
 
>> a = b && a;
 
> Given how other such operators are defined, for it to mean the latter
> would violate the Principle of Least Astonishment.

I suppose, but it would be interesting to know how useful 
either would be.
 
> Still, I'm not sure I see the usefulness here; I can't remember the last
> time I saved the result of && (or ||) in a variable, much less in one of
> its operands.

The time I remember wanting it was a series of malloc() calls, where
I didn't need to test each individually. Even more, each was inside
a preprocessor macro, complicating the code. Maybe:

#define allocate(x, y, z) (x=malloc(y*sizeof(z)))

  flag=1;
  flag &&= allocate(a,10,int);
  flag &&= allocate(b, 20,int);

  if(!flag) ...

(snip on in place)

> I'm guessing this refers to two-operand instructions, where the
> destination register (or memory location) is also one of the sources.

I suppose, but registers are fast, and for memory you have to load
and store either way.  (Well, probably to cache now.)
 
> Some (questionable) sources that say a+=b generates faster machine code
> than a=a+b, but I doubt that has been true in decades, if ever.  Today,
> it's merely syntactic sugar.

It is more interesting when the left side is more complicated.

   x[(int)sqrt(y)]+=y;

but even if the time is the same, the convenience and more 
readability not having to write the same thing twice.

That is, not having to verify when reading or changing it that
both are exactly the same.

Seems that could apply for &&= and ||=, and even for ->=.

-- glen

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

#77418

On 29-Nov-15 16:44, glen herrmannsfeldt wrote:
> Stephen Sprunk <stephen@sprunk.org> wrote:
>> Still, I'm not sure I see the usefulness here; I can't remember the
>> last time I saved the result of && (or ||) in a variable, much less
>> in one of its operands.
> 
> The time I remember wanting it was a series of malloc() calls, where 
> I didn't need to test each individually. Even more, each was inside a
> preprocessor macro, complicating the code. Maybe:
> 
> #define allocate(x, y, z) (x=malloc(y*sizeof(z)))
> 
>   flag=1;
>   flag &&= allocate(a,10,int);
>   flag &&= allocate(b, 20,int);
> 
>   if(!flag) ...
> 
> (snip on in place)

Yuck.

>> I'm guessing this refers to two-operand instructions, where the
>> destination register (or memory location) is also one of the sources.
> 
> I suppose, but registers are fast, and for memory you have to load
> and store either way.  (Well, probably to cache now.)

The 2-operand machines I know allow at least one memory operand:

mov reg, [b]
add [a], reg

A few will even allow two memory operands:

add [a], [b]

But if you're storing into a third register, you need another instruction:

mov [a], reg
add [b], reg
mov reg, [c]

or

mov [a], [c]
add [b], [c]

OTOH, 3-operand machines generally don't allow memory operands:

mov [a], reg1
mov [b], reg2
add reg1, reg2, reg3
mov reg3, [c]

and there is no benefit to a+=b vs c=a+b.

>> Some (questionable) sources that say a+=b generates faster machine
>> code than a=a+b, but I doubt that has been true in decades, if
>> ever.  Today, it's merely syntactic sugar.
> 
> It is more interesting when the left side is more complicated.
> 
>    x[(int)sqrt(y)]+=y;
> 
> but even if the time is the same, the convenience and more 
> readability not having to write the same thing twice.

Agreed, though I dislike such a complicated LHS and probably wouldn't
write that in the first place without a very good reason.

> That is, not having to verify when reading or changing it that
> both are exactly the same.
> 
> Seems that could apply for &&= and ||=, and even for ->=.

For the latter, any modern compiler would use CSE to turn this:

foo->bar->baz->quux = foo->bar->baz->quux->next;

into this:

tmp = foo->bar->baz->quux;
tmp = tmp->next;

(Ignore the lack of * or & where needed; it's pseudocode.)

That's what I'd write in the first place, simply because it's clearer to
the reader (if not the compiler) what is happening.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#77454

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Stephen Sprunk <stephen@sprunk.org> wrote:
> 
> > Some (questionable) sources that say a+=b generates faster machine code
> > than a=a+b, but I doubt that has been true in decades, if ever.  Today,
> > it's merely syntactic sugar.
> 
> It is more interesting when the left side is more complicated.
> 
>    x[(int)sqrt(y)]+=y;
> 
> but even if the time is the same, the convenience and more 
> readability not having to write the same thing twice.
> 
> That is, not having to verify when reading or changing it that
> both are exactly the same.

Not to mention not having side effects evaluated twice.

Whether it's good style to have side effects to the left of += is
another matter, but it does make a difference.

> Seems that could apply for &&= and ||=, and even for ->=.

And ditto here.

Richard

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

#77348

BartC <bc@freeuk.com> writes:
> On 28/11/2015 17:12, glen herrmannsfeldt wrote:
[...]
>> I have previously noted the absence of ||= and &&=, in some
>> cases using |= or &= in their place.
>
> || and && are also a little funny compared with normal ops.
>
> && for example takes two boolean operands and returns a boolean result.

&& takes two *scalar* operands and yields an *int* result with the value
0 or 1.  One or both operands are compared for inequality to zero.

But yes, the operands and result are what I call "logical boolean",
meaning that we normally care only whether they're zero (treated
as false) or non-zero (treated as true).

> An actual boolean operand would normally be 1 or 0, so that & could be 
> used instead.

An operand of type _Bool could only have the value 0 or 1 (barring
previous undefined behavior).  A scalar operand could have any zero
non-zero value.

> If an operand of && isn't already boolean 1 or 0, for example some 
> arbitrary integer value, then an expression such as (a &&= b) is 
> effectively changing how a is being used.

Presumably if you're evaluating `a &&= b` (or, in actual C, `a = a && b`),
you're already treating a as a "logically boolean" value.

    int cond = isdigit(foo);
    cond &&= isdigit(bar);

> Even if still within the type rules, there's something a bit off about 
> it. You wouldn't normally want to change a count into a boolean for example.

Then you wouldn't normally write `count &&= b`, just as you wouldn't
write `sqrt('x')`.

> The short-circult aspect doesn't help. And it's difficult to visualise 
> how &&= would map into a machine in-place operator as & or + would.

That's no different from the existing semantics of &&.  I'm not
sure what you mean when you say it "doesn't help"; in many ways,
it certainly does.

Mapping &&= to machine instructions is no more difficult than
mapping && to machine instructions -- and I'm content to let the
compiler do that for me.

> If a has a non-zero value, then it will always need to be replaced by 0 
> or 1 (depending on b); never just modified.

Yes.  Which is perfectly normal behavior for values used as conditions
in C.  I admit that C's treatment of zero as false and any non-zero
value as true is peculiar, but we've had several decades to deal with
it.  If you're not used to it by now, ....

Perl's && and || operators yield the value of the last operand
evaluated rather than just a 0/1 or false/true value.  That makes
them more flexible than C's operators -- but of course it's far too
late to change C.  Feel free to consider it for any new languages
you design.

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

#77350

On 28/11/2015 21:10, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:

> But yes, the operands and result are what I call "logical boolean",
> meaning that we normally care only whether they're zero (treated
> as false) or non-zero (treated as true).

The operands will either be 0 or 1 already (the result of == for 
example), or be some scalar value that is either going to be 0 (or 0.0 
or NULL), or /anything else/. The result will be 0 or 1.

That's why I'm saying there can be a mismatch between operands and 
result. In the proposed 'a &&= b', a is both operand and result.

> Presumably if you're evaluating `a &&= b` (or, in actual C, `a = a && b`),
> you're already treating a as a "logically boolean" value.
>
>      int cond = isdigit(foo);
>      cond &&= isdigit(bar);

If isdigit() returns 0 or 1, then there's no need to use && here; & will do.

(Perhaps it's easier to see my point if you imagine another language 
where the operands of && can be any type (strings, lists, etc where 
perhaps being non-empty counts as True).

Then in general, the result of 'a && b' is not going to be the same type 
as a, so 'a &&=b' would not be meaningful. In C, left operand and result 
might both be int, but that's all.)

> Perl's && and || operators yield the value of the last operand
> evaluated rather than just a 0/1 or false/true value.

Then Perl's && and || ops are different from C's and my concerns don't 
apply.

(I consider && and || (logical, non-bitwise 'and' and 'or') to be 
important operators in conditions: if (a=b && b<10). Here the actual 
result of &&, even if notionally a boolean, is not of interest; it just 
determines program flow. (Usually the 0 or 1 result doesn't even get 
evaluated beyond testing condition flags.)

But when used for its value, as in c = a && b, then the way Perl handles 
that can be useful. That's a different enough usage however that I would 
question using the same && and || operators.)

-- 
Bartc

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

#77385

BartC <bc@freeuk.com> wrote:

> On 28/11/2015 21:10, Keith Thompson wrote:
> > BartC <bc@freeuk.com> writes:
> 
> > But yes, the operands and result are what I call "logical boolean",
> > meaning that we normally care only whether they're zero (treated
> > as false) or non-zero (treated as true).
> 
> The operands will either be 0 or 1 already (the result of == for 
> example), or be some scalar value that is either going to be 0 (or 0.0 
> or NULL), or /anything else/. The result will be 0 or 1.
> 
> That's why I'm saying there can be a mismatch between operands and 
> result. In the proposed 'a &&= b', a is both operand and result.

But you haven't explained how this is different from the currently
perfectly acceptable

  a = a && b;

Richard

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

#77393

On 29/11/2015 11:42, Richard Bos wrote:
> BartC <bc@freeuk.com> wrote:
>
>> On 28/11/2015 21:10, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>> But yes, the operands and result are what I call "logical boolean",
>>> meaning that we normally care only whether they're zero (treated
>>> as false) or non-zero (treated as true).
>>
>> The operands will either be 0 or 1 already (the result of == for
>> example), or be some scalar value that is either going to be 0 (or 0.0
>> or NULL), or /anything else/. The result will be 0 or 1.
>>
>> That's why I'm saying there can be a mismatch between operands and
>> result. In the proposed 'a &&= b', a is both operand and result.
>
> But you haven't explained how this is different from the currently
> perfectly acceptable
>
>    a = a && b;

It might be legal but it's probably not a common construction (c = a && 
b is more likely), unless a already has the value 0 or 1. Then it can 
also be expressed as:

    a = a & !!b;

which becomes:

    a &= !!b;

So it would be useful in this arrow case to avoid using !!.

As an example:

  double x,y;

  x = x && y;

is legal. But would be a strange piece of code.

Also, &&= isn't just syntactic sugar with no real cost. Some effort is 
needed to ensure that the left-hand-side of &&= is only evaluated once. 
And the short-circuit characteristics mean you need dedicated 
implementation code as it is different from other operators.

There is perhaps a case for orthogonality to be made by allowing 
compound versions of all the binary operators (and the unary ones, which 
I've seen). But binary operators include == and <=, and those would look 
extremely odd:

   a === b;
   a <== b;

So, using your argument, since these are equivalent to the perfectly legal:

   a = a==b;
   a = a<=b;

why shouldn't these new compound operators be added too?

(The unary compound operators I've seen work with negative and abs 
(which was an operator), logical and bitwise 'not'. In C they might look 
like this:

   -= a;       // a = -a
   != a;       // a = !a
   ~= a;       // a = ~a

But += a is not so useful for obvious reasons. While *= a (a=*a) and &= 
a (a = &a), wouldn't work because the result would be the wrong type.)

-- 
Bartc

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

#77397 — Re: "->="

On 11/29/2015 10:16 AM, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>>> a = a && b;
>> It might be legal but it's probably not a common construction (c = a &&
>
> int exitStrategy()
> { int success = 1;
>    success = success && openTheWindow();
>    success = success && lookOutOfTheOpenedWindow();
>    success = success && leaveTheRoomByTheOpenedWindow();
>    return success; }
>
>    This will ensure that
>
>      - each step only is attempted as long as all of the
>        preceding attempts succeeded, and
>
>      - the return value indicates overall success.

	int exitStrategy(void) {
	    return openTheWindow()
	        && lookOutOfTheOpenedWindow()
	        && leaveTheRoomByTheOpenedWindow();
	}

"... beautiful new impediments to understanding."
-- from the Seventh Commandment for C Programmers

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#77402 — Re: "->="

On 29/11/2015 15:16, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>>> a = a && b;
>> It might be legal but it's probably not a common construction (c = a &&
>
> int exitStrategy()
> { int success = 1;
>    success = success && openTheWindow();
>    success = success && lookOutOfTheOpenedWindow();
>    success = success && leaveTheRoomByTheOpenedWindow();
>    return success; }

You snipped my: "unless a already has the value 0 or 1", which it has 
here. I then go onto say you can then use: "a = a & !!b", at which point 
someone could have pointed that this doesn't have the same short-circuit 
semantics as &&.

That would then make a good argument for having &&= (and ||=).

(That doesn't mean I have to like it though!)

-- 
Bartc

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

#77406

On Sunday, November 29, 2015 at 8:24:21 AM UTC-6, Bart wrote:
> There is perhaps a case for orthogonality to be made by allowing 
> compound versions of all the binary operators (and the unary ones, which 
> I've seen). But binary operators include == and <=, and those would look 
> extremely odd:
> 
>    a === b;
>    a <== b;

The mention of <== brings up an interesting point, which is that like the
short-circuit boolean operators, the relational operators have a sensible
"related" compound operator, but as with the short-circuit boolean operators
the pattern would be different from normal compound operators.

As I see it, the sensible pattern for relational and short-circuit operators
would be "if (rhs satisfies condition) lhs=rhs;".  While I I'm not sure how
such things should be done syntactically, I think it would be useful to have
compound operators which perform:

   if (a < b) a=b;
   if (a > b) a=b;
   if (!b) a=b; // Not evaluating expressions within a if b is not zeroish
   if (b) a=b; // Not evaluating expressions within a if b is zeroish

Note that no existing operators behave in those ways [IMHO, && and || should
have yielded the last-evaluated value, rather than coercing to integer 1
and integer 0; such behavior would have been both more efficient for
compilers and more useful] but that doesn't mean that operators that
conditionally modify the lhs wouldn't be useful.

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

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

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

csiph-web