[解決済み] なぜ `int pow(int base, int exponent)` は C++の標準ライブラリにないのですか？

質問

私が見つけられないだけなのだろうと感じています。何か理由があって、C++の pow を除くすべての関数に対して、"power" 関数を実装していません。 float と double s?

実装が些細なものであることは分かっているのですが、標準ライブラリにあるべき仕事をやっているような気がしています。堅牢なべき乗関数（つまり、何らかの一貫した、明示的な方法でオーバーフローを処理する）は、書いていて楽しくない。

どのように解決するのか？

現在 C++11 という特殊なケースが追加されました。 C++11 [c.math] /11 は、すべての float/double/long double をオーバーロードしたものです（強調、言い換えあり）。

さらに、それを保証するのに十分な追加のオーバーロードがあるものとする。 に対応する引数がある場合、その引数は double パラメータが double または整数型に対応するすべての引数が double パラメータは、事実上 double .

つまり、基本的には整数のパラメータをdoubleに格上げして演算を実行することになります。

以前は C++11 (ご質問のあった時です) 整数のオーバーロードは存在しませんでした。

の製作者と密接な関係があったわけでもないので、そのようなことはありません。 C また C++ その創造の日々に（しかし、私は です また、ANSI/ISOの委員会にも参加していませんので、あくまでも私の意見です。私は、次のように考えています。 インフォームド しかし、私の妻が言うように（頻繁に、そしてあまり励ます必要もなく）、私は以前にも間違っていたことがあるのです :-)

一応、仮定は以下の通り。

I 疑う というのは、ANSI以前のオリジナルの C この機能がなかったのは、まったく必要なかったからです。まず、整数の累乗を行う完璧な方法がすでにあったのです（倍数を用いて、単に整数に変換し直し、変換前に整数のオーバーフローとアンダーフローをチェックする）。

第二に、もうひとつ忘れてはならないのは、本来の意図である C は システム プログラミング言語で、浮動小数点がその分野で望ましいかどうかは疑問です。

最初のユースケースの1つはUNIXのコード化でしたから、浮動小数点はほとんど役に立たなかったでしょう。CのベースとなったBCPLも、冪乗の用途はなかった（記憶では浮動小数点はまったくなかった）。

余談ですが、積分なべき乗演算子は、おそらくライブラリ呼び出しではなく、二項演算子だったでしょう。2つの整数を足すときに x = add (y, z) でなく x = y + z - の部分が 言語 というより、ライブラリです。

第三に、積分力の実装は比較的些細なものなので、言語の開発者はもっと有用なものを提供した方が時間を有効に使えることはほぼ確実です（機会費用に関する以下のコメント参照）。

それは、本家の C++ . 元の実装は事実上、単なる翻訳機で C の属性の多くを引き継いでいます。 C . 本来の目的はC-with-classであって、C-with-class-plus-a-little bit of extra-math-stuffではないのです。

なぜ今まで標準に加えられなかったかというと C++11 標準化団体には、従うべき特定のガイドラインがあることを忘れてはなりません。例えば、ANSIは C は、特に既存のプラクティスを成文化することを使命としています。 ではなく 新しい言語を作るためです。そうでなければ、気が狂ってAdaを提供していたかもしれませんね。）

その規格の後の反復版にも具体的なガイドラインがあり、根拠文書（言語自体の根拠ではなく、委員会がなぜある決定をしたかの根拠）で確認することができます。

例えば C99 の2つを具体的に継承しています。 C89 の指導方針は、追加できるものを制限しています。

• 言語は小さく、シンプルに。
  
• ある操作を行うための1つの方法のみを提供すること。

ガイドライン（必ずしもそれら 具体的な は、各ワーキンググループのために規定されたものであり、そのため C++ 委員会（および他のすべてのISOグループ）も同様である。

さらに、標準化団体は、以下のようなものがあることを認識しています。 機会費用 (経済用語で、ある決定をするために見送らなければならないものを意味する）。たとえば、1万ドルの超大型ゲーム機を買うという機会費用は、友好的な関係（あるいはおそらく すべて 半年間くらいは、もう一人の妻との関係が続くのです。

エリック・ガナーソンは、これをうまく説明するために、彼の -100点満点の解説 基本的に、機能は100点満点でスタートするので、検討されるにはかなりの価値を追加する必要があります。

言い換えれば、あなたは積分型演算子（正直、半端なコーダーでも10分もあれば作れる）とマルチスレッドのどちらを標準に加えたいですか？私自身は、後者があれば、UNIXとWindowsで異なる実装に煩わされなくて済むので、そちらを希望します。

私は、標準ライブラリ（ハッシュ、btree、赤黒木、辞書、任意マップなど）の何千何万ものコレクションも同様に見てみたいのですが、根拠が述べているように。

標準とは、実装者とプログラマーとの間の条約である。

そして、標準化団体の実装者の数は、プログラマーの数をはるかに上回っています（少なくとも機会費用を理解していないプログラマーは）。もし、そのようなものがすべて追加されたら、次の標準は C++ となります。 C++215x そして、おそらくその300年後には、コンパイラの開発者によって完全に実装されていることでしょう。

とにかく、これが私の（かなり膨大な）感想です。もし投票が質より量に基づいて行われるなら、私はすぐに他のみんなを吹き飛ばしてしまうだろう。ご清聴ありがとうございました :-)