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

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

solution allocation of memory and composite numbers

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

Contents

  solution allocation of memory and composite numbers Dexterr <dejangru@gmail.com> - 2014-12-24 05:52 -0800
    Re: solution allocation of memory and composite numbers Dexterr <dejangru@gmail.com> - 2014-12-24 05:55 -0800
      Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 06:41 -0800
        Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 20:16 +0000
          Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:39 -0800
            Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 21:22 +0000
              Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 22:33 +0000
                Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-25 00:54 +0000
                  Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 18:38 -0800
                  Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-25 12:07 +0100
                  Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-26 22:05 +0000
                    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-26 22:33 +0000
                      Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-27 22:08 +0000
                        Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-27 23:28 +0000
                        Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-29 18:34 +0000
                          Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-30 19:23 +0000
                    Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-26 15:43 -0800
                      Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-26 15:59 -0800
                      Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-27 14:45 +0100
                      Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-27 21:55 +0000
                        Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 14:07 -0800
                          Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-27 23:44 +0100
                            Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 15:49 -0800
                            Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 21:52 -0800
                              Re: solution allocation of memory and composite numbers Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-28 15:54 +0100
                          Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-28 00:03 +0000
                    Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-26 17:13 -0800
                      Re: solution allocation of memory and composite numbers Geoff <geoff@invalid.invalid> - 2014-12-27 10:23 -0800
                        Re: solution allocation of memory and composite numbers Stephen Sprunk <stephen@sprunk.org> - 2014-12-27 13:03 -0600
                          Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 12:24 -0800
                        Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 12:23 -0800
                        Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-27 13:31 -0800
                        Re: solution allocation of memory and composite numbers Öö Tiib <ootiib@hot.ee> - 2014-12-27 18:42 -0800
                          Re: solution allocation of memory and composite numbers Keith Thompson <kst-u@mib.org> - 2014-12-27 22:07 -0800
                        Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-30 19:26 +0000
                          Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 20:01 +0000
                            Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 12:18 -0800
                              Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 21:15 +0000
                                Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 13:49 -0800
                                  Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 22:03 +0000
                                    Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 23:57 +0000
                                Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-30 22:35 +0000
                            Re: solution allocation of memory and composite numbers Dr Nick <nospam-4@temporary-address.org.uk> - 2014-12-31 12:24 +0000
                              Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-31 17:08 +0000
                                Re: solution allocation of memory and composite numbers Dr Nick <nospam-4@temporary-address.org.uk> - 2014-12-31 17:37 +0000
                        Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 20:09 +0000
                          Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 12:24 -0800
                            Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2014-12-30 21:28 +0000
                              Re: solution allocation of memory and composite numbers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-30 13:53 -0800
                                Re: solution allocation of memory and composite numbers Kaz Kylheku <kaz@kylheku.com> - 2015-01-04 02:22 +0000
                        Re: solution allocation of memory and composite numbers Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2014-12-31 13:32 +0100
                    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-27 01:37 +0000
                    Re: solution allocation of memory and composite numbers raltbos@xs4all.nl (Richard Bos) - 2014-12-27 12:19 +0000
                      Re: solution allocation of memory and composite numbers gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-27 14:39 +0000
            Re: solution allocation of memory and composite numbers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-24 22:29 +0000
      Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-24 15:05 +0000
    Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 16:55 +0000
      iso646.h Noob <root@127.0.0.1> - 2014-12-25 18:26 +0100
        Re: iso646.h Geoff <geoff@invalid.invalid> - 2014-12-25 18:31 -0800
          Re: iso646.h Noob <root@127.0.0.1> - 2014-12-26 18:23 +0100
        Re: iso646.h Keith Thompson <kst-u@mib.org> - 2014-12-25 21:31 -0800
          Re: iso646.h fir <profesor.fir@gmail.com> - 2014-12-26 09:42 -0800
    Re: solution allocation of memory and composite numbers Barry Schwarz <schwarzb@dqel.com> - 2014-12-24 09:06 -0800
    Re: solution allocation of memory and composite numbers Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 16:59 +0000
    Re: solution allocation of memory and composite numbers BartC <bc@freeuk.com> - 2014-12-24 17:26 +0000
      Re: solution allocation of memory and composite numbers asetofsymbols@gmail.com - 2014-12-24 11:42 -0800

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

