- overuse of auto is dangerous - 5 Updates
- two's complement idea - 4 Updates
- Algorithms for integer ranges? - 5 Updates
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 02 07:13AM -0700 > [...] > Good reasons for using a different name for the same parameter in a > declaration and definition of a function? I can't think of any. Do you think it's possible that, for reasons of their own, someone would deliberately choose to use a different name for some function parameter where the function is declared, as compared to where the function is defined, even though you can't think of any good reason to do so? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 02 07:45AM -0700 On Thursday, April 2, 2020 at 10:13:17 AM UTC-4, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: ... > some function parameter where the function is declared, as > compared to where the function is defined, even though you > can't think of any good reason to do so? There's no inconsistency between that possibility and what Keith said; people often do things without having a good reason for doing them. He also only said that he couldn't think of any good reasons - that wording explicitly allows for the possibility of reasons he couldn't think of. In fact, his comment could even be interpreted as an invitation to enlighten him about what such reasons might be. Can you so enlighten him? If not, there was really no point in responding. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 02 07:20PM +0300 On 2.04.2020 17:13, Tim Rentsch wrote: > some function parameter where the function is declared, as > compared to where the function is defined, even though you > can't think of any good reason to do so? One possible reason would be to clarify a bad parameter name in the implementation, but to keep the header file unchanged to avoid "recompiling the world". Not sure if this is a good reason. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 02 10:19AM -0700 > some function parameter where the function is declared, as > compared to where the function is defined, even though you > can't think of any good reason to do so? The answer to this deeply uninteresting question is yes. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 02 10:25AM -0700 >> can't think of any good reason to do so? > There's no inconsistency between that possibility and what Keith said; > people often do things without having a good reason for doing them. Or for good reasons that I'm not aware of. > invitation to enlighten him about what such reasons might be. Can > you so enlighten him? If not, there was really no point in > responding. A bit of background. Much of my programming experience is in Ada, which allows separate declarations and definitions of functions and procedures in a manner similar to C and C++. Ada does not allow parameter names to differ between the declaration and definition (nor does it allow them to be omitted). I never found that the least bit inconvenient. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 02 07:05AM -0700 >>>>>> D; >>>>>> goto L; >>>>>> } [...] > restart' which would destroy all automatic variables in the function > and restart the function again. It would be equivalent to a 'goto' to > a label in the start of the function, [...] It is rather amusing that you didn't like creturn, and then describe a construct that behaves just the way a creturn would, except the retry/restart construct is less general than creturn. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 02 07:19AM -0700 > Do you don't understand that he considers that the way they invite > misuse, might be precisely the thing that he finds objectionable about > macros? [...] Please understand this: Your understandings are not my understandings. Your motivations are not my motivations. Your goals are not my goals. Your assumptions about meaning and communication do not match my own. I have the impression that your question is meant to be rhetorical. Mine was not: it was asked as just a question, nothing more. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 02 08:07AM -0700 On Thursday, April 2, 2020 at 10:19:50 AM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: ... > > misuse, might be precisely the thing that he finds objectionable about > > macros? [...] > Please understand this: Your understandings are not my understandings. That is quite clear. You appear to misunderstand a great many things. > Your motivations are not my motivations. Certainly not - I'd be appalled to have motivations that would lead me to behave the way that you do! > I have the impression that your question is meant to be rhetorical. Not quite. Your rejection of his response as an answer to your question would make more sense if you had been unaware of the point I was raising, and I'm sincerely interested in knowing whether that was the case. I'd also be interested in knowing whether you might have rejected it as invalid or irrelevant, and if so, why. In a sense, it was a rhetorical question - I would have hoped for a meaningful response, but I was not surprised by your failure to give one. > Mine was not: it was asked as just a question, nothing more. Yes, but you claimed incorrectly that he had not answered your question, implying that you failed to understand how his response qualifies as an answer to your question. I was merely explaining that to you (without, to be fair, any expectation that you would understand my explanation). |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 02 08:03PM +0300 On 2.04.2020 17:05, Tim Rentsch wrote: > It is rather amusing that you didn't like creturn, and then > describe a construct that behaves just the way a creturn would, > except the retry/restart construct is less general than creturn. That's because the main problem with the current solution (goto) is that it is too general. That's the reason why more restricted statements (break and continue) exist even though they could be replaced by goto-s. |
| legalize+jeeves@mail.xmission.com (Richard): Apr 02 02:13AM [Please do not mail me a copy of your followup] red floyd <no.spam@its.invalid> spake the secret code >I was looking for a way to use standard algorithms with a range of >integers. [...] Have you looked at the Range support that was added to C++20? <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4849.pdf> Look at 24.6.3 Iota view for (int i : iota_view{1, 10}) cout << i << ' '; // prints 1 2 3 4 5 6 7 8 9 10 -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Apr 02 02:15AM [Please do not mail me a copy of your followup] (Richard) legalize+jeeves@mail.xmission.com spake the secret code >Look at 24.6.3 Iota view >for (int i : iota_view{1, 10}) > cout << i << ' '; // prints 1 2 3 4 5 6 7 8 9 10 Also, if you don't have C++20 as an option, or don't want to wait, you can use the Ranges v3 library by Eric Niebler who wrote the spec for ranges in C++ 20. <https://github.com/ericniebler/range-v3> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 02 03:13AM > can use the Ranges v3 library by Eric Niebler who wrote the spec for > ranges in C++ 20. ><https://github.com/ericniebler/range-v3> I think that this is pointless. Take a look at golang, they recommend ordinary for loop for this... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Daniel P <danielaparker@gmail.com>: Apr 01 10:16PM -0700 On Wednesday, April 1, 2020 at 11:14:02 PM UTC-4, Melzzzzz wrote: > ><https://github.com/ericniebler/range-v3> > I think that this is pointless. Take a look at golang, they recommend > ordinary for loop for this... Agreed. Daniel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 02 06:12AM On Thu, 2020-04-02, Melzzzzz wrote: >><https://github.com/ericniebler/range-v3> > I think that this is pointless. Take a look at golang, they recommend > ordinary for loop for this... Doesn't mean much without the rationale, unless we all agree that "they" (who?) are usually right, and that Go advise extends to C++. I've happily used range() a lot in Python, and seq(1) in the shell ... but neither of those are C++. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment