5 ms·

[On the Cforall team] For what it's worth, one of the features Cforall adds to C is RAII. The exception implementation isn't done yet, but it's waiting on (lim

[On the Cforall team] For what it's worth, one of the features Cforall adds to C is RAII. The exception implementation isn't done yet, but it's waiting on (limited) run-time type information, it already respects RAII.

seabrookmx 9y ago
I might have missed this.. but how is Cforall implemented? A new GCC or LLVM frontend, or is it a transpiles-to-C implementation ala. Nim or Vala?
- BruceIV 9y ago
  Transpiles-to-(GNU-)C -- it was first written before LLVM, if we were starting the project today it would likely be a Clang fork.
  - seabrookmx 9y ago
    Clang harks back to 2007 and LLVM 2003.. is this a research project that was recently taken back up? I was curious about the implementation because I've had rough experiences with Vala and Nim's approach. Unlike with "transpiles-to-js" languages, transpiling to C has some tooling gaps (debugging being the big one). I admittedly don't have a ton of experience with either language but I couldn't find a plugin that gave me a step-through debugger for something like CLion or VS Code. You can debug the C output directly but this will turn off newcomers and assumes the C output is clean.
    - BruceIV 9y ago
      The initial implementation was finished in '03, and we revived the project somewhere around '15, so your guess about a research project that was recently taken back up is correct. We intend to write a "proper compiler" at some point (probably either a Clang fork or a Cforall front-end on LLVM), but it hasn't been a priority for our limited engineering staff yet. I think we are getting a summer student to work on our debugging story (at least in GDB -- setting it up so it knows how to talk to our threading runtime and demangle our names), and improving our debugging capabilities has been a major focus of our pre-beta-release push.
deleted 9y ago
[deleted]
RhysU 9y ago
I have often wanted c99 with destructors for RAII purposes.
- enriquto 9y ago
  you do not need destructors if you put your stuff on the stack
  - jcelerier 9y ago
    just putting stuff on the stack in C won't magically call `fclose` or `pthread_mutex_unlock`, unlike destructors
baybal2 9y ago
What I will like is more strict compile time checks. Most C pros have to rely on external tooling for that.
- BruceIV 9y ago
  It's maybe not quite what you're looking for, but Cforall's polymorphic functions can eliminate nearly-all the unsafety of void-pointer-based polymorphism at little-to-no extra runtime cost (in fact, microbenchmarks in our as-yet-unpublished paper show speedup over void-pointer-based C in most cases due to more efficient generic type layout). As an example: forall(dtype T | sized(T)) T* malloc() { // in our stdlib return (T*)malloc(sizeof(T)); // calls libc malloc } int* i = malloc(); // infers T from return type
  - baybal2 9y ago
    Excuse me for my lamerism, but can you tell me what is a polymorphic function? My idea was that if it is better to do as much compile time checks as possible before you introduce run-time checks. Does that void pointer protection run faster that code that was checked at compile time? How?
    - BruceIV 9y ago
      A polymorphic function is one that can operate on different types[1]. You would maybe be familiar with them as template functions in C++, though where C++ compiles different versions of the template functions based on the parameters, we pass extra implicit parameters. The example above translates to something like the following in pure C: void* malloc_T(size_t sizeof_T, size_t alignof_T) { return malloc(sizeof_T); } int* i = (int*)malloc_T(sizeof(int), alignof(int)); In this case, since the compiler verifies that int is actually a type with known size (fulfilling `sized(T)`), it can generate all the casts and size parameters above, knowing they're correct. [1] To anyone inclined to bash my definition of polymorphism, I'm mostly talking about parametric polymorphism here, though Cforall also supports ad-hoc polymorphism (name-overloading). The phrasing I used accounts for both, and I simplified it for pedagogical reasons.

seabrookmx 9y ago

I might have missed this.. but how is Cforall implemented? A new GCC or LLVM frontend, or is it a transpiles-to-C implementation ala. Nim or Vala?

BruceIV 9y ago
Transpiles-to-(GNU-)C -- it was first written before LLVM, if we were starting the project today it would likely be a Clang fork.
- seabrookmx 9y ago
  Clang harks back to 2007 and LLVM 2003.. is this a research project that was recently taken back up? I was curious about the implementation because I've had rough experiences with Vala and Nim's approach. Unlike with "transpiles-to-js" languages, transpiling to C has some tooling gaps (debugging being the big one). I admittedly don't have a ton of experience with either language but I couldn't find a plugin that gave me a step-through debugger for something like CLion or VS Code. You can debug the C output directly but this will turn off newcomers and assumes the C output is clean.
  - BruceIV 9y ago
    The initial implementation was finished in '03, and we revived the project somewhere around '15, so your guess about a research project that was recently taken back up is correct. We intend to write a "proper compiler" at some point (probably either a Clang fork or a Cforall front-end on LLVM), but it hasn't been a priority for our limited engineering staff yet. I think we are getting a summer student to work on our debugging story (at least in GDB -- setting it up so it knows how to talk to our threading runtime and demangle our names), and improving our debugging capabilities has been a major focus of our pre-beta-release push.

deleted 9y ago

[deleted]

RhysU 9y ago

I have often wanted c99 with destructors for RAII purposes.

enriquto 9y ago
you do not need destructors if you put your stuff on the stack
- jcelerier 9y ago
  just putting stuff on the stack in C won't magically call `fclose` or `pthread_mutex_unlock`, unlike destructors

baybal2 9y ago

What I will like is more strict compile time checks. Most C pros have to rely on external tooling for that.

BruceIV 9y ago
It's maybe not quite what you're looking for, but Cforall's polymorphic functions can eliminate nearly-all the unsafety of void-pointer-based polymorphism at little-to-no extra runtime cost (in fact, microbenchmarks in our as-yet-unpublished paper show speedup over void-pointer-based C in most cases due to more efficient generic type layout). As an example: forall(dtype T | sized(T)) T* malloc() { // in our stdlib return (T*)malloc(sizeof(T)); // calls libc malloc } int* i = malloc(); // infers T from return type
- baybal2 9y ago
  Excuse me for my lamerism, but can you tell me what is a polymorphic function? My idea was that if it is better to do as much compile time checks as possible before you introduce run-time checks. Does that void pointer protection run faster that code that was checked at compile time? How?
  - BruceIV 9y ago
    A polymorphic function is one that can operate on different types[1]. You would maybe be familiar with them as template functions in C++, though where C++ compiles different versions of the template functions based on the parameters, we pass extra implicit parameters. The example above translates to something like the following in pure C: void* malloc_T(size_t sizeof_T, size_t alignof_T) { return malloc(sizeof_T); } int* i = (int*)malloc_T(sizeof(int), alignof(int)); In this case, since the compiler verifies that int is actually a type with known size (fulfilling `sized(T)`), it can generate all the casts and size parameters above, knowing they're correct. [1] To anyone inclined to bash my definition of polymorphism, I'm mostly talking about parametric polymorphism here, though Cforall also supports ad-hoc polymorphism (name-overloading). The phrasing I used accounts for both, and I simplified it for pedagogical reasons.