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

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

How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]);

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

Contents

  How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-30 11:35 +0530
    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-30 11:39 +0530
      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 22:24 -0800
        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:56 +0000
          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:40 -0800
            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-03 21:09 +0000
              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 16:30 -0800
    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2016-12-29 23:35 -0800
    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); jt@toerring.de (Jens Thoms Toerring) - 2016-12-30 09:59 +0000
      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 10:43 +0000
        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 12:55 +0000
          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 13:12 +0000
            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:37 +0000
              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 16:06 +0000
                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2016-12-30 08:41 -0800
                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 17:31 +0000
                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 19:20 +0000
                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 19:41 +0000
                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 12:46 -0800
                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:31 +0000
                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 11:50 -0800
                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:54 +0000
                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 11:35 +0000
                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 12:00 +0000
                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 12:16 +0000
                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 13:03 +0000
                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 14:52 +0000
                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:42 +0000
                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 16:14 +0000
                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:18 +0000
                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:09 -0800
                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-01 19:24 +0100
                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); bart4858@gmail.com - 2017-01-01 11:24 -0800
                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 20:05 +0000
                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:11 -0800
                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 22:25 +0000
                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:00 +0100
                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:51 -0800
                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 21:59 +0000
                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 14:34 -0800
                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:09 +0100
                                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 05:44 -0800
                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 15:18 +0100
                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-02 15:21 +0000
                                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 17:07 +0100
                                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 09:53 -0800
                                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 23:37 +0100
                                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:07 -0800
                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 12:11 +1300
                                                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:46 -0800
                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 00:54 +0100
                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 00:33 -0800
                                                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:11 +0000
                                                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 11:32 +0000
                                                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:05 +0000
                                                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 14:23 +0000
                                                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 16:04 +0100
                                                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:09 +0000
                                                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 17:23 +0100
                                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 09:00 -0800
                                                                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 20:33 +0100
                                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); luser droog <luser.droog@gmail.com> - 2017-01-03 11:40 -0800
                                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 12:23 -0800
                                                                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); luser droog <luser.droog@gmail.com> - 2017-01-03 12:39 -0800
                                                                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-03 13:51 -0800
                                                                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 22:58 -0800
                                                                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-16 10:24 -0800
                                                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:36 -0800
                                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:53 -0800
                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:13 +1300
                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-02 15:51 -0800
                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 00:51 +0100
                                                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); jt@toerring.de (Jens Thoms Toerring) - 2017-01-02 23:32 +0000
                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-02 23:46 +0000
                                                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 01:00 +0100
                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 00:42 -0800
                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ian Collins <ian-news@hotmail.com> - 2017-01-03 21:47 +1300
                                                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 01:31 -0800
                                                                          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 10:34 +0000
                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-03 11:19 +0000
                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-03 16:19 +0100
                                                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Thompson <dave.thompson2@verizon.net> - 2017-01-18 07:51 -0500
                                                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:30 +0000
                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Richard Heathfield <rjh@cpax.org.uk> - 2017-01-18 21:45 +0000
                                                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); raltbos@xs4all.nl (Richard Bos) - 2017-01-18 21:55 +0000
                                                                      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Gareth Owen <gwowen@gmail.com> - 2017-01-19 22:25 +0000
                                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 00:08 +0000
                                        Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-02 02:05 +0100
                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 09:45 -0800
                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:20 +0000
                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-01 15:26 -0800
                                  Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2017-01-01 23:48 +0000
                                    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 00:25 +0000
                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2017-01-01 16:44 +0100
                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Philip Lantz <prl@canterey.us> - 2017-01-01 23:54 -0800
                            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Keith Thompson <kst-u@mib.org> - 2017-01-01 13:25 -0800
                              Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 22:36 +0000
                                Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2017-01-01 15:38 -0800
          Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); BartC <bc@freeuk.com> - 2016-12-30 13:42 +0000
            Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); David Brown <david.brown@hesbynett.no> - 2016-12-30 15:07 +0100
      Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); supercat@casperkitty.com - 2016-12-30 10:21 -0800
    Re: How is he doing: int a[2] = { 1, 2 }; printf("%d\n", 2[a]); Veek M <vek.m1234@gmail.com> - 2016-12-31 07:37 +0530

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