#55517

On Saturday, December 27, 2014 9:55:57 PM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> What would you suggest in place of
> 
>   if (scanf("%d", &number) == 1)
> 
> in an introductory C course?
> 
Teach them to pass options on the commandline rather than trying
a dialogue with the user via stdin / stdout. That's how real programs
usually work, and it's less frustrating, as programming a computer
to talk is most definitely not C programming 101.

atoi() should be fine. If the number of parameters is wrong or the
numbers are out of range, it's easy and natural to put in the
checks. It also leads to a small "how can we tighten this up" lesson
which introduces strtol() / strtod().

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

#55519

Il 27/12/2014 23:07, Malcolm McLean ha scritto:
..
> atoi() should be fine. If the number of parameters is wrong or the
> numbers are out of range, it's easy and natural to put in the
> checks. [..]

atoi() is not guaranteed to set errno on error either and like
scanf() has undefined behavior when the value of the result
cannot be represented.

-- 
Vincenzo Mercuri

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

#55526

On Saturday, December 27, 2014 10:44:21 PM UTC, Vincenzo Mercuri wrote:
> Il 27/12/2014 23:07, Malcolm McLean ha scritto:
> ..
> > atoi() should be fine. If the number of parameters is wrong or the
> > numbers are out of range, it's easy and natural to put in the
> > checks. [..]
> 
> atoi() is not guaranteed to set errno on error either and like
> scanf() has undefined behavior when the value of the result
> cannot be represented.
> 
I know.
But the command line interpreter splits up all the graphical characters
into strings. So after the student has got something working with atoi,
the next step, which is for the instructor to say "and what happens
if the user passes a really huge value, like 1000000000000000000000?"
is much more tractable. He's got the clipped string with a nice nul
at the end, guaranteed in memory.

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

#55533

Vincenzo Mercuri <nomail@yahoo.it> writes:
> Il 27/12/2014 23:07, Malcolm McLean ha scritto:
> ..
>> atoi() should be fine. If the number of parameters is wrong or the
>> numbers are out of range, it's easy and natural to put in the
>> checks. [..]
>
> atoi() is not guaranteed to set errno on error either and like
> scanf() has undefined behavior when the value of the result
> cannot be represented.

You're right about the undefined behavior.  Somehow I had managed to
miss that.  The lesson is, when checking the standard, to check the
parent section for the function you're looking up as well as the section
that describes the function itself.

In this case, N1570 7.22.1.2 describes atoi, atol, and atoll, and says:

    Except for the behavior on error, they are equivalent to ...

followed by calls to strtol and stroll.  For atoi, the equivalent is:

    (int)strtol(nptr, (char **)NULL, 10)

But the parent section, 7.22.1, says:

    The functions atof, atoi, atol, and atoll need not affect the
    value of the integer expression errno on an error. If the value
    of the result cannot be represented, the behavior is undefined.

(And if I'm the only one who didn't notice that, congratulations to
everyone else for being more observant than me.)

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

#55549

Il 28/12/2014 06:52, Keith Thompson ha scritto:
> Vincenzo Mercuri <nomail@yahoo.it> writes:
>> Il 27/12/2014 23:07, Malcolm McLean ha scritto:
>> ..
>>> atoi() should be fine. If the number of parameters is wrong or the
>>> numbers are out of range, it's easy and natural to put in the
>>> checks. [..]
>>
>> atoi() is not guaranteed to set errno on error either and like
>> scanf() has undefined behavior when the value of the result
>> cannot be represented.
>
> You're right about the undefined behavior.  Somehow I had managed to
> miss that.  The lesson is, when checking the standard, to check the
> parent section for the function you're looking up as well as the section
> that describes the function itself.
>
> In this case, N1570 7.22.1.2 describes atoi, atol, and atoll, and says:
>
>      Except for the behavior on error, they are equivalent to ...
>
> followed by calls to strtol and stroll.  For atoi, the equivalent is:
>
>      (int)strtol(nptr, (char **)NULL, 10)
>

