> On 22 Sep 2020, at 08:54, Thiago Macieira <[email protected]> wrote: > > On Monday, 21 September 2020 22:55:16 PDT Lars Knoll wrote: >> I do not want to simply return an int, as the risk that people ignore the >> Unordered state it too big with that. So the other choice would be to add >> an enum in the Qt namespace (as I need this for QMetaType as well, which >> currently has a std::optional<int> compare()). > > For internal APIs, please return just a plain int.
Those compare() methods are meant to be public. > > For public ones, either call the internal or please use > std::optional<qsizetype>. Code generation is slightly better. Compare the > Clang panes at > > qsizetype - https://gcc.godbolt.org/z/5bTbq6 > int - https://gcc.godbolt.org/z/b6jn8s Really? Are we now making API decisions on how well a compiler manages to micro-optimize this? We have been using int as a return value for QString::compare(). qsizetype feels unnatural in this context, so I don’t want to use it. > > The other three compilers just show how using std::optional is worse than an > int: both GCC and ICC currently unnecessarily spill to the stack (you can > avoid the spillage with std::optional<signed char>). MSVC always returns non- > primitives by implicit reference, so a memory access is always present. > > All the memory accesses go away if you call an internal function: > https://gcc.godbolt.org/z/rYde7c Meaning you inline the public method. Before we go to micro optimisations, let’s please first define what the best API would look like from a users perspective. I can see three choices that don’t rely on C++20: 1) std::optional<int> compare(); 2) enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff }; Ordering compare(); 3) Implement a Qt replacement for std::partial_ordering (could use the std stuff if C++ 20 is available) and use that. Cheers, Lars _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