#100997

On 03/01/17 09:42, Malcolm McLean wrote:
> On Tuesday, January 3, 2017 at 12:00:43 AM UTC, David Brown wrote:
>> On 03/01/17 00:46, BartC wrote:
>>>
>>> What is much better is:
>>>
>>>   display(showst:1, showast:1, tofile:0, pause:1);
>>
>> That would be marvellous.  However, we have to deal with the language we
>> have at the moment.
>>
> It also makes calls very long.

It is useful when calls are already very long, with lots of parameters. 
In languages where you can use named parameters, you can use positional 
parameters too - you only name them if you want.  (This is one of the 
things that makes passing a struct of parameter information a poor 
substitute.)

>
>
>>>
>>> Of course the counter-argument is that there is no need to change the
>>> language; your smart-editor/IDE will know what the prototype of
>>> display() is, and knows the parameter names, and it could display this
>>> kind of information.
>>>
>>
>> The underlying language stays /stable/.  Better tools give you more
>> features on top of the language itself.
>>
> Code should be readable and writeable with a simple text editor.
> I'm not against tools like automatic parameter name display,
> but they often fail.

I find they are usually correct - but you have to set up your tools 
appropriately.

I agree that it should all work fine with a simple text editor - extra 
tools are bonuses, and should not be essential for coding.

>>
>> Named parameters like this is definitely something I would like to see
>> added to C.  But I know there are people who would disagree, and I know
>> there are many things that other people would like to add, which I don't
>> want.  And the last thing we want is for /all/ these sorts of features
>> to be added - then C would lose its most important characteristics of
>> stability, portability, and (relative) simplicity.
>>
>> Maybe named parameters will make it to C++ eventually.
>>
> Just write high level functions variadically, in the manner I
> explained else thread.
>

And as I said earlier, that "solution" is just an unsafe, unchecked,
illegible, unscalable, inefficient mess.  It was not worth posting once, 
and is certainly not worth mentioning again.

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

#102120

On 2 Jan 2017 23:32:39 GMT, jt@toerring.de (Jens Thoms Toerring)
wrote:
<snip>
> Amen. The argument was akin to having an enumeraion with
> 
> enum HEIGHTS {
>     HEIGHT_0,
>     HEIGHT_1,
>     HEIGHT_2,
>     ...
>     /* I'm leaving out about 4 million lines here */
>     ...
>     HEIGHT_4294967295
> };
> 
Nitpick: 4 billion (US) or 4 thousand million (GB).

Unless you re-define 'about' as 'very far away' :-?

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

#102156

David Thompson <dave.thompson2@verizon.net> writes:

> Nitpick: 4 billion (US) or 4 thousand million (GB).

How very 20th century of you. The UK has long ago adopted the 10^9 = billion.

https://en.oxforddictionaries.com/explore/how-many-is-a-billion

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

#102157

On 18/01/17 21:30, Gareth Owen wrote:
> David Thompson <dave.thompson2@verizon.net> writes:
>
>> Nitpick: 4 billion (US) or 4 thousand million (GB).
>
> How very 20th century of you. The UK has long ago adopted the 10^9 = billion.

Speak for yourself. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#102158

Gareth Owen <gwowen@gmail.com> wrote:

> David Thompson <dave.thompson2@verizon.net> writes:
> 
> > Nitpick: 4 billion (US) or 4 thousand million (GB).
> 
> How very 20th century of you. The UK has long ago adopted the 10^9 = billion.

And when Brexit's well and done, it'll also adopt the dollar.

Richard

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

#102192

raltbos@xs4all.nl (Richard Bos) writes:

