I've implement a small size optimized `string` at

https://github.com/nordlow/phobos-next/blob/c35fa4052738af0cd7ad39a9fa715b5ec29c7bba/src/nxt/sso_string.d

I'm now wondering whether or not its definition of comparison at

https://github.com/nordlow/phobos-next/blob/c35fa4052738af0cd7ad39a9fa715b5ec29c7bba/src/nxt/sso_string.d#L248

is a suitable definition of `opCmp` for `SSOString` in terms of independence of Phobos' `std.algorithm.comparison.cmp`.

I'm asking because comparison of `string`s can be done directly as

    assert("a" < "b")

without any dependence on Phobos.

Is there a builtin definition of array (of `char`) comparison defined somewhere in druntime?

Further, does

    "a" < "b"

perform autodecoding of UTF-8 sequences?

On Wednesday, 22 January 2020 at 08:30:55 UTC, Per Nordlöw wrote:
> is a suitable definition of `opCmp` for `SSOString` in terms of independence of Phobos' `std.algorithm.comparison.cmp`.

I just found

    import core.internal.array.comparison : __cmp;

I presume that is a better alternative if Phobos' independence is desired.

On Wednesday, 22 January 2020 at 08:44:15 UTC, Per Nordlöw wrote:

> I just found
>
>     import core.internal.array.comparison : __cmp;
>
> I presume that is a better alternative if Phobos' independence is desired.

That looks like it's for internal use. There is a `compare` method in the `TypeInfo` of each type.

https://github.com/dlang/druntime/blob/2fa694319da397d72ab09cb336f3d588107278c1/src/object.d#L541

--
/Jacob Carlborg

On Wednesday, 22 January 2020 at 10:19:38 UTC, Jacob Carlborg wrote:
> That looks like it's for internal use. There is a `compare` method in the `TypeInfo` of each type.

Will that incur an extra runtime cost compared to __cmp?

On Wednesday, 22 January 2020 at 14:50:01 UTC, Per Nordlöw wrote:

> Will that incur an extra runtime cost compared to __cmp?

I haven't looked at how `__cmp` is implemented but I would guess there's some extra overhead. Need to get type info and then there will be several virtual method calls involved. Seems to be one of the initial call to `compare` and then one for each element of the array.

BTW, why don't you implement `opCmp` with the built-in comparison operators. Those are going to get lower to a call to `__cmp`. Something like this:

int opCmp()(const scope typeof(this) that) const @nogc
{
    auto a = this[];
    auto b = that[];
    return a < b ? -1 : (a > b);
}

--
/Jacob Carlborg

On Wednesday, January 22, 2020 7:50:01 AM MST Per Nordlöw via Digitalmars-d- learn wrote:
> On Wednesday, 22 January 2020 at 10:19:38 UTC, Jacob Carlborg
>
> wrote:
> > That looks like it's for internal use. There is a `compare` method in the `TypeInfo` of each type.
>
> Will that incur an extra runtime cost compared to __cmp?

Regardless of the overhead involved, you really shouldn't be calling functions that start with __ or any that are in an internal package. They're not intended to be called directly by anything outside of druntime or Phobos, and they could change at any time. In the case of core.internal.array, the only reason that any of it is even exposed is because it had to be when it was changed to a template.

- Jonathan M Davis

On Wednesday, 22 January 2020 at 15:11:09 UTC, Jacob Carlborg wrote:
> int opCmp()(const scope typeof(this) that) const @nogc
> {
>     auto a = this[];
>     auto b = that[];
>     return a < b ? -1 : (a > b);
> }
>
> --
> /Jacob Carlborg

I see. Good to know. Thanks

On Wednesday, 22 January 2020 at 15:11:09 UTC, Jacob Carlborg wrote:
> BTW, why don't you implement `opCmp` with the built-in comparison operators. Those are going to get lower to a call to `__cmp`. Something like this:
>
> int opCmp()(const scope typeof(this) that) const @nogc
> {
>     auto a = this[];
>     auto b = that[];
>     return a < b ? -1 : (a > b);
> }
>
> --
> /Jacob Carlborg

I presume

int opCmp()(const scope typeof(this) that) const @nogc
{
    scope const a = this[];
    scope const b = that[];
    return a < b ? -1 : (a > b);
}

is preferred.