That's exactly the part I first read as well, and I was just too curious
to find out what the behavior of atoi() could be for values that cannot
be represented. Luckily enough, the answer was there at the beginning
of the same page :)

> But the parent section, 7.22.1, says:
>
>      The functions atof, atoi, atol, and atoll need not affect the
>      value of the integer expression errno on an error. If the value
>      of the result cannot be represented, the behavior is undefined.
>
> (And if I'm the only one who didn't notice that, congratulations to
> everyone else for being more observant than me.)
>

-- 
Vincenzo Mercuri

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

#55528

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Saturday, December 27, 2014 9:55:57 PM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> What would you suggest in place of
>> 
>>   if (scanf("%d", &number) == 1)
>> 
>> in an introductory C course?
>> 
> Teach them to pass options on the commandline rather than trying
> a dialogue with the user via stdin / stdout.

Yes, that works, though it does not scale particularly well.

<snip>
-- 
Ben.

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

#55470

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>>The experience I have of the trouble beginners have with scanf tells me
>>that it's not as bad as you seem to suggest (what else could I have
>>meant?).  It doesn't seem to me to "astoundingly difficult" to use
>>safely and correctly.
>
>   One could give as a recipe that to read an int value i 
>   the students should use this snippet:
>
> if( 1 == scanf( "%d", &i ))

Personally, I would never advise beginners to write their equality tests
backwards like that.  There's some risk I might have to read their code
some day.

[...]

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

#55501

On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>>>The experience I have of the trouble beginners have with scanf tells me
>>>that it's not as bad as you seem to suggest (what else could I have
>>>meant?).  It doesn't seem to me to "astoundingly difficult" to use
>>>safely and correctly.
>>
>>   One could give as a recipe that to read an int value i 
>>   the students should use this snippet:
>>
>> if( 1 == scanf( "%d", &i ))
>
>Personally, I would never advise beginners to write their equality tests
>backwards like that.  There's some risk I might have to read their code
>some day.
>

Some shops require it. There's a very good reason for doing it that
way, namely the = vs == bug in conditionals.

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

#55502

On 27-Dec-14 12:23, Geoff wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> if( 1 == scanf( "%d", &i ))
>> 
>> Personally, I would never advise beginners to write their equality
>> tests backwards like that.  There's some risk I might have to read
>> their code some day.
> 
> Some shops require it. There's a very good reason for doing it that 
> way, namely the = vs == bug in conditionals.

If your compiler/lint doesn't warn about "if (x=1)", then it's time to
upgrade to a better one.  If you really did want an assignment there,
"if ((x=1)!=0)" should silence the warning.

This strikes me as similar to telling students to use "++i;" rather than
"i++;" or "x<<3" rather than "x*8" because the former are allegedly
faster, even though they're less clear and less idiomatic.

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]

#55509

Stephen Sprunk <stephen@sprunk.org> writes:
> On 27-Dec-14 12:23, Geoff wrote:
>> Keith Thompson <kst-u@mib.org> wrote:
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>> if( 1 == scanf( "%d", &i ))
>>> 
>>> Personally, I would never advise beginners to write their equality
>>> tests backwards like that.  There's some risk I might have to read
>>> their code some day.
>> 
>> Some shops require it. There's a very good reason for doing it that 
>> way, namely the = vs == bug in conditionals.
>
> If your compiler/lint doesn't warn about "if (x=1)", then it's time to
> upgrade to a better one.  If you really did want an assignment there,
> "if ((x=1)!=0)" should silence the warning.

Typically

    if ((x = 1))