> Gareth Owen <gwowen@gmail.com> wrote:
>
>> David Thompson <dave.thompson2@verizon.net> writes:
>> 
>> > Nitpick: 4 billion (US) or 4 thousand million (GB).
>> 
>> How very 20th century of you. The UK has long ago adopted the 10^9 = billion.
>
> And when Brexit's well and done, it'll also adopt the dollar.

Well, it'll be nice to have a currency that doesn't keep falling against
the dollar.

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

#100835

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

> On Sunday, January 1, 2017 at 8:05:07 PM UTC, Ben Bacarisse wrote:
>> bart4858@gmail.com writes:
>> 
>> > I don't think people use _Bool enough to know the rules
>> > precisely.
>> 
>> It's a good idea to learn the rules even if you only use _Bool once or
>> twice but that is, I think, an unfashionable approach to programming.
>> 
> The problem is there is far too much of this garbage in programming.

I agree.  Programming should be simpler than it is.  But if you use C's
_Bool, I think knowing how it works is important.  C has a lot of very
odd rules which makes it a particularly bad choice for anyone not
prepared to learn them.

> A type which holds a flag that is set or unset, but with some sort of
> difficulty or complexity about it which means you really need to
> dig out the manual. Just use an int and set it to 1 or 0, the fancy
> types give no additional functionality, just complications.

In this case (negating a value) the result would be the same.  BartC
could equally have said "if you negate an int with a value of 1, you're
liable to end up with 4294967295" and used the same printf call to
justify it.  Something about _Bool must have prompted the idea that it
would be really weird, when in fact it isn't.

-- 
Ben.

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

#100844

On 01/01/17 20:24, bart4858@gmail.com wrote:

> I don't think people use _Bool enough to know the rules precisely.
> Adding 12 to a will yield 13, until it is assigned or cast to _Bool
> then the conversion kicks in. But this is not obvious. (If _Bool was
> in one of my languages, it probably wouldn't allow any arithmetic on
> it at all.)
>

I think most people use "_Bool" as "bool" after #include <stdbool.h>. 
And they use the type in the way it is primarily intended - as a Boolean 
type that can be either "true" or "false".  It is hard to imagine the 
kind of mindset that takes a value "true" and adds 12 - most programmers 
rarely write nonsense intentionally.

I suppose people may occasionally want to use a boolean value in a 
calculation, as a shortcut.  In that case, they should either know that 
C treats the _Bool as an int of value 0 or 1 in calculations, or they 
should stop using expressions that they don't understand.

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

#100794

On Sunday, January 1, 2017 at 3:43:01 PM UTC, Ben Bacarisse wrote:
> 
> That may well be true.  Do you want a language that is good for only the
> most common situations, or do you favour a whole new set of integer
> types: ones that saturate, ones that wrap and ones that signal overflow?
> 
No, ones that are big enough to count anything anyone would want
to count.
Give me 64 bits in my int. (You do have to have overflow behaviour,
but it hardly matters, no legitimate integer could overflow).

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

#100802

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> Give me 64 bits in my int.

Standard C must support an integer type at least 64 bit wide.  If you
have a complaint it can't be the C does not give you the functionality
you want.

<snip>
-- 
Ben.

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

#100831

On Sunday, January 1, 2017 at 9:43:01 AM UTC-6, Ben Bacarisse wrote:
> That may well be true.  Do you want a language that is good for only the
> most common situations, or do you favour a whole new set of integer
> types: ones that saturate, ones that wrap and ones that signal overflow?

Given that there are situations where each of those behaviors would be
required, and others where it would be acceptable to have overflow exhibit
loosely-defined behavior or even jump the rails entirely, having a means
by which programmers could specify their requirements and let compilers
implement them in the most efficient manner they know how would seem much
more conducive to the writing of portable code than making types behave
in different ways on different systems.

