問題タブ [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.

0 投票する
1 に答える
107 参照

c++ - コンストラクターに名前を付ける using 宣言が必要なのはなぜですか?

C++11 標準の 7.3.3.p1 と p3 の両方の段落は、コンストラクターを指定するusing 宣言を参照しています。なぜこれが必要なのですか?以下のコードは、基本クラスAのコンストラクターが派生クラスBで期待どおりに表示されることを示しています。

上記をコメントアウトしてusing A::A;も、プログラムの実行に変化はありません。

0 投票する
2 に答える
124 参照

c++ - GotW #53 で著者が言おうとしていることは何ですか?

この疑似コードは、"A Not-So-Good Long-Term Solution" というサブタイトルでGotW #53から入手したものです。特に以下の「//エラー:潜在的...」で始まるコメントに関連して、著者が言っていることをすでに数時間理解しようとしましたが、役に立ちませんでした。これについて何か助けていただければ幸いです。

0 投票する
3 に答える
88 参照

c++ - 以下の main() の `df(1);` 式に曖昧さがないのはなぜですか?

d.f(1);以下の式で とmain()の間Base::f(int)に曖昧さがないのはなぜDerived::f(int)ですか?

0 投票する
1 に答える
145 参照

c++ - 基本クラス名で「使用」してアクセスを有効に変更しますか?

私の友人は私に次のコードを見せてくれました

彼はAInternal、ほとんど (すべてではないにしてもA) を実装する内部クラスとして使用しています。その後、彼は から継承しましAInternalたが、彼が望んでいたようにAInternal(これは実装の詳細であるため) アクセスできないままであり、保護された (実装された) を継承します。彼が行ったusingことは、基本クラス名をアクセス可能にすることでした (継承も保護Aされていたため、デフォルトで保護されていました)。AInternal

実際、これは問題なく動作しました (ただし、後でわかったように、メンバー関数は保持されていましprivateた。基本クラスが作成されpublicただけです)。ただし、GCC でしか動作しませんでした。ベースをAアクセス可能にできません。何か案が?Clang で動作するコードを壊すことさえできます

誰か助けてくれませんか?

0 投票する
2 に答える
1528 参照

c++ - 継承コンストラクターで typename を使用した C++ の宣言

この質問を読んでいるときに、奇妙な点を見つけました。

以来typename、コンストラクターではなく、クラス名を注入Baseclass<T>::Baseclassする必要があります。私の知る限り、これは次の場合と同じです。

念のため、テストコードを書きました。

ただし、gcc 4.8.3 で動作します。

なしでも動作しtypenameます。

なぜこれらの結果が得られたのですか? 私は何を取りこぼしたか?

0 投票する
1 に答える
541 参照

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繰り返しになりますが、キーワードを使用しないのはなぜですか?

0 投票する
2 に答える
1815 参照

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 宣言の場合については明示的に言及していません。何か不足していますか?