- No judgment, just forgiveness and guidance - 4 Updates
- neoGFX wiki - 4 Updates
- Use of the break; and continue; statments - 1 Update
- peformance of wait notify concept of condition variable - 7 Updates
- How to do this (small task - std::transform?)? - 2 Updates
- How to do this (small task - std::transform?)? - 1 Update
| Ian Collins <ian-news@hotmail.com>: May 20 09:10AM +1200 On 05/19/17 10:33 PM, Rick C. Hodgin wrote: > We all have sin. Off-topic multi-posting is a sin. -- Ian |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 02:28PM -0700 On 5/19/2017 2:10 PM, Ian Collins wrote: > On 05/19/17 10:33 PM, Rick C. Hodgin wrote: >> We all have sin. > Off-topic multi-posting is a sin. Agreed. |
| Barry Schwarz <schwarzb@dqel.com>: May 19 03:06PM -0700 On Sat, 20 May 2017 09:10:09 +1200, Ian Collins <ian-news@hotmail.com> wrote: >On 05/19/17 10:33 PM, Rick C. Hodgin wrote: >> We all have sin. >Off-topic multi-posting is a sin. So is responding to them. -- Remove del for email |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 19 04:16PM -0700 Ian Collins wrote: > On 05/19/17 10:33 PM, Rick C. Hodgin wrote: > > We all have sin. > Off-topic multi-posting is a sin. If I were posting my artwork, or how to lose fat and gain muscle tone, then yoy may be correct. But I am posting about Jesus, and teaching you about forgiveness of sin and eternal life. These things are of such paramount importance to all people that it would be a sin to not post such teachings. Thank you, Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 19 05:57PM +0100 On 19/05/2017 10:04, fir wrote: >> neoGFX version 1.0 is about 75% complete at this stage. >> /Flibble > give more details on details implementation (something usefull for someone who like to learn something interesting) then it would be interesting post It is open source so you can see the implementation for yourself. /Flibble |
| fir <profesor.fir@gmail.com>: May 19 02:31PM -0700 W dniu piątek, 19 maja 2017 18:57:50 UTC+2 użytkownik Mr Flibble napisał: > >> /Flibble > > give more details on details implementation (something usefull for someone who like to learn something interesting) then it would be interesting post > It is open source so you can see the implementation for yourself. im to lazy and bored, but you may write couple on lines on it (as i said: what was hard, what esy, what you think on it - wrote down something interesting and maybe some interesting topics will arise) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 19 04:08PM -0700 fir, I wrote a couple lines on it. Perhaps you could set aside your negativity toward me and learn something. Thank you, Rick C. Hodgin |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 04:09PM -0700 On 5/19/2017 4:08 PM, Rick C. Hodgin wrote: > fir, I wrote a couple lines on it. Perhaps you could set aside your > negativity toward me and learn something. ;^o |
| Tim Rentsch <txr@alumni.caltech.edu>: May 19 04:04PM -0700 > I would be interested in getting feedback on my post and the topic in > general. > [...] I have comments both on the topic and on how to present it. I'll try to give the comments mostly in that order. First, I echo the response given by Ian Collins. If a loop uses break (appropriately) to exit the loop, the code often can, and usually should, be recast so that the loop is in a subfunction, and 'return' is used rather than 'break'. Generally 'return' to exit a loop early is better than 'break'. What's more, the most common case for early loop exit is a search that found something, in which case 'return' provides not only the exit out of the loop but also a way of transmitting the value (eg an index or an address) of what was found. Second, I echo the response given by Jorgen Grahn. Start by teaching function composition (including invariants for loops, etc), and there won't be as much need for rules about 'break' and 'continue', etc. When beginners overuse such statements, usually that indicates a deeper problem related to how they write code to begin with (which at the level of a single function I use the term "function composition"). If their function composition skills are good, they won't need to be told which break/continue are okay and which ones should be revised away; if not, trying to follow heuristic rules probably won't help them much. Some general comments: I don't use break or continue very often, but I don't go out of my way to avoid them either. Partly that's because my code composition habits mostly automatically avoid them early, so I don't worry if I find myself writing one. Of course that may not be true for beginners, so how can we help them with that? Rather than say "minimize the use of break and continue", I suggest something like "whenever you find yourself starting to write 'break' or 'continue', ask yourself if there's a way to write the code that is easier to understand." The first step is to be aware of cases that might need further exploration. Having said that, let me partially retract it. The behaviors of 'break' and 'continue' are actually pretty dissimilar, despite them being close cousins in terms of syntax. I think it's a mistake to lump them together in terms of composition advice. The easier one is 'continue', which is (for loops) roughly akin to what an early return in a function does: it says, "we know what to do in this case, what that is is simple and not the main line, so we're just going to get it out of the way and be done with it." Especially benign are cases where the continue is at the top level of the loop body (so nothing has happened between a non-nested test and the 'continue' statement). Because of that, I recommend writing these cases in a distinctive way, without braces or nesting, eg if (c == '\n' ) continue; The more that has happened (eg side effects) since the start of the loop and the continue test, and/or the more deeply nested the 'continue' statement, the redder the flag in a code review. And conversely for less deeply nested and less state change since the current loop iteration started. What considerations are important is different with 'break'. I have the same redness heuristic with 'break' about nesting as I do with 'continue', but apart from that I really don't think of them as being in the same category. Two of the examples you gave for 'break' (with a 'found' flag, and code duplication), ran counter to what I expected. Rather than pontificate about minor points of style, let me say something about giving examples. I recommend: Examples be detailed and specific rather than generic and abstract; As much as possible examples be taken from actual code rather than hypothetical examples; The set of examples first include good usage (ie, where breaks does not appear); For each example of bad usage, a revised form be shown that avoids the bad usage; and, The set of examples last include cases where 'break' is used appropriately. These recommendations likewise apply for 'continue'. If you're feeling ambitious, the example sets could include examples that are "on the fence", ie, where there are plusses and minuses to each of the different approaches, which might allow talking about making tradeoffs in composition choices. Okay I will stop here. If you decide to revise your tutorial I'd be interested to see the results. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 09:35AM -0700 On 5/19/2017 1:15 AM, Bonita Montero wrote: >> No, you are wrong. What you wrote is _not_ correct when the HANDLE is >> hooked up to IOCP. ... > Read the article I referred to; it isn't about IOCPs. I did read it. I never really liked using OVERLAPPED with the event. Also, never like using completion routines. Imvho, IOCP is much, much better. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 07:33PM +0200 >> Read the article I referred to; it isn't about IOCPs. > But, you used IOCP in your code? Yes, in booth, but I extend the file before a IOCP is bound to the file-handle. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 07:33PM +0200 > I did read it. I never really liked using OVERLAPPED with the event. > Also, never like using completion routines. > Imvho, IOCP is much, much better. There is no advantage of a IOCP in this case. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 19 07:34PM +0200 > You used async IO and failed to wait on the event in your code. Yes, I missed the wait, but fortunately it isn't necessary because extending a file is always synchronous, even if the file is opened for overlapped I/O. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 11:20AM -0700 On 5/19/2017 10:34 AM, Bonita Montero wrote: > Yes, I missed the wait, but fortunately it isn't necessary because > extending a file is always synchronous, even if the file is opened > for overlapped I/O. Where is this documented by Microsoft? |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 11:30AM -0700 On 5/19/2017 10:33 AM, Bonita Montero wrote: >> But, you used IOCP in your code? > Yes, in booth, but I extend the file before a IOCP is bound to the > file-handle. Okay. But, can you be 100% sure that the async IO file never will give an async result? How? |
| "Chris M. Thomasson" <invalid@invalid.invalid>: May 19 02:02PM -0700 On 5/19/2017 10:33 AM, Bonita Montero wrote: >> Also, never like using completion routines. >> Imvho, IOCP is much, much better. > There is no advantage of a IOCP in this case. Why do you use that event for the expansion, and fail to wait on it, then switch over to IOCP? Even in the IOCP mode, you make your code fail when ReadFile returns TRUE: WHY? This is just plain strange. |
| JiiPee <no@notvalid.com>: May 19 04:47PM +0100 On 19/05/2017 16:36, Stefan Ram wrote: >> I know how to do it with a for-loop of course, but would like to know >> how to do it with std-functions. > ::std::for_each, SCNR. but how? for_each works only for ONE object, right? You cannot copy from one vector to another using that I think. |
| JiiPee <no@notvalid.com>: May 19 08:09PM +0100 Thanks, nice. Just what I wanted. I ll study it now. On 19/05/2017 17:22, Stefan Ram wrote: |
| ram@zedat.fu-berlin.de (Stefan Ram): May 19 04:28PM >auto & target = vector0.at( offset ); There should be a »1« above instead of the »0«. |
| 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