This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.  */		\

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]