Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 09:38 +1300 |
| Message-ID | <ect7ltFq0soU3@mid.individual.net> |
| In reply to | #100807 |
On 01/ 2/17 09:11 AM, Stefan Ram wrote: > Ian Collins <ian-news@hotmail.com> writes: >> On 01/ 2/17 08:54 AM, Stefan Ram wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>>> I wonder why C hasn't adopted the simple rule from C++: if a parameter >>>> isn't going to be used, don't give it a name. >>> There's a style checker for C++ in clang, and when I write: >> It should be telling that control reaches end of non-void function... > > I was referring to »clang-tidy« with »-checks=* -Weverything -W -Wall«. Note this is a guideline, not a language standard rule. If you refer to the relevant style guideline (https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions) it includes the note: "Parameter names may be omitted only if the parameter is unused and its purpose is obvious." So clang-tidy is being over zealous. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-01 13:59 -0800 |
| Message-ID | <3500f98c-6317-47bb-b703-c1530496ba93@googlegroups.com> |
| In reply to | #100810 |
On Sunday, January 1, 2017 at 8:38:37 PM UTC, Ian Collins wrote: > > it includes the note: > > "Parameter names may be omitted only if the parameter is unused and its > purpose is obvious." > Kind of an oxymoron. If a parameter is used, its purpose can often be obvious. But if it is unused, there must always be the question why it was included.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-01 14:24 -0800 |
| Message-ID | <ln1swmxvu0.fsf@kst-u.example.com> |
| In reply to | #100820 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, January 1, 2017 at 8:38:37 PM UTC, Ian Collins wrote:
>> it includes the note:
>>
>> "Parameter names may be omitted only if the parameter is unused and its
>> purpose is obvious."
>>
> Kind of an oxymoron. If a parameter is used, its purpose can often
> be obvious. But if it is unused, there must always be the question
> why it was included.
Yes, and sometimes the answer to that question might be obvious.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-01 15:51 -0800 |
| Message-ID | <5b5861c2-94b6-43af-872d-7135c9d57204@googlegroups.com> |
| In reply to | #100820 |
On Sunday, January 1, 2017 at 3:59:37 PM UTC-6, Malcolm McLean wrote:
> On Sunday, January 1, 2017 at 8:38:37 PM UTC, Ian Collins wrote:
> > "Parameter names may be omitted only if the parameter is unused and its
> > purpose is obvious."
> >
> Kind of an oxymoron. If a parameter is used, its purpose can often
> be obvious. But if it is unused, there must always be the question
> why it was included.
The reason for inclusion in the called function is generally obvious:
callers are going to pass the argument, so the called functions need
to receive it. On the other hand, without knowing what the parameter
is supposed to represent, it's hard to know whether one should be
using it.
Perhaps the nicest way to handle such things would be to allow functions
to specify distinct parameter and argument types, with the compiler
coercing values as necessary. A lot of memory-management code ends up
looking like:
void *do_something(void *p1, void *p2, ...whatever...)
{
unsigned char *pp1 = p1;
unsigned char *pp2 = p1;
... code uses pp1 and pp2 from here on out instead of p1 and p2
}
Even if a compiler can optimize out the redundant variables, the
declarations and initializations add complexity to the code, making it
unclear whether intention is to copy the passed-in pointers or merely
be able to use them as type "unsigned char*". A syntax to allow a
programmer to specify caller-side and called-function-side types of
arguments and parameters would resolve that problem as well as the
unused-argument issue (simply allow unused arguments to be declared
as having a called-function-side type of "void").
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 13:09 +1300 |
| Message-ID | <ectk27Fq0soU4@mid.individual.net> |
| In reply to | #100834 |
On 01/ 2/17 12:51 PM, supercat@casperkitty.com wrote:
> On Sunday, January 1, 2017 at 3:59:37 PM UTC-6, Malcolm McLean wrote:
>> On Sunday, January 1, 2017 at 8:38:37 PM UTC, Ian Collins wrote:
>>> "Parameter names may be omitted only if the parameter is unused and its
>>> purpose is obvious."
>>>
>> Kind of an oxymoron. If a parameter is used, its purpose can often
>> be obvious. But if it is unused, there must always be the question
>> why it was included.
>
> The reason for inclusion in the called function is generally obvious:
> callers are going to pass the argument, so the called functions need
> to receive it. On the other hand, without knowing what the parameter
> is supposed to represent, it's hard to know whether one should be
> using it.
>
> Perhaps the nicest way to handle such things would be to allow functions
> to specify distinct parameter and argument types, with the compiler
> coercing values as necessary. A lot of memory-management code ends up
> looking like:
>
> void *do_something(void *p1, void *p2, ...whatever...)
> {
> unsigned char *pp1 = p1;
> unsigned char *pp2 = p1;
> ... code uses pp1 and pp2 from here on out instead of p1 and p2
> }
>
> Even if a compiler can optimize out the redundant variables, the
> declarations and initializations add complexity to the code, making it
> unclear whether intention is to copy the passed-in pointers or merely
> be able to use them as type "unsigned char*". A syntax to allow a
> programmer to specify caller-side and called-function-side types of
> arguments and parameters would resolve that problem as well as the
> unused-argument issue (simply allow unused arguments to be declared
> as having a called-function-side type of "void").
In what way is that a better solution to allowing unnamed parameters?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-01 16:50 -0800 |
| Message-ID | <7a6aab4b-acc4-4c08-88ae-dbdbecd79f4f@googlegroups.com> |
| In reply to | #100836 |
On Sunday, January 1, 2017 at 6:09:52 PM UTC-6, Ian Collins wrote: > In what way is that a better solution to allowing unnamed parameters? As noted, it would allow for the situation where a function needs to receive pointers to arbitrary objects but process those objects as a sequence of bytes (a situation unnamed parameters wouldn't help at all). Further, function headers often serve as a form of documentation; if a string-display function which is designed for a black and white console ignores a couple parameters "int fgColor:void" and "int bgColor:void) [I really don't know what syntax would be best], someone reading the code might be able to recognize that it shouldn't be expected to use those parameters. If instead it just ignored a couple of parameters of type "int", someone examining the code might have no idea whether they represented something the code should be using.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 14:24 +1300 |
| Message-ID | <ectodvFq0soU6@mid.individual.net> |
| In reply to | #100841 |
On 01/ 2/17 01:50 PM, supercat@casperkitty.com wrote: > On Sunday, January 1, 2017 at 6:09:52 PM UTC-6, Ian Collins wrote: Keeping some of the context would be nice. >> In what way is that a better solution to allowing unnamed parameters? > > As noted, it would allow for the situation where a function needs to > receive pointers to arbitrary objects but process those objects as a > sequence of bytes (a situation unnamed parameters wouldn't help at all). Which wasn't the issue being discussed. > Further, function headers often serve as a form of documentation; if > a string-display function which is designed for a black and white console > ignores a couple parameters "int fgColor:void" and "int bgColor:void) [I > really don't know what syntax would be best], someone reading the code > might be able to recognize that it shouldn't be expected to use those > parameters. If instead it just ignored a couple of parameters of type > "int", someone examining the code might have no idea whether they > represented something the code should be using. If the parameters aren't named, it's pretty clear that they aren't intended to be used! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-02 01:53 +0100 |
| Message-ID | <o4c86n$tnj$1@dont-email.me> |
| In reply to | #100810 |
On 01/01/17 21:38, Ian Collins wrote: > On 01/ 2/17 09:11 AM, Stefan Ram wrote: >> Ian Collins <ian-news@hotmail.com> writes: >>> On 01/ 2/17 08:54 AM, Stefan Ram wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>>> I wonder why C hasn't adopted the simple rule from C++: if a parameter >>>>> isn't going to be used, don't give it a name. >>>> There's a style checker for C++ in clang, and when I write: >>> It should be telling that control reaches end of non-void function... >> >> I was referring to »clang-tidy« with »-checks=* -Weverything -W >> -Wall«. > > Note this is a guideline, not a language standard rule. > > If you refer to the relevant style guideline > (https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions) > it includes the note: > > "Parameter names may be omitted only if the parameter is unused and its > purpose is obvious." > > So clang-tidy is being over zealous. > Warnings, especially those selected by flags like this, are always going to be viewed differently by different people. /You/ think this particular check is over zealous - other people think differently. I am not sure when a parameter might be unnamed, unused, and it's purpose obvious. The only case I can think of is when you are using one of these single-item empty classes, like nothrow_t, or perhaps operator++(int), where the parameter exists only to get the desired overload. But maybe you are thinking of other examples? (Perhaps even one relevant to C and not C++, but I'd be interested in C++ cases too.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-02 14:15 +1300 |
| Message-ID | <ectnt9Fq0soU5@mid.individual.net> |
| In reply to | #100842 |
On 01/ 2/17 01:53 PM, David Brown wrote: > On 01/01/17 21:38, Ian Collins wrote: >> On 01/ 2/17 09:11 AM, Stefan Ram wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>>> On 01/ 2/17 08:54 AM, Stefan Ram wrote: >>>>> Ian Collins <ian-news@hotmail.com> writes: >>>>>> I wonder why C hasn't adopted the simple rule from C++: if a parameter >>>>>> isn't going to be used, don't give it a name. >>>>> There's a style checker for C++ in clang, and when I write: >>>> It should be telling that control reaches end of non-void function... >>> >>> I was referring to »clang-tidy« with »-checks=* -Weverything -W >>> -Wall«. >> >> Note this is a guideline, not a language standard rule. >> >> If you refer to the relevant style guideline >> (https://google.github.io/styleguide/cppguide.html#Function_Declarations_and_Definitions) >> it includes the note: >> >> "Parameter names may be omitted only if the parameter is unused and its >> purpose is obvious." >> >> So clang-tidy is being over zealous. >> > > Warnings, especially those selected by flags like this, are always going > to be viewed differently by different people. /You/ think this > particular check is over zealous - other people think differently. Don't forget that this isn't a compiler warning: it is a style checker warning. As we all know, style is subjective. C++ specifically allows unnamed parameters for this very case, so the style warning is over zealous. > I am not sure when a parameter might be unnamed, unused, and it's > purpose obvious. The only case I can think of is when you are using one > of these single-item empty classes, like nothrow_t, or perhaps > operator++(int), where the parameter exists only to get the desired > overload. But maybe you are thinking of other examples? (Perhaps even > one relevant to C and not C++, but I'd be interested in C++ cases too.) The most common use case in C would be functions called through a table of pointers. In C++ it could also be a function called in a template. One example that comes to mind is something like an open function for a device where some devices use control flag parameter values and others don't. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-02 02:28 -0800 |
| Message-ID | <kfnvatxsqmj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100805 |
Ian Collins <ian-news@hotmail.com> writes:
> On 01/ 2/17 04:00 AM, David Brown wrote:
>> On 30/12/16 16:55, BartC wrote:
>>> On 30/12/2016 14:00, David Brown wrote:
>>>> On 30/12/16 14:04, BartC wrote:
>>>>
>>>>> Not even 'Unused parameter'?
>>>>
>>>> int foo(int a) {
>>>> (void) a;
>>>> return 123;
>>>
>>> Ugly.
>>
>> It is less ugly than incorrect code - and code that does not use the
>> parameters is, IME at least, usually wrong or at least an indication of
>> inefficiency somewhere. It is not /always/ wrong, of course, but usually.
>
> I wonder why C hasn't adopted the simple rule from C++: if a parameter
> isn't going to be used, don't give it a name.
Perhaps because the C community doesn't agree with the premise
that the problem is one that needs solving.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-31 06:24 +1300 |
| Message-ID | <ecnjj0Fpuo9U15@mid.individual.net> |
| In reply to | #100650 |
On 12/31/16 02:04 AM, BartC wrote: > On 30/12/2016 11:07, David Brown wrote: >> >> First, you write code in sensible sizes. Second, you use a build system >> that only re-compiles what it has to - so only the file you have changed >> needs re-compiled. And third, so what if it takes a couple of seconds >> in the background for the compilation to finish? >> >> If you have a big project, you might want to separate the link stage >> from the compilation stages, since a big link takes time and it is often >> not convenient to structure your code for partial linking. But >> compilation of the file you are working on, while working on it, is >> rarely an issue. > > Seems to be a lot of pandering to the compiler to me: > > - Having to keep file sizes small Pandering to good design. > - Having to structure the project differently Pandering to good design. > - Having to use an external manager smart enough to > know when not to compile modules Such tool have been around since before I started programming in the 70s... > - Having to use a separate faster machine to compile on > when the target would be too slow So do you install a compiler on your ARM Cortex-M3 development board and compile your 5000 line file there? If you are lucky enough to have one of bigger parts, you might just be able to get most of the file into RAM. > Just my view... Not based on working on any non-trivial C projects no doubt. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-30 17:53 +0000 |
| Message-ID | <o466rs$kdo$1@dont-email.me> |
| In reply to | #100684 |
On 30/12/2016 17:24, Ian Collins wrote: > On 12/31/16 02:04 AM, BartC wrote: > >> - Having to use a separate faster machine to compile on >> when the target would be too slow > > So do you install a compiler on your ARM Cortex-M3 development board and > compile your 5000 line file there? If you are lucky enough to have one > of bigger parts, you might just be able to get most of the file into RAM. It might have trouble running gcc at all then, if it is some embedded device. But the machine in question was an early Raspberry Pi, with 32-bit 700MHz processor, 512MB ram I think, 4GB SD storage and HD display. It runs gcc, a GUI desktop, and a browser. This had gcc running at something over 100lps optimised, or 500lps unoptimised. The same machine can copy a 100-file directory of perhaps 10 MB (how the hell you get 'ls' to sum all the file sizes?) in some 0.2 seconds elapsed time. The same machine can compile source to byte-code at ten of thousands of lines per second. So the hardware is more than capable; the culprit is clearly gcc. >> Just my view... > > Not based on working on any non-trivial C projects no doubt. I keep my projects small. That is also a skill. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-30 10:01 -0800 |
| Message-ID | <93b875e5-86ab-472a-a3b8-d35805cd20c8@googlegroups.com> |
| In reply to | #100687 |
On Friday, December 30, 2016 at 11:53:40 AM UTC-6, Bart wrote:
>(how the
> hell you get 'ls' to sum all the file sizes?)
I usually resort to awk
$ ls -l|awk '{sum+=$5}END{print sum}'
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-31 09:57 +1300 |
| Message-ID | <eco013Fpuo9U16@mid.individual.net> |
| In reply to | #100687 |
On 12/31/16 06:53 AM, BartC wrote: > On 30/12/2016 17:24, Ian Collins wrote: >> On 12/31/16 02:04 AM, BartC wrote: > >>> Just my view... >> >> Not based on working on any non-trivial C projects no doubt. > > I keep my projects small. That is also a skill. It is also a luxury mainly enjoyed by solo programmers. When there are 40+ people working on the code solid processes are essential. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 13:50 -0800 |
| Message-ID | <bb41d7d3-f47c-4615-971e-acea01084e5d@googlegroups.com> |
| In reply to | #100684 |
On Friday, December 30, 2016 at 11:25:00 AM UTC-6, Ian Collins wrote: > On 12/31/16 02:04 AM, BartC wrote: > > Seems to be a lot of pandering to the compiler to me: > > > > - Having to keep file sizes small > > Pandering to good design. There is a lot to be said for being able to simply feed a single file to a compiler and hit "go", without having to configure projects, make files, or anything else, especially if a compiler is fast enough that executable files can be considered "disposable".
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-31 11:09 +1300 |
| Message-ID | <eco490Fpuo9U17@mid.individual.net> |
| In reply to | #100702 |
On 12/31/16 10:50 AM, supercat@casperkitty.com wrote: > On Friday, December 30, 2016 at 11:25:00 AM UTC-6, Ian Collins wrote: >> On 12/31/16 02:04 AM, BartC wrote: >>> Seems to be a lot of pandering to the compiler to me: >>> >>> - Having to keep file sizes small >> >> Pandering to good design. > > There is a lot to be said for being able to simply feed a single file to a > compiler and hit "go", without having to configure projects, make files, or > anything else, especially if a compiler is fast enough that executable files > can be considered "disposable". There's a nothing good to be said about having to merge several other people's changes with yours in said single file... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 14:46 -0800 |
| Message-ID | <cbf7080e-877b-4246-a292-ab278b1ba67d@googlegroups.com> |
| In reply to | #100706 |
On Friday, December 30, 2016 at 4:09:44 PM UTC-6, Ian Collins wrote: > There's a nothing good to be said about having to merge several other > people's changes with yours in said single file... Actually, there is something good to be said about it compared with having to merge changes that involve multiple files. Handling independent changes to disjoint files is often much easier than handling independent changes made to the same file, *but* it can also create issues that would not arise when working with disparate versions of discrete files. Besides--it's possible to work with something as a group of files that are #included from a master build file. It may be necessary to use a naming convention to prevent name clashes between what would otherwise be static identifiers, but given a fast compiler such an approach may yield fewer surprises than trying to work with separately-compiled modules.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-31 12:28 +1300 |
| Message-ID | <eco8thFq02kU1@mid.individual.net> |
| In reply to | #100710 |
On 12/31/16 11:46 AM, supercat@casperkitty.com wrote: > On Friday, December 30, 2016 at 4:09:44 PM UTC-6, Ian Collins wrote: >> There's a nothing good to be said about having to merge several other >> people's changes with yours in said single file... > > Actually, there is something good to be said about it compared with having > to merge changes that involve multiple files. No, there isn't. I spent several months as build master on one project which included pulling in changes from a couple of other teams who shared the code base. The most pain came from a few big files. Simple changes git handles well, conflicts it does not. > Handling independent changes > to disjoint files is often much easier than handling independent changes made > to the same file, *but* it can also create issues that would not arise when > working with disparate versions of discrete files. Such as? > Besides--it's possible to work with something as a group of files that are > #included from a master build file. It may be necessary to use a naming > convention to prevent name clashes between what would otherwise be static > identifiers, but given a fast compiler such an approach may yield fewer > surprises than trying to work with separately-compiled modules. Surprises? Fewer, bigger files kill both build times and developer productivity for anything other than single person projects. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 16:01 -0800 |
| Message-ID | <c26e1a2a-734e-4f5f-bef5-673fd51a6c8a@googlegroups.com> |
| In reply to | #100715 |
On Friday, December 30, 2016 at 5:28:57 PM UTC-6, Ian Collins wrote: > On 12/31/16 11:46 AM,supercat wrote: > > On Friday, December 30, 2016 at 4:09:44 PM UTC-6, Ian Collins wrote: > >> There's a nothing good to be said about having to merge several other > >> people's changes with yours in said single file... > > > > Actually, there is something good to be said about it compared with having > > to merge changes that involve multiple files. > > No, there isn't. > > I spent several months as build master on one project which included > pulling in changes from a couple of other teams who shared the code > base. The most pain came from a few big files. Simple changes git > handles well, conflicts it does not. For changes which are independent, that is true. > > Handling independent changes > > to disjoint files is often much easier than handling independent changes made > > to the same file, *but* it can also create issues that would not arise when > > working with disparate versions of discrete files. > > Such as? Situations where a change to one library affect the behavior of a second library which is then used by the main code, and where such changes in the behavior of the second library necessitate changes to the main code. If the main code doesn't use the first library directly, it may not be clear that changes to it would affect the main code. > > Besides--it's possible to work with something as a group of files that are > > #included from a master build file. It may be necessary to use a naming > > convention to prevent name clashes between what would otherwise be static > > identifiers, but given a fast compiler such an approach may yield fewer > > surprises than trying to work with separately-compiled modules. > > Surprises? > > Fewer, bigger files kill both build times and developer productivity for > anything other than single person projects. Surprises, like discovering that something had changed in such a way that a file needed to be recompiled but for whatever reason the make utility hadn't noticed. As for build times, I used to routinely do full builds on Pascal programs which were around the 2,000-line mark on a 4.77MHz 8088 with a really slow hard drive. Since that time, machine speeds have increased more than a thousandfold. I recognize that partial builds will be needed when things get into the millions of lines, but a lot of compilers get really slow with projects that are a lot smaller than that. Rather than saying that slow compilation should be acceptable because it isn't necessary to rebuild everything, and then saying that a developer should accept the limitations of a partial-build system because that's the only way to avoid wasting time waiting for slow rebuilds, how about instead recognizing ways of making full builds fast enough to avoid the need for partial builds on small-to-mid-sized projects?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-30 14:48 -0800 |
| Message-ID | <6f47f591-6c91-44d5-aed4-649483b8e602@googlegroups.com> |
| In reply to | #100706 |
On Friday, December 30, 2016 at 10:09:44 PM UTC, Ian Collins wrote: > On 12/31/16 10:50 AM, supercat@casperkitty.com wrote: > > On Friday, December 30, 2016 at 11:25:00 AM UTC-6, Ian Collins wrote: > >> On 12/31/16 02:04 AM, BartC wrote: > >>> Seems to be a lot of pandering to the compiler to me: > >>> > >>> - Having to keep file sizes small > >> > >> Pandering to good design. > > > > There is a lot to be said for being able to simply feed a single file to a > > compiler and hit "go", without having to configure projects, make files, or > > anything else, especially if a compiler is fast enough that executable files > > can be considered "disposable". > > There's a nothing good to be said about having to merge several other > people's changes with yours in said single file... > git's automatic merge is very good. I will admit that for mission-critical embedded work such as you do it raises issues of testing for inadvertent admission of bugs. For graphics work, that isn't such an issue (you'll tend to see the bug soon enough).
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web