C++でintを継承できないのはなぜですか？

疑問点

こんなことができたらいいな。

class myInt : public int
{

};

どうしてダメなんだろう？

なぜそうしたいのか？より強力な型付け。例えば、2つのクラスを定義することができます intA と intB というように intA + intA または intB + intB でなく intA + intB .

intはクラスではありません。

"intはメンバーデータを持っていない "そうです、32ビットもあります。

"Intsはメンバ関数を持たない." まあ、彼らは以下のような演算子の束を持っています。 + と - .

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

Neilのコメントはかなり正確です。Bjarne は、この正確な可能性を検討し、拒否することに言及しました。

1 :

イニシャライザの構文は、以前は は組み込み型に対して違法でした。これを可能にするために という概念を導入しました。 組み込み型はコンストラクタと デストラクタを持つという概念を導入しました。たとえば

int a(1);    // pre-2.1 error, now initializes a to 1

私はこの概念を拡張して 組み込みクラスからの派生を許可する という概念を拡張し、組み込み型に対する組み込み型演算子の明示的な宣言を可能にすることを考えました。 演算子を使えるようにすることも考えました。しかし 自制した。

を許可する から派生した int からの派生を許可しても C++プログラマに与える影響は と比べて格段に新しいものを与えるわけではありません。 を持つことに比べれば int メンバを持つことと比較して、著しく新しいものを提供しています。これは 主に int は は派生クラスがオーバーライドするための仮想関数を クラスがオーバーライドする仮想関数を持たないからです。もっと深刻なのは C言語の変換ルールは非常に混沌としています。 というのは、Cの変換規則は非常に混沌としていて int , short などは、お行儀が良い 普通のクラスではうまくいきません。 それらはC互換であるか、あるいは 比較的行儀の良いC++のクラスの規則に従うか のルールに従うかですが、両方ではありません。

パフォーマンスが int をクラスにしないことを正当化するというコメントに関しては、（少なくともほとんど）誤りです。しかし、Smalltalk のほぼすべての実装は最適化されているので、実装はクラスでない型をどのように動作させるかと本質的に同じであることができます。たとえば、smallInteger クラスは 15 ビットの整数を表し、「+」メッセージは仮想マシンにハードコードされているため、smallInteger から派生しても、組み込み型に近いパフォーマンスが得られます (Smalltalk は C++ と十分に異なるため、パフォーマンスの直接比較は難しく、あまり意味がないと思われますが)。

SmalltalkのsmallIntegerの実装でquot;wasted"となっている1ビット（16ビットではなく15ビットしか表現しない理由）は、おそらくCやC++では必要ないでしょう。SmalltalkはJavaに少し似ていて、オブジェクトを定義するとき、実際にはオブジェクトへのポインタを定義しているだけで、オブジェクトを動的に確保する必要があります。操作するもの、パラメータとして関数に渡すものなどは、常にポインタだけであり、オブジェクトそのものではありません。

それは ではなく この場合、通常ポインタであるはずの場所に直接整数値が置かれます。smallInteger とポインタを区別するために、彼らはすべてのオブジェクトを偶数バイトの境界で割り当てるように強制し、LSB が常に明確になるようにしています。smallInteger は常に LSB が設定されています。

しかし、Smalltalk は動的型付けであり、値そのものを見て型を推測できなければならず、smallInteger は基本的に LSB を型タグとして使用しているため、このほとんどは必要なことなのです。C++が静的型付けであることを考えると、値から型を推測する必要はありません。したがって、おそらく型タグのためにビットを無駄にする必要はないでしょう。

^{1. で C++ の設計と進化 , §15.11.3.}