To be sure, it's useful to have some types whose behaviors vary according
to what will be most efficient on the target platform, for use in cases
where programmers don't have particularly tight requirements.  On a 36-bit
machine, math with a 36-bit unsigned type that stores nine bits per byte
will be much more efficient than math with a 32-bit unsigned type that
stores eight, but such machines would still benefit greatly from the
existence of the latter types (in big-endian and little-endian formats)
since they would be able to process unmodified code which uses such types.

Many fundamental design decisions in C were made on the basis of 1970s
computer and compiler technology; given all the developments since then,
there's no reason such decisions should be regarded as sacred except to
the extent necessary to ensure compatibility with an existing code base.

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

#100833

On 01/01/2017 15:42, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 01/01/2017 13:03, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>>> All I can find is something
>>>> that says they can never overflow because the values wrap around.
>>>
>>> From which a set of very useful properties follow.
>>
>> Sure. But probably there are more instances in practice where they are
>> not useful.
>
> That may well be true.  Do you want a language that is good for only the
> most common situations, or do you favour a whole new set of integer
> types: ones that saturate, ones that wrap and ones that signal overflow?

This is a low-level language. The behaviour that is simplest to 
implement, because that's how the hardware probably works, is to wrap.

It doesn't mean that that gives the correct results or that that 
behaviour is desired. Very often if an unsigned operation wraps, then 
something may have gone wrong.

But my comment a few posts back was about negating an unsigned value 
being as meaningless as a negating a pointer. OK, some people may have 
intentionally wanted an additive inverse, but probably not many!

(More likely, they're being sloppy about observing the correct 
signed/unsigned types in expressions, but often they will still end up 
with the right results, since hardware add and subtract is usually 
oblivious to signed/unsigned values.)

>> Until you have to explain it to someone for the umpteenth time.
>
> No, I disagree even in that case.  I find your seemingly endless
> whinging about things that can't be changed much more irritating.

Why couldn't it have been changed? It can be detected in compilers and 
the construct can be deprecated. The only loss would be to the IOCCC.

Eventual result: one bit of useless baggage eliminated.

-- 
Bartc

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

#100837

BartC <bc@freeuk.com> writes:

> On 01/01/2017 15:42, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 01/01/2017 13:03, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>
>>>>> All I can find is something
>>>>> that says they can never overflow because the values wrap around.
>>>>
>>>> From which a set of very useful properties follow.
>>>
>>> Sure. But probably there are more instances in practice where they are
>>> not useful.
>>
>> That may well be true.  Do you want a language that is good for only the
>> most common situations, or do you favour a whole new set of integer
>> types: ones that saturate, ones that wrap and ones that signal overflow?
>
> This is a low-level language. The behaviour that is simplest to
> implement, because that's how the hardware probably works, is to wrap.

Great.  That's what you get with unsigned types.  I thought you were
objecting to that in some way.

<snip>
>>> Until you have to explain it to someone for the umpteenth time.
>>
>> No, I disagree even in that case.  I find your seemingly endless
>> whinging about things that can't be changed much more irritating.
>
> Why couldn't it have been changed? It can be detected in compilers and
> the construct can be deprecated. The only loss would be to the IOCCC.

By which you mean i[a] specifically (i an int and a a pointer)?  Why do
you think I would object to compilers detecting and complaining about
that construct?  In general I favour lots and lots of compiler help.

-- 
Ben.

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

#100783

On 01/01/17 15:52, BartC wrote:
> On 01/01/2017 13:03, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> All I can find is something
>>> that says they can never overflow because the values wrap around.
>>
>> From which a set of very useful properties follow.
>
> Sure. But probably there are more instances in practice where they are
> not useful.
>
> You don't want a pixel value of +250, or near-white, to suddenly become
> black when you add 6. You don't want to have a size_t type to wrap
> around to a plausible in-bounds value when you add multiply its value.

So don't do that.  If you don't like the natural overflow behaviour of a 
type, then don't let it overflow.

For a while, there were plans to have support for saturating types as 
well as fixed point types in an extension to the C standard, but that 
seems to have mostly been forgotten.

