10 ms·

Generics in C without void* or macros – enabled by psychec

90 points by unusualcool 7y ago

nitrix 7y ago
You should never typedef a pointer to an object. That’s common knowledge amongst experienced C developers and an immediate red flag, even for myself normally welcoming of anything built with Haskell.
- naasking 7y ago
  A red flag implying what, exactly?
- toxik 7y ago
  While I agree with this, I think it's a ridiculously common thing to see among major software vendors. A lot of Apple's APIs are typedef'd pointers to various structs.
- bitcharmer 7y ago
  I'm not an expert C developer but can see some semantic benefits of typedefing a pointer. Is this considered harmful because it hides the fact that you're dealing with a pointer in the first place?
  - raxxorrax 7y ago
    As evidenced by countless examples of somethingPTR-types, it is done regularly. But the main problem is indeed that you hide the pointer. If you apply qualifiers like const to your type, results might me unexpected. It might have semantic benefits, but C developers should be trained to ignore all these strange *-symbols anyway.
- glouwbug 7y ago
  If it's an opaque pointer I see no reason to typedef it as there is zero way to dereference any struct members. It's all semantic sugar anyway.
- seamyb88 7y ago
  Yeah, true. Although, the problem is lessened if properly abstracted away via opacity. MPFR (GNU multi-precision library) typedefs an array of size 1 holding its basic type, as opposed to just typedefing the struct of the basic type. This is (I think) purely so they don't have to put '&' in front of their "objects" when passing them around. While I've great respect for the authors of that fantastic library, I only have this to say about the practice: Jeeesh!
- 19ylram49 7y ago
  I don’t see why not, as long as you make it clear what it is. E.g., if a C API is handing me an opaque handle that I need to pass around to the rest of the API, I don’t need to know that it’s a pointer (I’m not the one dereferencing it) and I’d rather not have to worry about that if I’m using the API properly.
- elihu 7y ago
  I agree that it's something you shouldn't do, but that's just an opinion. Many C programmers are fine with it.
  - Gibbon1 7y ago
    Yeah it's not like something 'bad' is going to happen. I typedef function pointers when they get too verbose. Otherwise not. But it's not the mole hill I'd choose to die on either.
- insulanus 7y ago
  You should never hide a pointer to a type with a typedef.
TorKlingberg 7y ago
No void* or macros, but requires a special compiler frontend.
- jackewiehose 7y ago
  Yes, that was confusing. "Look, you don't need to use these C-features if you use another language than C."
  - klingonopera 7y ago
    C++ 14, Haskell and Python. One of the reasons I'm actually going for pure C in this modern day and age, is that I can just write a small program, without having any other dependency. I'm sure the same could be said for C++, too, but for some reason, with my setup (GCC 5.1.0 with MinGW on Windows 7), I'm averaging around 800KB on C++ vs 80KB on C, for the (mostly) same code. EDIT: It appears that exception-handling is one of the reasons the binary is bigger in C++ than C. I mainly write code for embedded devices, so whatever programs I write on x86 is to interface with those devices, hence I'm quite comfortable staying with C.
    - unusualcool 7y ago
      This needs to be made clearer in the readme: C++ and Haskell are requirements for building the type inference engine; Python is necessary for invoking the frontend (or the binaries can be downloaded).
    - Crinus 7y ago
      Are you sure it isn't debugging information that bloats the executable? Try a strip --strip-all your.exe and see if it is still that big.
      - klingonopera 7y ago
        > Try a strip and see if it is still that big. ...I guarantee that it is nothing short of humongous xD Joking aside, maybe, I don't know, it's been a while since I used some C++ code, but I'll have a look into it the next time around. ...though it's probably unlikely, I use Code::Blocks and exclusively use the "Release" candidate, and uncheck the "Debug" version, and I'm quite confident the CB authors know what they are doing.
