4 ms·

What problem does this solve that isn’t superficial? I don’t see why it’s important to include.

sigsev_251 3y ago
Generic libraries. There are programming domains in the embedded world where code reuse can shorten the development timeline in a significant way, which gives engineers more time to test and verify.
- sfpotter 3y ago
  Example? Why not just use C++?
  - sigsev_251 3y ago
    Because there are platforms with no, or really buggy C++ support.
    - sfpotter 3y ago
      What is an example of an embedded systems project which truly benefits from a generic library in the way that you described?
      - sigsev_251 3y ago
        Aviation would be my personal experience. We have to implement services on the aircraft for structured communication support with the ground tower. Those would really benefit from something like that, since we wouldn't have to implement a backend for every project and we could simply reuse the whole library everywhere.
        sfpotter 3y ago
        I don’t see how generic programming (a la polymorphic types as presented) is the only or even the best solution to this problem.
    - phkahler 3y ago
      That sounds like a someone else's problem. Find a platform that supports the language you need rather than try to make C into that language. It is not C's job to be everything to everyone.
uecker 3y ago
1. Type safety for generic interfaces such as qsort. 2. Language interoperability. Then you need to have a dynamic framework for constructing types and function calls.
- sfpotter 3y ago
  If you’re in a situation where you “truly need” type safe generic interfaces, why wouldn’t you just use a different language? I don’t understand your second point.
  - uecker 3y ago
    There is no other languages with the same advantages as C and a good type system.
    - trealira 3y ago
      What advantages do you have in mind? Why not just use C++, Ada, or Rust?
  - uecker 3y ago
    The other point: For interoperability with other languages you often need to construct function calls at run-time. For this one needs to be able to describe types. Adding this by external libraries is always a pain because one has to carefully support the ABI of all supported architectures. A compiler can support this seamlessly. A _Typeof operator that returns a type that can be passed around and interrogated at run-time solves this in a very elegant and simple way.
- hgs3 3y ago
  Hi Martin, thank you for writing this proposal. This is just my two cents, but one-off void* functions, like qsort, are less of a pain point relative to generic containers. With generic containers it's common to have a collection of void* functions that must be consistently invoked with identical type T. Correct me if I'm wrong, but this proposal cannot genericize a struct field, i.e. it can genericize type 'T' but not 'T->someField'. The latter would be useful for something like 'vec_push(v,p)' where 'v->data[]' is the type T needed to determine if 'p' is a compatible type. Tangentially related, the macro-based containers you've written here [1] are the best answer for type-generic containers I've come across. One "gotcha" is the container name must be a valid C identifier otherwise it doesn't token paste correctly (see Example #2 of your REAMDE where you typedef'd string* as string_ptr to workaround this). Would you give consideration to a new preprocessor mechanism for concatenating a list of tokens into a single valid C identifier? i.e. Something like CONCAT(struct Foo *) would produce struct_Foo_Ptr? The result is guaranteed token paste-able. [1] https://github.com/uecker/noplate https://github.com/uecker/noplate

Generic libraries. There are programming domains in the embedded world where code reuse can shorten the development timeline in a significant way, which gives engineers more time to test and verify.

sfpotter 3y ago
Example? Why not just use C++?
- sigsev_251 3y ago
  Because there are platforms with no, or really buggy C++ support.
  - sfpotter 3y ago
    What is an example of an embedded systems project which truly benefits from a generic library in the way that you described?
    - sigsev_251 3y ago
      Aviation would be my personal experience. We have to implement services on the aircraft for structured communication support with the ground tower. Those would really benefit from something like that, since we wouldn't have to implement a backend for every project and we could simply reuse the whole library everywhere.
      - sfpotter 3y ago
        I don’t see how generic programming (a la polymorphic types as presented) is the only or even the best solution to this problem.
  - phkahler 3y ago
    That sounds like a someone else's problem. Find a platform that supports the language you need rather than try to make C into that language. It is not C's job to be everything to everyone.

uecker 3y ago

1. Type safety for generic interfaces such as qsort. 2. Language interoperability. Then you need to have a dynamic framework for constructing types and function calls.

sfpotter 3y ago
If you’re in a situation where you “truly need” type safe generic interfaces, why wouldn’t you just use a different language? I don’t understand your second point.
- uecker 3y ago
  There is no other languages with the same advantages as C and a good type system.
  - trealira 3y ago
    What advantages do you have in mind? Why not just use C++, Ada, or Rust?
- uecker 3y ago
  The other point: For interoperability with other languages you often need to construct function calls at run-time. For this one needs to be able to describe types. Adding this by external libraries is always a pain because one has to carefully support the ABI of all supported architectures. A compiler can support this seamlessly. A _Typeof operator that returns a type that can be passed around and interrogated at run-time solves this in a very elegant and simple way.
hgs3 3y ago
Hi Martin, thank you for writing this proposal. This is just my two cents, but one-off void* functions, like qsort, are less of a pain point relative to generic containers. With generic containers it's common to have a collection of void* functions that must be consistently invoked with identical type T. Correct me if I'm wrong, but this proposal cannot genericize a struct field, i.e. it can genericize type 'T' but not 'T->someField'. The latter would be useful for something like 'vec_push(v,p)' where 'v->data[]' is the type T needed to determine if 'p' is a compatible type. Tangentially related, the macro-based containers you've written here [1] are the best answer for type-generic containers I've come across. One "gotcha" is the container name must be a valid C identifier otherwise it doesn't token paste correctly (see Example #2 of your REAMDE where you typedef'd string* as string_ptr to workaround this). Would you give consideration to a new preprocessor mechanism for concatenating a list of tokens into a single valid C identifier? i.e. Something like CONCAT(struct Foo *) would produce struct_Foo_Ptr? The result is guaranteed token paste-able. [1] https://github.com/uecker/noplate https://github.com/uecker/noplate