Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
STC
A modern, user friendly, generic, type-safe and fast C99 container library: String, Vector, Sorted and Unordered Map and Set, Deque, Forward List, Smart Pointers, Bitset and Random numbers. (by stclib)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
As I mentioned in my thread a few weeks ago (and in my readme), CC definitely compiles slowly, at least relative to other approaches to generics. But I'm not sure what part of that compile-speed penalty stems from its frequent use of extendible _Generic expressions versus function inlining and other preprocessor stuff. At one point, I tried to increase compile speed by replacing some of the _Generics with a different mechanism only to find that compile time got worse, not better.
The preprocessor is actually quite fast, as long as you are just doing primitive replacement things. I benchmarked my preprocessor brainfuck interpreter (without optimizations) against a constexpr brainfuck interpreter (without optimizations), and it beat constexpr for interpreting smaller programs. isort4 for example is a brainfuck program that does insertion sort on 45 inputs, and the preprocessor implementation was more than twice as fast as the constexpr one. Larger programs are slower to interpret with the preprocessor, because it always needs to copy the entire program code.
The prototype of CC used this mechanism to provide a generic API for types instantiated via templates (so basically like other container libraries, but with an extendible-_Generic-based API laid over the top of the generated types). This approach has some significant advantages over the approach CC now uses, but I got a bit obsessed with eliminating the need to manually instantiate templates.
The prototype of CC used this mechanism to provide a generic API for types instantiated via templates (so basically like other container libraries, but with an extendible-_Generic-based API laid over the top of the generated types). This approach has some significant advantages over the approach CC now uses, but I got a bit obsessed with eliminating the need to manually instantiate templates.
The prototype of CC used this mechanism to provide a generic API for types instantiated via templates (so basically like other container libraries, but with an extendible-_Generic-based API laid over the top of the generated types). This approach has some significant advantages over the approach CC now uses, but I got a bit obsessed with eliminating the need to manually instantiate templates.
I think the case for such extensions is strongest when they can be implemented from within standard C (in which case "extensions" is a misnomer?). But if they rely on compiler extensions or [custom](https://www.reddit.com/r/C_Programming/comments/d1gt4x/generics_in_c_without_void_or_macros_enabled_by) [preprocessors](https://github.com/logological/gpp), then we could at least consider just switching to C++.
It took me a long time to understand, coming from higher level programming, that a lot of exactly that "higher level" is just systematic fat pointer conventions. And because pointers-with-metadata is not a first-class language construct, we invent all these languages that codify a particular fat pointer convention. Cello is an example of what kinds of abstractions can be built on top of a tiny little bit of (non-native) fat pointer convention.
Related posts
- Conditional preprocessor macro, anyone?
- I wrote an optimizing brainfuck interpreter using only the C Preprocessor, here is how
- Who needs C++? C preprocessor meta programming is the future.
- Show HN: Optimizing brainfuck interpreter using only the C preprocessor
- Let's write an optimizing Brainfuck interpreter using only the C Preprocessor