zenogais 7y ago
Type generic expressions [1] already exist in C11. You can do this without a special compiler front-end if you need it, you would just need to define each variant by hand. These are supported in GCC and Clang with the -std=c11 flag. [1]: http://www.robertgamble.net/2012/01/c11-generic-selections.html http://www.robertgamble.net/2012/01/c11-generic-selections.h...
- AndrewBissell 7y ago
  I developed these ideas a bit further with the use of XX macros, which allow you to make a set of functions generic across some list of types. There can be real performance wins to this over void*: https://abissell.com/2014/01/16/c11s-_generic-keyword-macro-applications-and-performance-impacts/ https://abissell.com/2014/01/16/c11s-_generic-keyword-macro-...
  - flukus 7y ago
    That looks handy. I got bored one day and built a fluent interface: http://flukus.github.io/fluent-interfaces-for-c.html http://flukus.github.io/fluent-interfaces-for-c.html
- okl 7y ago
  _Generic has been created for a specific use (tgmath.h) and is not very powerful.
kristoff_it 7y ago
Interesting link, but if anybody is interested in making real practical use of generics in a C-style language, then it's best to take a look at Zig.
- potiuper 7y ago
  Zig is not able to output c code that could be consumed by an alternative [optimized|verified/proofed] C compiler like Intel along with other questionable decisions such as "Zig does not support RAII or operator overloading because both make it very difficult to tell where function calls happen just by looking at a function body. Zig tends to avoid syntactic sugar except where it would have a significant effect on the semantics of a program. Zig does not have a C-style for loop, because you can just use the more general-purpose while loop instead with only a little bit of extra code. [1] The compiler is free to inline non-extern functions, change their parameters, and otherwise !!do whatever it wants!!, since they are internal functions." [2] [1] https://ziglang.org/download/0.1.1/release-notes.html https://ziglang.org/download/0.1.1/release-notes.html [2] https://andrewkelley.me/post/intro-to-zig.html https://andrewkelley.me/post/intro-to-zig.html
  - AndyKelley 7y ago
    Just a note for drive by viewers, there's a link here to 0.1.1 release notes but a lot has changed since 0.1.1: * [0.2.0 release notes](https://ziglang.org/download/0.2.0/release-notes.html https://ziglang.org/download/0.2.0/release-notes.html) * [0.3.0 release notes](https://ziglang.org/download/0.3.0/release-notes.html https://ziglang.org/download/0.3.0/release-notes.html) * [0.4.0 release notes](https://ziglang.org/download/0.4.0/release-notes.html https://ziglang.org/download/0.4.0/release-notes.html) 0.5.0 is scheduled to be released Sept 30.
blazemaster 7y ago
I don't really understand what the point of all this is, and why anyone would consider using this in a real-world application they're developing. There's already a C-like language which lets you write type-safe generic programs: it's called C++! And if for some reason you really want or need to restrict yourself to using C language features (almost) exclusively, you can disable RTTI, exceptions, and use a technique to avoid linking to libstdc++ (or equivalent). It really seems to me that the point of all this is just to reinvent the wheel, but maybe I'm missing something, I only skimmed the paper.
- billfruit 7y ago
  I also think it is rather strange for many projects to continue with C, esp for large projects, where c++ offers much conveniences to the programmer. IIRC gcc only recently started allowing c++ in it's source, and I wonder if emacs allows it still in it's source.
  - rootw0rm 7y ago
    SQLite kicks ass. Don't hate.
  - aidenn0 7y ago
    Exceptions are a major point of contention. Most of the conveniences C++ offers to the programmer are not possible without exceptions, and non-local transfer of control is not just a huge departure from C, it's one that is hard to gradually transition to.
    - edflsafoiewq 7y ago
      > Most of the conveniences C++ offers to the programmer are not possible without exceptions Like what?
      - aidenn0 7y ago
        Pretty much anything involving constructors that fail.
deleted 7y ago
[deleted]
jasonhansel 7y ago
Can you add existentially-quantified generics? Then OOP with dynamic dispatch would just be syntactic sugar. IMHO this would be way better than C++ since it would completely unify generics with the OO approach.
kbbr 7y ago
I like C for the small set of basic rules and that it does not impose much cognitive overhead of learning too many new things for a given project I have to get to know. Typedefs were already too much and I prefer not to use them...
- Koshkin 7y ago
  Typedefs are nice if you do not want to write 'struct' all the time...
  - klingonopera 7y ago
    Yes! Typedefs are definitely worth the time spent learning them.
