5 ms·

Obj-C is nice, but it's not like they couldn't use C++. So why not just C++? why this obsession with C even when it makes no sense?

by camus2 9y ago

pvdebbe 9y ago
C is a vastly simpler language with good and well-tried semantics. The simpler language spec may make sense to do OO with suboptimal tools vs C++.
- camus2 9y ago
  > C is a vastly simpler language with good and well-tried semantics.The simpler language spec may make sense to do OO with suboptimal tools vs C++. But GObject isn't a simple type system on top of C, A C compiler wont catch any GObject type error since everything is about casting "types" with macros, a C compiler has absolutely no understanding of GObject type system. I don't believe one second writing GObject code is simpler than writing C++ code, having looked at serveral GObject codebases.
  - marktangotango 9y ago
    No one claimed gobject c was simpler to write than c++. That would be a foolish claim.
pavlov 9y ago
Traditionally C++ hasn't had a stable ABI. Object code from different compilers and even compiler versions has been incompatible. That made it a no-go for system frameworks. It's the same in Apple land: macOS uses a lot of C++ internally, but it's all wrapped into plain C APIs using an object system called CoreFoundation (which is IMO better than GObject because it was designed for "toll-free bridging" with Objective-C, so there is a low-friction path to a higher level language). There have been operating systems that built their APIs in C++. BeOS and Symbian are the most notable ones. Both ran into serious trouble with the ABI being tied to a specific compiler, which in practice made it hard to port newer GCC or Clang.
- andrioni 9y ago
  How did Microsoft solve it with their C++ APIs? I've never ventured much into Windows programming, but I remember hearing that MFC uses C++, and newer stuff is mostly C++-based.
  - pjmlp 9y ago
    Usually everyone makes use of COM. With Longhorn's failure, most of the .NET APIs that were part of the design how Longhorn was supposed to be, became COM APIs in Vista. Since then all major APIs were always COM based, with WinRT design goal being to do with COM what was originally imagined for Longhorn. Just that the COM APIs in UWP have been improved. Interfaces must inherit from IInspectable instead of IUnknown and .NET Metada is used instead of COM type libraries. COM allows any language on Windows that can interface with it to have access to an OS OO ABI. Which means any .NET language, Delphi, C++ and if feeling masochist C. EDIT: I think Ruby and Python can also consume COM. I also forgot to mention VBScript and JavaScript.
  - thriftwy 9y ago
    They carry around their bridge library called MSVC redistributable, and that one is tied to compiler version. Fortunately for them they don't release compiler versions too often, but stuff you have on your Windows install perhaps carries around half dozen of MSVC redistributable library sets. All Windows APIs are still C (stdcall to be precise) with some COM.
    - pjmlp 9y ago
      > All Windows APIs are still C (stdcall to be precise) with some COM. Only if we are speaking about until Vista. With Vista the majority of Win32 API are only COM, not "with some COM", even the userspace drivers are COM. WinRT introduced in Windows 8, nowadays rebranded as UWP, is also COM. Of course one can be masochist and make use of the low level C compatible COM bindings, or embrace ATL, WTL, C++/CX or the new C++/WinRT and enjoy productivity.
      - 9y ago
pjmlp 9y ago
Because UNIX was always a C territory, it is like asking why the obsession with JavaScript on the browser. Back in the day, on the heat of the C vs C++ language wars on GNU/Linux, the C guys would pick GNOME and the C++ guys would be KDE. Then there were those of us that would gladly pick KDE, if it wasn't for the license Trolltech was originally using, so there was the effort to create Gtk-- and Gnome--, which wasn't that well seen, back then. Back then the GNU Coding Standards suggested using only C[0] which helped language's adoption, in a world where OS/2, Windows, BeOS and Symbian were heavily adopting C++. At least nowadays they acknowledge there are other programming languages that can be used. [0]- https://www.gnu.org/prep/standards/standards.html#Source-Language https://www.gnu.org/prep/standards/standards.html#Source-Lan...
deleted 9y ago
[deleted]
lukaslalinsky 9y ago
GObject has a much richer object model than what C++ provides out of the box. They could have used C++ and added the other semantics, but then you would end up with something similar to QObject in Qt and people would complain about that too.
- camus2 9y ago
  > GObject has a much richer object model than what C++ provides out of the box. They could have used C++ and added the other semantics, but then you would end up with something similar to QObject in Qt and people would complain about that too. But C compiler doesn't support GObject system. A C++ compiler obviously does support C++ types. GObject might be richer but writing GObject code is like coding in Javascript. The compiler isn't going to detect any of your type mistakes. this is not acceptable for someone who isn't familiar with GObject complexity. Qt is much much easier to work with, even for a bad C++ programmer.

