これがg++のバグであるかどうかはわかりません(バージョン4.2.4以降)。コードはg++4.4で渡されるようになりました(以下のUPDATEを参照)。このコードを他のバージョンのコンパイラー用にコンパイルするために、デフォルトの引数の周りに括弧のセットを追加できます。
template<typename A, typename B>
class Foo { };
struct Bar {
void method ( Foo<int,int> const& stuff = ( Foo<int,int>() ) );
};
IMO、これらの括弧は、デフォルトの引数がクラス本体の後半で宣言される可能性のあるクラスのメンバーを参照できるという追加の要件があるため、必要です。
struct Bar {
void method ( int i = j); // 'j' not declared yet
static const int j = 0;
};
上記のコードは正当であり、「メソッド」の宣言が解析されているとき、メンバー「j」はまだ表示されていません。したがって、コンパイラは、構文チェックのみを使用してデフォルトの引数を解析できます(つまり、括弧とコンマの一致)。g ++が元の宣言を解析しているとき、実際に表示されているのは次のとおりです。
void method ( Foo<int,int> const& stuff = Foo<int // Arg 1 with dflt.
, int>() ); // Arg 2 - syntax error
括弧のセットを追加すると、デフォルトの引数が正しく処理されます。
次のケースは、g ++が成功したが、Comeauが構文エラーを生成する例を示しています。
template<int J, int K>
class Foo { };
struct Bar {
void method ( Foo<0, 0> const & i = ( Foo<j, k> () ) );
static const int j = 0;
static const int k = 0;
};
編集:
「複数の引数を持つ関数呼び出しを使用することもできます」というコメントに応えて、これで問題が発生しない理由は、関数呼び出し内のコンマが括弧で囲まれているためです。
int foo (int, int, int);
struct Bar {
void method ( int j =
foo (0, 0, 0) ); // Comma's here are inside ( )
};
したがって、式の構文のみを使用してこれを解析することが可能です。C ++では、すべての'('は')'と一致する必要があるため、これは簡単に解析できます。ここで問題が発生する理由は、「<」はC ++でオーバーロードされているため、一致する必要がないため、より小さい演算子またはテンプレート引数リストの先頭になる可能性があるためです。次の例は、デフォルトの引数で「<」が使用されている場所を示しており、より小さい演算子を意味します。
template<int I, int J>
class Foo { };
struct Bar {
template <typename T> struct Y { };
void method ( ::Foo<0,0> const& stuff = Foo<10 , Y < int > = Y<int>() );
struct X {
::Foo<0, 0> operator< (int);
};
static X Foo;
};
上記の「Foo<10」は、「X」で定義された「operator <」の呼び出しであり、テンプレート引数リストの先頭ではありません。繰り返しますが、Comeauは上記のコードで構文エラーを生成し、g ++(3.2.3を含む)はこれを正しく解析します。
参考までに、適切な参照は8.3.6/5の注記です。
[注:メンバー関数宣言では、デフォルトの引数式の名前は3.4.1で説明されているように検索されます。
そして3.4.1/8で
関数のdeclaratorid29)に続くクラスXのメンバー関数(9.3)の定義で使用される名前は、次のいずれかの方法で宣言する必要があります。
..。
—クラスXのメンバーであるか、X(10.2)の基本クラスのメンバーであるか、または
ここでのこの箇条書きは、すべてのクラスメンバーが宣言されるまで、コンパイラにデフォルト引数の意味のルックアップを「遅延」させる部分です。
<更新>
「EmployedRussian」で指摘されているように、g++4.4はこれらすべての例を解析できるようになりました。ただし、DRがC ++標準委員会によって対処されるまで、私はこれを「バグ」と呼ぶ準備ができていません。他のコンパイラ/ツール(そしておそらくg ++の将来のバージョン)への移植性を確保するために、長期的な追加の括弧が必要になると思います。
私の経験では、C ++標準では、コンパイラベンダーはすべて同じパーサーテクノロジを使用する必要があり、すべてのテクノロジが同等に強力であるとは期待できません。その結果、解析要件では通常、ベンダーが超人的な偉業を実行する必要はありません。これを説明するために、次の2つの例を検討してください。
typedef T::TYPE TYPE;
T::TYPE t;
「T」が依存している場合、各コンテキストで「TYPE」はタイプ名である必要がありますが、標準では引き続きtypenameキーワードが必要です。これらの例は明確であり、1つのことしか意味しませんが、標準(すべてのパーサーテクノロジーを可能にするため)では、typenameキーワードが必要です。
これらの例の解析に失敗したコンパイラが、追加の括弧でコードの解析が可能である限り、「標準準拠」であるようにDRがアドレス指定される可能性があります。
</ UPDATE>