Announcement

Collapse
No announcement yet.

GTK 4.0 Toolkit Officially Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    caligula
    Senior Member

  • caligula
    replied
    Originally posted by zxy_thf View Post
    Nobody stop projects doing C++ -> C ABI -> C++ header only binding.
    This is how clover was implemented.

    Laziness is the main reason of not doing so, to be frank.
    You'd lose the whole concept of zero cost abstractions doing that. I mean that's what usually happens when you need bindings, but if performance was a secondary concern, using C++ would make little sense. There are other languages that require a lot less runtime support and are happy with much simpler compilers, yet provide reasonable type safety. C++ has some features that make resource handling a bit nicer, but even then, the most popular toolkits (Qt) require tons of other build tools as well. Compare that to e.g. ImGui.

    Leave a comment:

  • kpedersen
    Senior Member

  • kpedersen
    replied
    Don't think of C as just a language. Think of it as a solid underlying platform. The reason why Gtk+ has such great support for language bindings is because it is written in C.

    The following interop examples are much more complex if C wasn't involved.

    Java <-> C#
    Rust <-> Java
    Python <-> Perl

    They all go through C. Yes, very few are truly skilled enough to write decent code in C. But it needs to be done and we do our best. Either way, the fact that compiler vendors are *finally* starting to give a sh*t about safety (i.e with sanitizers) is improving code quality considerably. So much so that for many projects, C is very easy to justify again.
    kpedersen
    Senior Member
    Last edited by kpedersen; 16 December 2020, 08:53 PM.

    Leave a comment:

  • andreano
    Senior Member

  • andreano
    replied
    Originally posted by andre30correia View Post
    C++ is garbage
    If C had some of the useful zero-cost abstractions, like templates, constexpr and static_assert, I would be open to agree, if comparing to C++. My criticism of C (and C++) though, would be about UB: The compiler is allowed to silently delete your code instead of failing, which undermines its role as "portable assembly" – a faithful machine-near language. I hope to learn Zig next year, and see if it is a better C in some ways.

    Leave a comment:

  • zxy_thf
    Senior Member

  • zxy_thf
    replied
    Originally posted by oleid View Post

    A small fan ist better than no fan

    Anyway, huge pain points in GUI toolkits is multi threading. C++ won't help here. Sure, there are mutexes, however, the language won't help you to make sure everything is threadsafe.

    I recall multithreading being a huge PITA in Qt. Especially when using GL widgets.

    On the other hand, rust gui toolkits as iced or druid nicely work in multi threaded apps.
    Yeah I agree, Qt's signal-slot works way differently with MT, and requires an event loop.
    OpenGL + MT is a complete disaster. The function pointers are not even guaranteed identical among contexts/threads (don't remember details but on Windows things are really funny).
    For OpenGL case I don't think Rust would help here.

    For C vs C++, my point is not only about the toolkit, but also the whole gnome ecosystem, because the blog post is about the whole gnome (sorry if anyone is confused).

    The complete statement of my post at #9 is:
    For some reason I don't know, the majority of Gnome projects were written in C.
    We can certainly debate whether it's feasible to use C++ for library development, but for application development, using C is really inefficient, and even C++ is not so attractive given the success of electron-based VSCode.
    Thus, while the core part of Gnome ecosystem might be Okay, the applications part may not be able to lure enough new developers.
    zxy_thf
    Senior Member
    Last edited by zxy_thf; 16 December 2020, 08:12 PM.

    Leave a comment:

  • rastersoft
    Senior Member

  • rastersoft
    replied
    Originally posted by jKicker View Post
    And will you help in fixing that opensource software or the answer is invariably no?
    Why should him? Everybody knows that free/open source code grows in the trees.

    Leave a comment:

  • oleid
    Senior Member

  • oleid
    replied
    Originally posted by zxy_thf View Post
    I'm not a huge fan of Rust. Moving from C to C++ will be smoother IMO, and this process already has success stories (gcc).
    In addition, smarter pointers and RAII can address quite a few memory management issues.
    A small fan ist better than no fan

    Anyway, huge pain points in GUI toolkits is multi threading. C++ won't help here. Sure, there are mutexes, however, the language won't help you to make sure everything is threadsafe.

    I recall multithreading being a huge PITA in Qt. Especially when using GL widgets.

    On the other hand, rust gui toolkits as iced or druid nicely work in multi threaded apps.

    Leave a comment:

  • klapaucius
    Phoronix Member

  • klapaucius
    replied
    Originally posted by mdedetrich View Post

    If you consider name mangling as part of the ABI (which you reasonably should) then it does break very often.

    The matter of fact is, C++ is much more complex than C which makes it harder to provide a reasonably stable ABI (in practical terms).
    But mangling is implementation specific, it's not dictated by the standard. And yet, how many binary-only applications written in GTK are you aware of, that would be affected by an ABI change, if GTK was written in C++?

    Leave a comment:

  • zxy_thf
    Senior Member

  • zxy_thf
    replied
    Originally posted by klapaucius View Post

    Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.
    The ABI problem is not only about the breakages, but also the incompatibilities.
    One can compile a C library with GCC and link it with Clang, or vise versa, but this won't work for C++.

    Nevertheless, this isn't a real problem (again, think of how mesa implements OpenCL).

    Leave a comment:

  • mdedetrich
    Senior Member

  • mdedetrich
    replied
    Originally posted by klapaucius View Post

    Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.


    If you consider name mangling as part of the ABI (which you reasonably should) then it does break very often.

    The matter of fact is, C++ is much more complex than C which makes it harder to provide a reasonably stable ABI (in practical terms).

    Leave a comment:

  • klapaucius
    Phoronix Member

  • klapaucius
    replied
    Originally posted by mdedetrich View Post

    C++ is a terrible choice for a general purpose GUI library because the C++ ABI breaks all of the time.
    Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.



    Leave a comment:

Working...
X