Here's a beginning on what that might look like: https://github.com/athanatos/ceph/commits/wip-sam-enc-dec-proto The design mostly comes from Allen/Varada's approach, but it uses unsafe_appender (I don't really feel strongly about that, Sage indicated that just using a raw pointer would probably be faster). The important part is that the top two commits above convert all primitive types as well as vector and pair (provided that their templated types support the new machinery). This means that vector<int> should be able to preallocate and use unsafe_appender for all existing users. I think it's worth going to some effort to make it easy to convert over existing users. -Sam On Thu, Aug 18, 2016 at 10:35 AM, Allen Samuels <Allen.Samuels@xxxxxxxxxxx> wrote: > No reason not to merge them. > > > Allen Samuels > SanDisk |a Western Digital brand > 2880 Junction Avenue, San Jose, CA 95134 > T: +1 408 801 7030| M: +1 408 780 6416 > allen.samuels@xxxxxxxxxxx > > >> -----Original Message----- >> From: Samuel Just [mailto:sjust@xxxxxxxxxx] >> Sent: Thursday, August 18, 2016 9:43 AM >> To: Allen Samuels <Allen.Samuels@xxxxxxxxxxx>; Varada Kari >> <Varada.Kari@xxxxxxxxxxx>; ceph-devel@xxxxxxxxxxxxxxx >> Subject: wip-enc-dec >> >> Is there a reason not to put this new machinery directly into encoding.h? The >> new machinery seems to be sufficient to implement the existing ::encode >> and ::decode types and should be compatible, right? >> With the containers, we can use template trickery to also forward the new >> functions when present in the mapped types. That would let us gradually >> adapt the code base. >> -Sam -- 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
