Boost logo

Boost :

From: Domen Vrankar (domen.vrankar_at_[hidden])
Date: 2020-03-09 13:05:56


On Mon, Mar 9, 2020, 1:19 PM degski via Boost <boost_at_[hidden]> wrote:

> On Sun, 8 Mar 2020 at 17:59, Gavin Lambert via Boost <
> boost_at_[hidden]>
> wrote:
>
> > On 7/03/2020 07:14, Vinnie Falco wrote:
> > > In other words, the same type of shitty C API found in ZLib - no
> thanks.
> >
> > There's a reason general-use libraries end up gravitating towards shitty
> > C APIs -- because C++ has a much more shitty ABI, making the C API the
> > only one that can actually be consumed cross-compiler and
> > cross-language-binding.
> >
>
> Thanks for confirming I'm not alone thinking the above. I would like to add
> that imo, there is nothing shitty about a c-api, it is a different language
> all-together, the fact that it is different doesn't make it shitty. It's
> clear, simple and without surprises (cross platform/std/compiler), what's
> not to love?
>
> Dismissing things like zlib (here on the list) or re-writing half of
> OpenSSL in c++ (also under consideration), is utter madness and shows
> little appreciation of the age of those libs and the breadth of their
> adoption/use.
>

I prefer C for ABI part but do prefer C++ for API so I, like you, consider
rewrites in some cases counter productive, however I do want my code to use
C++ API and statically/dynamically link to C however the header only
wrapper wants (that's why I always wrap OpenGL and other hair pulling level
C APIs).

Everyone has their own taste and reasons but still: Since when did Boost
mailing list become a place for rallies against C++?

Btw in case there is a direction towards wrapper instead of rewrite -
perhaps Boost lib should not be limited to a single compression and instead
wrap libarchive or something like that:
https://github.com/do-m-en/libarchive_cpp_wrapper

This one is my unmaintained old toy but I noticed that others can be found
by Google so maybe they could be used as a starting point.

Regards,
Domen

> degski
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk