問題タブ [implicit-conversion]

Scala 2.8の仕様はセクション7.3で述べています（強調表示は私のものです）：

暗黙的なパラメーターとメソッドは、ビューと呼ばれる暗黙的な変換を定義することもできます。タイプSからタイプTへのビューは、関数タイプS => Tまたは（=> S）=> Tを持つ暗黙の値、またはそのタイプの値に変換可能なメソッドによって定義されます。ビューは2つの状況で適用されます。

1. 式eがタイプTであり、Tが式の予想されるタイプptに準拠していない場合。この場合、eに適用可能で、結果タイプがptに準拠する暗黙のvが検索されます。検索は、暗黙のパラメータの場合と同じように進行します。ここで、暗黙のスコープはT=>ptのいずれかです。そのようなビューが見つかった場合、式eはv（e）に変換されます。

[...]

上記および以下の事実を前提としています。

1. Longのサブタイプではありませんjava.lang.Comparable[Long]。つまり、次のタイプに準拠していませんT。T <: java.lang.Comaparable[Long]
2. Predef含むimplicit def longWrapper (x: Long) : RichLong
3. RichLongのサブタイプですjava.lang.Comparable[Long]。つまり、次のタイプに準拠します。TT <: java.lang.Comaparable[Long]

Longが検出され、のサブタイプが期待される場所に暗黙の変換が適用されることを期待しjava.lang.Comparable[Long]ます。でも：

値が明示的に変換された場合、結果は期待どおりです。

変換関数が暗黙的に適用されないのはなぜですか？

私はLINQPadでいくつかのコードゴルフを見ていて、なぜだろうと思っています：

主に、最初のものが機能し、2番目のものが「'string'と'int'の間の暗黙の変換なし」エラーをスローする理由。

INT タイプの ID フィールドを持つテーブルがあります。

私はいくつかのデータ検証を行っており、それに気づきました

と

完全に機能しますが、使用すると

それは私に同じ結果を与えました！これはどのように可能ですか？

セクション 6.1 Implicit conversionsでは、恒等変換を次のように定義しています。

ID 変換は、任意の型から同じ型に変換します。この変換は、必要な型を既に持っているエンティティがその型に変換可能であると言えるように存在します。

では、このような文の目的は何でしょうか?

(§6.1.6 暗黙の参照変換で)

暗黙の参照変換は次のとおりです。

• [...]
• 任意の参照型から参照 T型への暗黙的な ID または参照型 T₀への参照変換があり、T₀に への ID 変換がある場合T。

と：

(§6.1.7 ボクシング変換で)

• 値型は、インターフェイス型₀Iへのボックス化変換があり、0 が への ID 変換を持っている場合、_{インターフェイス}型へのボックス化変換を持ちます。III

最初は冗長に見えます (トートロガス)。しかし、彼らは目的のためにそこにいるに違いないのに、なぜ彼らはそこにいるのでしょうか?

上記の段落がなければ、 ₁が暗黙的に_2に変換できないような2 つのタイプT₁、T₂の例を挙げていただけますか?TT

これをコンパイルしようとすると、次のエラーが発生します。

Btree.scala:9: エラー: パラメータの順序付けの暗黙的な値が見つかりませんでした: Ordering[K] 抽象クラス Node[K,V] extends TreeMap[K,V]

TreeMap は、私が提供する暗黙の Ordering[A] val を受け入れることになっています。おそらく、暗黙のパラメーターは、Btree(TreeMap) がインスタンス化されるオブジェクト Tester にある必要がありますか? Ordering に Comparable[K] を実装する型 K を持たせたいので、暗黙の宣言を Btree クラス内に保持することをお勧めします。わかる？

私はちょうどこのコード行に出くわしました：

ここで、をlength2返しますdouble。NULL0.0が0、、、および/またはに相当するのはちょっと困惑しますfalse。

これはC++標準の一部ですか、それとも未定義の動作ですか？

次のような暗黙の演算子を使用することに何か問題がありますか？

このようにオブジェクトのインスタンスを値型として扱うことができると思っていたのですが、この例を見たことがないので、誰かが指摘できるようなことをしない理由があるのではないかと思いました。

私の実際のコードでは、これをデータ抽象化レイヤーの一部として実行することを考えていました。これにより、基になるデータを説明する情報を含むオブジェクトを返すことができますが、ロジックコードは、必要なときにそれを値型として扱うことができます。は値であり、同時にすべてを適切に保ち、ジェネリックスでタイプセーフにします。

Scala が以下を最適化できない理由:

を。

に：

b.

?

