search

Stiffstream / restinio

Cross-platform, efficient, customizable, and robust asynchronous HTTP(S)/WebSocket server C++ library with the right balance between performance and ease of use
Other
1.13k stars 92 forks source link

How critical is it to keep RESTinio a C++14 project in 2021? #135

Closed eao197 closed 8 months ago

eao197 commented 3 years ago

This question is related to #132. Http-parser is no longer maintained and it is necessary to replace HTTP-parsing code in RESTinio with something else.

There are several ways to do that. Http-parser can be replaced by somewhat similar, like https://github.com/nodejs/llhttp or https://github.com/h2o/picohttpparser. That way has its advantages (well-tested code that is maintained by others). But there are some drawbacks too. One of them is handling dependencies. Http-parser was present in vcpkg and Conan and that simplified distribution of RESTinio via those managers. That is not the case for llhttp and picohttpparser (AFAIK).

Another way is to write our own HTTP-parser for RESTinio. It'll require a lot of work, of course. But can give us some benefits. Like native support for non-standard HTTP-methods (we were asked about that feature in the past, see #26). Or like support for some rarely used HTTP features (chunk extensions (https://tools.ietf.org/html/rfc7230#section-4.1.1) as an example).

However if we choose to write our own HTTP-parser then we'll have two alternatives:

  1. Forget about "header-onlyness" of RESTinio. The code of HTTP-parser will be placed into a .cpp file and RESTinio will be an ordinary compilable library (with typical for C++ static/dynamic dichotomy).
  2. Keep RESTinio as a header-only library and express HTTP-parser as constexpr and/or template-based stuff.

I personally think that keeping RESTinio as a header-only library is a good thing. But writing complex constexpr/template-based code in C++14 is harder than in C++17. So switching to C++17 for RESTinio v0.7 can significantly simplify our work.

The switch to C++17 can also reduce the number of required third-party libraries. For example, there won't be a need for optional-lite, string_view-lite, and variant-lite. Maybe we can even throw out expected-lite (because somewhat similar to expected can be written on the top of std::variant manually).

So I want to ask users of RESTinio: is it critical to you to keep C++14 as the minimal required C++ standard for RESTinio in 2021?

I don't look further than 2021, but think that in 2022 we'll switch to C++17 anyway.

The choice of the replacement for http-parser isn't done yet. I just do an overview of different possibilities. And it is good to know what our users think about.

feliwir commented 3 years ago

I'd appreciate a switch to C++17. I use that as the minimum standard for all my projects for a while now and it works everywhere reasonably well. The reduction of third-party deps is a great benefit of that aswell, as you've already mentioned

prince-chrismc commented 3 years ago

Its enterprise consumer who struggle with changing standards... CentOS 7 is still supported till 2024 so we still have support the older (pre c++11) ABI... but upgrading tool chains leads to surprises long after engineering does the work and customers on costume running linux from scratch start using it.

That being said change waits for no one, I don't mind an excuse to tell my boss we have to upgrade. 😉

eao197 commented 8 months ago

C++17 is the minimal C++ standard since v.0.7.0