On Thu, 23 Sept 2021 at 01:13, Matt Bentley <mattreecebentley@gmail.com> wrote: 
Thanks Joel- if you don't mind I'll quote you in a later version of the paper
(putting together an appendix of use-case quotations). 

I don't mind, though I have noticed that some in the committee assume people's experience feedback when coming from games and some other industries are not taken seriously and are considered not relevant, not necessarily officially but effectively.
Basically, I don't think that will help.
Where is it used in music? AFAIK most plugin design etc is strictly
ordered in terms of samples etc, so I'm interested as to where it's
getting used in the process.

For music, which is still a bit new to me (I have been in this domain on the programming side only for a year now), I have seen situations where hive would have been a better choice and would have simplified the code - but was not available at the time of writing or the devs weren't ready to setup a similar container to solve their problem (and then I ended up having to maintain that, but couldn't replace the whole thing with hive without a major rewrite).
I'm talking about music as in the domain, not specifically audio code (which is what you are mentioning). The main example I am thinking about is musical score modeling, transformation, display and audio interpretation (similar to playing midi, but from a score instead of midi). The internal data model is where I spotted the issues that could have been simplified by hive, mainly by benefiting from fast traversal and stable location of elements, allowing to refer to them directly instead of doing shared pointers guesses. (that codebase also could benefit from immutable data structures but that's unrelated).
It's totally possible my experience is not common in that specific domain, but I spotted this and it's a pattern/situation/opportunity I have seen a lot of codebases in the last 15 years (mostly in performance-focused domains).

Joël Lamotte


On 22/09/2021 6:03 am, Klaim - Joël Lamotte via SG14 wrote:
> Hi, here is my opinion:
> I'm using colony/hive and I have been in several industries where
> similar containers were used, and even more industries where the current
> standard containers are misused to solve the problems that hive solves
> easily.
> The domains where I have seen these situations: robotics, game (engines
> and not), gaming(lottery), simulation and now music (all these with both
> not-embedded and embedded context).
> I also had some C++ students confused by standard containers in
> situations where something like hive would have made more sense (in
> particular when order is not important but memory location of elements is).
> I'm all for hive being available as soon as possible.
> A. Joël Lamotte
> On Mon, 20 Sept 2021 at 16:58, Guy Cpp via SG14 <sg14@lists.isocpp.org
> <mailto:sg14@lists.isocpp.org>> wrote:
>     Might I also remark to SG14 that if there is any proposal besides
>     hive you like the look of, for example linear algebra, please shout
>     about it to LEWG at any invitation. Most Recently Surfaced is the
>     algorithm.
>     (P1385 is unlikely to be ready for January though.)
>     Cheers,
>     G
>     On Mon, 20 Sept 2021 at 14:25, Michael Wong via SG14
>     <sg14@lists.isocpp.org <mailto:sg14@lists.isocpp.org>> wrote:
>         Matthew, Thank you for this push and reminder. Several members
>         are in LEWG and should continue to support this proposal. This
>         is one of the most sought after proposal and is on our agenda of
>         lists of SG14 proposals we track.
>         On Sun, Sep 19, 2021 at 7:01 PM Matt Bentley via SG14
>         <sg14@lists.isocpp.org <mailto:sg14@lists.isocpp.org>> wrote:
>             Hi all-
>             I've put a request forward on the LEWG mailing list to see
>             what the
>             feeling is around getting what was formerly the colony
>             proposal (now
>             'hive') into C++23.
>             I know it's easy to miss these posts, what with the volume
>             of traffic in
>             LEWG, so if anyone here is also on LEWG please put your
>             opinion forward
>             there. In my view 2027 is too late to see hive in the standard.
>             The current proposal is here if anyone is interested:
>             https://isocpp.org/files/papers/P0447R16.html
>             <https://isocpp.org/files/papers/P0447R16.html>
>             Cheers,
>             Matt
>             _______________________________________________
>             SG14 mailing list
>             SG14@lists.isocpp.org <mailto:SG14@lists.isocpp.org>
>             https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>             <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
>         _______________________________________________
>         SG14 mailing list
>         SG14@lists.isocpp.org <mailto:SG14@lists.isocpp.org>
>         https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>         <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
>     _______________________________________________
>     SG14 mailing list
>     SG14@lists.isocpp.org <mailto:SG14@lists.isocpp.org>
>     https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>     <https://lists.isocpp.org/mailman/listinfo.cgi/sg14>
> _______________________________________________
> SG14 mailing list
> SG14@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14