この場合、なぜ構造型付けを使用する必要があるのでしょうか? スタイルbでの記述はあまりにも醜いため (1. ロジックの局所性が失われ、2. これらの追加の明示的なクラスの名前を不必要に考案する必要があるため)、aははるかにパフォーマンスが低いため、 Scala コンパイラーにこの最適化を実行してもらいたいと思います。 bよりも。

私が尋ねた最後の質問は、別のことを理解しようとしたときにつまずいたものでした... 私も理解できません（私の日ではありません）。

これは非常に長い質問文ですが、少なくとも、この質問が私だけでなく多くの人に役立つことを願っています.

私が持っているコードは次のとおりです。

式 1 と 3 は完全に機能しますが、式 2 はコンパイルされません。

私が正しく理解していれば、何が起こるか：

式1

1. cはconst、標準の変換シーケンス (修飾変換が 1 つだけで構成される) を使用して暗黙的に変換されます。
2. V<float>(const S<T> & s)が呼び出され、オブジェクトが生成したテンポラルが生成されます (これをtconst V<float>と呼びましょう)。これは一時的な値であるため、すでに const 修飾されています。
3. aはcと同様に const に変換されます。
4. operator+(const V<float> & a, const V<float> & b)が呼び出され、 qconst V<float>と呼べるタイプのテンポラルが生成されます。
5. デフォルトV<float>::operator=(const & V<float>)は呼び出されます。

私はここまで大丈夫ですか？私が最も微妙な間違いを犯した場合でも、私に知らせてください.暗黙のキャストについてできるだけ深く理解しようとしています...

式 3

1. cは に変換されV<float>ます。そのために、ユーザー定義の変換シーケンスがあります:
   1.1. 最初の標準変換:修飾変換S<float>を介して。 1.2. ユーザー定義の変換:コンストラクター経由。 1.3秒基準換算：経由資格換算へ。const S<float>
const S<float>V<float>V<float>(const S<T> & s)
V<float>const V<float>
2. デフォルトV<float>::operator=(const & V<float>)は呼び出されます。

式2？

私が理解していないのは、なぜ 2 番目の式に問題があるのか​​ということです。次のシーケンスができないのはなぜですか?

1. cは に変換されV<float>ます。そのために、ユーザー定義の変換シーケンスがあります:
   1.1. 初期標準変換:修飾変換S<float>を介して。 1.2. ユーザー定義の変換:コンストラクター経由。 1.3。最終標準変換:資格変換 を介して。const S<float>
const S<float>V<float>V<float>(const S<T> & s)
V<float>const V<float>
2. 手順 2 ～ 6 は式 1 の場合と同じです。

C++ 標準を読んだ後、私は次のように言いました。おそらく問題は 13.3.3.1.2.3 に関係しています! どの州：

ユーザー定義の変換がテンプレート変換関数によって指定されている場合、2 番目の標準変換シーケンスは完全一致ランクでなければなりません。

しかし、資格変換には完全一致ランクがあるため、それは当てはまりません...

本当に手がかりがない...

さて、あなたが答えを持っているかどうかにかかわらず、ここまで読んでくれてありがとう:)

ISO/IEC 14882、プログラミング言語 – C++をよく読んだ後const、次のような単一の引数コンストラクターを持つユーザー定義型への暗黙的な変換が必要な理由はまだわかりません

セクション 4 ライン 3 から開始

宣言 T t=e; の場合にのみ、式 e を暗黙的に型 T に変換できます。いくつかの発明された一時変数 t (8.5) に対して、整形式です。特定の言語構造では、式をブール値に変換する必要があります。そのような文脈で現れる式 e は、文脈上 bool に変換されると言われ、宣言が bool t(e); である場合にのみ整形式です。いくつかの発明された一時変数 t (8.5) に対して、整形式です。どちらの暗黙的な変換の効果も、宣言と初期化を実行し、変換の結果として一時変数を使用することと同じです。T が左辺値参照型 (8.3.2) の場合、結果は左辺値であり、それ以外の場合は右辺値です。式 e は、初期化で左辺値として使用される場合に限り、左辺値として使用されます。

その後、8.5 行 6 でユーザー定義型に関連する初期化子に関するセクションを見つけました。

プログラムが const 修飾された型 T のオブジェクトの既定の初期化を呼び出す場合、T は、ユーザー提供の既定のコンストラクターを持つクラス型でなければなりません。

最後に、ユーザー定義の変換について 12.3 行 2 で終了しました。

ユーザー定義の変換は、明確な場合にのみ適用されます (10.2、12.3.2)。

言うまでもなく、10.2 と 12.3.2 は私の質問に答えませんでした。

1. const暗黙の変換にどのような影響があるかについて、誰かが光を当てることができますか?
2. を使用するとconst、12.3 行 2 ごとに変換が「明確」になりますか?
3. constセクション 4 で説明した左辺値と右辺値に何らかの影響がありますか?