| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 22 11:30AM -0800 Christian Gollwitzer <auriocus@gmx.de> writes: [...] > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly > a good reason IMHO. https://softwareengineering.stackexchange.com/a/133523/33478 -- 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 */ |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 22 07:57PM On Wed, 22 Jan 2020 20:04:58 +0100 > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. It is a better solution than exceptions for breaking out of a nested loop, usually. |
| Christian Gollwitzer <auriocus@gmx.de>: Jan 22 08:04PM +0100 > I have paint to watch drying instead. Nice idiom > No doubt it comes from the same ivory > tower that claims gotos should never be used. Ivory tower, for sure? We have while, for, break, continue, return, and exceptions. All these compile to some sort of goto in machine code. What good reasons are left for a literal goto? I can see it in C for error handling (because it lacks exceptions) - in C++ there is hardly a good reason IMHO. Christian |
| Ian Collins <ian-news@hotmail.com>: Jan 23 10:03AM +1300 On 23/01/2020 08:04, Christian Gollwitzer wrote: > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. With the help of clang-tidy warnings, we have finally cleansed our decades old code base of goto :) -- Ian |
| Ian Collins <ian-news@hotmail.com>: Jan 23 10:03AM +1300 On 23/01/2020 08:57, Chris Vine wrote: >> good reason IMHO. > It is a better solution than exceptions for breaking out of a nested > loop, usually. Extracting the loop is better still! -- Ian. |
| aminer68@gmail.com: Jan 22 11:34AM -0800 Hello, About modelizations and detection of race conditions and deadlocks in parallel programming.. I have just taken further a look at the following project in Delphi called DelphiConcurrent by an engineer called Moualek Adlene from France: https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas And i have just taken a look at the following webpage of Dr Dobb's journal: Detecting Deadlocks in C++ Using a Locks Monitor https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644 And i think that both of them are using technics that are not as good as analysing deadlocks with Petri Nets in parallel applications , for example the above two methods are only addressing locks or mutexes or reader-writer locks , but they are not addressing semaphores or event objects and such other synchronization objects, so they are not good, this is why i have written a tutorial that shows my methodology of analysing and detecting deadlocks in parallel applications with Petri Nets, my methodology is more sophisticated because it is a generalization and it modelizes with Petri Nets the broader range of synchronization objects, and in my tutorial i will add soon other synchronization objects, you have to look at it, here it is: https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets You have to get the powerful Tina software to run my Petri Net examples inside my tutorial, here is the powerful Tina software: http://projects.laas.fr/tina/ Also to detect race conditions in parallel programming you have to take a look at the following new tutorial that uses the powerful Spin tool: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html This is how you will get much more professional at detecting deadlocks and race conditions in parallel programming. Thank you, Amine Moulay Ramdane. |
| 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