>
> And you don't really want _Bool values to be anything other than 0 or 1.
> Yet if you negate a _Bool with a value of 1, you're liable to end up
> with 4294967295.

If you assign to a _Bool, you get either 0 or 1.

_Bool b1 = true;
_Bool b2 = -b1;
int i = b2;		// i is 1


>
>>> My original point was that commutative pointer arithmetic is neither
>>> useful nor sensible as it leads to the 2[a] of the subject line.
>>
>> Yes, I know that was your point.  As far as I'm concerned that topic is
>> done with -- you think it's neither useful nor sensible and I disagree.
>
> Until you have to explain it to someone for the umpteenth time.
>

For most people, it's just a matter of saying "this is an oddity of the 
way arrays and pointers work in C.  You will not see it in real code, 
except from someone trying to be a smart-ass".  And that's all there is 
to it.

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

#100852

Ben Bacarisse wrote:
> BartC writes:
> > You can bamboozle me with higher mathematics but that won't stop
> > people being confused by i[A] when they come across it.
> 
> I agree.  And, for the record, I accept that had C made addition
> non-commutative where pointers were involved you would not be moaning
> about it as yet another oddity in the language.

Do you think so? I think he would be moaning about the one special
case where addition was not commutative.

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

#100816

BartC <bc@freeuk.com> writes:
> On 01/01/2017 12:00, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 01/01/2017 10:54, Richard Bos wrote:
>>>> BartC <bc@freeuk.com> wrote:
>>>>> On 30/12/2016 16:41, Keith Thompson wrote:
>>>>>> Which exists because there is no unary "-" for pointers, and negating a
>>>>>> pointer makes no sense.
>>>>>
>>>>> Neither does negating an unsigned int.
>>>>
>>>> There goes someone who has never studied group theory.
>>>
>>> What does group theory say about 32- and 64-bit pointers?
>>
>> Nothing as far as I can see.  What's your point?  There are lots of
>> types in C that don't form a group.  C's unsigned ints do.
>
> Where does it say that in the Standard? All I can find is something that 
> says they can never overflow because the values wrap around.

It doesn't.  But someone familiar with mathematical group theory can
read the C standard's description of unsigned types and conclude that
the set of unsigned int values are a group under the operation of
addition.  There is no particular reason for the Standard to mention
that fact.

> My original point was that commutative pointer arithmetic is neither 
> useful nor sensible as it leads to the 2[a] of the subject line.
>
> You can bamboozle me with higher mathematics but that won't stop people 
> being confused by i[A] when they come across it.

The remark about group theory was in response to your statement
that negating an unsigned int makes no sense.  An understanding of
simple group theory is one way (not the only one) to demonstrate
that negating an unsigned int *can* make perfectly good sense.

For any value x, negating that value can be defined to yield a
value, called -x, such that -x + x is zero.  By this definition,
-1U == UINT_MAX, because -1U + UINT_MAX == 0.

If you're using unsigned int values in a context where negating an
unsigned int doesn't make sense, then don't negate them.

The commutativity of the indexing operator is an entirely
separate issue.  I agree with you that it would have made sense for
pointer-plus-integer addition *not* to be commutative, but the fact
that it is commutative is a mild oddity, not the serious problem
you try to make it out to be.  As it happens I've discussed it here:
    http://stackoverflow.com/a/18393343/827263

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

#100827

Keith Thompson <kst-u@mib.org> writes:
<snip>
> The commutativity of the indexing operator is an entirely
> separate issue.  I agree with you that it would have made sense for
> pointer-plus-integer addition *not* to be commutative, but the fact
> that it is commutative is a mild oddity, not the serious problem
> you try to make it out to be.

I'd make a further distinction between the commutativity of the indexing
operation and the commutativity of pointer-plus-integer arithmetic.  It
would be perfectly possible to prohibit 1[a] without forcing addition
involving a pointer to be non-commutative.

