Re: [boost] [container] Contributing 'stationary_vector' to Boost

niedz., 12 cze 2022 o 10:58 Mehrdad Niknami via Boost napisał(a):

On Mon, Jan 18, 2021 at 12:39 AM Mehrdad Niknami wrote:

...

On Mon, Jan 18, 2021 at 12:32 AM Hans Dembinski < hans.dembinski@gmail.com> wrote:

...

Please do not top post. We have a no top-post policy for the mailing list.

I cannot help you with that. If he does not answer here, you could try to submit an issue to https://github.com/boostorg/container. Ion commits frequently to the repo, so I hope he sees that.

Best regards, Hans

Oh I see, okay thanks!

Best, Mehrdad

Hi all,

I just wanted to follow up on my stationary_vector proposal earlier. I do realize it's been a long time (I'm sorry about that)—I'll try to explain the current status below.

For context—I was in touch with Ion last year as was suggested here (thank you). He was very helpful and suggested improvements I would need to make to prepare this for a Boost review, and I made some changes in that light. Unfortunately, things stalled at that point, as life got in the way—initially for me, then for him—and he doesn't believe he'll have the bandwidth to review major contributions to Boost.Container anytime soon. Therefore he suggested I reach out to you all here in the hopes that someone may be able to move the ball forward.

Given I have more bandwidth in my life at the moment, I'd love to spend the extra time needed on this to get it into Boost ideally as soon as possible—I'd really love to make it available for people to use! I'm not really sure who else might be able to review/accept contributions to Boost.Container in particular, though, as I'm pretty new here.

Would anybody be able to help review this contribution and guide me through the process toward getting it merged?

Hi Mehrdād, Thank you for writing this library, and sharing it. I can share some hints on how to get a library accepted into Boost. But I am not sure if the same rules apply when you want to add a component to an existing library. Before a library gets into Boost it has to undergo the Boost Review process. Here's the link to the instructions describing the submission process: https://www.boost.org/development/submissions.html Here's the page describing the Boost Review process: https://www.boost.org/community/reviews.html The best one can do in order to make one's library get into Boost is to make sure the library meets the Boost Review standards. The process usually takes time. I can offer some very initial feedback about the design/usefulness. The link provided in the initial mail in this post does not work. I found this one instead: https://github.com/mehrdadn/libvital/blob/master/doc/cpp/vital/container/sta... I understand that the library offers different trade-offs to STL containers which one might find sometimes useful. But I am not sure when that would be. I would expect the docs to tell me when I would prefer this container to others already present in the STL. The docs say, stationary_vector is "semantically, it is *almost* a drop-in replacement for std::vector, except [...]". This is a misleading statement. "Almost" says nothing more than that it is actually not a drop-in replacement for std::vector. THe basic guarantee that std::vector provides is that it stores a contiguous array of elements underneath and that I can access it and pass it to a C-style function that works on raw arrays: std::vector<char> vec {'a', 'b', 'c', 'd'}; c_function_that_takes_pointer_and_length(vec.data(), vec.size()); I don't think stationary_vector can offer that. For that reason, I am not sure if "vector" is a good name for the container. The docs also say, "Exception-safety is intended to be on par with that of std::vector (if not better). I have tried to ensure this, but it has undergone limited testing." This does not seem comforting. "Exception safety" cannot be equal or better than that of another library. It is not even clear what you mean by this. It is not libraries that offer exception safety, but functions that offer guarantees as to what state the objects are left in when a function that modified them reported an error. It also seems to be saying that the author does not know if the library functions are exception safe. The best course of action would be to *document* the exception safety of the functions in the library and provide automatic tests for demonstrating that these guarantees are satisfied. How to test this is described at: https://www.boost.org/community/exception_safety.html "*Testing* for single-threaded use is done against test suites for std::vector from standard libraries" -- how can they pass, given that stationary_vector doesn't guarantee a contiguous layout of elements? I hope that you will find this critique helpful. Regards, &rzej;