Obj-C is nice, but it's not like they couldn't use C++. So why not just C++? why this obsession with C even when it makes no sense?

by camus2 9y ago

Obj-C is nice, but it's not like they couldn't use C++. So why not just C++? why this obsession with C even when it makes no sense?

pvdebbe 9y ago

C is a vastly simpler language with good and well-tried semantics. The simpler language spec may make sense to do OO with suboptimal tools vs C++.

camus2 9y ago
> C is a vastly simpler language with good and well-tried semantics.The simpler language spec may make sense to do OO with suboptimal tools vs C++. But GObject isn't a simple type system on top of C, A C compiler wont catch any GObject type error since everything is about casting "types" with macros, a C compiler has absolutely no understanding of GObject type system. I don't believe one second writing GObject code is simpler than writing C++ code, having looked at serveral GObject codebases.
- marktangotango 9y ago
  No one claimed gobject c was simpler to write than c++. That would be a foolish claim.

pavlov 9y ago

Traditionally C++ hasn't had a stable ABI. Object code from different compilers and even compiler versions has been incompatible. That made it a no-go for system frameworks. It's the same in Apple land: macOS uses a lot of C++ internally, but it's all wrapped into plain C APIs using an object system called CoreFoundation (which is IMO better than GObject because it was designed for "toll-free bridging" with Objective-C, so there is a low-friction path to a higher level language). There have been operating systems that built their APIs in C++. BeOS and Symbian are the most notable ones. Both ran into serious trouble with the ABI being tied to a specific compiler, which in practice made it hard to port newer GCC or Clang.

andrioni 9y ago
How did Microsoft solve it with their C++ APIs? I've never ventured much into Windows programming, but I remember hearing that MFC uses C++, and newer stuff is mostly C++-based.
- pjmlp 9y ago
  Usually everyone makes use of COM. With Longhorn's failure, most of the .NET APIs that were part of the design how Longhorn was supposed to be, became COM APIs in Vista. Since then all major APIs were always COM based, with WinRT design goal being to do with COM what was originally imagined for Longhorn. Just that the COM APIs in UWP have been improved. Interfaces must inherit from IInspectable instead of IUnknown and .NET Metada is used instead of COM type libraries. COM allows any language on Windows that can interface with it to have access to an OS OO ABI. Which means any .NET language, Delphi, C++ and if feeling masochist C. EDIT: I think Ruby and Python can also consume COM. I also forgot to mention VBScript and JavaScript.
- thriftwy 9y ago
  They carry around their bridge library called MSVC redistributable, and that one is tied to compiler version. Fortunately for them they don't release compiler versions too often, but stuff you have on your Windows install perhaps carries around half dozen of MSVC redistributable library sets. All Windows APIs are still C (stdcall to be precise) with some COM.
  - pjmlp 9y ago
    > All Windows APIs are still C (stdcall to be precise) with some COM. Only if we are speaking about until Vista. With Vista the majority of Win32 API are only COM, not "with some COM", even the userspace drivers are COM. WinRT introduced in Windows 8, nowadays rebranded as UWP, is also COM. Of course one can be masochist and make use of the low level C compatible COM bindings, or embrace ATL, WTL, C++/CX or the new C++/WinRT and enjoy productivity.
    - 9y ago

pjmlp 9y ago

Because UNIX was always a C territory, it is like asking why the obsession with JavaScript on the browser. Back in the day, on the heat of the C vs C++ language wars on GNU/Linux, the C guys would pick GNOME and the C++ guys would be KDE. Then there were those of us that would gladly pick KDE, if it wasn't for the license Trolltech was originally using, so there was the effort to create Gtk-- and Gnome--, which wasn't that well seen, back then. Back then the GNU Coding Standards suggested using only C[0] which helped language's adoption, in a world where OS/2, Windows, BeOS and Symbian were heavily adopting C++. At least nowadays they acknowledge there are other programming languages that can be used. [0]- https://www.gnu.org/prep/standards/standards.html#Source-Language https://www.gnu.org/prep/standards/standards.html#Source-Lan...

deleted 9y ago

[deleted]

lukaslalinsky 9y ago

GObject has a much richer object model than what C++ provides out of the box. They could have used C++ and added the other semantics, but then you would end up with something similar to QObject in Qt and people would complain about that too.

camus2 9y ago
> GObject has a much richer object model than what C++ provides out of the box. They could have used C++ and added the other semantics, but then you would end up with something similar to QObject in Qt and people would complain about that too. But C compiler doesn't support GObject system. A C++ compiler obviously does support C++ types. GObject might be richer but writing GObject code is like coding in Javascript. The compiler isn't going to detect any of your type mistakes. this is not acceptable for someone who isn't familiar with GObject complexity. Qt is much much easier to work with, even for a bad C++ programmer.