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

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

nested while loop computing triangular number - issues

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

Contents

  nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-11 06:31 -0700
    Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-11 06:52 -0700
    Re: nested while loop computing triangular number - issues Siri Cruz <chine.bleu@yahoo.com> - 2015-07-11 07:07 -0700
      Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-11 07:27 -0700
        Re: nested while loop computing triangular number - issues Siri Cruz <chine.bleu@yahoo.com> - 2015-07-11 08:19 -0700
    Re: nested while loop computing triangular number - issues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 15:28 +0100
      Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-11 08:01 -0700
        Re: nested while loop computing triangular number - issues James Kuyper <jameskuyper@verizon.net> - 2015-07-11 12:24 -0400
        Re: nested while loop computing triangular number - issues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 21:24 +0100
          Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-12 09:35 -0700
            Re: nested while loop computing triangular number - issues Keith Thompson <kst-u@mib.org> - 2015-07-12 11:55 -0700
              Re: nested while loop computing triangular number - issues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 22:14 +0100
              Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-13 08:05 -0700
      Re: nested while loop computing triangular number - issues David Kleinecke <dkleinecke@gmail.com> - 2015-07-11 10:51 -0700
        Re: nested while loop computing triangular number - issues Keith Thompson <kst-u@mib.org> - 2015-07-11 14:56 -0700
          Re: nested while loop computing triangular number - issues David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 09:32 -0700
            Re: nested while loop computing triangular number - issues James Kuyper <jameskuyper@verizon.net> - 2015-07-12 13:19 -0400
              Re: nested while loop computing triangular number - issues David Kleinecke <dkleinecke@gmail.com> - 2015-07-13 10:16 -0700
            Re: nested while loop computing triangular number - issues Keith Thompson <kst-u@mib.org> - 2015-07-12 11:48 -0700
              Re: nested while loop computing triangular number - issues James Kuyper <jameskuyper@verizon.net> - 2015-07-12 15:23 -0400
              Re: nested while loop computing triangular number - issues Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 11:02 -0700
                Re: nested while loop computing triangular number - issues Keith Thompson <kst-u@mib.org> - 2015-07-15 13:19 -0700
                  Re: nested while loop computing triangular number - issues Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 11:01 -0700
    Re: nested while loop computing triangular number - issues Alla _ <modelling.data@gmail.com> - 2015-07-11 08:45 -0700

Page 2 of 2 — ← Prev page 1 [2]

#65643

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

> [snip]
>
> Incidentally, one thing I dislike about compound literals is
> that the storage duration of the object depends only on the
> context in which it appears.  A string literal always creates an
> array object with static storage duration.  A compound literal
> creates an object with static storage duration if it occurs
> outside a function, or with automatic storage duration if it
> occurs inside a function.  [snip] there are times it would be
> convenient to have a block-scope compound literal that refers to
> a static object.
>
> I might suggest an enhancement that permits something like:
>
>     (static struct foo){1, 0, 1, 0};
>
> at block scope.  (Of course non-constant expressions would not
> be permitted.)