will silence the warning.  I wouldn't write "if ((x=1) != 0)"; I
personally find that uglier than "if (1==x)".  (Yes, I know they have
different semantics; I'm comparing their esthetics, not their
semantics.)

> This strikes me as similar to telling students to use "++i;" rather than
> "i++;" or "x<<3" rather than "x*8" because the former are allegedly
> faster, even though they're less clear and less idiomatic.

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

#55508

Geoff <geoff@invalid.invalid> writes:
> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>>The experience I have of the trouble beginners have with scanf tells me
>>>>that it's not as bad as you seem to suggest (what else could I have
>>>>meant?).  It doesn't seem to me to "astoundingly difficult" to use
>>>>safely and correctly.
>>>
>>>   One could give as a recipe that to read an int value i 
>>>   the students should use this snippet:
>>>
>>> if( 1 == scanf( "%d", &i ))
>>
>>Personally, I would never advise beginners to write their equality tests
>>backwards like that.  There's some risk I might have to read their code
>>some day.
>
> Some shops require it. There's a very good reason for doing it that
> way, namely the = vs == bug in conditionals.

I'm grateful that I don't work at such a shop.

I'm aware of the rationale for backwards comparisons, and yes,
I suppose it can catch some bugs if the compiler doesn't issue
a warning.  And yes, I *can* read a backwards comparison and
understand what it means.  I just find it jarring and ugly.

If I were designing C from scratch, I'd probably use "=" for
comparison and ":=" for assignment.  IIRC Ritchie decided to use
"=" for assignment and "==" for comparison because the more common
operation should have a shorter symbol -- which is an interesting
approach, but IMHO it's turned out to be a poor choice.  Of course
we're stuck with it 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]

#55512

On Saturday, December 27, 2014 6:23:58 PM UTC, Geoff wrote:
> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
>
> >> if( 1 == scanf( "%d", &i ))
> >
> >Personally, I would never advise beginners to write their equality tests
> >backwards like that.  There's some risk I might have to read their code
> >some day.
> >
> 
> Some shops require it. There's a very good reason for doing it that
> way, namely the = vs == bug in conditionals.
>
Programmers often think like that.

There's constantly an attempt to set up the machine so that it catches
errors, e.g. const, mandatory casting, and, in other languages, whole
systems of signature enforcement. Writing comparisons backwards is
an example.

But it's doomed to failure. Machines can pick up some errors, but they
simply aren't clever enough to see what a program ought to be doing,
as opposed to what it does do. Humans, and not automated systems, 
need the ideal working environment, so they can write code which is
clutter-free and expresses the logic as naturally as possible.

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

#55531

On Saturday, December 27, 2014 8:23:58 PM UTC+2, Geoff wrote:
> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
> 
> >ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >
> >>>The experience I have of the trouble beginners have with scanf tells me
> >>>that it's not as bad as you seem to suggest (what else could I have
> >>>meant?).  It doesn't seem to me to "astoundingly difficult" to use
> >>>safely and correctly.
> >>
> >>   One could give as a recipe that to read an int value i 
> >>   the students should use this snippet:
> >>
> >> if( 1 == scanf( "%d", &i ))
> >
> >Personally, I would never advise beginners to write their equality tests
> >backwards like that.  There's some risk I might have to read their code
> >some day.
> >
> 
> Some shops require it. There's a very good reason for doing it that
> way, namely the = vs == bug in conditionals.

The "bug" does not compile anyway on current case:

    if( scanf( "%d", &i ) = 1 )

So the reason must be something else.

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

#55534

