Re: [PATCH v2] _Generic.3: New page documenting _Generic()

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1507 bytes --]

On 8/23/22 15:32, Alejandro Colomar wrote:
> Hi Florian,
> 
> On 8/23/22 09:58, Florian Weimer wrote:
> 
>> Note that this approach does not really work that well in practice
>> because macros using _Generic expand all the alternatives (in current
>> implementations; doing this differently requires deviating from the
>> layered implementation strategy suggested in the C standard).  This
>> means that _Generic-using macros can only be nested maybe three or four
>> levels deep, depending on the number of _Generic alternatives on each
>> level.  For <tgmath.h>, this is really not enough, so a high-quality
>> implementation of <tgmath.h> using _Generic is not feasible.  GCC
>> provides __builtin_tgmath, which is designed in such a way that when
>> used in a macro, the macro argument is only expanded once.
>>
>> Maybe mention this under BUGS?
>>
>> C++ templates do not suffer from this particular problem.
> 
> 
> Ahh, I get it now.  You mean that the preprocessed code could grow 
> exponentially, even if the assembly code is safe from such bloat, right?
> 
> Yeah, probably that should go into CAVEATS.
> 
> Would you mind sending a patch?
> 
> Anyway, if the standard defined intmax_t as a macro, it should probably 

s/intmax_t/imaxabs()/

> not specify how that macro is implemented; this is just a simple 
> suggestion, but a builtin of course would be better.
> 
> Cheers,
> 
> Alex
> 

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]