Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #117659 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-11-08 15:56 +0100 |
| Last post | 2023-11-13 22:46 -0800 |
| Articles | 20 on this page of 259 — 9 participants |
Back to article view | Back to comp.lang.c++
A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 15:56 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 19:31 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 20:56 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 23:25 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:33 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:36 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:38 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:42 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:08 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:11 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:12 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:17 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:35 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:39 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:40 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:41 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:42 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:44 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:44 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:45 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:48 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:50 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:58 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 22:46 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:52 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 21:10 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 06:07 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-17 21:16 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-18 04:06 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 12:53 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-18 20:04 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 19:24 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-18 20:29 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 21:46 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:18 -0500
Re: A Java- / .NET-like monitor Michael S <already5chosen@yahoo.com> - 2023-11-24 01:14 +0200
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:35 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:59 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 10:25 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-24 15:59 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-24 18:33 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:39 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 00:08 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 16:27 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 14:47 -0800
Re: A Java- / .NET-like monitor "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2023-11-25 13:02 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 17:28 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 18:48 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 18:09 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 13:12 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-25 18:10 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-25 19:30 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 14:57 -0800
Re: A Java- / .NET-like monitor Michael S <already5chosen@yahoo.com> - 2023-11-26 01:29 +0200
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 15:56 -0800
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 13:54 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 14:38 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 16:28 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 18:51 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-26 20:27 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 14:38 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 15:00 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 05:23 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-27 10:38 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 10:55 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-27 11:19 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 12:32 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-26 22:55 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:15 -0800
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-28 09:03 +0100
Re: A Java- / .NET-like monitor David Brown <david.brown@hesbynett.no> - 2023-11-25 13:58 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:09 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 05:58 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-19 05:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 07:00 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-19 06:08 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-19 12:05 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:08 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:11 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-19 12:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-20 13:26 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-20 12:18 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-21 10:25 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-23 21:38 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 08:56 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 01:22 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-24 19:10 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-24 15:43 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-25 13:04 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-25 15:06 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-26 11:35 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 15:45 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 05:24 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-26 22:22 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 08:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 00:28 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-27 09:34 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 14:59 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 14:59 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:19 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-28 15:13 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-18 12:46 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 21:47 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-18 14:02 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-18 20:20 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-20 13:12 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 08:01 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 08:01 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:50 +0100
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-11 17:45 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 05:43 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-12 05:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 11:00 +0100
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-12 17:18 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:33 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:47 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 12:50 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 06:20 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 07:44 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:51 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:55 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 08:00 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 08:07 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:08 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:07 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 15:18 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 16:46 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 16:09 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 17:41 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 18:41 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:25 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 14:25 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 22:50 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:07 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 05:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:08 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 03:59 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-16 15:02 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 18:12 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-16 17:45 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-27 15:24 -0800
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-12 17:53 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:51 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:33 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-13 04:50 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 22:05 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-14 03:30 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:35 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:26 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:11 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-15 23:07 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-16 06:39 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-16 21:48 -0500
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-17 16:29 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-17 10:22 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-17 18:37 +0000
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-18 00:45 +0000
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-18 02:30 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 11:11 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 07:35 +0100
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-13 15:05 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 16:36 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-13 17:24 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:48 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:29 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 16:44 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-16 14:16 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-13 04:48 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 14:32 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 21:27 -0500
Re: A Java- / .NET-like monitor scott@slp53.sl.home (Scott Lurndal) - 2023-11-14 15:12 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:35 -0500
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-13 21:58 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-14 03:27 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:28 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 21:29 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:47 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:18 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:20 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-15 21:26 +0000
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-16 00:25 -0500
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-14 20:42 -0500
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-28 15:32 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-12 19:17 -0500
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-09 05:17 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:18 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:20 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:19 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:20 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 23:51 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:10 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 15:32 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:35 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:17 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:22 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:27 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:29 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:31 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:34 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:36 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 06:40 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:42 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 07:32 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 22:54 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 23:01 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 23:03 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:30 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 21:32 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 14:59 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 19:49 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-08 18:16 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 13:49 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:37 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:40 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:39 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 13:41 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 05:36 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-08 20:41 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-08 18:16 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 10:07 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:11 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-09 10:17 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:22 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-09 01:23 -0800
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-10 13:56 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-10 15:08 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-10 15:15 +0100
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-11 02:59 +0000
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-10 12:44 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 04:53 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-10 20:09 -0800
Re: A Java- / .NET-like monitor Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-11-11 04:25 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 07:07 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 11:41 +0100
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-11 16:39 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-11 11:42 -0800
Re: A Java- / .NET-like monitor Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-11-11 17:49 -0500
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-12 05:40 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-12 12:46 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 23:13 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 10:04 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 01:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 11:00 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 02:08 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-14 11:23 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:27 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-14 12:29 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-15 05:54 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 12:21 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 04:00 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-15 19:10 -0800
Re: A Java- / .NET-like monitor Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-16 03:21 +0000
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-16 06:36 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-16 13:06 -0800
Re: A Java- / .NET-like monitor Bonita Montero <Bonita.Montero@gmail.com> - 2023-11-17 06:57 +0100
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-11 11:41 -0800
Re: A Java- / .NET-like monitor "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-11-13 22:46 -0800
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-24 15:59 +0000 |
| Message-ID | <bL38N.65219$cAm7.33028@fx18.iad> |
| In reply to | #117947 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/23/2023 11:59 PM, Bonita Montero wrote:
>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>
>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>
>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>> ported to Windows from some other platform.
>>
>>> Fwiw, check this out:
>>> https://sourceware.org/pthreads-win32/
>>
>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>
>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>> mutexes and condition variables since C++11 are more convenient to use.
>>
>>
>>
>>
>
>Have you ever wrapped up a C API in C++ using RAII before?
I generally consider using RAII for synchronization primitives
to be counterindicated. Amongst the reasons:
1) The critical sections usually end up being far to large
2) It makes reasoning about the synchronization code and
potential nested locking more difficult.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-24 18:33 +0000 |
| Message-ID | <20231124102842.71@kylheku.com> |
| In reply to | #117952 |
On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>
>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>
>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>> ported to Windows from some other platform.
>>>
>>>> Fwiw, check this out:
>>>> https://sourceware.org/pthreads-win32/
>>>
>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>
>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>> mutexes and condition variables since C++11 are more convenient to use.
>>>
>>>
>>>
>>>
>>
>>Have you ever wrapped up a C API in C++ using RAII before?
>
> I generally consider using RAII for synchronization primitives
> to be counterindicated. Amongst the reasons:
> 1) The critical sections usually end up being far to large
Use braces?
{
mutex_locker m(obj);
}
> 2) It makes reasoning about the synchronization code and
> potential nested locking more difficult.
It's just a syntactic sugar to avoid forgetting to unlock.
The thing is, you need a complementary unlocker to
avoid the nesting:
{
mutex_locker m(obj);
// ...
if (obj.situation()) {
mutex_unlocker u(obj); // temporarily give up mutex
other_obj.method(); // this can call us back again
}
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-24 15:39 -0800 |
| Message-ID | <ujrc8c$2gjhg$3@dont-email.me> |
| In reply to | #117955 |
On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>
>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>> ported to Windows from some other platform.
>>>>
>>>>> Fwiw, check this out:
>>>>> https://sourceware.org/pthreads-win32/
>>>>
>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>
>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Have you ever wrapped up a C API in C++ using RAII before?
>>
>> I generally consider using RAII for synchronization primitives
>> to be counterindicated. Amongst the reasons:
>> 1) The critical sections usually end up being far to large
>
> Use braces?
>
> {
> mutex_locker m(obj);
>
>
> }
DING!!! :^)
>
>> 2) It makes reasoning about the synchronization code and
>> potential nested locking more difficult.
>
> It's just a syntactic sugar to avoid forgetting to unlock.
>
> The thing is, you need a complementary unlocker to
> avoid the nesting:
>
> {
> mutex_locker m(obj);
>
> // ...
>
> if (obj.situation()) {
> mutex_unlocker u(obj); // temporarily give up mutex
> other_obj.method(); // this can call us back again
> }
> }
>
>
:^)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-25 00:08 +0000 |
| Message-ID | <3Wa8N.2235$PJoc.2084@fx04.iad> |
| In reply to | #117958 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>
>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>
>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>> ported to Windows from some other platform.
>>>>>
>>>>>> Fwiw, check this out:
>>>>>> https://sourceware.org/pthreads-win32/
>>>>>
>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>
>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>
>>> I generally consider using RAII for synchronization primitives
>>> to be counterindicated. Amongst the reasons:
>>> 1) The critical sections usually end up being far to large
>>
>> Use braces?
>>
>> {
>> mutex_locker m(obj);
>>
>>
>> }
>
>DING!!! :^)
No, not really. It's not always that
easy, and sometimes programmers even use 'goto'.
That's certainly no more readable than
pthread_lock(obj);
do something
pthread_unlock(obj);
I'd argue the RAII solution is less readable.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-24 16:27 -0800 |
| Message-ID | <ujrf2b$2gqoe$2@dont-email.me> |
| In reply to | #117960 |
On 11/24/2023 4:08 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>
>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>> ported to Windows from some other platform.
>>>>>>
>>>>>>> Fwiw, check this out:
>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>
>>>> I generally consider using RAII for synchronization primitives
>>>> to be counterindicated. Amongst the reasons:
>>>> 1) The critical sections usually end up being far to large
>>>
>>> Use braces?
>>>
>>> {
>>> mutex_locker m(obj);
>>>
>>>
>>> }
>>
>> DING!!! :^)
>
> No, not really. It's not always that
> easy, and sometimes programmers even use 'goto'.
>
> That's certainly no more readable than
>
> pthread_lock(obj);
>
> do something
>
> pthread_unlock(obj);
>
> I'd argue the RAII solution is less readable.
RAII can come in handy. I don't think its all that bad. Humm...
_______________________
{
mutex_raii_lock(my_lock);
}
_______________________
vs:
_______________________
my_lock.lock();
my_lock.unlock();
_______________________
Btw, wrt C++, RAII tends to work rather well with exceptions... ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-25 14:47 -0800 |
| Message-ID | <ujtti0$2v76e$3@dont-email.me> |
| In reply to | #117961 |
On 11/24/2023 4:27 PM, Chris M. Thomasson wrote:
> On 11/24/2023 4:08 PM, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>>
>>>>>>>>> Which, I would guess, never used by 99.9% of programs that were
>>>>>>>>> not
>>>>>>>>> ported to Windows from some other platform.
>>>>>>>
>>>>>>>> Fwiw, check this out:
>>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>>
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>> That's an unnecessary discussion for a C++ programmer since the
>>>>>>> RAII-ish
>>>>>>> mutexes and condition variables since C++11 are more convenient
>>>>>>> to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>>
>>>>> I generally consider using RAII for synchronization primitives
>>>>> to be counterindicated. Amongst the reasons:
>>>>> 1) The critical sections usually end up being far to large
>>>>
>>>> Use braces?
>>>>
>>>> {
>>>> mutex_locker m(obj);
>>>>
>>>>
>>>> }
>>>
>>> DING!!! :^)
>>
>> No, not really. It's not always that
>> easy, and sometimes programmers even use 'goto'.
>>
>> That's certainly no more readable than
>>
>> pthread_lock(obj);
>>
>> do something
>>
>> pthread_unlock(obj);
>>
>> I'd argue the RAII solution is less readable.
>
> RAII can come in handy. I don't think its all that bad. Humm...
> _______________________
> {
> mutex_raii_lock(my_lock);
^^^^^^^^^^^^^
OOPS!
mutex_raii_lock lock(my_lock);
> }
> _______________________
>
> vs:
> _______________________
> my_lock.lock();
> my_lock.unlock();
> _______________________
>
> Btw, wrt C++, RAII tends to work rather well with exceptions... ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2023-11-25 13:02 +0100 |
| Message-ID | <ujsnp1$2poh8$3@dont-email.me> |
| In reply to | #117960 |
Op 25.nov.2023 om 01:08 schreef Scott Lurndal:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>
>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>> ported to Windows from some other platform.
>>>>>>
>>>>>>> Fwiw, check this out:
>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>
>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>
>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>
>>>> I generally consider using RAII for synchronization primitives
>>>> to be counterindicated. Amongst the reasons:
>>>> 1) The critical sections usually end up being far to large
>>>
>>> Use braces?
>>>
>>> {
>>> mutex_locker m(obj);
>>>
>>>
>>> }
>>
>> DING!!! :^)
>
> No, not really. It's not always that
> easy, and sometimes programmers even use 'goto'.
>
> That's certainly no more readable than
>
> pthread_lock(obj);
>
> do something
>
> pthread_unlock(obj);
>
> I'd argue the RAII solution is less readable.
In many cases it is not that simple.
It is more like:
{
mutex_locker m(obj);
do something
if (....) continue;
if (....) break;
if (...) return;
do something else
}
vs.:
pthread_lock(obj);
{
do something
if (...) {
pthread_unlock(obj);
continue;
}
if (...) {
pthread_unlock(obj);
break;
}
if (....) {
pthread_unlock(obj);
return;
}
do something else
} catch (...) {
pthread_unlock(obj);
throw;
}
pthread_unlock(obj);
Personally I find the first way more readable and easier to maintain.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-25 17:28 +0000 |
| Message-ID | <S8q8N.22591$yAie.14909@fx44.iad> |
| In reply to | #117962 |
"Fred. Zwarts" <F.Zwarts@HetNet.nl> writes:
>Op 25.nov.2023 om 01:08 schreef Scott Lurndal:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/24/2023 10:33 AM, Kaz Kylheku wrote:
>>>> On 2023-11-24, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>> On 11/23/2023 11:59 PM, Bonita Montero wrote:
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>>> On 11/23/2023 3:14 PM, Michael S wrote:
>>>>>>>
>>>>>>>>> Which, I would guess, never used by 99.9% of programs that were not
>>>>>>>>> ported to Windows from some other platform.
>>>>>>>
>>>>>>>> Fwiw, check this out:
>>>>>>>> https://sourceware.org/pthreads-win32/
>>>>>>>
>>>>>>> Am 24.11.2023 um 06:35 schrieb Chris M. Thomasson:
>>>>>>>
>>>>>>> That's an unnecessary discussion for a C++ programmer since the RAII-ish
>>>>>>> mutexes and condition variables since C++11 are more convenient to use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Have you ever wrapped up a C API in C++ using RAII before?
>>>>>
>>>>> I generally consider using RAII for synchronization primitives
>>>>> to be counterindicated. Amongst the reasons:
>>>>> 1) The critical sections usually end up being far to large
>>>>
>>>> Use braces?
>>>>
>>>> {
>>>> mutex_locker m(obj);
>>>>
>>>>
>>>> }
>>>
>>> DING!!! :^)
>>
>> No, not really. It's not always that
>> easy, and sometimes programmers even use 'goto'.
>>
>> That's certainly no more readable than
>>
>> pthread_lock(obj);
>>
>> do something
>>
>> pthread_unlock(obj);
>>
>> I'd argue the RAII solution is less readable.
>
>In many cases it is not that simple.
>It is more like:
>
> {
> mutex_locker m(obj);
> do something
> if (....) continue;
> if (....) break;
> if (...) return;
> do something else
> }
>
>vs.:
>
> pthread_lock(obj);
> {
> do something
> if (...) {
> pthread_unlock(obj);
> continue;
> }
> if (...) {
> pthread_unlock(obj);
> break;
> }
> if (....) {
> pthread_unlock(obj);
> return;
> }
> do something else
> } catch (...) {
> pthread_unlock(obj);
> throw;
> }
> pthread_unlock(obj);
>
>Personally I find the first way more readable and easier to maintain.
I'd argue that the critical region may be too large if all those
checks are required within.
I've used both, but in code (bare metal os/hv) compiled with
-fno-exceptions the following is preferable to RAII.
pthread_lock(obj);
if (xxx) goto unlock;
do something
if (yyy) goto unlock;
do something else
unlock:
pthread_unlock(obj);
six of one, half dozen of the other. This solution doesn't have
magic behavior and can more easily be reasoned to be correct.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-25 18:48 +0100 |
| Message-ID | <ujtc1t$2sp67$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117967 |
Am 25.11.2023 um 18:28 schrieb Scott Lurndal: > I've used both, but in code (bare metal os/hv) compiled with > -fno-exceptions the following is preferable to RAII. > > pthread_lock(obj); > > if (xxx) goto unlock; > > do something > > if (yyy) goto unlock; > > do something else > > unlock: > pthread_unlock(obj); Why do you disable exceptions with code that doesn't throw ?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-25 18:09 +0000 |
| Message-ID | <NLq8N.65597$cAm7.60868@fx18.iad> |
| In reply to | #117968 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 25.11.2023 um 18:28 schrieb Scott Lurndal: > >> I've used both, but in code (bare metal os/hv) compiled with >> -fno-exceptions the following is preferable to RAII. >> >> pthread_lock(obj); >> >> if (xxx) goto unlock; >> >> do something >> >> if (yyy) goto unlock; >> >> do something else >> >> unlock: >> pthread_unlock(obj); > >Why do you disable exceptions with code that doesn't throw ? To prevent the code from ever throwing, of course and to ensure that no exception infrastructure gets generated into the object files.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-25 13:12 +0100 |
| Message-ID | <ujsobk$2ps2p$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117955 |
Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: > It's just a syntactic sugar to avoid forgetting to unlock ... RAII is magnitudes more convenient and lass error-prone than manual resource handling.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-11-25 18:10 +0000 |
| Message-ID | <20231125100947.641@kylheku.com> |
| In reply to | #117965 |
On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: > >> It's just a syntactic sugar to avoid forgetting to unlock ... > > RAII is magnitudes more convenient and lass error-prone > than manual resource handling. Sure, but that's not necessarily an effective way to "sell" it to someone who is being skeptical. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-11-25 19:30 +0000 |
| Message-ID | <%Wr8N.40010$zh16.35086@fx48.iad> |
| In reply to | #117970 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: >> >>> It's just a syntactic sugar to avoid forgetting to unlock ... >> >> RAII is magnitudes more convenient and lass error-prone >> than manual resource handling. > >Sure, but that's not necessarily an effective way to "sell" it to >someone who is being skeptical. I would argue that is is not 'less error-prone' than explicit locking, properly written and unit tested.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-25 14:57 -0800 |
| Message-ID | <ujtu5d$2v76e$4@dont-email.me> |
| In reply to | #117971 |
On 11/25/2023 11:30 AM, Scott Lurndal wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: >> On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: >>> >>>> It's just a syntactic sugar to avoid forgetting to unlock ... >>> >>> RAII is magnitudes more convenient and lass error-prone >>> than manual resource handling. >> >> Sure, but that's not necessarily an effective way to "sell" it to >> someone who is being skeptical. > > I would argue that is is not 'less error-prone' than > explicit locking, properly written and unit tested. It can create a dog with different fleas in some cases.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-11-26 01:29 +0200 |
| Message-ID | <20231126012940.00001397@yahoo.com> |
| In reply to | #117971 |
On Sat, 25 Nov 2023 19:30:03 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Kaz Kylheku <864-117-4973@kylheku.com> writes: > >On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: > >> > >>> It's just a syntactic sugar to avoid forgetting to unlock ... > >> > >> RAII is magnitudes more convenient and lass error-prone > >> than manual resource handling. > > > >Sure, but that's not necessarily an effective way to "sell" it to > >someone who is being skeptical. > > I would argue that is is not 'less error-prone' than > explicit locking, properly written and unit tested. RAII is horrible, but unfortunately necessary in big undisciplined C++ projects. The root bug in C++ language design are constructors that can fail, but can't return error code. That problem begot exceptions. And the presence of exceptions begot RAII. RAII is bad, but less bad than other solutions.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-11-25 15:56 -0800 |
| Message-ID | <uju1ij$2voqe$1@dont-email.me> |
| In reply to | #117976 |
On 11/25/2023 3:29 PM, Michael S wrote: > On Sat, 25 Nov 2023 19:30:03 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: >>>> >>>>> It's just a syntactic sugar to avoid forgetting to unlock ... >>>> >>>> RAII is magnitudes more convenient and lass error-prone >>>> than manual resource handling. >>> >>> Sure, but that's not necessarily an effective way to "sell" it to >>> someone who is being skeptical. >> >> I would argue that is is not 'less error-prone' than >> explicit locking, properly written and unit tested. > > RAII is horrible, but unfortunately necessary in big undisciplined C++ > projects. Horrible? It's not that bad. > The root bug in C++ language design are constructors that can fail, but > can't return error code. > That problem begot exceptions. And the presence of exceptions begot > RAII. RAII is bad, but less bad than other solutions. > > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-11-26 13:54 +0100 |
| Message-ID | <ujvf5l$3934n$1@dont-email.me> |
| In reply to | #117976 |
On 26/11/2023 00:29, Michael S wrote: > On Sat, 25 Nov 2023 19:30:03 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> On 2023-11-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 24.11.2023 um 19:33 schrieb Kaz Kylheku: >>>> >>>>> It's just a syntactic sugar to avoid forgetting to unlock ... >>>> >>>> RAII is magnitudes more convenient and lass error-prone >>>> than manual resource handling. >>> >>> Sure, but that's not necessarily an effective way to "sell" it to >>> someone who is being skeptical. >> >> I would argue that is is not 'less error-prone' than >> explicit locking, properly written and unit tested. > > RAII is horrible, but unfortunately necessary in big undisciplined C++ > projects. > The root bug in C++ language design are constructors that can fail, but > can't return error code. That's easily solved in cases like this - write constructors that can't fail. In the kind of systems I work with, something like acquiring a mutex cannot fail unless there is a major system failure that renders it unsafe to run anything - the system then turns off all the machinery it controls, logs everything it can, and alerts the user to the failure. That applies equally to a free-standing "lock" function or an RAII constructor solution. There is no need for exceptions, error codes, or anything of that sort. > That problem begot exceptions. And the presence of exceptions begot > RAII. RAII is bad, but less bad than other solutions. > I am not a fan of exceptions in low-level code or control code. They are fine in high-level PC stuff when dealing with things that can reasonably fail but where you don't want to bother with all the details all the time - such as a constructor for opening a handle to a database. (I mostly use Python for that kind of thing anyway, but that's just personal choice.) Once you stop thinking that code can fail, and write code that doesn't fail, it all becomes much easier, and RAII is just another useful tool. (And you can compile with exceptions fully disabled.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-26 14:38 +0100 |
| Message-ID | <ujvhph$39dt7$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117979 |
Am 26.11.2023 um 13:54 schrieb David Brown: > Once you stop thinking that code can fail, and write code that doesn't > fail, it all becomes much easier, and RAII is just another useful tool. > (And you can compile with exceptions fully disabled.) With exceptions and RAII failures are also very easy to handle because you handle them only at a few places and not where they happen or in the call levels between. Avoiding exceptions looks hard to me because the runtime can throw a lot of exceptions, mostly bad_alloc()s or system_error()s.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-11-26 16:28 +0100 |
| Message-ID | <ujvo70$3adcv$1@dont-email.me> |
| In reply to | #117980 |
On 26/11/2023 14:38, Bonita Montero wrote: > Am 26.11.2023 um 13:54 schrieb David Brown: > >> Once you stop thinking that code can fail, and write code that doesn't >> fail, it all becomes much easier, and RAII is just another useful >> tool. (And you can compile with exceptions fully disabled.) > > With exceptions and RAII failures are also very easy to handle because > you handle them only at a few places and not where they happen or in > the call levels between. No, exceptions do not make things easier - they make them /different/. Sometimes it might be helpful to move failure handling to a different part of the code, sometimes it makes things harder. Sometimes it is best to have a failure handling solution that does not care what can fail, or how it can fail, and only think about failures when you have a way to deal with them (that's exceptions). Sometimes it is best to be entirely sure about wait failures can occur at the point of failure, and deal with them or pass them on explicitly (that's error returns, std::expect, railway programming, etc.). Sometimes it is best to ensure failure is not possible within the scope of the software, so that no failure handling is needed (or nothing beyond abort(), kernel panic, etc.) The only thing you can be sure about with failure handling is that anyone who says they know the perfect answer, or that their preferred method is always far better than others, is wrong. > Avoiding exceptions looks hard to me because the runtime can throw a > lot of exceptions, mostly bad_alloc()s or system_error()s. > Any code that sees a "bad_alloc" exception is already borked. It is not failing because of the exception, it is failing because of the bad programming.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-11-26 18:51 +0100 |
| Message-ID | <uk00ih$3bl9e$1@raubtier-asyl.eternal-september.org> |
| In reply to | #117981 |
Am 26.11.2023 um 16:28 schrieb David Brown: > No, exceptions do not make things easier - they make them /different/. Without exceptions you'd have to deal with return codes at each call level; this *is* much more work. > Sometimes it might be helpful to move failure handling to a different > part of the code, sometimes it makes things harder. In C++ exceptions are mostly used for resource collapse situations, i.e. out of memory errors, network errors of filesystem failures. With that exceptions are the most convenient way to handle that. These types of errors are handled in most cases. > Any code that sees a "bad_alloc" exception is already borked. With exceptions you can handle such situations in a clean way with a small effort. > It is not failing because of the exception, it is failing because > of the bad programming. bad_alloc doesn't depend on the programming but rather how much memory you have. You might ignore bad_alloc for small allocations since they're unlikely to happen, but not for large allocations. I don't understand your attitude while programming with C++ because the runtime uses exceptions so much.
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web