This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new __builtin_choose_type (patch)
On Wed, Oct 03, 2001 at 11:16:10PM -0400, Aldy Hernandez wrote:
> the builtin_equal_types() approach is simpler in my opinion
> (implementation wise).
How is that? Magnus' original proposal was
_Bool __builtin_equal_types(arg | type, arg | type)
You can't have a type name (like "int" or "float") without
playing with grammar rules.
Further, there is a usability question. Which is cleaner?
#define foo(x, y) \
({ \
__typeof(x + y) tmp = x*x + y*y; \
if (__builtin_equal_types(tmp, float)) \
tmp = sqrtf(tmp); \
else if (__builtin_equal_types(tmp, double)) \
tmp = sqrt(tmp); \
else if (__builtin_equal_types(tmp, long double)) \
tmp = sqrtl(tmp); \
else \
abort(); \
tmp; \
})
#define foo(x, y) \
__builtin_choose_type(x+y, float, sqrtf(x*x + y*y), \
__builtin_choose_type(x+y, double, sqrt(x*x + y*y), \
__builtin_choose_type(x+y, long double, sqrtl(x*x + y+y), \
/* The void expression results in a compile-time error \
when assigning the result to something. */ \
(void)0)))
Hmm. This isn't the best example because of "x*x" doing multiple
evaluations of x, but you get the idea -- with equal_types we must
use a statement expression, but we needn't with choose_type. Plus
there's the issue of using a type that doesn't match.
On to the "does the type match" issue. Does 'char*' match 'const char *',
or need it be an exact match? I can see arguments either way.
r~