問題タブ [using-declaration]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - コンストラクターに名前を付ける using 宣言が必要なのはなぜですか?
C++11 標準の 7.3.3.p1 と p3 の両方の段落は、コンストラクターを指定するusing 宣言を参照しています。なぜこれが必要なのですか?以下のコードは、基本クラスA
のコンストラクターが派生クラスB
で期待どおりに表示されることを示しています。
上記をコメントアウトしてusing A::A;
も、プログラムの実行に変化はありません。
c++ - GotW #53 で著者が言おうとしていることは何ですか?
この疑似コードは、"A Not-So-Good Long-Term Solution" というサブタイトルでGotW #53から入手したものです。特に以下の「//エラー:潜在的...」で始まるコメントに関連して、著者が言っていることをすでに数時間理解しようとしましたが、役に立ちませんでした。これについて何か助けていただければ幸いです。
c++ - 以下の main() の `df(1);` 式に曖昧さがないのはなぜですか?
d.f(1);
以下の式で とmain()
の間Base::f(int)
に曖昧さがないのはなぜDerived::f(int)
ですか?
c++ - 基本クラス名で「使用」してアクセスを有効に変更しますか?
私の友人は私に次のコードを見せてくれました
彼はAInternal
、ほとんど (すべてではないにしてもA
) を実装する内部クラスとして使用しています。その後、彼は から継承しましAInternal
たが、彼が望んでいたようにAInternal
(これは実装の詳細であるため) アクセスできないままであり、保護された (実装された) を継承します。彼が行ったusing
ことは、基本クラス名をアクセス可能にすることでした (継承も保護A
されていたため、デフォルトで保護されていました)。AInternal
実際、これは問題なく動作しました (ただし、後でわかったように、メンバー関数は保持されていましprivate
た。基本クラスが作成されpublic
ただけです)。ただし、GCC でしか動作しませんでした。ベースをA
アクセス可能にできません。何か案が?Clang で動作するコードを壊すことさえできます
誰か助けてくれませんか?
c++ - 派生クラスに適用される C++ の 'Using' キーワードの欠点
using
最近、このキーワードの新しい用途を発見しました。機能を参照するのではnamespace
なく、派生クラスの宣言内で。私の場合、これは「operator=」メンバー関数を取り巻く問題に関して適切でした。
宣言を考えると、次のような状況がありました。
... のオブジェクトがCStringEx
期待どおりに機能しませんでした:
代わりに、' CStringEx has no 'operator=()' function that takes an argument of type wchar_t* ' (または - 非常に近い - その効果に近い言葉)というコンパイラ エラーが生成されました。かなりの研究の後、これはoperator=
、派生クラスのコンパイラによって自動的に生成されたメンバー関数でさえ、その親クラスから継承されたものをオーバーライドするためであることがわかりました。これは私には直観に反し、ユーザーフレンドリーに思えます。
ただし、using
キーワードを追加すると:
...子クラスは親のoperator=
メンバー関数を使用するようになり、すべて問題ありません。
ここまでは順調ですね。ただし、ここや他の場所をさらに読んだ後、多くのプログラマーがusing
この目的での使用を好まないことがわかりました。たとえば、親からすべての operator= を取り込むなど、望ましくない可能性のある副作用について説明しているコメンテーターを読みました。ただし、非常に特殊な状況を除いて、すべての親メンバー関数を継承する理由がわかりません。これが主な懸念事項である場合、誰かがそうすることの一般的な危険性を説明できますか?
私が考えることができる唯一の代替手段は、その親のすべて のメンバー関数の子クラスにスタブ関数を書き出してから、operator=
それらのそれぞれのメンバー関数を明示的に呼び出すことです。
このバージョンと比較すると、using CString::operator=
これは非常に醜く、扱いにくく、面倒です。using
繰り返しになりますが、キーワードを使用しないのはなぜですか?
c++ - 従属修飾 ID を持つクラス メンバーの using 宣言は従属名にする必要がありますか?
C++11 標準のドラフト N3337 では、[namespace.udecl]
using 宣言は、using 宣言が現れる宣言領域に名前を導入します。
すべての using 宣言は宣言とメンバー宣言であるため、クラス定義で使用できます。
メンバー宣言として使用される using 宣言では、nested-name-specifier は、定義されているクラスの基本クラスに名前を付けるものとします。
これは通常、次の例のように、基本クラス内で保護された typedef を派生クラスで公開するために使用され、Clang の最新バージョンで正常にコンパイルされます。
using 宣言は、テンプレート クラスを参照できます。これはコンパイルされます:
依存する基本クラスのテンプレートを参照することもできます。以下は正常にコンパイルされます (typedef がコメント化されています)。
のコメントを外すtypename
と、インスタンス化時にエラーが発生しますB<int>
: 「エラー: 非型で使用される 'typename' キーワード」。
typedef のコメントを外すと、B
最初のインスタンス化の前に解析するときにエラーが発生します。Type
これは、コンパイラが依存型名として扱わないためだと思います。
の最後の段落は[namespace.udecl]
、using 宣言が依存する名前を指定する可能性があること、およびtypename
導入された名前のさらなる使用法を明確にするためにキーワードを使用する必要があることを示唆しています。
using-declaration がキーワード typename を使用し、従属名 (14.6.2) を指定する場合、using-declaration によって導入された名前は typedef-name として扱われます。
私の読書は、それが従属名であることを[temp.dep]
示唆しています。A<T>::Type
論理的には、using 宣言によって導入された名前も依存する必要がありますが[temp.dep]
、依存する using 宣言の場合については明示的に言及していません。何か不足していますか?