On Tuesday, 16 July 2013 at 14:18:02 UTC, bearophile wrote:
    size_t vertexCount() @property const pure nothrow
    {
        assert(_sumHead.length == _sumTail.length);
        return _sumHead.length - 1;
    }

Is that better written in a struct/class invariant?

Nice thought -- probably; it's a condition that must always hold.

        size_t degreeIn(immutable size_t v) const pure nothrow
        {
            assert(v + 1 < _sumTail.length);
            return _sumTail[v + 1] - _sumTail[v];
        }

Here you are looking for the method pre-condition.

Ahh, you mean inside in { ... } brackets? I did consider writing it like that. It wasn't clear to me what the benefits were, though, especially as I did consider making this an enforce() rather than an assert().

And "in size_t v" is enough compared to "immutable size_t v".

Does "in" allow for subsequent mutation _within_ the function?

For such kind of code I suggest to use UFCS chains.

Can you explain in a little more detail? It's not an aspect of programming I'm familiar with.

Also be careful with the performance of such range-based code, writing benchmarks. Unfortunately often DMD doesn't compile it efficiently.

Yes, this is a concern of mine too. In benchmarks I've carried out, the calls to e.g. neighbours() take up a substantial chunk of the overall runtime -- but that said, the number of calls to them is very, very large. It works out as on the order of between 1e-9 and 1e-8 seconds per call.

These kinds of range-based solutions seem to be a part of D where LDC typically produces the best performance. But I would not use DMD for serious number crunching of any kind -- as it stands it can't match either of the other two compilers.

Anyway, thanks very much for the useful feedback :-)

Reply via email to