Post B5tEwiR22ZTf48lkSu by thephd@pony.social
(DIR) More posts by thephd@pony.social
(DIR) Post #B5tCcZxzcGdN6MSNZg by thephd@pony.social
1 likes, 0 repeats
It's live.https://godbolt.org/z/71f3xxcYh#include <stdio.h>#define bar(x) _Generic(x, \ int v: v, \ struct foo v: v.name \)struct foo { char* name; };int main() { struct foo f = { "test" }; bar(3); bar(f) = "something"; puts(f.name); // prints "something"}
(DIR) Post #B5tCwTzlWlH0NCmDey by thephd@pony.social
0 likes, 0 repeats
@simontatham -- not to bother you but since this is now live you can probably kick the tires a little bit on it in Godbolt. I think it solves most of your concerns (save what happens in the default: branch!).Still need to figure out if I need braces around the _Generic bits to see if it works.
(DIR) Post #B5tDsThgllUgGTyYjY by poliorcetics@social.treehouse.systems
0 likes, 0 repeats
@thephd I am confused but it seems cool
(DIR) Post #B5tDsTu61dQ0sxmT4a by thephd@pony.social
0 likes, 0 repeats
@poliorcetics the magic is in the identifier after the default and after the int in the _Generic: it allows you to take an ident on the value put into a C _Generic expression so you don't have to keep re-computing the value to use it in the branches. It also gives safe type checking.
(DIR) Post #B5tEwiR22ZTf48lkSu by thephd@pony.social
0 likes, 0 repeats
@dysfun I'm tryin'.
(DIR) Post #B5tEyDLwZdfNFI6Uwi by wren6991@types.pl
0 likes, 0 repeats
@thephd wait that's illegal
(DIR) Post #B5tEyDVW03K3iya8rg by thephd@pony.social
0 likes, 0 repeats
@wren6991 It might not be, soon!!
(DIR) Post #B5tIxC4iEtbEoEoSZ6 by uecker@mastodon.social
0 likes, 0 repeats
@thephd I don' think we need more braces. The scope can be limited as you implemented it.
(DIR) Post #B5tgy7r5oM4IuaQ4jQ by alison@burningboard.net
0 likes, 0 repeats
@thephd @poliorcetics Is __Generic already part of C?I always enjoyed seeing more of the internal in GDB:(gdb) p *process_secondary_params$1 = {_Bool (struct parser_props *, char *)} 0x3523a <process_secondary_params>
(DIR) Post #B5twtAYFxSBh5nGe92 by fay59@tech.lgbt
0 likes, 0 repeats
@thephd if you allowed “auto x” for a default case, `#define bar(X) _Generic(X, auto x: …)` could become the least bad way to bind the expansion of a preprocessor macro to a variable inside a single expression
(DIR) Post #B5twtArOoHV43ADvyy by typeswitch@gamedev.lgbt
0 likes, 0 repeats
@fay59 @thephd you can use `default` ... `_Generic(X, default x: ...)` should work. https://godbolt.org/z/3bGKqaWPK
(DIR) Post #B5twtB2k86ZecLWzfE by thephd@pony.social
0 likes, 0 repeats
@typeswitch @fay59 Yeah, I think auto should be reserved for if it ever gets more advanced and we use auto for something closer to "safe type deduction that does not trigger type checking errors" rather than another way to spell default.auto would also provide opportunities for const auto x: (all const variables but not mutable ones), auto *p: (all pointer variables), and things of that nature.
(DIR) Post #B5twwagPG4fp0Si9HU by thephd@pony.social
0 likes, 0 repeats
@alison @poliorcetics _Generic comes from C11, yeah. It's been there for 15 years, but I believe MSVC was lagging on it until very recently (like 1.5 years ago?)
(DIR) Post #B5tySy8jgItcyfxtGC by uecker@mastodon.social
0 likes, 0 repeats
@thephd at file scope it is still a bit weird...
(DIR) Post #B5tySyK507yDXrGwwS by thephd@pony.social
0 likes, 0 repeats
@uecker Right now doing int x = _Generic(1, int v: v); is just an error in the implementation. We can maybe fix up _Generic to bless such a selection as a constant expression, but I'm in no rush to do that right now honestly.
(DIR) Post #B5vcMos7Pw35ovm6QC by valorzard@mastodon.gamedev.place
0 likes, 0 repeats
@thephd ...wait what the hell is happening here?is this like a factory for creating new structs, except the structs are referred by number?
(DIR) Post #B6A8qJtJ5KXTAWsdZQ by thephd@pony.social
0 likes, 0 repeats
@simontatham Yeah, that was a weirdly C++-ish error message; thanks for reporting. Seems like something got crossed in the parsing bit; I pushed a fix to the thephd.dev branch and it'll eventually reflect there. (Probably gotta wait until Monday midday to test again on Godbolt.)On the bright side, on my local branch it worked out just fine when I tested your code against the modified patch so that was nice.
(DIR) Post #B6BkJFkdRlHWBnRZXU by thephd@pony.social
0 likes, 0 repeats
@simontatham Following up, it's indeed fixed! https://godbolt.org/z/4Wv31bej8Thanks for poking at it, should be more (or less?) okay now.
(DIR) Post #B6Bljipa3FKPrUwTFw by thephd@pony.social
0 likes, 0 repeats
@simontatham It was more of an implementation peculiarity than anything else, really. Internally, we check if what is coming in is a modifiable lvalue and -- if it is -- take a reference to it. Unfortunately the way we were doing it before took a reference to the stripped-down type if certain kinds of pointers got involved, and this wrecked parsing a little bit.But that part's been fixed and the modifiable lvalue bit is only taken later.
(DIR) Post #B6C5ImwSenIXsOawkK by thephd@pony.social
0 likes, 0 repeats
@simontatham I have no good solution for multi match generics other than the function pointer arguments trick. I have sat down to try and figure out a non-amviguous syntax for this but it has not worked out at all. It's similar to the problem of trying to initialize multiple different types in for loop init expressions: very little syntactic space to maneuver.That being said, maybe we need to grow a little beyond Generic if we want this kind of power.
(DIR) Post #B6C5PPFn7yNKR4nAnY by thephd@pony.social
0 likes, 0 repeats
@simontatham nesting generics is a little less.problematic but nested macro and expansion can get compile-time expensive.
(DIR) Post #B6C9PYYsv8977X3A24 by thephd@pony.social
0 likes, 0 repeats
@simontatham I believe @erisceleste has some opinions on this and has done stuff like this before, so she can chime in about it.