bitwize 7y ago
So to program C in this special way I need C++, Haskell, and Python. No thank you. If/when I still work in C, it's with the aim of keeping bloat and dependencies to a dull roar at most.

90 points by unusualcool 7y ago

You should never typedef a pointer to an object. That’s common knowledge amongst experienced C developers and an immediate red flag, even for myself normally welcoming of anything built with Haskell.

naasking 7y ago
A red flag implying what, exactly?
toxik 7y ago
While I agree with this, I think it's a ridiculously common thing to see among major software vendors. A lot of Apple's APIs are typedef'd pointers to various structs.
bitcharmer 7y ago
I'm not an expert C developer but can see some semantic benefits of typedefing a pointer. Is this considered harmful because it hides the fact that you're dealing with a pointer in the first place?
- raxxorrax 7y ago
  As evidenced by countless examples of somethingPTR-types, it is done regularly. But the main problem is indeed that you hide the pointer. If you apply qualifiers like const to your type, results might me unexpected. It might have semantic benefits, but C developers should be trained to ignore all these strange *-symbols anyway.
glouwbug 7y ago
If it's an opaque pointer I see no reason to typedef it as there is zero way to dereference any struct members. It's all semantic sugar anyway.
seamyb88 7y ago
Yeah, true. Although, the problem is lessened if properly abstracted away via opacity. MPFR (GNU multi-precision library) typedefs an array of size 1 holding its basic type, as opposed to just typedefing the struct of the basic type. This is (I think) purely so they don't have to put '&' in front of their "objects" when passing them around. While I've great respect for the authors of that fantastic library, I only have this to say about the practice: Jeeesh!
19ylram49 7y ago
I don’t see why not, as long as you make it clear what it is. E.g., if a C API is handing me an opaque handle that I need to pass around to the rest of the API, I don’t need to know that it’s a pointer (I’m not the one dereferencing it) and I’d rather not have to worry about that if I’m using the API properly.
elihu 7y ago
I agree that it's something you shouldn't do, but that's just an opinion. Many C programmers are fine with it.
- Gibbon1 7y ago
  Yeah it's not like something 'bad' is going to happen. I typedef function pointers when they get too verbose. Otherwise not. But it's not the mole hill I'd choose to die on either.
insulanus 7y ago
You should never hide a pointer to a type with a typedef.

TorKlingberg 7y ago

No void* or macros, but requires a special compiler frontend.

jackewiehose 7y ago
Yes, that was confusing. "Look, you don't need to use these C-features if you use another language than C."
- klingonopera 7y ago
  C++ 14, Haskell and Python. One of the reasons I'm actually going for pure C in this modern day and age, is that I can just write a small program, without having any other dependency. I'm sure the same could be said for C++, too, but for some reason, with my setup (GCC 5.1.0 with MinGW on Windows 7), I'm averaging around 800KB on C++ vs 80KB on C, for the (mostly) same code. EDIT: It appears that exception-handling is one of the reasons the binary is bigger in C++ than C. I mainly write code for embedded devices, so whatever programs I write on x86 is to interface with those devices, hence I'm quite comfortable staying with C.
  - unusualcool 7y ago
    This needs to be made clearer in the readme: C++ and Haskell are requirements for building the type inference engine; Python is necessary for invoking the frontend (or the binaries can be downloaded).
  - Crinus 7y ago
    Are you sure it isn't debugging information that bloats the executable? Try a strip --strip-all your.exe and see if it is still that big.
    - klingonopera 7y ago
      > Try a strip and see if it is still that big. ...I guarantee that it is nothing short of humongous xD Joking aside, maybe, I don't know, it's been a while since I used some C++ code, but I'll have a look into it the next time around. ...though it's probably unlikely, I use Code::Blocks and exclusively use the "Release" candidate, and uncheck the "Debug" version, and I'm quite confident the CB authors know what they are doing.

zenogais 7y ago

Type generic expressions [1] already exist in C11. You can do this without a special compiler front-end if you need it, you would just need to define each variant by hand. These are supported in GCC and Clang with the -std=c11 flag. [1]: http://www.robertgamble.net/2012/01/c11-generic-selections.html http://www.robertgamble.net/2012/01/c11-generic-selections.h...

