Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion - Restbed 5 should move to C++17? #386

Open
ben-crowhurst opened this issue Jul 8, 2019 · 8 comments
Open

Discussion - Restbed 5 should move to C++17? #386

ben-crowhurst opened this issue Jul 8, 2019 · 8 comments
Assignees
Milestone

Comments

@ben-crowhurst
Copy link
Member

We plan on releasing Restbed 5 with a minimum standard set to C++17. Please discuss any objections to this move.

@ben-crowhurst ben-crowhurst added this to the 5.0 milestone Jul 8, 2019
@ben-crowhurst ben-crowhurst pinned this issue Jul 8, 2019
@ben-crowhurst ben-crowhurst changed the title Discussion - Restbed 5 should move to C++2017? Discussion - Restbed 5 should move to C++17? Jul 8, 2019
@ben-crowhurst
Copy link
Member Author

Does the community have the stomach for moving directly to C++20?

@GordonEldest
Copy link

GordonEldest commented Oct 31, 2019

IMHO

Well I am not in favor unless there is a real performance benefit.

I already have issue keeping up with all change in the writing habit of developper using latest fancy coding that new model allow.
I also saw some reported issues that may be related to lack of knowledge of usage of lambda (extensively used in exemples).
This may reduce the audience and create some frustration.

Sidely even compiler manufacturer have some issue keeping up,
and I saw some difference on MSoft Debug/Release that may create fake bug with C++17

So some stability is good before moving to C+20

Another point, maybe personnal,
I suffer of the Asio clutter and digging in it with the debugger is difficult, however sometime mandatory, to enlight some throw. (For exemple the "handshake: wrong revision" that's a cryptic one that maybe related to version of OpenSSL or a miss during my CMake (Ongoing investigation))
ASIO maybe a higher priority rather than a move to c++20
The boundary between pur RestBed issues and dependencies issues will became fuzzier.

@mipac
Copy link

mipac commented Apr 21, 2020

C++17 seems ok for ms/clang/gcc on x86/arm, for my use cases
C++20 seems to early to be bulletproof and really portable for the moment

A work around Restless would be great, to have a restbed srv/client solution
An access to asio context could be great too

@Jahrenski
Copy link

c++17 all the way. But MS is still considering c++20 as experimental.

@ben-crowhurst
Copy link
Member Author

We are keen on the ratification of the Networking TS before we really push out v5; 4.*v will contain bug fixes and security updates and is considered LTS.

@ben-crowhurst
Copy link
Member Author

ben-crowhurst commented Jun 8, 2021

Update regarding version five.

We've decided not to rely directly on the std::networking functionality and will look to push 5.0-Beta into the public sphere no later than July 2021.

The API will allow an ASIO, std::networking, etc... implementation to be provided via service methods e.g set_network_adaptor. However, the default build will work directly with OS standard socket functionality.

@axelsommerfeldt
Copy link
Contributor

axelsommerfeldt commented Nov 1, 2021

Unfortunately the company I'm working for is bound to (embedded) toolchains which do not offer C++17 support and it seems that this will not change in the near future. But as long as bugs will still be fixed for restbed 4 I guess we could live with a decision to base restbed 5 on either C++17 or C++20.

@ben-crowhurst
Copy link
Member Author

Thanks for the input. We intend 4.* to remain LTS and branch off 5+ adding new features and C++17/20 support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants