4

現在、私の科学計算コードの1つに、次のものがあります。

//Include M_PI constant
#define _USE_MATH_DEFINES
//Needed for square root function.
#include <math.h>

これは動作します...少なくともLinuxでは...すべてのプラットフォームのCコンパイラでテストしたわけではありません。しかし、いくつかの古いFortranコードを調査したとき、私は最近、別のコード（自分のものではない）でpiを定義するこの一見賢い方法に出くわしました：

<angle in deg.>*8.0d0 * datan(1.0d0) / 360.0d0

もちろん、これはCで完全に実行可能ですよね？したがって、変換関数を次のように定義できます。

inline double DegToRad(const double A)
{
   return A * atan(1.0) / 45.0;
}

どちらのアプローチがより移植性がありますか？あるアプローチを別のアプローチよりも使用する価値のある数値（丸めなど）の考慮事項はありますか？

M_PI定数によってコードが読みやすくなるのが好きです。もちろん、上記のアプローチを使用して、自分のPI定数を割り当てることもできます。

複数のプラットフォーム（Windows、Linuxなど）を対象とするC / C ++コードのベストプラクティスと見なされるものは何ですか？

4

1 に答える 1

6

読みやすさの問題を最小限にしないでください。個人的に、私はこのようなことをします：

#ifndef M_PI
// Source: http://www.geom.uiuc.edu/~huberty/math5337/groupe/digits.html
#define M_PI 3.141592653589793238462643383279502884197169399375105820974944592307816406 
#endif

#define DEG_TO_RAD (M_PI/180.0)
#define RAD_TO_DEG (180.0/M_PI)

そして宣言する

inline double DegToRad(const double deg) {
   return deg * DEG_TO_RAD;
}

inline double RadToDeg(const double rad) {
   return rad * RAD_TO_DEG;
}

これはおそらく多かれ少なかれ移植性がないでしょう（両方atanともM_PICとC ++の両方で標準です）。ただし、使用するよりも読みやすくatan、コンパイラの最適化設定によっては、コストのかかるtrig関数呼び出しを節約できる場合があります。

更新：M_PIは思ったほど標準的ではないようです。上記を含める#ifndefことで、利用できない場合に対処する必要があります。

于 2012-12-03T20:00:04.343 に答える