Login
You're viewing the discuss.systems public feed.

Replies

  • James WidmanJamesWidman@mastodon.social
    Jan 13, 2025, 8:30 AM

    @thephd @euneuber
    1) this looks really good!

    2) why this:
    _Operator(+, ml_vec2, ml_vec2, ml_vec2_add);

    ...when you could instead have this:

    _Operator(+, ml_vec2_add);

    ...and infer the operand types from the parameter types of the function?

    💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 13, 2025, 8:35 AM

    @thephd @euneuber i guess the form with explicit operand types could make it easier to find the _Operator() declaration with `grep`...?

    (which, as a clangd user, i would be sad to learn that anyone still uses `grep` to find declarations instead setting up a mouse-binding in the text editor so that you can (for example) ctrl-click on the operator token to make the editor jump to the location given by clangd, but...)

    💬 1🔄 0⭐ 0
  • Björkus "No time_t to Die" Dorkusthephd@pony.social
    Jan 14, 2025, 5:31 PM

    @JamesWidman @euneuber We do not do integer promotion or anything, as talked about in the video. And as mentioned during audience commentary (not sure if you could hear that), this means you can do:

    _Operator(+, ml_vec2, double, ml_vec2_double_add);
    _Operator(+, ml_vec2, float, ml_vec2_double_add);
    _Operator(+, ml_vec2, int, ml_vec2_double_add);
    _Operator(+, ml_vec2, char, ml_vec2_double_add);
    _Operator(+, ml_vec2, short, ml_vec2_double_add);
    _Operator(+, ml_vec2, long, ml_vec2_double_add);

    You get to avoid having to rewrite the function for multiple different types, and can simulate "promotion" by just having a number of operator declarations.

    💬 1🔄 1⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 14, 2025, 10:20 PM

    @thephd @euneuber i did miss that; sorry!

    ok, this is cool. I don't like the promotion rules, but some users were bound to ask for them. So i really like the fact that, if they really want it, at least they'll have to explicitly opt into it like this. (And during a code review where it's introduced, it'll be like a big neon sign to anyone reading it.)

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 15, 2025, 12:49 AM

    @joe @thephd @euneuber ok, yes [edit: no, see below],

    BUT

    at least it won't be in the standard library.

    i mean, at least it seems like a pretty safe bet that the C committee wouldn't put that in the standard library.

    like, i'm 99...

    80% sure that the C committee wouldn't put that in the standard library.

    💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 15, 2025, 1:18 AM

    @joe @thephd @euneuber more seriously: i can't seem to find it in the video now, but i think there is actually a proposed rule for _Operator() that's says that an operand type cannot be a pointer type..? (so iiuc, the compiler would error on your _Operator(<<) above).

    💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 15, 2025, 1:24 AM

    @joe @thephd @euneuber ...But i think it might allow:

    _Operator(>>, &, const char, FILE, fputs);

    (the function signature is fputs(const char*, FILE*);)

    ...i think...? And that means that:

    const char *s = "hello";
    FILE *f = fopen(/*...*/);

    *s >> *f;

    would translate to:

    fputs(&*s, &*f);

    💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 15, 2025, 1:53 AM

    @joe @thephd @euneuber found the relevant bit in the video, starting at about 58:00, in response to a question about pointers:

    [58:45] "[...] the same way you can't override for `int, int`, you can't override it for `int *` or `MyStruct * [...] [A pointer is] still a built-in type, even though it's a pointer to your type."

    So, a compiler would issue an error for:
    _Operator(<<, FILE*, const char *, fputs);

    ...because both operand types are built-in types...

    💬 1🔄 0⭐ 0
  • 💬 2🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • James WidmanJamesWidman@mastodon.social
    Jan 15, 2025, 4:53 PM

    @thephd @joe @euneuber TIL that the definition of "lvalue" was modified to "an expression with [...] a complete object type" sometime after C99 (in which the definition didn't mention completeness), thus rendering expressions like &*p ill-formed when typeof(*p) is incomplete

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Jari Komppa 🇫🇮 (has moved)sol_hsa@peoplemaking.games
    Jan 13, 2025, 10:44 AM

    @euneuber @thephd
    Couple questions that occurred to me while watching that; what can be an operator? If It's a free word, that would potentially solve the "why did you use << for this" issue, as people could define stuff like "a cross b".

    Second is that whether single parameter operators are allowed, like !

    Combined, these two would allow for some really wild ioccc entries.

    💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Gina Peter BanyardGirgias@phpc.social
    Jan 14, 2025, 2:27 AM

    @euneuber @thephd
    This is possibly a really really dumb idea for handling the temporaries.
    Would something like `_Operator(op1, op2, left, middle, right, temp_destructor)` that code gen:
    ```
    T1 = left op1 middle;
    R = T1 op2 right;
    temp_destructor(T1);
    ```
    Work?

    Yes this means you'd need to write a _lot_ of these if you support multiple operators. But this would be explicit, and if you add some attributes like associative and commutative to help rearranging that would reduce the combinations.

    💬 0🔄 0⭐ 0
  • Björkus "No time_t to Die" Dorkusthephd@pony.social
    Jan 14, 2025, 6:08 PM

    @Girgias @euneuber I mean, maybe. This just seems like doing proper destructors the long way around, though, so I feel like instead C should just eat the paste and either painfully make linear types for operator work, OR use runtime variables to track such matters.

    💬 0🔄 0⭐ 0