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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#101021

On 03/01/17 18:00, supercat@casperkitty.com wrote:
> On Tuesday, January 3, 2017 at 10:23:42 AM UTC-6, David Brown wrote:
>> On 03/01/17 17:09, Ben Bacarisse wrote:
>>> I my experience opaque types are more common (and indeed useful) for
>>> that with sometimes a few named external objects, but I don't think I've
>>> seen compound literal used to construct values are run-time.
>>>
>>
>> The construction and access to that kind of type is usually hidden
>> within macros.  I don't know if compound literals are used to implement
>> such macros, but it is certainly a possibility.
>
> Compound literals are often only useful with types that are passed by value.

Not true.  And if it were true, then so what?

<snip the stuff that is technically true, but irrelevant>

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

#101022

On Tuesday, January 3, 2017 at 1:33:56 PM UTC-6, David Brown wrote:
> On 03/01/17 18:00, supercat@casperkitty.com wrote:
> > On Tuesday, January 3, 2017 at 10:23:42 AM UTC-6, David Brown wrote:
> >> On 03/01/17 17:09, Ben Bacarisse wrote:
> >>> I my experience opaque types are more common (and indeed useful) for
> >>> that with sometimes a few named external objects, but I don't think I've
> >>> seen compound literal used to construct values are run-time.
> >>>
> >>
> >> The construction and access to that kind of type is usually hidden
> >> within macros.  I don't know if compound literals are used to implement
> >> such macros, but it is certainly a possibility.
> >
> > Compound literals are often only useful with types that are passed by value.
> 
> Not true.  And if it were true, then so what?
> 
> <snip the stuff that is technically true, but irrelevant>

Not sure what the juxtaposition "often only" describes,
but compound literals are useful when you need to pass
a pointer as well. Because you can make a 1-element array
and let it decay to the needed pointer.

(int[1]){ 42 }

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

#101026

On Tuesday, January 3, 2017 at 1:40:46 PM UTC-6, luser droog wrote:
> Not sure what the juxtaposition "often only" describes,
> but compound literals are useful when you need to pass
> a pointer as well. Because you can make a 1-element array
> and let it decay to the needed pointer.
> 
> (int[1]){ 42 }

How often is there a need to have code create and populate a temporary
array every time a function is called?  If performance is a non-issue
and the called function won't care if the pointer becomes invalid after
it returns, passing the address of a compound literal may be a valid but
inefficient way of giving a fixed set of data to a called subroutine,
but for a language which is supposedly designed around efficiency to define
a new syntax to accomplish something which is less efficient than the old
ways of doing it would seem counter-productive.

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

#101029

On Tuesday, January 3, 2017 at 2:24:24 PM UTC-6, supe...@casperkitty.com wrote:
> On Tuesday, January 3, 2017 at 1:40:46 PM UTC-6, luser droog wrote:
> > Not sure what the juxtaposition "often only" describes,
> > but compound literals are useful when you need to pass
> > a pointer as well. Because you can make a 1-element array
> > and let it decay to the needed pointer.
> > 
> > (int[1]){ 42 }
> 
> How often is there a need to have code create and populate a temporary
> array every time a function is called?  If performance is a non-issue
> and the called function won't care if the pointer becomes invalid after
> it returns, passing the address of a compound literal may be a valid but
> inefficient way of giving a fixed set of data to a called subroutine,
> but for a language which is supposedly designed around efficiency to define
> a new syntax to accomplish something which is less efficient than the old
> ways of doing it would seem counter-productive.

Perhaps my experience is not common, but I've recently
been working with code that uses int to hold UCS-4 Unicode
code points, so it's not unusual in my code to use
(int[]){...} to build 'strings' of these 'characters'.

Also I don't see how the compound literal syntax is necessarily
any less efficient than not using/having it. 

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

#101042

On Tuesday, January 3, 2017 at 2:39:16 PM UTC-6, luser droog wrote:
> Also I don't see how the compound literal syntax is necessarily
> any less efficient than not using/having it.

Given:

   static int const foo[10] = {1,2,3,4,5,6,7,8,9,10};

   doSomething(&foo);

the calling code merely needs to operate on one thing--a pointer to the
array--regardless of what the function might do with it.  By contrast,
given:

   doSomething((int[]){1,2,3,4,5,6,7,8,9,10});

a compiler that doesn't know what doSomething will do with the pointer it
receives would have no choice but to write ten values into a temporary array
every time the function is called.

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

#101925

supercat@casperkitty.com writes:

