Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-03 03:02:58

On Sun, Jul 2, 2017 at 7:44 PM, Edward Diener via Boost <
boost_at_[hidden]> wrote:

> On 7/2/2017 8:17 PM, Niall Douglas via Boost wrote:
>
>> (note to this reply: on his request, Vinnie and I have replayed an
>> offlist conversation we had back onto boost-dev in order to get
>> feedback. Hence the tone adopted is a bit weird and I'm talking about
>> boost-dev as a third party, which makes no sense if I were writing this
>> to here. Be aware I have edited this message somewhat over the original
>> as this goes on the public record, it is not identical to the original)
>>
>>
>> I have no desire to enlarge the scope of Beast beyond that which is
>>> suitable for standardization.
>>>
>>
>> I would be absolutely amazed if HTTP hard coded for the Networking TS
>> could be standardised.
>>
>> There are tons of big C++ users out there who would rightly veto such a
>> thing. Qt provides an extensive networking implementation which does not
>> work well with ASIO. So does Apple, Google and Microsoft, all of whom
>> have substantial proprietary networking implementations, and whose WG21
>> reps would veto such a proposal in my opinion.
>>
>> If you are aiming for Beast to be standardised, I think you are
>> absolutely dead in the water with the current design. I had no idea
>> until now that you intended that, and I really think you need to tell
>> the Boost peer review that, because I don't think anyone else realises
>> that either.
>>
>
> No, this sort of thing is irrelevant. Whether any Boost library would like
> to be part of the C++ standard or not should not come into consideration
> when reviewers look at a library to be added to Boost. In reality nearly
> all Boost authors of libraries probably would like their libraries to be
> added as a C++ standard library, but this has nothing to do with the
> quality of the library itself.
>

+1

In C and C++ it is possible to design libraries that are both portable and
low overhead compared to pretty much any other language. While Python may
need all kinds of libraries to do basic things, in C and C++ many times
there is no need for a library to be standardized, there would be little
gain. Consider for example something like libpng or Boost -- they're
available, often preinstalled on pretty much any operating system under the
sun already.

Further, I think it is a bad idea to standardize a library before it has
been deployed for many years outside of the standard, no matter how good it
may be. If it is that good, people will reach and use it anyway, and if not
the standard is better for not including it.

It is especially evil to attempt to standardize a library as means to force
adoption -- again, if the library is better than any other alternative,
people will use it. If not, it has no place in the standard.