Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63160 > unrolled thread
| Started by | kuznecov.alexey@gmail.com |
|---|---|
| First post | 2015-06-10 12:38 -0700 |
| Last post | 2015-06-18 20:38 +0000 |
| Articles | 20 on this page of 96 — 21 participants |
Back to article view | Back to comp.lang.c
sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 12:38 -0700
Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-10 16:00 -0400
Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:53 -0700
Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 13:11 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 21:21 +0100
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-10 22:08 +0100
Re: sizeof(arr[0]) Andrew Cooper <amc96@cam.ac.uk> - 2015-06-11 00:27 +0100
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:34 +0100
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:38 +0100
Re: writing code for people who don't know the language (was: sizeof(arr[0])) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-10 21:16 -0400
Re: writing code for people who don't know the language Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 02:35 +0100
Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:16 +0100
Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:29 +0100
Re: writing code for people who don't know the language gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-11 11:43 +0000
Re: sizeof(arr[0]) Paul N <gw7rib@aol.com> - 2015-06-14 13:13 -0700
Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-14 17:52 -0700
Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:26 -0400
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 19:34 +0100
Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:55 -0400
Re: sizeof(arr[0]) Melzzzzz <melz@zzzzz.com> - 2015-06-15 20:59 +0200
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 20:11 +0100
Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 15:22 -0400
Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-16 09:51 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 10:51 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 19:14 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:43 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 20:03 +0100
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:15 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:34 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 20:28 +0100
Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 15:42 -0400
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:35 -0700
Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 16:59 -0400
Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-16 22:05 +0100
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:27 -0700
Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-17 07:07 +0100
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 01:22 +0100
Re: sizeof(arr[0]) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-16 19:45 +0000
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:03 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:58 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 05:58 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:46 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:14 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 17:58 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:07 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:09 -0700
Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:46 -0700
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:13 -0700
Re: sizeof(arr[0]) Nathan Wagner <nw@hydaspes.if.org> - 2015-06-18 07:14 +0000
Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 09:54 +0200
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-18 05:19 -0700
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 10:53 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 11:17 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 13:59 -0700
Re: sizeof(arr[0]) Ian Collins <ian-news@hotmail.com> - 2015-06-18 13:41 +1200
Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:04 +0200
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:18 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:30 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:53 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:43 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:52 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:01 -0700
Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-16 23:49 +0200
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:58 -0700
Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-17 14:10 +0200
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 13:20 +0100
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:16 -0700
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:39 -0700
Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 18:38 +0000
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:45 -0700
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:22 -0700
Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 21:25 +0000
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 11:05 -0700
Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:15 -0400
Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:07 -0700
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:16 -0700
Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 10:22 -0700
Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-18 10:42 -0700
Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:41 -0700
Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 00:12 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:12 +0100
Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 09:12 -0700
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 17:32 +0100
Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:56 -0700
Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 23:53 +0100
Re: sizeof(arr[0]) Bartc <bc@freeuk.com> - 2015-06-11 00:33 +0100
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:37 +0100
Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 06:05 -0700
[OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-17 16:07 +0200
Re: [OT] The number 42 (was Re: sizeof(arr[0])) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:23 -0700
Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:21 +0200
Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:35 -0700
Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:18 +0200
Re: [OT] The number 42 (was Re: sizeof(arr[0])) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 10:08 +0100
Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 15:13 +0100
Re: sizeof(arr[0]) raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:38 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 05:58 -0700 |
| Message-ID | <0749ad55-972a-408a-b605-55213cd73225@googlegroups.com> |
| In reply to | #63394 |
On Wednesday, June 17, 2015 at 5:58:56 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > I would argue that "return(42);" does remove ambiguity over "return > > 42;". > > So your answer to "what possible ambiguity is there in return 42; that > is dispelled by writing return(42);" is "none", but you would, none the > less, "argue that return(42); does remove ambiguity over return 42;". I can see how that would be confusing. I explained it in a later post. "None" there means "below threshold," but not exactly 0, just not enough to warrant any need for parenthesis. However, using parenthesis does make it clearer. At least that's my opinion. Add that to $1 and you could get yourself a cup of coffee. Maybe. :-) > Do you mean that there is no ambiguity but, despite that, you would > argue that there was simply for the sake of arguing? No. I apologize for my wording. I hope it's clear now. > <snip> > >> Ah. If you think of return as a function we are on different planets. > > Same planet. Different points of view looking at the same thing. > > The analogy is intended to highlight the great distance between these > vantage points. Agreed. But the interesting thing about being on different planets, is that each has its own flavor, its own atmosphere, its own history, its own culture (or cultures). They grew up differently, but yet are both planets. Equal in status, but different in fundamentals. And that's okay you see, for it is the way of the entire universe. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 15:46 +0100 |
| Message-ID | <87wpz2tmt0.fsf@bsb.me.uk> |
| In reply to | #63402 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, June 17, 2015 at 5:58:56 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > I would argue that "return(42);" does remove ambiguity over "return >> > 42;". >> >> So your answer to "what possible ambiguity is there in return 42; that >> is dispelled by writing return(42);" is "none", but you would, none the >> less, "argue that return(42); does remove ambiguity over return 42;". > > I can see how that would be confusing. I explained it in a later post. > "None" there means "below threshold," but not exactly 0, just not enough > to warrant any need for parenthesis. However, using parenthesis does > make it clearer. But neither "none" nor "none above the threshold" (whatever that is) answers the question to which "none" what the answer. What is the ambiguity you spoke of that is removed by adding the parentheses? I get that you might simply have misspoken and meant to say "I like them" or something like that, but you spoke of and ambiguity being removed, and I can't see one, even if it is "below" some threshold -- I can't see it at all -- nada. One thing you may not know: the ()s were once required in a return statement. Seeing them makes me think the author is using an ancient dialect of C, and that makes go check a few things to be sure they are not. In that rather specialised way they confuse matters for me. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 08:14 -0700 |
| Message-ID | <0033c5c1-b015-4a3f-9011-1f44d796d5da@googlegroups.com> |
| In reply to | #63411 |
On Wednesday, June 17, 2015 at 10:46:44 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > On Wednesday, June 17, 2015 at 5:58:56 AM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> > I would argue that "return(42);" does remove ambiguity over "return > >> > 42;". > >> > >> So your answer to "what possible ambiguity is there in return 42; that > >> is dispelled by writing return(42);" is "none", but you would, none the > >> less, "argue that return(42); does remove ambiguity over return 42;". > > > > I can see how that would be confusing. I explained it in a later post. > > "None" there means "below threshold," but not exactly 0, just not enough > > to warrant any need for parenthesis. However, using parenthesis does > > make it clearer. > > But neither "none" nor "none above the threshold" (whatever that is) > answers the question to which "none" what the answer. What is the chance of rain today? None. Really? Yes, the weather forecast says no change of rain. Sunny all day. What about meteors? What? Suppose a meteor comes by and alters the atmosphere in some way? I suppose... What about earthquakes? Volcanoes? Something that we hadn't taken into account in our initial assessment of weather analysis? I see your point. Okay, the chance of rain is "None," which could of course mean there is a chance of rain in certain circumstances, or if something unlikely happens. So is it really "None?" No, not really. But for all practical purposes, yes. Yes it is. I understand. > What is the > ambiguity you spoke of that is removed by adding the parentheses? It just conveys completely that the value 42 is being input into the return, whereas "return 42;" probably conveys that meaning, and it would be natural to conclude it does, but there's no way to be 100% sure. It could be something like RET 42 in x86 assembly, which returns and pops 42 bytes off the stack in the process (though I suppose one could argue that return(42); could do the same thing). > I get > that you might simply have misspoken and meant to say "I like them" or > something like that, but you spoke of and ambiguity being removed, and I > can't see one, even if it is "below" some threshold -- I can't see it at > all -- nada. That's okay. Chocolate. Vanilla. They both exist for a reason. > One thing you may not know: the ()s were once required in a return > statement. Seeing them makes me think the author is using an ancient > dialect of C, and that makes go check a few things to be sure they are > not. In that rather specialised way they confuse matters for me. I did not know that. Interesting. I know that many C compilers today allow for the trailing , in a list because it's easier for generated code to not remove that trailing comma and just leave it there. I disagree with that as well because someone following along after in that code for maintenance would wonder "Did the original developer leave off some more data?" The same with not using the keyword "void" in something like "int f()" instead of "int f(void)" because it's much more difficult to accidentally type void than it is to accidentally leave it blank. And seeing it blank also begs the question, "Was the developer finished here? Did they mean to leave it blank, or is this placeholder code not yet developed?" My opinions. > <snip> > -- > Ben. I also have many tools in my arsenal. Parentheses is one of them. I also use horizontal character spacing, and vertical line spacing, and some type of text formatting in nearby comments to draw attention, etc. On the whole, I use parentheses far more places than they're needed by syntax, and I do it to make it more clear in source code what's transpiring. I use return(42); and am happy. I use sizeof(x) and am happy. I use other such things with parentheses and am happy. If you're happy without them, then I'm also happy for you. Happiness all around! :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-06-17 17:58 +0100 |
| Message-ID | <87381qtgpc.fsf@bsb.me.uk> |
| In reply to | #63417 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, June 17, 2015 at 10:46:44 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> > On Wednesday, June 17, 2015 at 5:58:56 AM UTC-4, Ben Bacarisse wrote: >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> >> > I would argue that "return(42);" does remove ambiguity over "return >> >> > 42;". >> >> >> >> So your answer to "what possible ambiguity is there in return 42; that >> >> is dispelled by writing return(42);" is "none", but you would, none the >> >> less, "argue that return(42); does remove ambiguity over return 42;". >> > >> > I can see how that would be confusing. I explained it in a later post. >> > "None" there means "below threshold," but not exactly 0, just not enough >> > to warrant any need for parenthesis. However, using parenthesis does >> > make it clearer. >> >> But neither "none" nor "none above the threshold" (whatever that is) >> answers the question to which "none" what the answer. > > What is the chance of rain today? > None. > Really? > Yes, the weather forecast says no change of rain. Sunny all day. > What about meteors? > What? > Suppose a meteor comes by and alters the atmosphere in some way? > I suppose... > > What about earthquakes? Volcanoes? Something that we hadn't taken > into account in our initial assessment of weather analysis? > > I see your point. Okay, the chance of rain is "None," which could > of course mean there is a chance of rain in certain circumstances, > or if something unlikely happens. > > So is it really "None?" > No, not really. But for all practical purposes, yes. Yes it is. > I understand. Eh? In what way is return(42); like weather? Saying there is no ambiguity does not mean there is none, barring asteroids, it means none. The analogy does not help me one bit -- i still have no idea what you meant to say. If all that was to illustrate the difference between the first answer, "none", and what you meant "none above threshold" then it was not needed. I get the difference -- I just don't know what the threshold is (but I also don't care so there's no need to explain it). >> What is the >> ambiguity you spoke of that is removed by adding the parentheses? > > It just conveys completely that the value 42 is being input into the > return, whereas "return 42;" probably conveys that meaning, and it > would be natural to conclude it does, but there's no way to be 100% > sure. It could be something like RET 42 in x86 assembly, which returns > and pops 42 bytes off the stack in the process (though I suppose one > could argue that return(42); could do the same thing). Sorry, but that's a nonsense justification. Someone might see the return(42); form as pushing an argument ans executing a call instruction. As you suggest, I can make up as many just-so stories as you can. >> I get >> that you might simply have misspoken and meant to say "I like them" or >> something like that, but you spoke of and ambiguity being removed, and I >> can't see one, even if it is "below" some threshold -- I can't see it at >> all -- nada. > > That's okay. Chocolate. Vanilla. They both exist for a reason. As I said, if you meant it's just a personal preference I'm OK with that, but instead I wasted time trying to find out what ambiguity the ()s remove (despite the clue that you said there was none on one occasion). This last remark suggest is is simply a personal choice, but above you try to offer a justification for it. <snip> > On the whole, I use parentheses far more places than they're needed > by syntax, Fine, but you might want to reconsider this remark: "I use return(x); everywhere in source code." <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 10:07 -0700 |
| Message-ID | <2048ecc4-c42e-490e-b4b0-a672efcf03df@googlegroups.com> |
| In reply to | #63431 |
On Wednesday, June 17, 2015 at 12:58:31 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Wednesday, June 17, 2015 at 10:46:44 AM UTC-4, Ben Bacarisse wrote: > >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> > On Wednesday, June 17, 2015 at 5:58:56 AM UTC-4, Ben Bacarisse wrote: > >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > >> >> > I would argue that "return(42);" does remove ambiguity over "return > >> >> > 42;". > >> >> > >> >> So your answer to "what possible ambiguity is there in return 42; that > >> >> is dispelled by writing return(42);" is "none", but you would, none the > >> >> less, "argue that return(42); does remove ambiguity over return 42;". > >> > > >> > I can see how that would be confusing. I explained it in a later post. > >> > "None" there means "below threshold," but not exactly 0, just not enough > >> > to warrant any need for parenthesis. However, using parenthesis does > >> > make it clearer. > >> > >> But neither "none" nor "none above the threshold" (whatever that is) > >> answers the question to which "none" what the answer. > > > > What is the chance of rain today? > > None. > > Really? > > Yes, the weather forecast says no change of rain. Sunny all day. > > What about meteors? > > What? > > Suppose a meteor comes by and alters the atmosphere in some way? > > I suppose... > > > > What about earthquakes? Volcanoes? Something that we hadn't taken > > into account in our initial assessment of weather analysis? > > > > I see your point. Okay, the chance of rain is "None," which could > > of course mean there is a chance of rain in certain circumstances, > > or if something unlikely happens. > > > > So is it really "None?" > > No, not really. But for all practical purposes, yes. Yes it is. > > I understand. > > Eh? In what way is return(42); like weather? Saying there is no > ambiguity does not mean there is none, barring asteroids, it means none. > The analogy does not help me one bit -- i still have no idea what you > meant to say. > > If all that was to illustrate the difference between the first answer, > "none", and what you meant "none above threshold" Check. > then it was not > needed. I get the difference -- I just don't know what the threshold > is (but I also don't care so there's no need to explain it). Check. > >> What is the > >> ambiguity you spoke of that is removed by adding the parentheses? > > > > It just conveys completely that the value 42 is being input into the > > return, whereas "return 42;" probably conveys that meaning, and it > > would be natural to conclude it does, but there's no way to be 100% > > sure. It could be something like RET 42 in x86 assembly, which returns > > and pops 42 bytes off the stack in the process (though I suppose one > > could argue that return(42); could do the same thing). > > Sorry, but that's a nonsense justification. Someone might see the > return(42); form as pushing an argument ans executing a call > instruction. As you suggest, I can make up as many just-so stories > as you can. Check. > >> I get > >> that you might simply have misspoken and meant to say "I like them" or > >> something like that, but you spoke of and ambiguity being removed, and I > >> can't see one, even if it is "below" some threshold -- I can't see it at > >> all -- nada. > > > > That's okay. Chocolate. Vanilla. They both exist for a reason. > > As I said, if you meant it's just a personal preference I'm OK with > that, but instead I wasted time trying to find out what ambiguity the > ()s remove (despite the clue that you said there was none on one > occasion). This last remark suggest is is simply a personal choice, but > above you try to offer a justification for it. It doesn't make "return(42);" less ambiguous, but it does make something like "return(lnBase + lnAdds - lnSubtracts);" less ambiguous than the equivalent "return lnBase + lnAdds - lnSubtracts;" I use that type of code in places where I return some calculation rather than assigning it first to a variable. Not always, but if it's an obvious thing I do. > <snip> > > On the whole, I use parentheses far more places than they're needed > > by syntax, > > Fine, but you might want to reconsider this remark: > > "I use return(x); everywhere in source code." If there is some place I haven't or don't, then it's an oversight on my behalf, or it's code I've missed from a contributor, or brought in either "as is" or "relatively as is" from another project. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 10:09 -0700 |
| Message-ID | <c41a0947-e1f7-4e3d-8845-66164339752c@googlegroups.com> |
| In reply to | #63433 |
On Wednesday, June 17, 2015 at 1:07:59 PM UTC-4, Rick C. Hodgin wrote: > On Wednesday, June 17, 2015 at 12:58:31 PM UTC-4, Ben Bacarisse wrote: > > Fine, but you might want to reconsider this remark: > > > > "I use return(x); everywhere in source code." > > If there is some place I haven't or don't, then it's an oversight on > my behalf, or it's code I've missed from a contributor, or brought > in either "as is" or "relatively as is" from another project. It could also be old code before I settled on this standard. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-06-17 10:46 -0700 |
| Message-ID | <76f793c2-6b49-4388-8ea2-615687d56047@googlegroups.com> |
| In reply to | #63434 |
On Wednesday, June 17, 2015 at 10:10:07 AM UTC-7, Rick C. Hodgin wrote: > On Wednesday, June 17, 2015 at 1:07:59 PM UTC-4, Rick C. Hodgin wrote: > > On Wednesday, June 17, 2015 at 12:58:31 PM UTC-4, Ben Bacarisse wrote: > > > Fine, but you might want to reconsider this remark: > > > > > > "I use return(x); everywhere in source code." > > > > If there is some place I haven't or don't, then it's an oversight on > > my behalf, or it's code I've missed from a contributor, or brought > > in either "as is" or "relatively as is" from another project. > > It could also be old code before I settled on this standard. :-) I have tried but I can't agree even agree that return(x) is a "function". To me that means "return" the expression "(x)". But then I remember how Pascal did "returns". At the end of function "foo" it returned value "x" by foo = x C could have done this but chose not to.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 11:13 -0700 |
| Message-ID | <lnsi9qjj9t.fsf@nuthaus.mib.org> |
| In reply to | #63433 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
[...]
> > It doesn't make "return(42);" less ambiguous, but it does make something
> like "return(lnBase + lnAdds - lnSubtracts);" less ambiguous than the
> equivalent "return lnBase + lnAdds - lnSubtracts;"
No, it doesn't.
The syntax of a return statement is
return expression[opt] ;
There is no operator precedence outside the (optional) expression.
There is no way that
return x + y - z;
could be treated as
(return x) + y - z;
or could be interpreted that way by anyone who knows the C language.
Someone ignorant of C *might* make that mistake, but there's no way you
can make your C code explicit enough to avoid any such
misunderstandings.
If you want to use extra parentheses, go ahead. If you continue to post
invalid justifications for doing so, we will continue to refute them.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Nathan Wagner <nw@hydaspes.if.org> |
|---|---|
| Date | 2015-06-18 07:14 +0000 |
| Message-ID | <slrnmo4rv7.8fr.nw@granicus.if.org> |
| In reply to | #63446 |
On 2015-06-17, Keith Thompson <kst-u@mib.org> wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > [...] >> > It doesn't make "return(42);" less ambiguous, but it does make something >> like "return(lnBase + lnAdds - lnSubtracts);" less ambiguous than the >> equivalent "return lnBase + lnAdds - lnSubtracts;" > > No, it doesn't. One wonders if Mr Hodgin thinks that "(a * b) + c" is less ambiguous than "a * b + c". AFAIK the C specification is not ambiguous in itself, so the only thing left is how easy it is for a human to understand by looking at it. Parentheses on a return statement always make me do a double take and instead of just noting that a value is being returned and moving on, I now have to look at the code to make sure nothing else goofy is happening. Furthermore, if the ( is right next to the return, I can't use my whitespace pattern recognition apparatus to quickly find the return statement(s) in a function. -- nw
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-18 09:54 +0200 |
| Message-ID | <mlttca$2mf$1@dont-email.me> |
| In reply to | #63482 |
On 18/06/15 09:14, Nathan Wagner wrote: > On 2015-06-17, Keith Thompson <kst-u@mib.org> wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> [...] >>>> It doesn't make "return(42);" less ambiguous, but it does make something >>> like "return(lnBase + lnAdds - lnSubtracts);" less ambiguous than the >>> equivalent "return lnBase + lnAdds - lnSubtracts;" >> >> No, it doesn't. > > One wonders if Mr Hodgin thinks that "(a * b) + c" is less ambiguous > than "a * b + c". > > AFAIK the C specification is not ambiguous in itself, so the only thing > left is how easy it is for a human to understand by looking at it. To me, it sounds like Rick is using a poor choice of words with "ambiguous" - his posts would make more sense if it were replaced with "clearer". "return lnBase + lnAdds - lnSubtracts;" is not in any way ambiguous - there is only one possible interpretation of it in C. However, it is fair to argue that "return (lnBase + lnAdds - lnSubtracts);" is /clearer/ to a human reader, or faster for a human to parse - it is immediately obvious that the expression in brackets should be calculated, and the result returned. Obviously it is a matter of personal opinion whether the brackets improve readability here, but it would not be an unreasonable opinion.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-18 05:19 -0700 |
| Message-ID | <fdf90ed0-076b-4be8-a5ef-8ecf3ac98d63@googlegroups.com> |
| In reply to | #63482 |
On Thursday, June 18, 2015 at 3:15:24 AM UTC-4, Nathan Wagner wrote:
> On 2015-06-17, Keith Thompson <kst-u@mib.org> wrote:
> > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > [...]
> >> > It doesn't make "return(42);" less ambiguous, but it does make something
> >> like "return(lnBase + lnAdds - lnSubtracts);" less ambiguous than the
> >> equivalent "return lnBase + lnAdds - lnSubtracts;"
> >
> > No, it doesn't.
>
> One wonders if Mr Hodgin thinks that "(a * b) + c" is less ambiguous
> than "a * b + c".
Yes I do. :-)
But, perhaps the word I should've been using, as David Brown points
out, is "clearer" rather than "less ambiguous."
Ambiguous, adj
1. open to or having several possible meanings or interpretations;
equivocal: an ambiguous answer.
2. Linguistics. (of an expression) exhibiting constructional
homonymity; having two or more structural descriptions, as
the sequence Flying planes can be dangerous.
3. of doubtful or uncertain nature; difficult to comprehend,
distinguish, or classify:
a rock of ambiguous character.
4. lacking clearness or definiteness; obscure; indistinct:
an ambiguous shape; an ambiguous future.
I would have been using the #3 definition there, specifically the
"difficult to comprehend, DISTINGUISH, or classify," reference.
Use of "clearer" probably does make my meaning clearer, and therefore
also less ambiguous in certain circles. :-)
[Thank you, David.]
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-17 10:53 -0700 |
| Message-ID | <lna8vykyrj.fsf@nuthaus.mib.org> |
| In reply to | #63417 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, June 17, 2015 at 10:46:44 AM UTC-4, Ben Bacarisse wrote:
[...]
>> What is the
>> ambiguity you spoke of that is removed by adding the parentheses?
>
> It just conveys completely that the value 42 is being input into the
> return, whereas "return 42;" probably conveys that meaning, and it
> would be natural to conclude it does, but there's no way to be 100%
> sure. It could be something like RET 42 in x86 assembly, which returns
> and pops 42 bytes off the stack in the process (though I suppose one
> could argue that return(42); could do the same thing).
There is no ambiguity. None. Zero. `return 42;` and `return(42);`
mean exactly the same thing in C.
If I see a return statement with parentheses in C code written in the
last 30 years, my first assumption will be that the author doesn't know
the language very well. That can be useful if it's true; it means I'll
be on the lookout for other problems. If the author has communicated
that he or she *does* know the language and simply prefers the
parentheses, that's a different matter.
I don't object to your using unnecessary parentheses in your code. I'm
responding only because your claimed reasons for doing so are not valid.
You don't *need* to have a reason, or to tell us what it is. My only
concern here is with accuracy. (I personally find code that doesn't use
parentheses on return statements cleaner and easier to read, and as
you've seen I'm glad to expound on that point, but that imposes no
obligation on anyone else.)
[...]
> I did not know that. Interesting. I know that many C compilers today
> allow for the trailing , in a list because it's easier for generated
> code to not remove that trailing comma and just leave it there.
That's not just a matter of "many C compilers". It's specified by the
language grammar. Trailing commas are permitted in some contexts
(particularly enumeration lists and initializers), but not in others
(argument lists, for example). This was a grammar change in C99, so
pre-C99 compilers might not permit trailing commas even in those
contexts.
> I
> disagree with that as well because someone following along after in
> that code for maintenance would wonder "Did the original developer
> leave off some more data?"
Any such doubt is easily cured by understanding that it's a language
feature.
> The same with not using the keyword "void"
> in something like "int f()" instead of "int f(void)" because it's
> much more difficult to accidentally type void than it is to
> accidentally leave it blank. And seeing it blank also begs the
> question, "Was the developer finished here? Did they mean to leave
> it blank, or is this placeholder code not yet developed?"
`int f()` and `int f(void)` have different meanings. You can often get
away with using `int f()`, but it's poor style and can lead to
undiagnosed errors.
[...]
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 11:17 -0700 |
| Message-ID | <9ea0f74e-161f-4707-9fec-5756a9497d87@googlegroups.com> |
| In reply to | #63441 |
On Wednesday, June 17, 2015 at 1:53:15 PM UTC-4, Keith Thompson wrote: > There is no ambiguity. None. Zero. `return 42;` and `return(42);` > mean exactly the same thing in C. Okay. Sorry. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-17 13:59 -0700 |
| Message-ID | <768c3ed7-7526-4b46-aa06-41d7f8dd79dc@googlegroups.com> |
| In reply to | #63448 |
On Wednesday, June 17, 2015 at 1:53:15 PM UTC-4, Keith Thompson wrote: > There is no ambiguity. None. Zero. `return 42;` and `return(42);` > mean exactly the same thing in C. Something occurred to me here in re-reading your reply. I wasn't speaking specifically about C, or C's syntax, but rather about general code readability. Using the parentheses makes it less ambiguous for the human mind and eye in my opinion. A person without special training would recognize the abc(xyz) format sooner than they would recognize abc xyz format in my opinion. At the very least they might think (42) was a footnote number, but they would definitely know it was something associated with the "return". This is just my opinion, and it is a general observation, not one specific to C, but one that I do see in several places in C. It would be interested to conduct a poll of 50 random people at a university. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-06-18 13:41 +1200 |
| Message-ID | <cuelulFkitsU1@mid.individual.net> |
| In reply to | #63461 |
Rick C. Hodgin wrote: > On Wednesday, June 17, 2015 at 1:53:15 PM UTC-4, Keith Thompson wrote: >> There is no ambiguity. None. Zero. `return 42;` and `return(42);` >> mean exactly the same thing in C. > > Something occurred to me here in re-reading your reply. I wasn't > speaking specifically about C, or C's syntax, but rather about general > code readability. > > Using the parentheses makes it less ambiguous for the human mind and > eye in my opinion. A person without special training would recognize > the abc(xyz) format sooner than they would recognize abc xyz format > in my opinion. At the very least they might think (42) was a footnote > number, but they would definitely know it was something associated > with the "return". I'm sure I'm not alone in thinking the parentheses makes it more ambiguous - it makes a return look like another function call... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-18 10:04 +0200 |
| Message-ID | <mltu0d$4sb$1@dont-email.me> |
| In reply to | #63441 |
On 17/06/15 19:53, Keith Thompson wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
>
>> I did not know that. Interesting. I know that many C compilers today
>> allow for the trailing , in a list because it's easier for generated
>> code to not remove that trailing comma and just leave it there.
>
> That's not just a matter of "many C compilers". It's specified by the
> language grammar. Trailing commas are permitted in some contexts
> (particularly enumeration lists and initializers), but not in others
> (argument lists, for example). This was a grammar change in C99, so
> pre-C99 compilers might not permit trailing commas even in those
> contexts.
I find the trailing comma useful in some types of code:
typedef void (*FVoid)(void);
static const FVoid thingsToDo[] = {
doThis, // An important task
doThat, // Another task
doSomething, // Less important
doAnotherThing, // Critical task
};
The trailing comma makes the entries more consistent, easier to
re-arrange, and easier to extend. It's a small thing, but nice -
especially when you want to compare two versions of the code and see
what has /really/ changed.
(It is a nice enough feature that C++11 adopted it too.)
>
>> I
>> disagree with that as well because someone following along after in
>> that code for maintenance would wonder "Did the original developer
>> leave off some more data?"
>
> Any such doubt is easily cured by understanding that it's a language
> feature.
>
>> The same with not using the keyword "void"
>> in something like "int f()" instead of "int f(void)" because it's
>> much more difficult to accidentally type void than it is to
>> accidentally leave it blank. And seeing it blank also begs the
>> question, "Was the developer finished here? Did they mean to leave
>> it blank, or is this placeholder code not yet developed?"
>
> `int f()` and `int f(void)` have different meanings. You can often get
> away with using `int f()`, but it's poor style and can lead to
> undiagnosed errors.
>
The confusion here is sometimes caused by f() and f(void) being the same
thing in C++, unlike in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-06-16 13:18 -0700 |
| Message-ID | <lnd20vmmol.fsf@nuthaus.mib.org> |
| In reply to | #63363 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Tuesday, June 16, 2015 at 2:15:27 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>> > On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
>> >> One way to think of it is that "sizeof (int)" is the sizeof operator
>> >> acting on a type cast and "sizeof x" is the operator acting on a
>> >> variable (like "& x") - and to forget that "sizeof (x)" is possible.
>> >
>> > It's why sizeof should always be sizeof(), and never sizeof. I feel
>> > the same way about return (it should always be return() rather than
>> > return, and the same for other similar keywords).
>>
>> Do you write long(x); ++(p) and/or *(p) all the time?
>
> Yes. Every time. :-)
>
> No, of course not. But I do write it on things like sizeof(), and
> other similar things because I do look at them as a type of function.
Well there's your problem right there.
'sizeof" is not a function (nor is it a macro). It's an operator
whose symbol happens to be a keyword. It behaves in a number of
ways that are very different from the way functions behave: the
operand is usually not evaluated, the result depends only on the
type of the operand, and so forth.
The only things that's special about `sizeof` relative to other
operators are that (a) its symbol happens to be a keyword rather
than punctuation, and (b) its operand (not argument) can be either
an expression or a parenthesized type name (note that functions
cannot take type names as arguments).
Imagine a language that's identical to C, except that it spells
`sizeof` as `$"` Would you still insist on writing `$(x)`, or
would you be willing to write `$ x` or `$x`?
You can construct a mental model that treats "sizeof" as if it
were a function. If you do so carefully enough, and keep in mind
the special cases that result from the inconsistencies between
that model and reality, you can write consistent and correct code.
But IMHO that's a lot more effort than just learning what "sizeof"
really is. To do it reliably, you have to understand both your
mental model and the actual syntax and semantics of the language,
so you can avoid the inconsistencies.
[...]
> None. There's also no ambiguity in return x; or return result; I
> prefer for it to be return(42);, return(x), and return(result). I
> view those also as functions because I am giving it some input, and
> it is giving me an output (which happens to be the same value, though
> in some cases it is cast through a function, such as "return(2);" when
> 2 must be translated to a float. As such ... function, just one that
> happens to be a compile-time function, rather than runtime.
Similarly, "return" is a keyword, not a function, and it's used
as part of a "return statement", which has its own unique syntax
that's not related to function call syntax.
A return statement, unlike a function call, doesn't yield a result;
you can't write `x = return 42;`. It causes the function in which
it occurs to return a result, which then becomes the value yielded
by the function call expression. *Very* different.
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-16 21:30 +0100 |
| Message-ID | <mlq0ug$les$1@dont-email.me> |
| In reply to | #63373 |
On 16/06/15 21:18, Keith Thompson wrote: <snip> > Similarly, "return" is a keyword, not a function, and it's used > as part of a "return statement", which has its own unique syntax > that's not related to function call syntax. In fact, we run into considerable difficulties if we consider "return" to be a function. A function returns either void (nothing) or a value of a particular type. What type, then, does return() have? If it returns void, then it cannot achieve its (general) purpose, which is to provide the return value for a function that calls it. But if it returns any other type, we have to answer the question of what type it should return, and there does not seem to be a single suitable type. And we also encounter another problem. Since return() is the mechanism by which functions return, return() must itself call return(), and there is no base case - it's return()s all the way down. -- 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]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-16 13:53 -0700 |
| Message-ID | <7859379f-69fa-485e-8777-cf5dcb335206@googlegroups.com> |
| In reply to | #63375 |
On Tuesday, June 16, 2015 at 4:30:31 PM UTC-4, Richard Heathfield wrote:
> On 16/06/15 21:18, Keith Thompson wrote:
>
> <snip>
>
> > Similarly, "return" is a keyword, not a function, and it's used
> > as part of a "return statement", which has its own unique syntax
> > that's not related to function call syntax.
>
> In fact, we run into considerable difficulties if we consider "return"
> to be a function. A function returns either void (nothing) or a value of
> a particular type. What type, then, does return() have? If it returns
> void, then it cannot achieve its (general) purpose, which is to provide
> the return value for a function that calls it.
That is not its function. That is one form of its function. It has
another function (overloaded) which allows it to execute the same
mechanics that are required to return control to the caller, but without
preparing the return value. And I'd wager that there are flavors of C
out there that, were we to examine the assembly code they generate,
actually do return an implicit 0 value in the case of a void return,
which is then simply discarded by the caller.
> But if it returns any
> other type, we have to answer the question of what type it should
> return, and there does not seem to be a single suitable type.
Overloading. A function created at compile-time by the compiler to
conduct those various tasks.
> And we also encounter another problem. Since return() is the mechanism
> by which functions return, return() must itself call return(), and there
> is no base case - it's return()s all the way down.
Nonsense. :-) Return is called, which interrogates the machine in the
manner required to execute the functionality of the return() function,
which is to leave this place and go back to where it came from. That
is a function as much as cos(x) is a function.
cos(x) will load some value x into the machine's hardware, or into the
software emulation load value, interrogate the machine to compute the
result, and store that result in the location that machine uses to
convey values through expressions.
return() will load some value x into the machine's hardware, or not if
it's void, and then interrogate the machine to execute the hard return
back to the caller, which completes its part of the transaction which
then completes upon return where that value is then possibly retrieved,
but ultimately employed in whatever way is required to proceed through
the expression, just as in cos(x).
cos(x) calls a function which may translate into direct machine hardware
instructions (assembly, load x, cos, store t).
return(x) calls a function which does translate into direct machine
hardware instructions, optionally storing the result given it as input,
and then interrogating the machine to perform the hard return.
I see it as a full function, but with one limitation: It is terminal.
It cannot be used as:
y = cos(return(42));
...because the return function will preclude the continuation of that
code, and therefore must generate a syntax error in this case because
the surrounding expression cannot be executed with the mechanical
limitations of that which return does.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-06-16 13:43 -0700 |
| Message-ID | <c9c28771-abc5-41df-8d09-7d7b004d0e3e@googlegroups.com> |
| In reply to | #63373 |
On Tuesday, June 16, 2015 at 4:18:59 PM UTC-4, Keith Thompson wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > On Tuesday, June 16, 2015 at 2:15:27 PM UTC-4, Ben Bacarisse wrote:
> >> Do you write long(x); ++(p) and/or *(p) all the time?
> > No, of course not. But I do write it on things like sizeof(), and
> > other similar things because I do look at them as a type of function.
>
> Well there's your problem right there.
>
> 'sizeof" is not a function (nor is it a macro). It's an operator
> whose symbol happens to be a keyword. It behaves in a number of
> ways that are very different from the way functions behave: the
> operand is usually not evaluated, the result depends only on the
> type of the operand, and so forth.
>
> The only things that's special about `sizeof` relative to other
> operators are that (a) its symbol happens to be a keyword rather
> than punctuation, and (b) its operand (not argument) can be either
> an expression or a parenthesized type name (note that functions
> cannot take type names as arguments).
>
> Imagine a language that's identical to C, except that it spells
> `sizeof` as `$"` Would you still insist on writing `$(x)`, or
> would you be willing to write `$ x` or `$x`?
I would write this every time:
$((*p)->x)
Every time. Without reservation. Unless I was threatened in some
way, in which case I would probably yield.
> You can construct a mental model that treats "sizeof" as if it
> were a function. If you do so carefully enough, and keep in mind
> the special cases that result from the inconsistencies between
> that model and reality, you can write consistent and correct code.
> But IMHO that's a lot more effort than just learning what "sizeof"
> really is. To do it reliably, you have to understand both your
> mental model and the actual syntax and semantics of the language,
> so you can avoid the inconsistencies.
I have never found an inconsistency in using that form. I'd be curious
to hear of one which could exist, after which I will likely explain
further how I would never code in that way. :-)
> > None. There's also no ambiguity in return x; or return result; I
> > prefer for it to be return(42);, return(x), and return(result). I
> > view those also as functions because I am giving it some input, and
> > it is giving me an output (which happens to be the same value, though
> > in some cases it is cast through a function, such as "return(2);" when
> > 2 must be translated to a float. As such ... function, just one that
> > happens to be a compile-time function, rather than runtime.
>
> Similarly, "return" is a keyword, not a function, and it's used
> as part of a "return statement", which has its own unique syntax
> that's not related to function call syntax.
>
> A return statement, unlike a function call, doesn't yield a result;
> you can't write `x = return 42;`. It causes the function in which
> it occurs to return a result, which then becomes the value yielded
> by the function call expression. *Very* different.
I see it as not different, because ... the "x = return 42;" operation
you state here really does exist, but it comes in the form "x = f();"
where the last thing done in f() for source code is "return 42;" which
then does assign to the value x and initiates whatever machine
mechanics are required to return from the function call, so as to
return control to the remainder of the mechanics first initiated in
the mechanics of executing f(), to then use that value for the
assignment.
"return" mechanically prepares something in a particular way so that
it can be received at the left-side of the thing which called it,
which is itself part of a mechanical process of execution. It is
all part of the same thing, and it is all some kind of logical
function.
I view it very much as a function because instead of taking a and b
and performing some discrete operation on it which yields an immediate
result, it takes input and executes several steps (some exposed only
internally within the machine, some externally in assembly opcodes),
to take that input value and wield it in such a way that it is then
usable beyond.
I've gotten by 45 years thinking and writing code this way ... well,
probably only 25 years or so because there was that time in there
before I'd ever heard of C, let alone coded in it.
BTW, 42 was Jackie Robinson's jersey number. I've often wondered if
that wasn't Adams' impetus in using that number for the answer to
why the universe exists ... ie, breaking down barriers, working
together, and doing our best.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web