include/denc: improvements #12626
include/denc: improvements #12626
Conversation
| Foo(buffer::ptr::iterator& p, uint64_t features = 0); | ||
| } | ||
|
|
||
| Will have be deconde constructble. Instances of this class can be |
| efficiently decoded into containers. | ||
|
|
||
| Since decode-constructors are new, I require all of them to accept a | ||
| features argument, to avoid the combinatorial explosion. |
There was a problem hiding this comment.
We need to be very careful with this. We generally rely on being able to transition a class from unfeatured to featured and get compile errors on all encoding paths. If callers for this pass in feature fields they aren't explicitly passed (e.g., from a features=0 arg) we may silently fill in bogus features. (Hopefully we haven't already done this elsewhere!)
|
Several build errors.. see https://jenkins.ceph.com/job/ceph-pull-requests/16112/ |
|
The ctor changes are great! |
adamemerson
force-pushed
the
wip-denconstruction
branch
3 times, most recently
from
8361514
to
4be1d09
Compare
adamemerson
force-pushed
the
wip-denconstruction
branch
2 times, most recently
from
c1b91c8
to
65951e4
Compare
|
@liewegas Take another look at this? I plan to redo the constructor stuff on top of it to see if I can get it to work under Trusty Tahr. I don't know if you want to pull this in as is since it's a logically separate change, or hold off until I have the whole thing done. |
|
Let's keep them separate
|
|
retest this please |
adamemerson
force-pushed
the
wip-denconstruction
branch
from
65951e4
to
3d83da8
Compare
|
retest this please |
| std::array<legacy_t, 2> s = { legacy_t(1), legacy_t(2) }; | ||
| test_encode_decode(s); | ||
| cout << "std::tuple<uint64_t, uint32_t>" << std::endl; | ||
| std::tuple<uint64_t, uint32_t> s = { 100, 97 }; |
There was a problem hiding this comment.
the jenkins fails. so might want to put something like
std::tuple<uint64_t, uint32_t> s = { 100U, 97U };instead
| } | ||
| { | ||
| cout << "std::tuple<std::string, uint3_t>" << std::endl; | ||
| std::tuple<std::string, uint32_t> s = { "foo", 97 }; |
| } | ||
| { | ||
| cout << "std::tuple<std::string, std::set<uint32_t>>" << std::endl; | ||
| std::tuple<std::string, std::set<uint32_t>> s = { "bar", {1, 2, 3} }; |
adamemerson
force-pushed
the
wip-denconstruction
branch
3 times, most recently
from
ac501a9
to
15f675c
Compare
|
@liewegas All right! The tests are hammered into submission. |
|
passed rados suite test, http://pulpito.ceph.com/sage-2016-12-29_20:50:13-rados-wip-sage-testing---basic-smithi/ |
adamemerson
force-pushed
the
wip-denconstruction
branch
from
15f675c
to
035f661
Compare
|
@liewegas Do you mean it didn't pass? I see a couple erros but they look like clock skews and problems with the testing infrastructure. |
adamemerson
force-pushed
the
wip-denconstruction
branch
from
035f661
to
9d421a1
Compare
adamemerson
force-pushed
the
wip-denconstruction
branch
from
9d421a1
to
a958ff7
Compare
|
I meant it passed; failures do not appear related. This all looks fine to me. I'm not sure that boost::optional and tuple are that useful, since we aren't explicitly encoding those types, but it's certainly harmless to support them. With optional, for example, it is probably just as likely that we will use a shared flags field to indicate the presence of optional fields. But it does happen... |
|
retest this please |
Using template templates, kill off the reduplication in container encoding. Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
We could support zero-length tuples, but contiguous appender doesn't like zero-length writes, so I've ruled them out for now. Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
adamemerson
force-pushed
the
wip-denconstruction
branch
from
a958ff7
to
ea52d39
Compare
Collapse duplicated code between all containers.
(I know about the test failures, I'll run through those.)