Comment by fuhsnn

13 hours ago

The recent #def #enddef proposal[1] would eliminate the need for backslashes to define readable macros, making this pattern much more pleasant, finger crossed for its inclusion in C2Y!

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3531.txt

9 comments

fuhsnn

Reply
cb321  13 hours ago

While long-def's might be nice, you can even back in ANSI C 89 get rid of the backslash pattern (or need to cc -E and run through GNU indent/whatever) by "flipping the script" and defining whole files "parameterized" by their macro environment like https://github.com/c-blake/bst or https://github.com/glouw/ctl/

Add a namespacing macro and you have a whole generics system, unlike that in TFA.

So, it might add more value to have the C std add an `#include "file.c" name1=val1 name2=val2` preprocessor syntax where name1, name2 would be on a "stack" and be popped after processing the file. This would let you do types/functions/whatever "generic modules" with manual instantiation which kind of fits with C (manual management of memory, bounds checking, etc.) but preprocessor-assisted "macro scoping" for nested generics. Perhaps an idea to play with in your slimcc fork?

  • glouwbug  7 hours ago

    I've been thinking of maybe doing CTL2 with this. Maybe if #def makes it in.

    • cb321  6 hours ago

      I think the #include extension could make vec_vec / vec_list / lst_str type nesting more natural/maybe more general, but maybe just my opinion. :-)

      I guess ctags-type tools would need updating for the new possible definition location. Mostly someone needs to decide on a separation syntax for stuff like `name1(..)=expansion1 name2(..)=expansion2` for "in-line" cases. Compiler programs have had `cc -Dname(..)=expansion` or equivalents since the dawn of the language, but they actually get the OS/argv idea of separation from whatever CL args or Windows APIs or etc.

      Anyway, might makes sense to first get experience with a slimcc/tinycc/gcc/clang cpp++ extension. ;-) Personally, these days I mostly just use Nim as a better C.

hyperbolablabla  10 hours ago

I really don't think the backslashes are that annoying? Seems unnecessary to complicate the spec with stuff like this.

  • kreco  1 hour ago

    The backslashes itself make the preprocessor way more complicated for no real advantage (apart when it's unavoidable like in macros).

    For every single symbol you need to actually check if there is a splice (backslash + new line) in it. For single pass compiler, this contribute to a very slow lexing phase as this splice can appear anywhere in a C/C++ code.

    • jcelerier  40 minutes ago

      I don't think this is optimizing for the right thing, I've sat in front of hundreds of gcc & clang compiler time traces and lexing is a minuscule percentage of the time spent in the compiler

  • cb321  4 hours ago

    FWIW, https://www.cs.cornell.edu/andru/ Andrew Myers had some patch to gcc to do this back in the late 90s.

    Anyway, as is so often the case, it's about the whole ecosystem not just of tooling but the ecosystem of assumptions about & around tooling.

    As I mentioned in my other comment, if you want you can always cc -E and re-format the code somehow, although the main times you want to do that are for line-by-line stepping in debuggers or maybe for other cases of "lines as source coordinates" like line-by-line profilers.

    Of course, a more elegant solution might be just having more "adjustable step size/source coordinates" like "single ';'-statement or maybe single sequence control point in debuggers than just "line orientation". This is, in fact, so natural an idea that it seems a virtual certainty some C debugger has an "expressional step/next", especially if written by a fan more of Lisp than assembly. Of course, at some point a library is just debugged/trusted, but if there are "user hooks" those can be buggy. If it's performance important, it may never be unwelcome to have better profile reports.

    While addr2line has been a thing forever, I've never heard of an addr2expr - probably because "how would you label it?" So, pros & cons, but easy for debugger/profilers is one reason I think the parameterized file way is lower friction.

    • core-explorer  5 minutes ago

      debugging information is more precise than line numbers, it usually conveys line and column in a source file.

      Some debuggers make use of it when displaying the current program state, the major debuggers do not allow you to step into a specific sub-call on a line (e.g. skip function arguments and go straight to the outermost function call). This is purely a UI issue, they have enough information. I believe the nnd debugger has implemented selecting the call to step into.

      Addr2line could be amended. I am working on my own debugger and I keep re-implementing existing command line tools as part of my testing strategy. A finer-grained addr2line sounds like a good exercise.