> On Tuesday, January 3, 2017 at 2:39:16 PM UTC-6, luser droog wrote:
>> Also I don't see how the compound literal syntax is necessarily
>> any less efficient than not using/having it.
>
> Given:
>
>    static int const foo[10] = {1,2,3,4,5,6,7,8,9,10};
>
>    doSomething(&foo);
>
> the calling code merely needs to operate on one thing--a pointer to the
> array--regardless of what the function might do with it.  By contrast,
> given:
>
>    doSomething((int[]){1,2,3,4,5,6,7,8,9,10});
>
> a compiler that doesn't know what doSomething will do with the pointer it
> receives would have no choice but to write ten values into a temporary array
> every time the function is called.

Notice that he is cheating, because the performance comparison
is being done between constructs that have different semantics.
If we're allowed to change the semantics, we might as well
eliminate the function call altogether - the result will be
a lot faster than if the function is called.

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

#101997

On Monday, January 16, 2017 at 12:58:55 AM UTC-6, Tim Rentsch wrote:
> supercat writes:
> 
> > On Tuesday, January 3, 2017 at 2:39:16 PM UTC-6, luser droog wrote:
> >> Also I don't see how the compound literal syntax is necessarily
> >> any less efficient than not using/having it.
> >
> > Given:
> >
> >    static int const foo[10] = {1,2,3,4,5,6,7,8,9,10};
> >
> >    doSomething(&foo);
> >
> > the calling code merely needs to operate on one thing--a pointer to the
> > array--regardless of what the function might do with it.  By contrast,
> > given:
> >
> >    doSomething((int[]){1,2,3,4,5,6,7,8,9,10});
> >
> > a compiler that doesn't know what doSomething will do with the pointer it
> > receives would have no choice but to write ten values into a temporary array
> > every time the function is called.
> 
> Notice that he is cheating, because the performance comparison
> is being done between constructs that have different semantics.
> If we're allowed to change the semantics, we might as well
> eliminate the function call altogether - the result will be
> a lot faster than if the function is called.

If doSomething() were defined in such a fashion that it does not retain
a copy of the passed-in pointer after it exits, nor cause the data
identified by the pointer to be written, in what way would the semantics
of the form using the const array differ from that of the form using the
compound initializer?  If the semantics would be identical in that use
case, in what way would use of the const array form be "cheating"?

It would be possible to write a doSomething() function which would cause
the behavior of the two forms to be different, but would you expect that
to be the case even 50% of the time?  If not, that would suggest that in
the majority of use cases for constructs like the above, code using the
compound literal syntax would be slower than code that achieved identical
behavior using a separately-declared object of static duration.

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

#102845

supercat@casperkitty.com writes:

> On Monday, January 16, 2017 at 12:58:55 AM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>>
>>> On Tuesday, January 3, 2017 at 2:39:16 PM UTC-6, luser droog wrote:
>>>> Also I don't see how the compound literal syntax is necessarily
>>>> any less efficient than not using/having it.
>>>
>>> Given:
>>>
>>>    static int const foo[10] = {1,2,3,4,5,6,7,8,9,10};
>>>
>>>    doSomething(&foo);
>>>
>>> the calling code merely needs to operate on one thing--a pointer
>>> to the array--regardless of what the function might do with it.
>>> By contrast, given:
>>>
>>>    doSomething((int[]){1,2,3,4,5,6,7,8,9,10});
>>>
>>> a compiler that doesn't know what doSomething will do with the
>>> pointer it receives would have no choice but to write ten values
>>> into a temporary array every time the function is called.
>>
>> Notice that he is cheating, because the performance comparison
>> is being done between constructs that have different semantics.
>> If we're allowed to change the semantics, we might as well
>> eliminate the function call altogether - the result will be
>> a lot faster than if the function is called.
>
> If doSomething() were defined in such a fashion that it does not retain
> a copy of the passed-in pointer after it exits, nor cause the data
> identified by the pointer to be written, in what way would the semantics
> of the form using the const array differ from that of the form using the
> compound initializer?  If the semantics would be identical in that use
> case, in what way would use of the const array form be "cheating"?
>
> It would be possible to write a doSomething() function which would cause
> the behavior of the two forms to be different, but would you expect that
> to be the case even 50% of the time?  [...]

Irrelevant.  It's still an apples-and-oranges comparison.

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

#101725

luser droog <luser.droog@gmail.com> writes:

> [...] you can make a 1-element array
> and let it decay to the needed pointer.
>
> (int[1]){ 42 }

