Re: [Multi] Proposal

From: Alfredo Correa (alfredo.correa_at_[hidden])
Date: 2024-09-25 02:27:08

Date: Sun, 22 Sep 2024 17:13:07 +0200
> From: Seth <bugs_at_[hidden]>
>

Thanks Sehe for the feedback.
I answered Artyom in a separate message in the mailing list.

>
> On Sat, Sep 21, 2024, at 7:10 PM, Artyom Beilis via Boost wrote:
>
>
> > But if you don't provide algorithms, maybe I'd better take a
> > library/framework that does.
> Perhaps.
>

This is the eternal discussion of frameworks vs generic components.

> > But, you making numpy-like library... otherwise you wouldn't be
> > interfacing cblas.
>
> A clear case of diyd/diyd ("Damned If You Do, Damned If You Don't"). Of
> all the features you're missing here you decry "At least show ways to
> interoperate with existing thirdparty libraries". Now, they went and did
> that (if I'm not mistaken, clearly marked as an extension that might not
> even be part of the proposed library), and you decry that. There's no
> winning.
>

I couldn't have said it better myself.

> > It [OpenCV] ain't perfect by any means. But it works, well debugged,
> understood
> > and is a widely available library that does the job.
>
> It's also a pretty heavy dependency, especially if you didn't need all the
> other stuff, and appears to be an example of an intrusive framework (for
> good reason, IFF you need the rest)
>

Right, comparing a framework with a generic component is a waste of time.

One has to look at how things inside and "outside" the framework compare,
and how the code scales after that.
This takes a lot of time and effort and will keep boiling down to
frameworks vs generic component.
I will say "you can sort with std::sort a 2D array" and the other person
will answer either that a) "he/she doesn't need to do that" or b) that
"he/she can ask the developer of the framework to implement .sort_by_row
and .sort_by_col`" or c) that "he/she can take the pointer to the data
structure and do it himself".
It is a never ending argument.

> > Exceptions are useful. And claiming that you don't throw ones means
> > you don't use new...
>
> Many things don't require allocation. Meanwhile `new(std::nothrow)` has
> existed since c++11.
>

It is more general than that, the library tries to gives some guarantees
for exceptions that happen during allocation or element copy/assignments.
The library itself doesn't throw exceptions during these operations, but it
handles the ones that the elements operations or allocators produce, if it
needs to,

Thank you all for you feedback,
Alfredo