Öö Tiib <ootiib@hot.ee> writes:
> On Saturday, December 27, 2014 8:23:58 PM UTC+2, Geoff wrote:
>> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
>> >ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> >
>> >>>The experience I have of the trouble beginners have with scanf tells me
>> >>>that it's not as bad as you seem to suggest (what else could I have
>> >>>meant?).  It doesn't seem to me to "astoundingly difficult" to use
>> >>>safely and correctly.
>> >>
>> >>   One could give as a recipe that to read an int value i 
>> >>   the students should use this snippet:
>> >>
>> >> if( 1 == scanf( "%d", &i ))
>> >
>> >Personally, I would never advise beginners to write their equality tests
>> >backwards like that.  There's some risk I might have to read their code
>> >some day.
>> >
>> 
>> Some shops require it. There's a very good reason for doing it that
>> way, namely the = vs == bug in conditionals.
>
> The "bug" does not compile anyway on current case:
>
>     if( scanf( "%d", &i ) = 1 )
>
> So the reason must be something else.

I think it's the same reason, combined with a perfectly appropriate
desire for consistency.

If I assume for the sake of argument that, for example, (42 == n)
is better than (n == 42), then it makes sense to cultivate the habit
of *always* putting the constant on the left side of a comparison --
even if the RHS isn't an lvalue, or if the operator is something
other than "==".

Given that the purpose of the convention is to avoid "==" vs. "="
errors, the idea is that it avoids such errors *without having to
stop and think about it*.  The point is to use the safer version
because it's a habit.  If you have to stop and think about which
cases are made safer by putting the constant on the left, then that
same mental effort will remind you to use "==" and not "=".

There are similar habits I've cultivated myself because they're
easier than thinking about each instance.  I always avoid defining
identifiers starting with an underscore rather than thinking
about which such identifiers I can use safely in which contexts.
I always use { and } on selection and iteration statements rather
than thinking about when they're not needed.

"Yoda conditions" <http://en.wikipedia.org/wiki/Yoda_conditions>
are in much the same spirit.  The main difference is that I Don't
Like Them.

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

#55595

Geoff <geoff@invalid.invalid> wrote:

> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
> >ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >
> >> if( 1 == scanf( "%d", &i ))
> >
> >Personally, I would never advise beginners to write their equality tests
> >backwards like that.  There's some risk I might have to read their code
> >some day.
> 
> Some shops require it. There's a very good reason for doing it that
> way, namely the = vs == bug in conditionals.

That bug is a very good reason _not_ to use this hack. Try it when both
operands are variables... introducing a bug in _some_ of your
comparisons while at the same time giving yourself a false feeling of
security is a very good way to create more, not fewer, bugs. Teach them,
rather, to pay attention to what they're writing. They'll need it
anyway; this trick only makes not paying attention _more_, not less
likely.

Richard

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

#55597

On 2014-12-30, Richard Bos <raltbos@xs4all.nl> wrote:
> Geoff <geoff@invalid.invalid> wrote:
>
>> On Fri, 26 Dec 2014 17:13:47 -0800, Keith Thompson <kst-u@mib.org>
>> >ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> >
>> >> if( 1 == scanf( "%d", &i ))
>> >
>> >Personally, I would never advise beginners to write their equality tests
>> >backwards like that.  There's some risk I might have to read their code
>> >some day.
>> 
>> Some shops require it. There's a very good reason for doing it that
>> way, namely the = vs == bug in conditionals.
>
> That bug is a very good reason _not_ to use this hack. Try it when both
> operands are variables... introducing a bug in _some_ of your

Huh? When both operands are variables, the conding convention doesn't apply.
So it provides neither benfit, nor harm.

If either of the variables is const-qualified, then conforming with
the convention means making that one the left operand, in which case
it provides the guard against accidental use of = instead of ==.

> comparisons while at the same time giving yourself a false feeling of
> security is a very good way to create more, not fewer, bugs.

That's more of an argument against having a feeling, not against the practice.

Any tool which promotes safety can give you a feeling of security, such
as, for instance, a type system that is statically checked.

That such things give us some sense of confidence is normal. It is reasonable
to have more confidence when there are more safeguards, if it is in rational
proportion to the power and scope of those safeguards.

> Teach them,
> rather, to pay attention to what they're writing.

