Ariel-Burton wrote:
> My opinion might change as I actually look through the implementation of
> `HexFloat`, but given that we will have 4 subclasses (IEEEFloat, HexFloat,
> DecimalFloat, and DoubleAPFloat), we might to reorganize the hierarchy of the
> APFloat inner classes so that we can do some of the operations without having
> to do the full union dispatch--there is essentially a common core of
> {fltSemantics, sign, category, exponent, significand} that we can share among
> all of them, with the latter three having extra fields.
>
> But I'm not sure this patch is the appropriate place to do that
> reorganization.
I agree this is not the right place for a reorganization of the APFloat
hierarchy, and I agree that there's a conversation to be had.
I have wondered a bit about how this set of classes are arranged. To me it
looks like dispatching off the fltSemantics pointer is much like a virtual
method call, and I wonder why the decision to implement an ad hoc mechanism
like this was adopted. The arrangement requires the first field of any of
these related classes to be the pointer to the fltSemantics. This looks very
fragile.
https://github.com/llvm/llvm-project/pull/179771
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
