On 08/03/2017, Sage Weil wrote:
> That removes a lot of the flexibily of the current DENC. OTOH, it
> might be that the set of cases where the above is insufficient and
> the current DENC still is is pretty small?
Well! In the bounded case we know there's a limit on the amount of
flexibility we /can/ have, just because we're not allowed to vary the
encoding based on anything BUT supplied feature bits, so I don't think
we have to worry about encodings.
I /suspect/ the amount of flexibility we'd end up using for bounded
objects if fairly small, though I can, as mentioned, think of fancier
things to do. (I think any interesting, likely cases could be handled
by const functions that take some set of class members and return some
stuff to be encoded. Which coudl be done in the same sort of
semideclarative style.)
> I'm inclined to just drop the trick and pass T() everywhere
> instead... at least until we have something better. Objections?
Two potential ones. On the one hand that would require everything
dencable to be default constructible. That isn't a problem now but
it's something I'd like to not have be the case forever. (But that
bridge can be crossable in the Idealized Future.)
The more pressing objection might be that if the current idea is to
make sure bounded objects really /are/ bounded, passing T() might be
the worst of all worlds. If caught at compile time the problem goes
away. If caught at runtime with the nullptr it at least gives a
definite error in a useful place. If we pass T() then an object that
claims to be bounded but /isn't/ could calculate the wrong bound and
then we'd have to debug overruns or underruns or something.
Given that, I think if we're going to give up on this feature for now,
the 'least bad' alternative would be to just document the requirements
for an object that claims to be bounded but pass the supplied object
reference in all cases. We might have poorer performance from someone
violating the guarantee, but not outright incorrectness. Also errors
of this sort seem as if they should be easily eyeballed. One need only
look for objects that claim to be bounded and see how they implement
their bound_encode method.
--
Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
