- Is this safe? - 5 Updates
- lvalue assignment difference between C and C++ - 2 Updates
- single object - 1 Update
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 21 07:58PM +0200 > Make your program multi process then. Problem solved. Too late. Nowadays I'm happy if there are less than 100 threads in the process, otherwise debugging them might become really tedious. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Feb 21 10:35AM -0800 > >introduce extraneous issues. > 3 lines is short and I didn't introduce any extranious issues. Other posters > created them. No, they didn't. When there's multiple possible reasons why you might be worried about whether a given piece of code is safe, you need to identify which of the possibilities is the one you are actually worried about. You considered it so obvious that you don't care about UTF-8, that you didn't consider the possibility that other people would consider that to be the most obvious safety concern. The people who responded considered the resolution of the issue that you were concerned with to be so obvious that they didn't even consider the possibility that you were uncertain about it. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Feb 21 10:58AM -0800 > >Not what you're asking, but the common convention in C++ is to separate > >the type specification from the variable, i.e. `auto& c` not `auto &c`. > Whose common convention? The convention you're using is popular for simple declarations, because it uses the space to separate the sequence of declaration specifiers from the list of declarators. That's a helpful distinction to be aware of, because if there is more than one declarator, they all share the declaration specifiers. However, this is a different context, the range declaration for a range-based for statement. If followed by a comma-delimited list of identifiers, i it would be parsed as a structured binding declaration, and in that context & would be shared by all of those identifiers, so it makes sense to separate it from them, and combine it with the preceding specifiers, which they would also share. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 21 12:15PM -0800 On 2/21/2023 9:58 AM, Paavo Helde wrote: >> Make your program multi process then. Problem solved. > Too late. Nowadays I'm happy if there are less than 100 threads in the > process, otherwise debugging them might become really tedious. 100 threads? I am wondering what they are all doing. ;^) |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 21 11:41PM +0200 21.02.2023 22:15 Chris M. Thomasson kirjutas: >> Too late. Nowadays I'm happy if there are less than 100 threads in the >> process, otherwise debugging them might become really tedious. > 100 threads? I am wondering what they are all doing. ;^) Mostly waiting for each other, or for external events. The general goal is to have the number of active calculation threads in the order of physical CPU cores, or somewhat higher if there is hyperthreading. So the number of actively running threads is usually less than 20 or 30, the rest are waiting. I'm sure it ought be possible to reduce the number of needed threads several times by code reorganization, but the cost/benefit ratio does not seem to encourage this work. |
| Armando di Matteo <armando.dimatteo87@gmail.com>: Feb 21 09:15AM -0800 Andrey Tarasevich wrote: > (a = b) = 2; > // Invalid in C, valid in C++ > // (and starting from C++11 the behavior is well-defined) What does it do, assign `b` to `a` and immediately afterwards assign 2 to `a`? |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Feb 21 09:46AM -0800 On 02/21/23 9:15 AM, Armando di Matteo wrote: >> // Invalid in C, valid in C++ >> // (and starting from C++11 the behavior is well-defined) > What does it do, assign `b` to `a` and immediately afterwards assign 2 to `a`? Yes. -- Best regards, Andrey |
| Muttley@dastardlyhq.com: Feb 21 05:14PM On Tue, 21 Feb 2023 09:13:14 -0800 (PST) > ~MyClass() { instantiated = false; } >} >would that be okay? Don't help the kids with their coursework. |
| 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