On Saturday, 19 September 2020 11:41:08 PDT Ville Voutilainen wrote: > On Fri, 18 Sep 2020 at 21:58, Thiago Macieira <[email protected]> wrote: > > Anyway, the int suffices because we only need four values: > > equal/equivalent,> > > less than, greater than, unordered. We can even adopt the same values: > > // less=0xff, equiv=0x00, greater=0x01, unordered=0x02 > > > > or we can use -127 for unordered like libc++ does or -128 like Microsoft > > STL. > Well, if we envision making it convertible to something later on, then > *PLEASE* use a class type. > I have recent experience on a particular codebase that wanted to > migrate from custom allocators > to standard allocators, and one significant part of it was converting > standard allocators to the custom > ones. But that didn't work because the API vocabulary type was > CustomAllocator*. > > You can't write a conversion from a type you don't own to an int, or > vice versa. Don't fall into that trap, it's impossible > to dig yourself out of it.
Sorry, I don't understand the issue. I'm thinking of an internal function that is used to implement operator<=> (and if pre-C++20 support is desired, operator== and operator<). That's how I implemented QCborValue, though compare() is public and it does not need unordered comparisons. If it works for memcmp and QString::compare, I don't see why it couldn't work here too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
