Earlier quoted context omitted.
Not necessary to pull whole boost
You are missing gp's point. Any boost dependency is an instant no-go in a lot of projects.
ASIO doesn't require boost, there's a stand-alone version.
Dalin – A C++ non-blocking network library on Linux
11–20 of 52 posts
Re: Dalin – A C++ non-blocking network library on Linux
#12Earlier quoted context omitted.
Not necessary to pull whole boost
You are missing gp's point. Any boost dependency is an instant no-go in a lot of projects.
Asio is also available as a standalone library without any dependencies (C++11): https://think-async.com/
Re: Dalin – A C++ non-blocking network library on Linux
#13Re: Dalin – A C++ non-blocking network library on Linux
#14Re: Dalin – A C++ non-blocking network library on Linux
#15Why is it not using C++ 14? Not a criticism, honest question, I only write C++ occasionally.
Re: Dalin – A C++ non-blocking network library on Linux
#16From a short review I don't like this much.
- It's containing it's own abstraction over pthread instead of std::thread/std::mutex/... - It passes shared_ptr via reference (yeah, this saves an increment and decrement on the refcounting, but the code is not tuned that much) - it prints directly to sterr (via fprintf) making it hard to redirect errors somewhere else - It seems not to be prepared to be ported to other platforms - It could make use of std::chrono instead of int64 timestamps - no build system (no CMake or anything) - tests not integrated, look verbose, all tests individually recompile all files, makes it hard to work test-drive
In summary I see no compelling reason over boost asio or such and potential issues.
Re: Dalin – A C++ non-blocking network library on Linux
#17"Only runs on Linux" C/C++ doesn't really have good general networking libraries that fit all purposes. On that note, I say: yes, great topic! However. Portability is one of the key features of C++, and why people still choose it for new projects. If one can constrain project to Linux I'm sure the project constraints would allow a more productive language to be used altogether.
On the one hand, you're right -- in that I can see and respect why you say that. On the otherhand, what the heck is wrong with using the syscalls? Every time I write a new high performance networking application, sure, i lose a day or two building primitives out of send recvmsg listen accept and splice, but once i'm done, i'm done, and things work. I'm confused why people feel the need to make paper thin abstraction…
BLE on Windows 10 is exactly the same as BLE on every other platform.
Re: Dalin – A C++ non-blocking network library on Linux
#18From a short review I don't like this much. - It's containing it's own abstraction over pthread instead of std::thread/std::mutex/... - It passes shared_ptr via reference (yeah, this saves an increment and decrement on the refcounting, but the code is not tuned that much) - it prints directly to sterr (via fprintf) making it hard to redirect errors somewhere else - It seems not to be prepared to be ported to other pl…
> It passes shared_ptr via reference
Talk about not getting it.
Re: Dalin – A C++ non-blocking network library on Linux
#19Why is it not using C++ 14? Not a criticism, honest question, I only write C++ occasionally.
It's not even fully C++11. Massive fail.
Re: Dalin – A C++ non-blocking network library on Linux
#20"Only runs on Linux" C/C++ doesn't really have good general networking libraries that fit all purposes. On that note, I say: yes, great topic! However. Portability is one of the key features of C++, and why people still choose it for new projects. If one can constrain project to Linux I'm sure the project constraints would allow a more productive language to be used altogether.
On the one hand, you're right -- in that I can see and respect why you say that. On the otherhand, what the heck is wrong with using the syscalls? Every time I write a new high performance networking application, sure, i lose a day or two building primitives out of send recvmsg listen accept and splice, but once i'm done, i'm done, and things work. I'm confused why people feel the need to make paper thin abstraction…
> On the one hand, you're right -- in that I can see and respect why you say that.
> On the otherhand, what the heck is wrong with using the syscalls? Every time I write a new high performance networking application, sure, i lose a day or two building primitives out of send recvmsg listen accept and splice, but once i'm done, i'm done, and things work.
...
> Tangentially, I positively can't WAIT for Networking support in c++20 -- that and Concepts I've been waiting for with baited breath.
You know that the networking support in c++20 is just Boost.Asio with namespace std, right ? You could have been using the exact same API today (or ten years ago for what it's worth), which is header-only, and supports TCP, UDP, Unix sockets, SSL, serial port communication, and all of this either synchronously or asynchronously, etc...
> I'm confused why people feel the need to make paper thin abstraction layers covering the berkeley sockets API.
Because:
* there are more efficient ways than the sockets API. For instance on windows the preferred way is IOCP: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... which allows for far better behaviour when multi-threading than select / poll.
* that's like saying "std:string is a thin abstraction layer over const char* and strlen". There is much more to this in big networking libraries: event loop handling, thread pools, etc.