Or just  (int[]){ 42 }

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

#100937

On 01/ 3/17 12:46 PM, Malcolm McLean wrote:
> On Monday, January 2, 2017 at 11:12:03 PM UTC, Ian Collins wrote:
>> On 01/ 3/17 12:07 PM, Malcolm McLean wrote:
>>> On Monday, January 2, 2017 at 10:37:45 PM UTC, David Brown wrote:
>>>> On 02/01/17 18:53, Malcolm McLean wrote:
>>>>
>>>>>
>>>>> But if we do this
>>>>>
>>>>> void makeIcon(int height, int width);
>>>>>
>>>>>
>>>>> Eiffel_tower = makeIcon(16, 64);
>>>>>
>>>>> We've reversed the convention, because height precedes width.
>>>>> Bu thre bug won't persist. The informal tester will take one look
>>>>> at that icon and say "width and height have been flipped".
>>>>>
>>>>>
>>>>
>>>> This is back to relying on parameter names again - nothing more.  And to
>>>> go back full circle to your complaint about bools, this is exactly the
>>>> same as you can do with bool arguments.  If it is good enough for int
>>>> arguments, it is good enough for bools.
>>>>
>>> Firstly, a bool literal is abstracted as "true" or "false", seldom as
>>> "SET_TRANSPARENT_MODE". An int literal is likely to be #defined
>>> EIFFEL_TOWER_HEIGHT, or assigned to a variable (int height = 64;).
>>
>> Says who?
>>
>> Why wouldn't bool constants be named any differently from integer ones?
>>
> Because "true" and "false" are considered sufficiently abstract.

Again, by who?

> Many people however don't like to see the literal 42 in code.
> They have coding standards that suggest it be #defined or turned into
> a named const int.

I'm sure I'm not in a minority when I chose to use named bool constants 
where true and false aren't the clearest choice.

> I have seen a few coding standards that discourage boolean parameters
> (it's not something I originated myself) but not many. It's something
> that needs to be spread through the community.

Nonsense.

-- 
Ian

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

#100930

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, January 2, 2017 at 10:37:45 PM UTC, David Brown wrote:
>> On 02/01/17 18:53, Malcolm McLean wrote:
>> > But if we do this
>> >
>> > void makeIcon(int height, int width);
>> >
>> >
>> > Eiffel_tower = makeIcon(16, 64);
>> >
>> > We've reversed the convention, because height precedes width.
>> > Bu thre bug won't persist. The informal tester will take one look
>> > at that icon and say "width and height have been flipped".
>> 
>> This is back to relying on parameter names again - nothing more.  And to 
>> go back full circle to your complaint about bools, this is exactly the 
>> same as you can do with bool arguments.  If it is good enough for int 
>> arguments, it is good enough for bools.
>>
> Firstly, a bool literal is abstracted as "true" or "false", seldom as
> "SET_TRANSPARENT_MODE". An int literal is likely to be #defined 
> EIFFEL_TOWER_HEIGHT, or assigned to a variable (int height = 64;).

Depending on the context, you can think of the constants "true" and
"false" as "magic numbers", just like 16 and 64.  If the meaning of 64
is sufficiently clear from context, it may be ok just to use that
literal value; otherwise you should probably give it a meaningful name.
In exactly the same way, if the meaning of `true` is sufficiently clear
from context, go ahead and use it; if not, give it a meaningful name.

I haven't actually seen this done very often, but there's no reason it
couldn't be.

On the other hand, if a function takes a bool argument and most calls of
that function need to use a more meaningful name than "true" or "false",
perhaps it's better to use an enumerated type instead.  But if you have
an existing function that already takes a bool argument, it's perfectly
reasonable to define your own meaningful constants.

[...]

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

#100931

On 03/01/17 00:07, Malcolm McLean wrote:
> On Monday, January 2, 2017 at 10:37:45 PM UTC, David Brown wrote:
>> On 02/01/17 18:53, Malcolm McLean wrote:
>>
>>>
>>> But if we do this
>>>
>>> void makeIcon(int height, int width);
>>>
>>>
>>> Eiffel_tower = makeIcon(16, 64);
>>>
>>> We've reversed the convention, because height precedes width.
>>> Bu thre bug won't persist. The informal tester will take one look
>>> at that icon and say "width and height have been flipped".
>>>
>>>
>>
>> This is back to relying on parameter names again - nothing more.  And to
>> go back full circle to your complaint about bools, this is exactly the
>> same as you can do with bool arguments.  If it is good enough for int
>> arguments, it is good enough for bools.
>>
> Firstly, a bool literal is abstracted as "true" or "false", seldom as
> "SET_TRANSPARENT_MODE".

There is no reason why not, if it makes things clearer.  But with bools, 
there is seldom a need /if/ you use sensible parameter names in your 
declarations.

And if you are trying to make a sensible, clear interface, you would 
probably use an enum type when there are multiple choices - not an int 
and then a bunch of unconnected #define's.

>  An int literal is likely to be #defined
> EIFFEL_TOWER_HEIGHT, or assigned to a variable (int height = 64;).

Again, you would do the same for bool's if it made sense - it's just 
less common because it is less necessary when there are only two choices.

>
> Secondly, even if you do see an int literal in the code, typically
> the number is a bit meaningful. You know the icons are going to be
> small images, so values, like 32, 64 are probably dimensions, values
> like 24, 193 more likely to be x, y co-ordinates. Again, you're
> quite likely to see something like winheight - 27 in real code, so
> you know that the parameter is the y coordinate  of the image, and is
> 27 pixels above the bottom of the window.

Usually your bools will make sense too.  If you function is called as 
"enableWidget(resetButton, true)" you can make a solid guess as to the 
meaning of "true".

>
> Arguments of "true" and "false" are just meaningless, however. Only
> by actually looking up the cal can you tell what they mean. Ad often
> calls have many parameters, and there's logic in the call expression.
> So you have to count the arguments to work out what the booleans values
> represent. It's not an insurmountable problem, but it makes programs
> harder to read than they would otherwise be.
>

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

#100924

David Brown <david.brown@hesbynett.no> wrote:
> On 02/01/17 18:53, Malcolm McLean wrote:

> >
> > But if we do this
> >
> > void makeIcon(int height, int width);
> >
> >
> > Eiffel_tower = makeIcon(16, 64);
> >
> > We've reversed the convention, because height precedes width.
> > Bu thre bug won't persist. The informal tester will take one look
> > at that icon and say "width and height have been flipped".
> >
> >

> This is back to relying on parameter names again - nothing more.  And to 
> go back full circle to your complaint about bools, this is exactly the 
> same as you can do with bool arguments.  If it is good enough for int 
> arguments, it is good enough for bools.

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
};

