3 ms·

> operator overloading for non-arithmetic purposes I’m not sure it makes it a ‘good’ idea, but I recently needed to overload [] on an embedded system. The chip

> operator overloading for non-arithmetic purposes I’m not sure it makes it a ‘good’ idea, but I recently needed to overload [] on an embedded system. The chip we used in a design didn’t have enough pins for both SPI and external memory. One of the memory address pins was used for both. So we wired up the memory skipping over the pin. This led to odd behavior that didn’t make sense until the original hardware engineer remembered he’d had to build it this way as a price compromise (the chip with enough pins would have probably been double the price). So I had to make sure that an adress translation happens on every access to DRAM, and overloading array access was a very obvious clean way to do this for any code that already did array access.

majewsky 6y ago
I think this is what Walter gets at with "only becomes apparent after years". Right now, you are aware that a[i] is not exactly (only practically) identical to *(a + i). The problem only arises when, years later, someone who reads the code does not realize that. Writing getoffset(a, i) instead of a[i] is uglier, but it will correctly prompt the reader to check out the definition (or documentation) for getoffset().
- martin-t 6y ago
  People could still accidentally use []. I think langs should also support forbidding certain constructs to avoid pitfalls.
  - milesvp 6y ago
    Yeah, it's actually worse than that. Anyone trying to access DRAM on this hardware rev needs to be aware of the problem. Whether or not they use [] in that particular code they need to know that memory accesses will bite them. They also need to make sure that their data structures are byte aligned with the memory boundary, or they're going to have impossible to debug bugs. Especially since the debugger has no way to know that DRAM is wired funny, so you can't trust it's output. There were really no clean ways to deal with this hardware compromise. Avoiding [] to Leave some bread crumbs around is maybe an ok solution. But there are bigger breadcrumbs around, like the malloc() implementation that is needed for this hardware.

majewsky 6y ago

I think this is what Walter gets at with "only becomes apparent after years". Right now, you are aware that a[i] is not exactly (only practically) identical to *(a + i). The problem only arises when, years later, someone who reads the code does not realize that. Writing getoffset(a, i) instead of a[i] is uglier, but it will correctly prompt the reader to check out the definition (or documentation) for getoffset().

martin-t 6y ago
People could still accidentally use []. I think langs should also support forbidding certain constructs to avoid pitfalls.
- milesvp 6y ago
  Yeah, it's actually worse than that. Anyone trying to access DRAM on this hardware rev needs to be aware of the problem. Whether or not they use [] in that particular code they need to know that memory accesses will bite them. They also need to make sure that their data structures are byte aligned with the memory boundary, or they're going to have impossible to debug bugs. Especially since the debugger has no way to know that DRAM is wired funny, so you can't trust it's output. There were really no clean ways to deal with this hardware compromise. Avoiding [] to Leave some bread crumbs around is maybe an ok solution. But there are bigger breadcrumbs around, like the malloc() implementation that is needed for this hardware.