Dalin – A C++ non-blocking network library on Linux • Hacker News Board

Re: Dalin – A C++ non-blocking network library on Linux

#21

Post by jcelerier » Sat, Sep 02, 2017, 12:53 PM UTC

moron4hire wrote: post #17

loxias wrote: post #5

Earlier quoted context omitted.

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.

What ? of course not. The BLE (and bluetooth, for what it's worth) API is different on every platform.

On windows: https://msdn.microsoft.com/en-us/library/windows/hardware/hh...

On linux: https://github.com/carsonmcdonald/bluez-experiments/blob/mas...

On macOS: https://github.com/sandeepmistry/osx-ble-peripheral/blob/mas...

Re: Dalin – A C++ non-blocking network library on Linux

#22

Post by jcelerier » Sat, Sep 02, 2017, 12:54 PM UTC

whatidonteven wrote: post #14

arunc wrote: post #13

Earlier quoted context omitted.

Why is that? Most of the modern c++ features were directly borrowed from boost

Compile time is a pretty big reason.

so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.

Re: Dalin – A C++ non-blocking network library on Linux

#23

Post by moron4hire » Sat, Sep 02, 2017, 1:20 PM UTC

jcelerier wrote: post #21

moron4hire wrote: post #17

Earlier quoted context omitted.

BLE on Windows 10 is exactly the same as BLE on every other platform.

What ? of course not. The BLE (and bluetooth, for what it's worth) API is different on every platform. On windows: https://msdn.microsoft.com/en-us/library/windows/hardware/hh... On linux: https://github.com/carsonmcdonald/bluez-experiments/blob/mas... On macOS: https://github.com/sandeepmistry/osx-ble-peripheral/blob/mas...

The names of the functions are different, but they fundamentally do the same things

Re: Dalin – A C++ non-blocking network library on Linux

#24

Post by eps » Sat, Sep 02, 2017, 1:47 PM UTC

arunc wrote: post #13

eps wrote: post #9

Earlier quoted context omitted.

You are missing gp's point. Any boost dependency is an instant no-go in a lot of projects.

Why is that? Most of the modern c++ features were directly borrowed from boost

Given the universality of C++, everyone effectively ends up writing in their own dialect and there is a sizeable faction that uses it as "C with Classes" and "C with templates". So there is a lot of C++ projects that explicitly steer clear of modern C++ features, especially derived from the mother of all unholy abominations and the manifestation of everything that is wrong with the modern C++, the boost library.

Give or take.

Re: Dalin – A C++ non-blocking network library on Linux

#25

Post by juiyout » Sat, Sep 02, 2017, 1:58 PM UTC

moron4hire wrote: post #23

jcelerier wrote: post #21

Earlier quoted context omitted.

What ? of course not. The BLE (and bluetooth, for what it's worth) API is different on every platform. On windows: https://msdn.microsoft.com/en-us/library/windows/hardware/hh... On linux: https://github.com/carsonmcdonald/bluez-experiments/blob/mas... On macOS: https://github.com/sandeepmistry/osx-ble-peripheral/blob/mas...

The names of the functions are different, but they fundamentally do the same things

Isn't every platform "fundamentally" do the same things?

Re: Dalin – A C++ non-blocking network library on Linux

#26

Post by pjmlp » Sat, Sep 02, 2017, 1:59 PM UTC

eps wrote: post #24

arunc wrote: post #13

Earlier quoted context omitted.

Why is that? Most of the modern c++ features were directly borrowed from boost

Given the universality of C++, everyone effectively ends up writing in their own dialect and there is a sizeable faction that uses it as "C with Classes" and "C with templates". So there is a lot of C++ projects that explicitly steer clear of modern C++ features, especially derived from the mother of all unholy abominations and the manifestation of everything that is wrong with the modern C++, the boost library. Give…

Usually those are the projects where CVEs are a common feature..

Re: Dalin – A C++ non-blocking network library on Linux

#27

Post by whatidonteven » Sat, Sep 02, 2017, 2:02 PM UTC

jcelerier wrote: post #22

whatidonteven wrote: post #14

Earlier quoted context omitted.

Compile time is a pretty big reason.

so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.

I used boost extensively in the past (2006-2011). But I have been disillusioned by all the accidental complexity. It's easy to use the complicated parts of boost, but you lose sight of the inefficiencies you introduce all over the place, be it code bloat, unnecessary indirections, splitting up of allocations, or merely bloating your build times.

Besides, std::unordered_map is flawed, the bucket interface forces suboptimal cache behavior. std::thread is such a thin abstraction, if you use C++ you might as well use it but it doesn't buy you much. same with std::mutex. std::regex on the other hand I avoid because it's easy to write "regular" expressions that cause backtracking with it. I would look at something like re2 instead, if I had to deal with text parsing a lot. or a proper LALR parser generator if the language is not regular.

Re: Dalin – A C++ non-blocking network library on Linux

#28

Post by whatidonteven » Sat, Sep 02, 2017, 2:12 PM UTC

pjmlp wrote: post #26

eps wrote: post #24

Earlier quoted context omitted.

Given the universality of C++, everyone effectively ends up writing in their own dialect and there is a sizeable faction that uses it as "C with Classes" and "C with templates". So there is a lot of C++ projects that explicitly steer clear of modern C++ features, especially derived from the mother of all unholy abominations and the manifestation of everything that is wrong with the modern C++, the boost library. Give…

Usually those are the projects where CVEs are a common feature..

They are also the projects that get the most attention. I wouldn't rule out that python/javascript/whatever projects have just as many, if not even more, security flaws than your typical widely-used C library. They are just not interesting enough to warrant the required attention. The flaws are likely to be more subtle than simple buffer overflows too, think of all the abstractions involved.

Re: Dalin – A C++ non-blocking network library on Linux

#29

Post by thiggy » Sat, Sep 02, 2017, 2:16 PM UTC

Its interesting that I can't find a comment in this thread that speaks to API design or how easy it is to use.

Re: Dalin – A C++ non-blocking network library on Linux

#30

Post by pjmlp » Sat, Sep 02, 2017, 2:43 PM UTC

whatidonteven wrote: post #28

pjmlp wrote: post #26

Earlier quoted context omitted.

Usually those are the projects where CVEs are a common feature..

They are also the projects that get the most attention. I wouldn't rule out that python/javascript/whatever projects have just as many, if not even more, security flaws than your typical widely-used C library. They are just not interesting enough to warrant the required attention. The flaws are likely to be more subtle than simple buffer overflows too, think of all the abstractions involved.

My point was "C with Classes" and "C with templates" versus modern C++ best practices.

C++ code can be quite safe, providing people stop writing C with C++ compilers.