Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168312
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: complex problem with gcc usage |
| Date | 2022-11-20 15:09 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <20221120070258.775@kylheku.com> (permalink) |
| References | <tl8eo4$2vpv0$1@dont-email.me> <20221118115253.118@kylheku.com> <tla4vb$36ma1$1@dont-email.me> <tlblkv$3aevl$1@dont-email.me> |
On 2022-11-19, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> On 11/19/2022 12:43 AM, aotto1968 wrote:
>>
>> the "_Generic feature looks good and I found a solution:
>>
>> /// cast a \e known-object into an \RMkNs{ObjectS} reference
>> #define MkOBJ_R(x) (_Generic((x),struct MkObjectS
>> *:(*x),default:((*(x)).super.obj)))
>> /// cast a \e known-object into an \RMkNs{ObjectS} pointer
>> #define MkOBJ(x) (&MkOBJ_R(x))
>
> How is this a solution, when it does not even remotely match the
> original problem? How does this implement `ifexists(ptr->super.obj)`?
Because aotto is imposing the rule/assuption that in fact
ifexists(ptr->super.obj) is true in the default case when the argument
is other than a certain type, that being "struct MkObjectS *".
That type is assumed not to have a "super.obj" field; it won't be
used even if it has one. Any other kind of argument to the macro must
be a pointer to a struct/union that does have "super.obj", because
the selected expression accesses such a member; if it doesn't, there
will be a diagnostic. That's where the "ifexists" test is effectively
being done.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
complex problem with gcc usage aotto1968 <aotto1968@t-online.de> - 2022-11-18 18:17 +0100
Re: complex problem with gcc usage Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-18 20:03 +0000
Re: complex problem with gcc usage aotto1968 <aotto1968@t-online.de> - 2022-11-19 09:43 +0100
Re: complex problem with gcc usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-11-19 14:39 +0000
Re: complex problem with gcc usage Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-19 16:13 +0000
Re: complex problem with gcc usage aotto1968 <aotto1968@t-online.de> - 2022-11-19 19:19 +0100
Re: complex problem with gcc usage Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-19 21:42 +0000
Re: complex problem with gcc usage Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-11-19 14:34 -0800
Re: complex problem with gcc usage aotto1968 <aotto1968@t-online.de> - 2022-11-20 08:40 +0100
Re: complex problem with gcc usage Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-20 15:09 +0000
Re: complex problem with gcc usage "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-18 12:10 -0800
csiph-web