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 :-)
