I thought (for shits and giggles) to try and implement the Aho-Corasick algorithm[1].


I thought I'd start with a struct to represent the "interval":

    struct Interval {
        size_t d_start;
        size_t d_end;
        size_t size;

        this(size_t start, size_t end) {
            d_start = start;
            d_end = end;
            size = d_end - d_start + 1;
        }
    }

It'd be useful to check for equality and inequality between instances of `Interval`, so I thought to use `.opEquals` for `d_start` and `d_end`.

    bool opEquals(ref const Interval i) const {
        // probably would be a bit more than just this, but for this issue
        // let's just stick with this.
        return d_start.opEquals(other.d_start) && d_end.opEquals(other.d_end);
    }


But I do get an error saying

`none of the overloads  of `opEquals` are callable using argument types `(const(ulong), const(ulong))`, candidates are:` and it doesn't say the candidates.

So should I bother with operator overloading here, or just make a member function?

[1] https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm

On Thursday, 14 March 2019 at 18:07:46 UTC, Alec Stewart wrote:
>         // let's just stick with this.
>         return d_start.opEquals(other.d_start) && d_end.opEquals(other.d_end);

Why not just use d_start == other.d_start && d_end == other.d_end there?


> So should I bother with operator overloading here, or just make a member function?

You shouldn't often call .opEquals yourself, just write a == b and let the compiler translate it if it needs to.

On Thu, Mar 14, 2019 at 06:07:46PM +0000, Alec Stewart via Digitalmars-d-learn wrote: [...]
>     bool opEquals(ref const Interval i) const {
>         // probably would be a bit more than just this, but for this issue
>         // let's just stick with this.
>         return d_start.opEquals(other.d_start) && d_end.opEquals(other.d_end);
>     }

There's no need to call opEquals explicitly like that. All you need to do is to use <, ==, and > as you normally would:

     bool opEquals(ref const Interval i) const {
         return d_start == other.d_start) && d_end == d_end;
     }


T

-- 
Без труда не выловишь и рыбку из пруда.

On Thursday, 14 March 2019 at 18:25:17 UTC, H. S. Teoh wrote:
> On Thu, Mar 14, 2019 at 06:07:46PM +0000, Alec Stewart via Digitalmars-d-learn wrote: [...]
>>     bool opEquals(ref const Interval i) const {
>>         // probably would be a bit more than just this, but for this issue
>>         // let's just stick with this.
>>         return d_start.opEquals(other.d_start) && d_end.opEquals(other.d_end);
>>     }
>
> There's no need to call opEquals explicitly like that. All you need to do is to use <, ==, and > as you normally would:
>
>      bool opEquals(ref const Interval i) const {
>          return d_start == other.d_start) && d_end == d_end;
>      }
>
>
> T

Thanks. I somehow managed to overthink this...

For < and >, would one do this?

    size_t opCmp(ref const Interval other) const {
        return d_start < other.d_start;
    }

    size_t opCmp(ref const Interval other) const {
        return d_end < other.d_end;
    }

    size_t opCmp(ref const Interval other) const {
        return d_start > other.d_start;
    }

    size_t opCmp(ref const Interval other) const {
        return d_end > other.d_end;
    }

Or would it better to do

    size_t opCmp(ref const Interval other) const {
        if (d_start < other.d_start) {
            return d_start < other.d_start;
        } else if (d_start > other.d_start) {
            return d_start > other.d_start;
        } else if (d_end < other.d_end) {
            return d_end < other.d_end;
        } else if (d_end > other.d_end) {
            return d_end > other.d_end;
        } else {
            return false;
        }
    }

On Thursday, 14 March 2019 at 19:39:53 UTC, Alec Stewart wrote:

> For < and >, would one do this?

I think you'd benefit a lot by reading http://ddili.org/ders/d.en/operator_overloading.html (just search for opCmp). I bet that will eliminate most of your confusion !