Just looking for some opinions on the next standard. What do you guys think of #embed and constexpr? Will you be using C23 or sticking to an older standard like C99 or C89?

  • cmeerw@programming.dev
    4·
    1 year ago

    I am not really seeing the case where it would make sense to move to C23 instead of either staying with C90/C99/C11 or moving to another language like C++, Zig, …

    #embed does add an important feature, but it seems to add quite a lot of complexity by adding it via the pre-processor and relying on optimisations to actually deliver on the benefits. It also has not yet been added to C++.

  • TheLinuxGuy@programming.dev
    3·
    1 year ago

    I would most likely be using C11 for threads.h and stdatomic.h for foreseeable future, the problem with using the latest and greatest standard is the risk of compiler not supporting it, so I would likely wait at least 5 years before switching to C23 sometime in 2028 or 2029. There was a bit of a controversy around optional bound checking in C11 that they end up removing/deprecating it, I am sure C23 would have something going on.

    I don’t plan on using #embed or constexpr in favor of maintaining common C programming practices, language familiarity is still an important factor to thriving project as much as people nag on me to rewrite everything in Rust or C++.

    • bsdGuy0@programming.devEnglish
      3·
      1 year ago

      I do prefer C, due to its simplicity alone. I think that rewriting programs in Rust, or C++, just because “they are better” would be an unwise descision.

      Don’t get me wrong, I do believe they are great languages, however, sometimes you must count your merits, and choose the best tool for the job.

      • TheLinuxGuy@programming.devEnglish
        2·
        1 year ago

        Yep, biggest reason why I chose C language is Foreign Function Interface. Code you write for C is more than likely to be usable in just about any other languages.

        • philm@programming.dev
          11·
          1 year ago

          Yeah but you can achieve this with Rust as well with extern "C" and #[no_mangle] (I couldn’t really go back to something like C anymore IMHO, all the high-level language niceties and a really good static type system, while maintaining the power of C…)

          • TheLinuxGuy@programming.devEnglish
            1·
            1 year ago

            I don’t think so on the extensibility aspect alone, some of the Rust syntax/trait does not map well to other languages when other languages attempts to extend Rust library. I write C code in a way that it would be extensible from any languages.

            • philm@programming.dev
              1·
              1 year ago

              Sure, but I think it’s rather shows the shortcomings of C IMO, I could write C like Rust (no_mangle everywhere), and achieve the same, but than I would miss out a lot of the nice features of Rust that are missing in C (among one is better automatic compiler optimizations (e.g. vectorization, better byte-packing of structs etc. not even starting with all the functional features). I don’t think it’s really an issue, you can get fancy within the Rust crate, and build a C compatible interface on top, that are just wrapper functions, and you likely think more about the API/interface to other languages which is probably not a bad thing, while having an idiomatic API for other Rust crates.

              But I agree, that it works better to just stay in the ecosystem of Rust (you can provide a nicer API/interface for your crate with generics/traits etc.).

              Anyway I don’t completely get what you mean with “extensible from any languages”?

              • TheLinuxGuy@programming.devEnglish
                01·
                1 year ago

                It just rooted back to my frustration when I was trying to fill in missing implementation details on projects like Skia (at the time it lacked support for Vulkan.) My very fundamental core belief is that for core libraries like say, Skia, Neural Net Framework, and other crucial projects like that should offer a way in C API that allows every type and implementation to be extended upon by any other language that can interface with C API by providing your own VTable or whatnot.

                One of the approach I do for my GUI Toolkit written in C (specifically on Linux to replace QT and GTK) was making a single inheritance object oriented programming in C.and if you insert the base class type structure at the top of your custom struct type and provide your own VTable for those objects, you can readily extend the underlying library natively in whatever programming language you use assuming it can talks to C API in a complete sense.

                Let me know if you want a demonstration of this, I would be happy to find the time to set up a small sample to give you the idea on how it’s done.

                And I am also aware of the criticisms on those approach, verbosity of attempting to implement object oriented programming in C is kind of absurd and the API coverage would balloon. That is largely why I work on a Compiler-Generator Framework specifically to address the challenges by allowing me to add dialects on top of C Language such as generic, object oriented programming, and various dialects. I brought C closer to C# in term of syntax and features and at the end of compilation, it still produces readable C language code output and it also generates what I called an FFI-JSON. It’s essentially a JSON file that describes all of the types used in a C project, the sizes of integers/floating points, structure types and it’s fields/offsets/sizes comments, and function declarations. It’s done in a way that you could read the JSON file and generate your programming language binding library saving you weeks of work.

                • philm@programming.dev
                  1·
                  1 year ago

                  implement object oriented programming in C is kind of absurd

                  Well IMHO OOP or specifically inheritance in general is absurd (hard take I know, I have had my traumatic experiences with inheritance hierarchies and refactoring/maintaining them - hell…).

                  I have done that (vtable OOP emulation in C) in my early years as CS student (like hmm I think 10 years ago?). It was fun experimenting with it, but ultimately I think C should be done imperative/procedural and modular composition of functions, and as such expose an API that is based on that.

                  I do for my GUI Toolkit written in C

                  Funny, I’m currently contributing to something similar in Rust :). Recently it also came up how to achieve cross-language bindings, Raph did prototyping for python a year ago in https://github.com/linebender/druid/tree/idiopath_py

                  I don’t think I would go an inheritance based route for a GUI toolkit/framework. Inheritance was IMHO generally a mistake in programming paradigms (at least this strong integration/promotion in most modern languages), too strong interconnected dependencies where they don’t make sense and constantly shoot you in the feet.

                  I think in times where React, Flutter, Jetpack Compose and SwiftUI etc. dominate (IMHO for a good reason), I would go into the direction of composable and declarative reactive UI. Make widgets strongly configurable on a fine-grained basis, and offer high-level bindings, but don’t offer more. In case that is an issue, I’d extend the core or maybe offer a way to natively extend the toolkit (e.g. because of performance, better integration/architecture/maintainability etc.)).