3 ms·

A bit harsh to call it inane observation. Going by the original example, the challenge is the lack of good c++ libraries for common tasks in systems programming

by npalli 5y ago

A bit harsh to call it inane observation. Going by the original example, the challenge is the lack of good c++ libraries for common tasks in systems programming (like Sockets, or networking - still experimental after 40+ years!!) and the only option is to directly embed C code into your C++ code. Other languages will keep the distinction between your C code and the host code. Python for ex. might have C code behind the scenes, however you will interact with the C library in a pythonic way. Your mental mode of your python program (regarding lifetime/memory of objects) is consistent. In contrast, with C++ your program has Hodge podge of high-level constructs like std::vector, string, RAII etc.. and suddenly you are in the void*, malloc, free land with your C code. The mental model of lifetime/memory of objects in your program is inconsistent and burdensome. People would rather program everything in C, at least it will be consistent albeit very low level.

fluoridation 5y ago
Note that I was mainly responding to the comment about std::thread using pthread internally. Not only is that not necessarily true, as the platform may not even have pthread, in those cases where it is true it's also true of the implementations of all other languages. How does Java do threads on UNIX other than by sooner or later calling pthread? I totally agree that sockets is a long overdue oversight in the language.
kllrnohj 5y ago
> the lack of good c++ libraries for common tasks in systems programming (like Sockets, or networking - still experimental after 40+ years!!) I don't think it's that shocking, is it? In most languages the networking support is basically just the C socket API exposed as well. A good API is a good API, it shouldn't really matter how it's implemented. Also seems like a massively unfounded leap to go from "the standard library doesn't have it" to "complete lack of good C++ libraries for common tasks". C++ has never been a "batteries included" language. That doesn't mean good libraries don't exist for it. Boost is very common in the C++ world, for example. And that "experimental" networking library is basically just asio but adopted by the standard library, and asio is not experimental or unstable: https://think-async.com/Asio/ https://think-async.com/Asio/ > Python for ex. might have C code behind the scenes, however you will interact with the C library in a pythonic way Kinda odd to use Python as an example when it just exposes C sockets pretty much directly and entirely non-pythonicly https://docs.python.org/3/library/socket.html https://docs.python.org/3/library/socket.html > In contrast, with C++ your program has Hodge podge of high-level constructs like std::vector, string, RAII etc.. and suddenly you are in the void*, malloc, free land with your C code. The mental model of lifetime/memory of objects in your program is inconsistent and burdensome. People would rather program everything in C, at least it will be consistent albeit very low level. Eh? No, people would just make a tiny wrapper around the C APIs and call it a day. It's a pretty odd stance to take to say that to avoid writing ~100 lines of C-style C++, you should instead write 10k lines of C? Also other than void* (which is in C++, too), you shouldn't be encountering malloc or free when calling C functions. That's not how any good C API works, and it's certainly not how the continuously mentioned socket APIs work.
spacechild1 5y ago
> the challenge is the lack of good c++ libraries for common tasks in systems programming (like Sockets, or networking - still experimental after 40+ years!!) C++ has plenty of excellent libraries for such tasks (just think of boost), they are just not part of the standard library.
ravenstine 5y ago
Why would C++ need to reimplement libraries and other features when it already has access to the ones in C? If it was supposed to be an entirely separate language then they probably would have called it D (pretty sure C++ was a thing before the actual D language).

by npalli 5y ago

fluoridation 5y ago

Note that I was mainly responding to the comment about std::thread using pthread internally. Not only is that not necessarily true, as the platform may not even have pthread, in those cases where it is true it's also true of the implementations of all other languages. How does Java do threads on UNIX other than by sooner or later calling pthread? I totally agree that sockets is a long overdue oversight in the language.

kllrnohj 5y ago

> the lack of good c++ libraries for common tasks in systems programming (like Sockets, or networking - still experimental after 40+ years!!) I don't think it's that shocking, is it? In most languages the networking support is basically just the C socket API exposed as well. A good API is a good API, it shouldn't really matter how it's implemented. Also seems like a massively unfounded leap to go from "the standard library doesn't have it" to "complete lack of good C++ libraries for common tasks". C++ has never been a "batteries included" language. That doesn't mean good libraries don't exist for it. Boost is very common in the C++ world, for example. And that "experimental" networking library is basically just asio but adopted by the standard library, and asio is not experimental or unstable: https://think-async.com/Asio/ https://think-async.com/Asio/ > Python for ex. might have C code behind the scenes, however you will interact with the C library in a pythonic way Kinda odd to use Python as an example when it just exposes C sockets pretty much directly and entirely non-pythonicly https://docs.python.org/3/library/socket.html https://docs.python.org/3/library/socket.html > In contrast, with C++ your program has Hodge podge of high-level constructs like std::vector, string, RAII etc.. and suddenly you are in the void*, malloc, free land with your C code. The mental model of lifetime/memory of objects in your program is inconsistent and burdensome. People would rather program everything in C, at least it will be consistent albeit very low level. Eh? No, people would just make a tiny wrapper around the C APIs and call it a day. It's a pretty odd stance to take to say that to avoid writing ~100 lines of C-style C++, you should instead write 10k lines of C? Also other than void* (which is in C++, too), you shouldn't be encountering malloc or free when calling C functions. That's not how any good C API works, and it's certainly not how the continuously mentioned socket APIs work.

spacechild1 5y ago

> the challenge is the lack of good c++ libraries for common tasks in systems programming (like Sockets, or networking - still experimental after 40+ years!!) C++ has plenty of excellent libraries for such tasks (just think of boost), they are just not part of the standard library.

ravenstine 5y ago

Why would C++ need to reimplement libraries and other features when it already has access to the ones in C? If it was supposed to be an entirely separate language then they probably would have called it D (pretty sure C++ was a thing before the actual D language).