What if pride in one's meticulous attention to what you're writing
gives rise to a *feeling* of security? Oops, same problem.

They'll need it
> anyway; this trick only makes not paying attention _more_, not less
> likely.

How so; you have to consciously apply it.  "I find myself
writing an equality comparison.  Which, if any, of the operands is
unmodifiable, that I may make it the left one?"

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

#55600

On Tuesday, December 30, 2014 8:01:38 PM UTC, Kaz Kylheku wrote:
> On 2014-12-30, Richard Bos <raltbos@xs4all.nl> wrote:
> 
> > That bug is a very good reason _not_ to use this hack. Try it when both
> > operands are variables... introducing a bug in _some_ of your
> 
> Huh? When both operands are variables, the conding convention doesn't apply.
> So it provides neither benfit, nor harm.
> 
The reason for not doing it is that it makes the code harder to read.

You can still read it, just as if you write without capitals or in d00d-spk text is
still comprehensible. But it makes it harder to spot logic errors when scanning code.

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

#55602

On 2014-12-30, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Tuesday, December 30, 2014 8:01:38 PM UTC, Kaz Kylheku wrote:
>> On 2014-12-30, Richard Bos <raltbos@xs4all.nl> wrote:
>> 
>> > That bug is a very good reason _not_ to use this hack. Try it when both
>> > operands are variables... introducing a bug in _some_ of your
>> 
>> Huh? When both operands are variables, the conding convention doesn't apply.
>> So it provides neither benfit, nor harm.
>> 
> The reason for not doing it is that it makes the code harder to read.
>
> You can still read it, just as if you write without capitals or in d00d-spk text is
> still comprehensible. But it makes it harder to spot logic errors when scanning code.

How so? Equality is a symmetric property. (foo == bar) means exactly
the same thing as (bar == foo).

If this kind of difference trips you up, you are not really reading
the code properly for its semantics.

If you're not really reading for semantics, you will not find errors.

In any case, code which follows a convention in this regard can reasonably
be expected to be *consistent*: to do it the same way everywhere.

So if you want to be able to tune out and unconsciously pass your eyes over
code, so that only strange-looking construct generate an alert,
that just requires a bit of re-training for this reversed convention.

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

#55605

On Tuesday, December 30, 2014 9:15:44 PM UTC, Kaz Kylheku wrote:
> 
> How so? Equality is a symmetric property. (foo == bar) means exactly
> the same thing as (bar == foo).
>
Not in natural language. "If the gradient of the line equals zero" can't
be replaced by "*if zero equals the gradient of the line".

You can say "if the gradient of the line equals our epsilon" or "if
our epsilon equals the gradient of the line", but they don't mean the
same thing. In the first case, the epsilon is a given and the line
varies, in the second, we're obviously considering making a change to
the epsilon.
>
> So if you want to be able to tune out and unconsciously pass your 
> eyes over code, so that only strange-looking construct generate an alert,
> that just requires a bit of re-training for this reversed convention.
>
If everyone consistently wrote so that constant terms were on the
right hand side of an equality sign, then that would be the case. 
But the world isn't going to change just to patch up a deficiency
in a programming language.

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

#55609

On 2014-12-30, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Tuesday, December 30, 2014 9:15:44 PM UTC, Kaz Kylheku wrote:
>> 
>> How so? Equality is a symmetric property. (foo == bar) means exactly
>> the same thing as (bar == foo).
>>
> Not in natural language. "If the gradient of the line equals zero" can't
> be replaced by "*if zero equals the gradient of the line".

Both are correct grammar and semantically equivalent. The second one
fails to be euphonic, which is just an esthetic judgment.

There is nothing wrong with a constant like "zero" being on the left of
"equals", because that is in fact necessary for sentences like:
"zero equals zero".

Lack of euphony in speaking won't raise an eyebrow among the kinds of
dweebs that discuss gradients of lines. Awkward speech goes hand in hand
with awkward behavior.

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

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

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

csiph-web