and a corresponding one for widths (and make it a "bit"
larger for a 64-bit machine of Malcolm's B64 project;-)

The advantage of a bool is that it can have only two
possible values and that you don't have to check for
anything when you receive one. It's either 'true' or
'false' (and those values are either 1 or 0 in an
arithmetic context). That simplifies a lot of things.
Otherwise you always have to worry how to deal with an
'int' that should be either 0 or 1 but isn't (and that's
not something theoretical, that's something I'm trying
to address in a larger project I've got involved with
currently).
                    Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#100929

On 02/01/2017 23:32, Jens Thoms Toerring wrote:
> David Brown <david.brown@hesbynett.no> wrote:

>> This is back to relying on parameter names again - nothing more.  And to
>> go back full circle to your complaint about bools, this is exactly the
>> same as you can do with bool arguments.  If it is good enough for int
>> arguments, it is good enough for bools.
>
> 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
> };
>
> and a corresponding one for widths (and make it a "bit"
> larger for a 64-bit machine of Malcolm's B64 project;-)
>
> The advantage of a bool is that it can have only two
> possible values and that you don't have to check for
> anything when you receive one. It's either 'true' or
> 'false' (and those values are either 1 or 0 in an
> arithmetic context). That simplifies a lot of things.

The point is that it simplifies too much. This function call doesn't 
tell you much:

   display(1,1,0,1);

Nor does:

   display(true,true,false,true);

What is much better is:

   display(showst:1, showast:1, tofile:0, pause:1);

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.

So the tendency is to make development tools more sophisticated (no 
matter that everyone uses different tools), while the only common 
factor, the underlying language, can stay primitive.

-- 
Bartc

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

#100935

On 03/01/17 00:46, BartC wrote:
> On 02/01/2017 23:32, Jens Thoms Toerring wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>
>>> This is back to relying on parameter names again - nothing more.  And to
>>> go back full circle to your complaint about bools, this is exactly the
>>> same as you can do with bool arguments.  If it is good enough for int
>>> arguments, it is good enough for bools.
>>
>> 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
>> };
>>
>> and a corresponding one for widths (and make it a "bit"
>> larger for a 64-bit machine of Malcolm's B64 project;-)
>>
>> The advantage of a bool is that it can have only two
>> possible values and that you don't have to check for
>> anything when you receive one. It's either 'true' or
>> 'false' (and those values are either 1 or 0 in an
>> arithmetic context). That simplifies a lot of things.
>
> The point is that it simplifies too much. This function call doesn't
> tell you much:
>
>   display(1,1,0,1);
>
> Nor does:
>
>   display(true,true,false,true);

Indeed.  My point is merely that bool parameters are no worse than int 
ones in this manner.  And in both cases, you can use named constants if 
that makes things clearer, or perhaps enumerated types rather than int 
or bool.

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

>
> 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.
>
> So the tendency is to make development tools more sophisticated (no
> matter that everyone uses different tools), while the only common
> factor, the underlying language, can stay primitive.
>

The underlying language stays /stable/.  Better tools give you more 
features on top of the language itself.

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.

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

#100953

On Tuesday, January 3, 2017 at 12:00:43 AM UTC, David Brown wrote:
> On 03/01/17 00:46, BartC wrote:
> 
> > The point is that it simplifies too much. This function call doesn't
> > tell you much:
> >
> >   display(1,1,0,1);
> >
> > Nor does:
> >
> >   display(true,true,false,true);
> 
> Indeed.  My point is merely that bool parameters are no worse than int 
> ones in this manner.  And in both cases, you can use named constants if 
> that makes things clearer, or perhaps enumerated types rather than int 
> or bool.
> 
If an int is 1 or 0, it doesn't tell you much. But if it holds a value
then, in conjunction with the function name, it can tell you quite
a lot. 

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


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

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

#100955

On 01/ 3/17 09:42 PM, Malcolm McLean wrote:
> On Tuesday, January 3, 2017 at 12:00:43 AM UTC, David Brown wrote:
>>
>> 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.

To go back to the lack of parameter checking we all enjoyed so much in 
the 80s?

-- 
Ian

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

#100956

On Tuesday, January 3, 2017 at 8:48:09 AM UTC, Ian Collins wrote:
> On 01/ 3/17 09:42 PM, Malcolm McLean wrote:
> 
> > Just write high level functions variadically, in the manner I
> > explained else thread.
> 
> To go back to the lack of parameter checking we all enjoyed so much in 
> the 80s?
> 
variadic functions expand parameters, you only have the wider types
A bit like B64.

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

#100959

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

> On Tuesday, January 3, 2017 at 8:48:09 AM UTC, Ian Collins wrote:
>> On 01/ 3/17 09:42 PM, Malcolm McLean wrote:
>> 
>> > Just write high level functions variadically, in the manner I
>> > explained else thread.
>> 
>> To go back to the lack of parameter checking we all enjoyed so much in 
>> the 80s?
>> 
> variadic functions expand parameters, you only have the wider types

Or, using conventional terms, the arguments in variadic function calls
(after the typed ones) are promoted.

That's *worse* than K&R C function calls in terms of type-checking.  The
semantics are the same, but at least in old C you could look at the
function definition to get a name and a type.

I suspect that only people who've never had to work on large K&R C code
bases want to go back.

> A bit like B64.

Yes.

-- 
Ben.

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

#100963

On 03/01/2017 08: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:
>>
>>> The point is that it simplifies too much. This function call doesn't
>>> tell you much:
>>>
>>>   display(1,1,0,1);
>>>
>>> Nor does:
>>>
>>>   display(true,true,false,true);
>>
>> Indeed.  My point is merely that bool parameters are no worse than int
>> ones in this manner.  And in both cases, you can use named constants if
>> that makes things clearer, or perhaps enumerated types rather than int
>> or bool.
>>
> If an int is 1 or 0, it doesn't tell you much. But if it holds a value
> then, in conjunction with the function name, it can tell you quite
> a lot.
>
>>>
>>> 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.

What, keyword parameters?

On the contrary, it can make them much shorter, combined with default 
parameters. Example:

  hwnd = CreateWindowEx(width:640, height:480, caption:"Demo");

compared with:

  hwnd = CreateWindowEx(
     0,                // exstyle
     "myclass",        //
     "Demo",           // caption
     DEFAULT,          // x pos
     DEFAULT,          // y pos
     640,              // width
     480,              // height
     NULL,             // parent
     NULL,             // menu
     NULL,             // instance
     0);               // lpParam

A very nice feature. (However, to apply it to existing functions such as 
my example, requires that function declarations are revised to add 
parameters names and default values.)

-- 
Bartc

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

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

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

csiph-web