AndrewBissell 7y ago
I developed these ideas a bit further with the use of XX macros, which allow you to make a set of functions generic across some list of types. There can be real performance wins to this over void*: https://abissell.com/2014/01/16/c11s-_generic-keyword-macro-applications-and-performance-impacts/ https://abissell.com/2014/01/16/c11s-_generic-keyword-macro-...
- flukus 7y ago
  That looks handy. I got bored one day and built a fluent interface: http://flukus.github.io/fluent-interfaces-for-c.html http://flukus.github.io/fluent-interfaces-for-c.html
okl 7y ago
_Generic has been created for a specific use (tgmath.h) and is not very powerful.

kristoff_it 7y ago

Interesting link, but if anybody is interested in making real practical use of generics in a C-style language, then it's best to take a look at Zig.

potiuper 7y ago
Zig is not able to output c code that could be consumed by an alternative [optimized|verified/proofed] C compiler like Intel along with other questionable decisions such as "Zig does not support RAII or operator overloading because both make it very difficult to tell where function calls happen just by looking at a function body. Zig tends to avoid syntactic sugar except where it would have a significant effect on the semantics of a program. Zig does not have a C-style for loop, because you can just use the more general-purpose while loop instead with only a little bit of extra code. [1] The compiler is free to inline non-extern functions, change their parameters, and otherwise !!do whatever it wants!!, since they are internal functions." [2] [1] https://ziglang.org/download/0.1.1/release-notes.html https://ziglang.org/download/0.1.1/release-notes.html [2] https://andrewkelley.me/post/intro-to-zig.html https://andrewkelley.me/post/intro-to-zig.html
- AndyKelley 7y ago
  Just a note for drive by viewers, there's a link here to 0.1.1 release notes but a lot has changed since 0.1.1: * [0.2.0 release notes](https://ziglang.org/download/0.2.0/release-notes.html https://ziglang.org/download/0.2.0/release-notes.html) * [0.3.0 release notes](https://ziglang.org/download/0.3.0/release-notes.html https://ziglang.org/download/0.3.0/release-notes.html) * [0.4.0 release notes](https://ziglang.org/download/0.4.0/release-notes.html https://ziglang.org/download/0.4.0/release-notes.html) 0.5.0 is scheduled to be released Sept 30.

blazemaster 7y ago

I don't really understand what the point of all this is, and why anyone would consider using this in a real-world application they're developing. There's already a C-like language which lets you write type-safe generic programs: it's called C++! And if for some reason you really want or need to restrict yourself to using C language features (almost) exclusively, you can disable RTTI, exceptions, and use a technique to avoid linking to libstdc++ (or equivalent). It really seems to me that the point of all this is just to reinvent the wheel, but maybe I'm missing something, I only skimmed the paper.

billfruit 7y ago
I also think it is rather strange for many projects to continue with C, esp for large projects, where c++ offers much conveniences to the programmer. IIRC gcc only recently started allowing c++ in it's source, and I wonder if emacs allows it still in it's source.
- rootw0rm 7y ago
  SQLite kicks ass. Don't hate.
- aidenn0 7y ago
  Exceptions are a major point of contention. Most of the conveniences C++ offers to the programmer are not possible without exceptions, and non-local transfer of control is not just a huge departure from C, it's one that is hard to gradually transition to.
  - edflsafoiewq 7y ago
    > Most of the conveniences C++ offers to the programmer are not possible without exceptions Like what?
    - aidenn0 7y ago
      Pretty much anything involving constructors that fail.

deleted 7y ago

[deleted]

jasonhansel 7y ago

Can you add existentially-quantified generics? Then OOP with dynamic dispatch would just be syntactic sugar. IMHO this would be way better than C++ since it would completely unify generics with the OO approach.

kbbr 7y ago

I like C for the small set of basic rules and that it does not impose much cognitive overhead of learning too many new things for a given project I have to get to know. Typedefs were already too much and I prefer not to use them...

Koshkin 7y ago
Typedefs are nice if you do not want to write 'struct' all the time...
- klingonopera 7y ago
  Yes! Typedefs are definitely worth the time spent learning them.

bitwize 7y ago

So to program C in this special way I need C++, Haskell, and Python. No thank you. If/when I still work in C, it's with the aim of keeping bloat and dependencies to a dull roar at most.