Re: [container] Contributing 'stationary_vector' to Boost

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2022-06-12 20:58:29

niedz., 12 cze 2022 o 10:58 Mehrdad Niknami via Boost <boost_at_[hidden]>
napisał(a):

> On Mon, Jan 18, 2021 at 12:39 AM Mehrdad Niknami <mniknami_at_[hidden]>
> wrote:
>
> > On Mon, Jan 18, 2021 at 12:32 AM Hans Dembinski <
> hans.dembinski_at_[hidden]>
> > 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/stationary_vector.md

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;