4 ms·

This is the first public release, open source under the Apache 2.0 license. From the linked document: > Cedro is a C language extension that works as a pre-pr

This is the first public release, open source under the Apache 2.0 license. From the linked document: > Cedro is a C language extension that works as a pre-processor with four features: > - The backstitch @ operator. > - Deferred resource release. > - Block macros. > - Binary inclusion. The source code archive and GitHub link can be found at: https://sentido-labs.com/en/library/ https://sentido-labs.com/en/library/ I have no intention of building this up to a new language: if you can switch to a new compiler, there are better alternatives. This is for cases where all you have is a C99 (or close to it) compiler or you need to produce plain C code for compilation on a different target machine which might only have C89.

eqvinox 5y ago
This feels very niche. Typing the \ at the end of multi-line macros is something many editors help with (and forgotten \s are visible in syntax hilighting.) Binary inclusion is frequently just a small build script. Deferred resource release is already available as a GCC/clang extension, so it's only for less capable compilers as you say yourself. That leaves the @ operator… which seems useful for specific cases (e.g. graphics rendering), but I can honestly say I don't really feel a need for that in the codebases I worked with. But. Let me offer some suggestions for extensions! :) An improved preprocessor would be massively useful if it had features like: - enumerating struct members in preprocessor macros (something like:) #define MACRO2(typename, fieldname, arg1, arg2) ... arg1 arg2 ... #define MACRO(typename, arg1, arg2) something { #each-member(MACRO2, typename, arg1, arg2) } struct bla { int a, b; } MACRO(struct bla, x, y) /* => something { MACRO2(struct bla, a, x, y) MACRO2(struct bla, b, x, y) } */ - same, for function parameters - and last but not least, macros consuming { } blocks, e.g. #define MACRO(...)#{name} something something #{name} something #{name} MACRO(1,2,3) { this block is consumed by the macro and placed in 2nd and 3rd #{name} (first one just signals the macro consumes a {} block } ...oh and, almost forgot, "extensible" macros: #define MACRO(...) abc #ifdef MACRO #extend MACRO(...) def MACRO(...) ghi #else #define MACRO(...) def stub ghi #endif (also, macros that can define other macros. Like _Pragma() => #pragma, _Define() => #define)
- yvdriess 5y ago
  +1 on the macro-time iteration. The hacks I found to do it are just too unwieldy to justify their use.
  - kevin_thibedeau 5y ago
    Pretty straightforward with m4.
    - eqvinox 5y ago
      Can't tell if this is a joke or not. Sure hope it is. If it isn't — the number of people who understand m4 well enough to be able to maintain something like this can probably be counted on a few hands.
  - eqvinox 5y ago
    Yeah, everything I posted there is based on something I had to do at one point or another, and none of it was pretty. (Some ugly enough to have decided against it even though it was done and working.)
- arthur2e5 5y ago
  The struct enumeration thing is certainly useful for homogenous vectors being written as structs, but one of the issues is that it requires the preprocessor to have significantly more knowledge of the underlying language. Would it be a better idea to have something generate X Macros from struct defs instead?
  - eqvinox 5y ago
    Yeah, the enumerations require the preprocessor to understand the language and process the struct definitions... which may not even exist yet if they contain macros :D. It's not an easy problem. Generating some kind of macro-usable list like you suggest is probably the way to go, essentially making the entire thing a 2-pass process. (That said, the C preprocessor doesn't have a concept of "lists", perhaps that's the thing to actually add here.)

eqvinox 5y ago

This feels very niche. Typing the \ at the end of multi-line macros is something many editors help with (and forgotten \s are visible in syntax hilighting.) Binary inclusion is frequently just a small build script. Deferred resource release is already available as a GCC/clang extension, so it's only for less capable compilers as you say yourself. That leaves the @ operator… which seems useful for specific cases (e.g. graphics rendering), but I can honestly say I don't really feel a need for that in the codebases I worked with. But. Let me offer some suggestions for extensions! :) An improved preprocessor would be massively useful if it had features like: - enumerating struct members in preprocessor macros (something like:) #define MACRO2(typename, fieldname, arg1, arg2) ... arg1 arg2 ... #define MACRO(typename, arg1, arg2) something { #each-member(MACRO2, typename, arg1, arg2) } struct bla { int a, b; } MACRO(struct bla, x, y) /* => something { MACRO2(struct bla, a, x, y) MACRO2(struct bla, b, x, y) } */ - same, for function parameters - and last but not least, macros consuming { } blocks, e.g. #define MACRO(...)#{name} something something #{name} something #{name} MACRO(1,2,3) { this block is consumed by the macro and placed in 2nd and 3rd #{name} (first one just signals the macro consumes a {} block } ...oh and, almost forgot, "extensible" macros: #define MACRO(...) abc #ifdef MACRO #extend MACRO(...) def MACRO(...) ghi #else #define MACRO(...) def stub ghi #endif (also, macros that can define other macros. Like _Pragma() => #pragma, _Define() => #define)

yvdriess 5y ago
+1 on the macro-time iteration. The hacks I found to do it are just too unwieldy to justify their use.
- kevin_thibedeau 5y ago
  Pretty straightforward with m4.
  - eqvinox 5y ago
    Can't tell if this is a joke or not. Sure hope it is. If it isn't — the number of people who understand m4 well enough to be able to maintain something like this can probably be counted on a few hands.
- eqvinox 5y ago
  Yeah, everything I posted there is based on something I had to do at one point or another, and none of it was pretty. (Some ugly enough to have decided against it even though it was done and working.)
arthur2e5 5y ago
The struct enumeration thing is certainly useful for homogenous vectors being written as structs, but one of the issues is that it requires the preprocessor to have significantly more knowledge of the underlying language. Would it be a better idea to have something generate X Macros from struct defs instead?
- eqvinox 5y ago
  Yeah, the enumerations require the preprocessor to understand the language and process the struct definitions... which may not even exist yet if they contain macros :D. It's not an easy problem. Generating some kind of macro-usable list like you suggest is probably the way to go, essentially making the entire thing a 2-pass process. (That said, the C preprocessor doesn't have a concept of "lists", perhaps that's the thing to actually add here.)