- "Functional exception-less error handling with C++23 - 5 Updates
- shared_ptr array range loop doesn't work - 7 Updates
| Vir Campestris <vir.campestris@invalid.invalid>: May 23 11:33AM +0100 On 17/05/2023 16:44, Bonita Montero wrote: > Am 17.05.2023 um 17:37 schrieb Scott Lurndal: >> And you know this, how, exactly? > I/O on mainframes is also PCI-whatever today. Back when I worked on mainframes, which might be before you were born, some of the big systems had multiple memory units each of which could be connected to disc and/or tape drives. They were of course all connected to the CPU cluster. Going to a PCI based system would tend to indicate that there is a single bus taking all the I/O and CPU traffic, which would be a bottleneck. If the mainframes of 40 years ago had got around that bottleneck why would it have been introduced in the time since? I suspect others here have more recent knowledge than I do. Andy |
| Richard Damon <Richard@Damon-Family.org>: May 23 07:49AM -0400 On 5/23/23 6:33 AM, Vir Campestris wrote: > would it have been introduced in the time since? > I suspect others here have more recent knowledge than I do. > Andy I think part of the answer was that mainframes were much more of a "Distributed" system then more modern machines. The "I/O Channels" were very much a form of processor assigned to do certain pieces of the work. The logic was slower, so the wires between the modules wasn't as critical, so you could have fatter connections. |
| scott@slp53.sl.home (Scott Lurndal): May 23 02:51PM >They were of course all connected to the CPU cluster. >Going to a PCI based system would tend to indicate that there is a >single bus taking all the I/O and CPU traffic, which would be a bottleneck. In the mainframes, there was still a single bus from the memory subsystem to the I/O subystem. And in those days, 8MByte/second was a high-speed transfer rate from memory to the I/O controller, and 1Mbyte/sec was the typical transfer rate between a disk drive and the disk controller, allowing eight controllers to simultaneously transfer data to/from memory (interleaved with processor accesses to the same memory). The PCI bus designed in the late 80s/early 90s was indeed a bus, (originally at 33mhz, 66mhz for PCI-X). Modern PCI express is _not_ a bus. It's a point-to-point serial link between the host memory complex and an I/O controller (storage host adapter, network interface card, etc). PCI Express Generation 6 will transfer 128 Gigabytes/second in a 16-lane configuration, and most high-end processors support multiple PCIe 6.0 controllers. >I suspect others here have more recent knowledge than I do. See above. |
| Muttley@dastardlyhq.com: May 23 02:54PM On Tue, 23 May 2023 14:51:25 GMT >Modern PCI express is _not_ a bus. It's a point-to-point serial link Though these days "serial" means little more than a single data line. Modern serial comms such as USB and SATA are packet based and have more in common with ethernet than RS232. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 23 06:26PM +0200 Am 23.05.2023 um 12:33 schrieb Vir Campestris: > If the mainframes of 40 years ago had got around that bottleneck > why would it have been introduced in the time since? Whatever PCIe I/O-devices mainframes have today - I get about ~1.1E6 / ~4GB/s random 4kB-I/Os per second on my 90$ Samsung 980 Pro 1TB PCIe 4.0 SSD with 3 - 4% CPU load (AMD 7950X, I/O completion ports - Perfor- mance Monitor shows ~1.1e6 interrupts per second) under Windows 11 and I guess that today's mainframes do that not much more efficient. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: May 22 11:20PM -0400 > N might be lost to the user but the compiler/runtime is quite well aware of > what it is otherwise delete[] couldn't work which makes me wonder why its > not made available to range based loops. Well, there are (up to) 2 different Ns. First N is a bound of template parameter when it is an array with a known bound. Second N is that number of elements that compiler knows (in the implementation-dependent way) when array delete expression destroys the objects. If begin() and end() on shared_ptr were defined, would these lines remain legal C++ code? shared_ptr<mystruct[3]> spt1(new mystruct[2]); // (a) shared_ptr<mystruct[2]> spt2(new mystrucct[3]); // (b) shared_ptr<mystruct[2]> spt3(getNFromFile()); // (c) ? If yes, how many elements would range loop iterate thru? I think maybe if the Standard only allowed shared_ptr specialization with an array of unknown bound, the behavior of end() would be technically easier to define (but still difficult to implement as any implementation-specific feature). Still, this would take us beyond smart pointer design goal -- which is in essence to improve on safety of a raw pointer while preserving as many of the raw pointer capabilities as possible. If we need an array, we have std::array; if we have a vector, we have std::vector and std::valarray. (I personally think it is a shame that we don't have an exact-size vector (i.e. a vector sized like valarray, with no capacities) but still it is not a good excuse to abuse poor little smart pointers. For the exact-size vector, using new[]- allocated memory and compiler trickery for N could be justified). -Pavel |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: May 23 07:11AM +0200 On 2023-05-21 5:53 AM, Pavel wrote: > unclear benefit. > E.g. assume that, in line with your example, N becomes part of > shared_ptr instatiation *type* It is. For example, otherwise my example of how to do this would not work. > or, even better: > shared_ptr<mystruct[3]> sp(new mystruct[getNOfMyStructs()]); > What can possibly go wrong? (TM) You shot your leg off. C++ allows that, in general. shared_ptr provides support for arrays, including I believe restrictions on conversions, but not total type safety enforcement. - Alf |
| "Öö Tiib" <ootiib@hot.ee>: May 23 12:14AM -0700 On Tuesday, 23 May 2023 at 06:22:18 UTC+3, Pavel wrote: > it is not a good excuse to abuse poor little smart pointers. For the > exact-size vector, using new[]- allocated memory and compiler trickery > for N could be justified). IOW it is shame that the implementation-dependent way of figuring how many destructors to call with delete[] to pointer allocated with new[] is not exposed to programmers for to write such a class themselves if the standard library does not bother. |
| Muttley@dastardlyhq.com: May 23 08:17AM On Mon, 22 May 2023 18:10:54 +0200 >No, if the shared_ptr should behave like a container you'd need >an iterator-type with * and ++ and a begin and end-method on the >shared_ptr. I think the C++ designers thought this isn't necessary. Well they thought it necessary to be able to store arrays and index them inside a shared pointer, so why didn't they complete the job? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 23 10:20AM +0200 > Well they thought it necessary to be able to store arrays and index > them inside a shared pointer, so why didn't they complete the job? No need to worry about that because there is a workaround that has other benefits as well. |
| Muttley@dastardlyhq.com: May 23 08:24AM On Tue, 23 May 2023 10:20:08 +0200 >> them inside a shared pointer, so why didn't they complete the job? >No need to worry about that because there is a workaround that has >other benefits as well. Yes I know, but thats not the point. If they going to add features to the language why don't they do it properly instead of some half assed job? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 23 03:44PM +0200 > Yes I know, but thats not the point. If they going to add features to the > language why don't they do it properly instead of some half assed job? For me the current solution is proper enough. C-style arrays aren't very common in C++. |
| 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