<tgmath.h>是一个在C99引入的标准C语言库提供的头文件。对于Fortran编写的数值软件，它向C语言提供更加简洁的接口。
跟C语言不同，Fortran提供了编写在该语言内部的“固有函数”，其表现得更像操作符一样。固有函数接受不同类型的参数，并根据参数的类型返回对应类型的返回值。同时，Fortran中的普通函数（“外部函数”）的行为跟C语言中的函数类似，对类型要求严格(即函数参数的类型必须符合，返回值也是固定的)。举个例子，Fortran77提供了一个名为INT的函数，它能够接受Integer、Real、Double和Complex的参数，并总是返回Integer。另有一个名为SIN的函数，接受Real、Double和Complex的参数并返回相同类型的值。这两个函数仅仅是固有函数的一小部分。
某种意义上，这个特性帮了程序员不少忙，因为即使变量类型改变了，函数调用也不需要更改。另一方面，用户定义的函数不能像这样工作，因此这些附加的便利性只有在不调用用户定义函数的情况下才成立。
仅仅根据以上描述，就已经有一些C程序员认为这个特性是丑陋的了。同样的理由，他们认为把printf整合到C中一样丑陋。
这个功能和其他特性在C99被整合进C语言，包含在在之前提到的中，目的是更好的支持数值计算。其中提供了三角函数和对数函数，舍入相关的函数和少数其它函数。这个头文件定义了一系列宏，覆盖了中已有的一些函数；例如，cos宏在参数是double的时候表现得像cos函数一样，参数是float时像cosf，参数是long double时像cosl，double _Complex时像ccos，参数是float _Complex时像ccosf，参数是long double _Complex时像ccosl。最终，如果参数是任何整形，宏调用cos函数，就像参数被隐式的转换为了double类型一样。
这个特性丑陋的第二个理由在于它试图模仿成函数，但是这个模仿不但不完美，甚至是非常危险的：如果你尝试着将泛型宏cos当成一个参数传递给函数，而事实上它总是被当做对应double的cos函数，因为cos后面不紧跟一个左括号的话宏根本不会展开。
最后一个被认为丑陋的理由在于，这样的宏在严格意义上的C上根本不能实现，它们需要依靠某种编译器支持——另外，某些经验（例如，glibc实现中bug被发现的速度）表明，这个特性基本上没有使用过，因此不应该被算作这个语言核心的一部分，尤其是它根本就不支持潜在的特性。（相比之下，<stdarg.h>对便携性的支持就非常的好。）
说了这么多，这个特性又丑陋有没有实用价值，我干嘛提到它？我写这个文章的原因是我在考察glibc的时候，发现它是一个如此天才的实现。我认为它应该用一种更好的办法被后人铭记，而不是像下面这样的注释一样。
Ulrich Drepperdrepper@redhat.com
Joseph S. Myersjsm28@cam.ac.hk
* math/tgmah.h: Make standard compliant. Don’t ask how.
最直接模仿Fortran编译器的方法是使用一个简单的宏：（我会用cos来举大部分例子，其他宏的语法是相似的。）
#define cos(X) __tgmath_cos(X)
编译器会将__tgmath_cos当做内部操作符，然后将其转换成某一个前端的函数调用。
我见过的被推选出的最简洁的解决方法，是在编译器前段给基本函数加上了重载支持，这可以利用运营商扩展来实现。（否则，C语言标准会要求编译器检查某个标示符的不兼容声明。）
#define cos(X) __tgmath_cos(X) #praga compiler_vendor overload __tgmath_cos double __tgmath_cos (double x) {return (cos) (x); } float __tgmath_cos (float x) {return cosf (x); } long double __tgmath_cos (long double x) {return cosl (x); } ...
(简单的习题： 为什么在定义__tgmath_cos(double)时，cos两旁有括号呢？)
当然，仅仅为了<tgmath.h>的这个目的而实现它是一件非常繁杂的工作。（虽然它有可能能在C++前端上工作。）没人想在C语言中用这样一个笨重的扩展，何况本就没多少程序使用<tgmath.h>，所以似乎这样扩展编译器有些不值得。
glibc的实现必须依靠那些用已经成熟的gcc版本推出的扩展，因此要实现它更加复杂了。
首先，让我们实现一个选择正确函数类型的宏吧。因为C语言不支持条件宏扩展，因此条件判断语句需要包含在扩展代码中。我们需要像下面这样代码：
#define cos(X) \ (X is real) ? ( \ (X has type double \ || X has an integer type) \ ? (cos) (X) \ : (X has type long double) \ ? cosl(X) \ : cosf (X) \ ) : ( (X has type double _Complex) \ ? ccos (X) ....
而且，我们发现写上面那样的条件判断语句非常简单。
“x is real”就是sizeof (X) == sizeof (__real__ (X))
“x has an integer type”就是(typeof(X))1.1 == 1（中等的习题：(__typeof__ (X))0.1 == 0不正确。这是为什么呢？） （事实上，glibc在某些情况使用了__builtin_classify_type，一种嵌入式的内部gcc，而在上述情况使用了另一种相似的替代。）
“x has typedouble/long double/float“也能被sizeof区分。但在有些硬件结构下，一些C类型被映射成相同的硬件类型，这时区分的结果可能那么精确，不过在这些硬件结构下这些不同类型的运算都没有差别，而且外部的C语言也不能识别出差别了。就C语言的”as-if”原则来说，这算是相当不错的了。
好的，这样一来我们的cos宏就能选择正确的函数来调用了。不过不幸的是，它总是返回long double _Complex类型的结果。原因在于，? :操作符的返回值的类型会是第二和第三操作数类型的“常用算术转换”。
我们能够避免这些类型转换来使用我们自己选择的类型，这需要另一个gcc扩展，声明表达式：
#define cos(X) ({ result_type __var; \ if (X is real) { \ if ((X has type double) \ || (X has an integer type)) { \ __var = (cos) (X); \ else if (X has type long double) \ __var = cosl (X); \ ... __var; })
现在，这个宏的结果永远会是result_type，问题引刃而解。
是吗？
事