<snip>
-- 
Ben.

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

#100832

On Sunday, January 1, 2017 at 4:36:29 PM UTC-6, Ben Bacarisse wrote:
> I'd make a further distinction between the commutativity of the indexing
> operation and the commutativity of pointer-plus-integer arithmetic.  It
> would be perfectly possible to prohibit 1[a] without forcing addition
> involving a pointer to be non-commutative.

I think it is useful to say that a compiler is allowed to regard x[y] as
*((x)+(y)) if it sees fit to do so, but that does not imply that the two
forms must be treated as equivalent.  Among other things, given "int a[5][5];"
treating the forms as equivalent means that although the type to which
a[0] decays in the expression a[0][x] is int*, it is semantically "special"
in that it can only access the first five elements of the array while an
int* that merely identifies the storage of the array taken as a whole should
be able to access all 25 elements.

If the Standard recognized that x[y] as an operator which operates on arrays
and will have the same meaning as *(x+y) in cases where the latter would
compile and the former would be defined, that would make the language more
expressive, since it would allow for the possibility of arrays whose elements
didn't have distinct addresses [e.g. packed arrays of types smaller than a
character], and also allow programmers to distinguish when they did and did
not want to promise that an index would remain within a row of a multi-
dimensional array (use a[x][y] if y will be within a row, or *(a[x]+y) if
it won't].  That seems more useful than merely regarding bracket notation
as syntactically redundant.

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

#100657

On 30/12/2016 13:24, Stefan Ram wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> And I am certain you would then have moaned about *that* instead.
>
>   In C, one can write the statement
>
> 2;
>
>   . The production is simply
>
> <expression> ";"
>
>   . In Java, they thought that »2;« makes no
>   sense and forbade it by the production
>
> <statement-expression> ";"
>
>   , and »2« is an expression in Java, but not
>   a statement-expression in Java.
>
>   However, now teaching Java is more complicated
>   than teaching C, because it does not suffice
>   to teach what an expression is, one also has to
>   explain what a statement-expression is.

I agree with how Java does it.

But C's method is not necessarily simpler, as expressions can count as 
statements, but statements don't necessarily count as expressions.

So sometimes {A;B;C;} can be rewritten as A,B,C and sometimes it can't; 
you now have to explain the circumstances where that is possible.

(I also do what Java does, but don't need to introduce a third class of 
construct, eg. <stmt-expr> as well as <expression> and <statement>. Out 
of the kinds of expressions that I also find useful as standalone 
statements:

    increment
    assign
    function-call

there are separate versions that are used in statements.)

>   In Java one still can write useless code as in C:
>
> Math.random();
>
>   . A function call qualifies as a statement-
>   expression in Java, even if it has no effect.

Your example /could/ have an affect, as I assume it steps the internal 
state of the PRNG.

You could play around with allowing void functions, but not non-void 
ones. But I think this is pointless. The thing is, if the function call 
is opaque, then you don't know what's going on inside it (or what could 
be going on next week when the function is revised).

-- 
Bartc

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

#100660

On 30/12/16 14:42, BartC wrote:

> But C's method is not necessarily simpler, as expressions can count as
> statements, but statements don't necessarily count as expressions.

"Expression statements" are a kind of statement in C, but not all
statements are expressions.

It's a bit like "all cats are animals, but not all animals are cats".
Only in this case, there is a standards document that makes this clear.

(Far from everything in the C standards are clear, but this case is.)

> 
> So sometimes {A;B;C;} can be rewritten as A,B,C and sometimes it can't;
> you now have to explain the circumstances where that is possible.
> 

If A, B and C are expressions, you can write A, B, C to get roughly the
same thing as { A; B; C; } (but the former is an expression, unlike the
later).

If you don't like this, then don't write A, B, C.  I don't like the
comma operator, and so I don't use the comma operator.  Problem solved
(if there ever was a problem).

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

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

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

csiph-web