DavidSpickett wrote: Got part way into the optional idea and though I think it would be a good one if we had started with it, it has some usability problems.
* We cannot assume that `sizeof(buffer) == sizeof(buffer_type)`. Which leads to some places where you have to write `sizeof(some_generic_type)`. Which is not ideal. Being able to use the member variable name is clearer. * We have to make the buffer "valid" before trying to read, then make it invalid if it fails. Rather than read and if it succeeds mark it valid. 3 steps vs. 2. * Some things like SVE resize the buffer when we get the new vector length, then at some point later assume the buffer can hold the result of a read. We'd have to track the expected size separately, and use that to resize it just before read. Which is not difficult, but it's a different strategy and I don't want to disturb all the SVE/SME handling at this stage. * Though our buffer + bool is in theory an optional, the way the class is designed where one thing fills the buffer and another reads from it later, the flexibility of when to set the bool does help us. Versus the automatic handling optional does. Once this whole class has been simplified and I can see the "unusual" code paths more easily, I might revisit the idea. For now, I'm sticking with the bag of booleans strategy. https://github.com/llvm/llvm-project/pull/197113 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
