4 ms·

But this is the same story with pretty much every language, right? I remember dealing with some of the C++ interop layers in Common Lisp back about 10 years ago

But this is the same story with pretty much every language, right? I remember dealing with some of the C++ interop layers in Common Lisp back about 10 years ago. All around an awful experience, and not really because of either CL or the interop layers themselves. It's just a boatload of complexity and the bigger the C++ library you want to target, the more likely it becomes that you have to deal with essentially all of the language. Compare that to C, where the story is often as good as "import the header and you're done". I'm not sure if there's a good path to a long-term solution, but I've been pushing to get nice C APIs in all the libraries I'm invested in, specifically because of this issue.

pjmlp 6y ago
On Windows that solution is COM, which many consider dead, while it actually won the .NET vs COM wars during Longhorn, and was eventually improved with .NET type system (WinRT). So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API. Microsoft is in the process of adding Rust to their COM/WinRT infrastructure. One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.
- jstimpfle 6y ago
  Calling simple and idiomatic procedural C interfaces [0] "clunky" and then contrasting them with the abomination that is COM is worthy of disagreement. Maybe the latter has its uses (I've never suffered enough through it to actually use it) but it definitely wins the clunkyness award. And that starts with its ridiculously unsearchable name. [0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.
  - pjmlp 6y ago
    With first class support (C++/WinRT, VCL, .NET) writing COM components is no different from ordinary C++ classes. Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.
    - jstimpfle 6y ago
      No different from ordinary C++ classes? (which are themselves more complex than what you need to suffer through with C)? Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa https://www.codeproject.com/Articles/9190/Understanding-The-... This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.
      - pjmlp 6y ago
        Naturally it is 90's enterprise technology, specially when you dig a 2005 article instead of a 2020 one. There is no good excuse to use outdated articles to attack technology one hates. Here, some 2020 stuff to educate yourself. https://docs.microsoft.com/en-us/windows/uwp/get-started/create-a-basic-windows-10-app-in-cppwinrt https://docs.microsoft.com/en-us/windows/uwp/get-started/cre... When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.
        deleted 6y ago
        [deleted]
        deleted 6y ago
        [deleted]
        jstimpfle 6y ago
        Here is an example of good code (written in C) exposed as a library with a clean procedural interface. Nothing archaic about that. https://github.com/rytc/enet_single/blob/master/enet_single.h https://github.com/rytc/enet_single/blob/master/enet_single....
- flohofwoe 6y ago
  COM is a solution to tunnel C++ interfaces through C APIs though, and it ceates a lof of complexity to support OOP APIs which should have been plain procedural APIs to begin with (compare the mess that is WinRT with the traditional Win32 windowing functions).
  - pjmlp 6y ago
    No one uses COM via C boilerplate unless they are masochists. WinRT is no mess, and I look forward to the day everyone has to put up with them, now that both application models are being merged anyway.
    - jstimpfle 6y ago
      Coincidentally, as an anecdotal data point, COM via C boilerplate (out of necessity) is all I've ever seen. And while it made me bloody angry each single time, I'm happy I didn't have to deal with the dogpile that was built on top of it.

pjmlp 6y ago

On Windows that solution is COM, which many consider dead, while it actually won the .NET vs COM wars during Longhorn, and was eventually improved with .NET type system (WinRT). So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API. Microsoft is in the process of adding Rust to their COM/WinRT infrastructure. One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.

jstimpfle 6y ago
Calling simple and idiomatic procedural C interfaces [0] "clunky" and then contrasting them with the abomination that is COM is worthy of disagreement. Maybe the latter has its uses (I've never suffered enough through it to actually use it) but it definitely wins the clunkyness award. And that starts with its ridiculously unsearchable name. [0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.
- pjmlp 6y ago
  With first class support (C++/WinRT, VCL, .NET) writing COM components is no different from ordinary C++ classes. Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.
  - jstimpfle 6y ago
    No different from ordinary C++ classes? (which are themselves more complex than what you need to suffer through with C)? Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-COM-Single-Threaded-Apartment-Pa https://www.codeproject.com/Articles/9190/Understanding-The-... This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.
    - pjmlp 6y ago
      Naturally it is 90's enterprise technology, specially when you dig a 2005 article instead of a 2020 one. There is no good excuse to use outdated articles to attack technology one hates. Here, some 2020 stuff to educate yourself. https://docs.microsoft.com/en-us/windows/uwp/get-started/create-a-basic-windows-10-app-in-cppwinrt https://docs.microsoft.com/en-us/windows/uwp/get-started/cre... When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.
      - deleted 6y ago
        [deleted]
      - deleted 6y ago
        [deleted]
      - jstimpfle 6y ago
        Here is an example of good code (written in C) exposed as a library with a clean procedural interface. Nothing archaic about that. https://github.com/rytc/enet_single/blob/master/enet_single.h https://github.com/rytc/enet_single/blob/master/enet_single....
flohofwoe 6y ago
COM is a solution to tunnel C++ interfaces through C APIs though, and it ceates a lof of complexity to support OOP APIs which should have been plain procedural APIs to begin with (compare the mess that is WinRT with the traditional Win32 windowing functions).
- pjmlp 6y ago
  No one uses COM via C boilerplate unless they are masochists. WinRT is no mess, and I look forward to the day everyone has to put up with them, now that both application models are being merged anyway.
  - jstimpfle 6y ago
    Coincidentally, as an anecdotal data point, COM via C boilerplate (out of necessity) is all I've ever seen. And while it made me bloody angry each single time, I'm happy I didn't have to deal with the dogpile that was built on top of it.