4 ms·

C++ still mixes with lots of C code especially in the system programming field, i.e. C++ has to use many Posix C calls, C++ does not have its own socket() API r

C++ still mixes with lots of C code especially in the system programming field, i.e. C++ has to use many Posix C calls, C++ does not have its own socket() API replacement for network programming, even C++ thread uses pthread underneath, etc. Unlike other languages, C++ needs quite some C code to get the whole thing working sometimes. I do agree that when you learn C++, you should not focus on its C roots.

fluoridation 5y ago
That's rather an inane observation. A program written in any language running on a system with a C API will eventually need to call to C through some kind of foreign function interface in order to interact with the system. C++ just has the peculiarity that its FFI is directly interoperable with C, so much so that it's legal C.
- nu11ptr 5y ago
  This is an interesting observation, but this also means people will often be expected to call those APIs directly as not everything will warrant a C++ wrapper. In other languages, with their (typically) noisy FFIs, almost no app. programmers use them directly (or at least very sparingly), but instead use a library wrapper written by someone else in their language. I think the point of the OP is that it creates a very unique "blended" experience in C++ vs. other languages and I would agree.
  - fluoridation 5y ago
    The advantage of a wrapper, even when the underlying API call is simple, is that your program can be system-agnostic. You don't need to care at the call site whether the call eventually resolves to pthread_create() or CreateThread(). The implementation has already taken care of it.
    - kllrnohj 5y ago
      That's not nearly the advantage you think it is. For many of these APIs, it's going to be just as easy to have a portable implementation of the pthread's or socket API itself. Simply wrapping an API, but otherwise exposing it as-is (which basically everyone does for threads & sockets) does not gain you any portability whatsoever.
- 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.
kllrnohj 5y ago
> C++ does not have its own socket() API replacement for network programming In experimental but there is the Networking TS: https://en.cppreference.com/w/cpp/experimental/networking https://en.cppreference.com/w/cpp/experimental/networking > even C++ thread uses pthread underneath https://en.cppreference.com/w/cpp/thread https://en.cppreference.com/w/cpp/thread was added in C++11. How it is implemented doesn't really matter, does it? It doesn't leak any pthread-ness.
jstimpfle 5y ago
I never understood how you couldn't focus on its "C roots", which are coincidentally also its core semantics (give or take). Why shouldn't one focus on that? I could agree that C++ has many constructs that allow one to get away without slightly advanced programming that would be needed when coding in C, but recommending that one shouldn't need to understand function is a bit much.
psyclobe 5y ago
Pays mighty well too!

fluoridation 5y ago

That's rather an inane observation. A program written in any language running on a system with a C API will eventually need to call to C through some kind of foreign function interface in order to interact with the system. C++ just has the peculiarity that its FFI is directly interoperable with C, so much so that it's legal C.

nu11ptr 5y ago
This is an interesting observation, but this also means people will often be expected to call those APIs directly as not everything will warrant a C++ wrapper. In other languages, with their (typically) noisy FFIs, almost no app. programmers use them directly (or at least very sparingly), but instead use a library wrapper written by someone else in their language. I think the point of the OP is that it creates a very unique "blended" experience in C++ vs. other languages and I would agree.
- fluoridation 5y ago
  The advantage of a wrapper, even when the underlying API call is simple, is that your program can be system-agnostic. You don't need to care at the call site whether the call eventually resolves to pthread_create() or CreateThread(). The implementation has already taken care of it.
  - kllrnohj 5y ago
    That's not nearly the advantage you think it is. For many of these APIs, it's going to be just as easy to have a portable implementation of the pthread's or socket API itself. Simply wrapping an API, but otherwise exposing it as-is (which basically everyone does for threads & sockets) does not gain you any portability whatsoever.
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.

kllrnohj 5y ago

> C++ does not have its own socket() API replacement for network programming In experimental but there is the Networking TS: https://en.cppreference.com/w/cpp/experimental/networking https://en.cppreference.com/w/cpp/experimental/networking > even C++ thread uses pthread underneath https://en.cppreference.com/w/cpp/thread https://en.cppreference.com/w/cpp/thread was added in C++11. How it is implemented doesn't really matter, does it? It doesn't leak any pthread-ness.

jstimpfle 5y ago

I never understood how you couldn't focus on its "C roots", which are coincidentally also its core semantics (give or take). Why shouldn't one focus on that? I could agree that C++ has many constructs that allow one to get away without slightly advanced programming that would be needed when coding in C, but recommending that one shouldn't need to understand function is a bit much.

psyclobe 5y ago

Pays mighty well too!