Yeah, that looks a lot more reasonable if we must split it out, though I would prefer boost. Matt ----- Original Message ----- > From: "Milosz Tanski" <milosz@xxxxxxxxx> > To: "Matt Benjamin" <mbenjamin@xxxxxxxxxx> > Cc: "Sage Weil" <sweil@xxxxxxxxxx>, "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx>, "ceph-devel" > <ceph-devel@xxxxxxxxxxxxxxx>, cbodley@xxxxxxxxxx > Sent: Wednesday, February 3, 2016 4:21:12 PM > Subject: Re: inline vector container > > On Wed, Feb 3, 2016 at 3:57 PM, Matt Benjamin <mbenjamin@xxxxxxxxxx> wrote: > > > > Hi, > > > > I think we should go with small_vector for this role, yes. I found two > > issues. First, there are critical defects in small_vector prior to boost > > 1.6.0. Second, though it is header-only, the coupling with related > > version-specific boost types (container, allocator, respective detail > > types, and platform-specific selectors...) seems to make pulling it in > > separately pretty unrealistic as an option. I looked at the cost of > > pulling in and selectively compiling (libs) an entire boost 1.6, and that > > went a lot easier (added less than a minute to my build time). > > > > Matt > > > > ----- Original Message ----- > > > From: "Sage Weil" <sweil@xxxxxxxxxx> > > > To: "Allen Samuels" <Allen.Samuels@xxxxxxxxxxx> > > > Cc: ceph-devel@xxxxxxxxxxxxxxx, mbenjami@xxxxxxxxxx, cbodley@xxxxxxxxxx > > > Sent: Wednesday, February 3, 2016 3:04:57 PM > > > Subject: Re: inline vector container > > > > > > On Wed, 3 Feb 2016, Allen Samuels wrote: > > > > One thing that the code base needs is a simple vector container that is > > > > optimized for a small number of elements, i.e., for small element > > > > counts we > > > > avoid the malloc/free overhead. But fully supports being resized into > > > > larger > > > > containers that are unbounded. Of course it will need to follow all of > > > > the > > > > proper object copy/move semantics so that things like unique_ptr, etc > > > > work > > > > correctly. > > > > > > > > I heard rumors that there was one available in the boost world, but I > > > > can’t > > > > seem to find it. Do you know about one being available? > > > > > > http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.html > > > The fb / folly code also has a small vector: > https://github.com/facebook/folly/blob/master/folly/small_vector.h > that used a C++11 move semantics whenever possible. Compared other > parts of folly this has pretty small dependencies on folly and those > can prob be ripped out. > > > > > > > > > > > > I’ve been prototyping one myself, just to get re-familiar with all of > > > > the > > > > C++11 move sementics, and trivial constructors, etc. > > > > > > > > The code is pretty complete, but the testing gets rather involved. > > > > There’s > > > > no reason to contain this if it’s available elsewhere. But if it isn’t > > > > I > > > > plan on continuing this… > > > > > > I think Casey had prototyped something similar using a custom allocator, > > > too, but I didn't actually look at the result. And Matt talked about > > > just > > > pulling the boost one in-tree until we get updated boost in the supported > > > distros, but I forget if he ran into problems there or not... > > > > > > sage > > > > -- > > -- > > Matt Benjamin > > Red Hat, Inc. > > 315 West Huron Street, Suite 140A > > Ann Arbor, Michigan 48103 > > > > http://www.redhat.com/en/technologies/storage > > > > tel. 734-707-0660 > > fax. 734-769-8938 > > cel. 734-216-5309 > > -- > > 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 > > > > > -- > Milosz Tanski > CTO > 16 East 34th Street, 15th floor > New York, NY 10016 > > p: 646-253-9055 > e: milosz@xxxxxxxxx > -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 -- 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