I don't know why you think this would be useful.  If the value is
used only for its value (ie, and the address is not taken),
simply leave off the 'static' and let the compiler notice that
the value can be initialized and kept statically.  If the address
is made use of, but the contents are not modified, writing the
compound literal with 'const' in the type should let the compiler
notice that the value can be allocated statically as well (ie,
even though there was no mention of 'static').  If the address is
made use of, and the contents are modified, then the object in
question could not be allocated statically without changing the
semantics, but that situation seems rather bizarre, or at least
extremely rare.  ISTM that adding a construct like you suggest is
not worth the very few situations (offhand I can't think of any)
where it would be useful, especially since there is such an easy
and obvious alternative.  Furthermore I would claim that the
situation where it is important to modify a static object in
such cases (where there is only _one_ textual reference to the
object in question) are unexpected enough so it would be worth
having a separate identifier rather than burying the value in
the middle of another expression.

I guess there is an exception to the above for compound literals
that appear within the initializer of a static object declared
(and defined) inside a function body, which hadn't occurred to me
before.  Without having thought about it too deeply, I expect it
would be easier just to make a rule than any compound literal
declared within an initializer of a static declared/defined
inside a function should be given static storage duration
automatically, just like what happens with those outside of any
function body, otherwise the declaration is going to fail anyway
because the value is not constant.  Right?

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

#65652

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> [snip]
>>
>> Incidentally, one thing I dislike about compound literals is
>> that the storage duration of the object depends only on the
>> context in which it appears.  A string literal always creates an
>> array object with static storage duration.  A compound literal
>> creates an object with static storage duration if it occurs
>> outside a function, or with automatic storage duration if it
>> occurs inside a function.  [snip] there are times it would be
>> convenient to have a block-scope compound literal that refers to
>> a static object.
>>
>> I might suggest an enhancement that permits something like:
>>
>>     (static struct foo){1, 0, 1, 0};
>>
>> at block scope.  (Of course non-constant expressions would not
>> be permitted.)
>
> I don't know why you think this would be useful.  If the value is
> used only for its value (ie, and the address is not taken),
> simply leave off the 'static' and let the compiler notice that
> the value can be initialized and kept statically.  If the address
> is made use of, but the contents are not modified, writing the
> compound literal with 'const' in the type should let the compiler
> notice that the value can be allocated statically as well (ie,
> even though there was no mention of 'static').

[...]

I was thinking of compound literals as analogous to string literals.

It's certainly useful to be able to assign a string literal to a
`const char*` object, and for that string to continue to exist outside
the scope in which it appears.

    {
        ...
        obj->name = "Fred";
        ...
    }

It would be awkward of the char array containing "Fred" were to vanish
at the closing brace.  I can imagine something similar for, say, a
structure rather than a character array.

I don't have a concrete example off the top of my head -- and a
non-const static object could cause problems if you're not careful.

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

#66033

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> [snip]
>>>
>>> Incidentally, one thing I dislike about compound literals is
>>> that the storage duration of the object depends only on the
>>> context in which it appears.  A string literal always creates an
>>> array object with static storage duration.  A compound literal
>>> creates an object with static storage duration if it occurs
>>> outside a function, or with automatic storage duration if it
>>> occurs inside a function.  [snip] there are times it would be
>>> convenient to have a block-scope compound literal that refers to
>>> a static object.
>>>
>>> I might suggest an enhancement that permits something like:
>>>
>>>     (static struct foo){1, 0, 1, 0};
>>>
>>> at block scope.  (Of course non-constant expressions would not
>>> be permitted.)
>>
>> I don't know why you think this would be useful.  If the value is
>> used only for its value (ie, and the address is not taken),
>> simply leave off the 'static' and let the compiler notice that
>> the value can be initialized and kept statically.  If the address
>> is made use of, but the contents are not modified, writing the
>> compound literal with 'const' in the type should let the compiler
>> notice that the value can be allocated statically as well (ie,
>> even though there was no mention of 'static').
>
> [...]
>
> I was thinking of compound literals as analogous to string literals.
>
> It's certainly useful to be able to assign a string literal to a
> `const char*` object, and for that string to continue to exist outside
> the scope in which it appears.
>
>     {
>         ...
>         obj->name = "Fred";
>         ...
>     }
>
> It would be awkward of the char array containing "Fred" were to vanish
> at the closing brace.  I can imagine something similar for, say, a
> structure rather than a character array.
>
> I don't have a concrete example off the top of my head -- and a
> non-const static object could cause problems if you're not careful.

I see.  So there are (or at least probably are) some
plausible use cases, even if we can't think of one
right at the moment.

Despite that I still think that the utility is sufficiently
small so that there is no reason to add a new construct
to the language, since the cost of declaring a static
variable is pretty small, and even could be seen as a benefit,
forcing a name to be chosen for the value in question.

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

#65297

oh, I got it! I had to initialize both n and triangular number right before the second, inner while loop. 
// nested while loop to prompt the user to name 5 ∆numbers
#include <stdio.h>

int main (void)
{
    int n, number, triangular_number, counter;
    counter = 1;
            
    while ( counter <= 5 )
    {
        printf ("Please, name your triangular number:  ");
        scanf  ("%i", &number);
        ++counter;
        
        triangular_number = 0;
        n = 1;
        
        while ( n <= number )
        {
           triangular_number += n;
           ++n;
        }
        
        printf ("The triangular number %i is %i\n", number, triangular_number);        
     }
    
    return 0;
}

now it works :)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web