東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

型推論っすかー

R・田中一郎タンが着火したと思しき型推論の使いどころ...悩ましいとこです。
匿名でないとシャレならんとこにはvar使え、これは同意です。

わかりきったとこならvarでもいぃんとちゃうの?
これについても同意っちゃー同意なんですけど、
僕がこだわるのがコンパイラの型推論が
プログラマの意図と一致しないことがあるなー、と。

var children = new List<Child>();
僕はおそらく、このテの(省略目的の)varは使わない気がします。
childrenはList<Child>でなくてはならないとは思っていない、
Child集合でありさえすればえぇのや、
ICollection<Child> children = new List<Child>();
なのよね僕のキモチ的には。

なんて場合でもコンパイラは
List<Child> children = new List<Child>();
だと推論しちゃうですよね。
# '型推論'ってコトバにも引っかかりを感じます。
#  文脈から導き出すんだろうから'型導出'じゃないかしらん

もひとつ。
for ( var i = 0; i < 10; ++i )
僕はこれも使わない(きっと)。
特に配列のindexなど、明確な目的を伴ってiを使うとき、
僕的にはiは(推論された型)intじゃなく符号のないuint(C/C++でのsize_t)
であって欲しいなーとか思うわけです。
# ClsCompliantじゃねぇじゃん!ってーツッコミもコメントにありますが、ともかくも
loop変数にただ回すだけ以上の意味があるなら型を意識したいと考えます。

コードから推論(だから導出だってーの)してくれるけど、
その結果とプログラマの思惑とは必ずしも一致しないよね。
ってことは心得ておかにゃなんねーかと思ってます。

[追記] んじゃ積極的に型推論を使うシチュエーションはあるんだろか、と。
これについても「プログラマの意図がより明確に伝わるなら」の条件に照らすでしょうね。

たとえば:
if ( x > y ) {
  var t = x;
  x = y;
  y = t;
}

「tはxの型に準ずる
って意図を表現しているんでこれはアリ(επι的に)。

投稿日時 : 2007年12月27日 14:29

コメントを追加

# re: 型推論っすかー 2007/12/27 14:37 シャノン

> 特に配列のindexとしてiを使うとき、僕的にはiは(推論された型)intじゃなく
> 符号のないuint(C/C++でのsize_t)であって欲しいなーとか思うわけです。

同意なんだけど、.NETではむやみに使うとClsCompliantじゃなくなっちゃうのよねー。

# re: 型推論っすかー 2007/12/27 14:38 とりこびと

>childrenはList<Child>でなくてはならないとは思っていない、
>Childの集合であればえぇのや、

激しく同意。
やっぱり引っかかるのはそこです。

# re: 型推論っすかー 2007/12/27 14:51 NyaRuRu

>childrenはList<Child>でなくてはならないとは思っていない、
>Childの集合であればえぇのや、

このあたりが関数型言語との大きな違いですかね.

let hoge = fuga
のような文を見たときに,
-これは代入ではなく変数束縛
-左辺は右辺の別名
-副作用はない
という思考法で読む関数型言語とはまた読み方の戦略が違うというのはあるかもしれません.
あっちの世界では,関数名に見えるものすら,単に関数の実体を束縛したものだったりしますからね.

# re: 型推論っすかー 2007/12/27 15:23 アキラ

エピさんに同意!

# re: 型推論っすかー 2007/12/27 15:36 R・田中一郎

for (var i = 0;
for (int i = 0;

に限れば、意図した結果なんですけどね。
同様に

List<Child> children = new List<Child>();

と書く人は var を使うかもしれないけれど、

ICollection<Child> children = new List<Child>();

と書く人は var は使わないでしょう。
この考え方については、僕も以下のようなコードでブログで触れています。

IDisposable d = new DataSet.HogeHoge();

そういう意味では、僕もエピさんに同意になるかと思います^^;

# re: 型推論っすかー 2007/12/27 15:44 とりこびと

Rさんの

>List<Child> children = new List<Child>();
>と書く人は var を使うかもしれないけれど、

Visual Basic なら

Dim children = new List(Of Child)
Dim children As new List(Of Child)

フフッハw

といっても「As」って書くと思いますけどw

# re: 型推論っすかー 2007/12/27 15:50 επιστημη

あそっか、unsignedで回したいなら
for ( var i = 0U;
ってか。
でもね...とソッチのコメントに書いてみた。

コンパイラが推論するのは構わんが、
血の通った人様に推論を強いるなよ、みたいな。

# re: 型推論っすかー 2007/12/27 16:23 凪瀬

人間にとってはコンパイラの推論をなぞるのが大変ですからねー。
ガチガチの静的型付けのほうが楽なんですよね。

# re: 型推論っすかー 2007/12/27 17:14 囚人

自分トコで書いたコメントをここにも投下。


ICollection<Child> children = new List<Child>();
で children の型は List<Child> だと、コードを書いている時点ではっきりしています。

敢えて宣言型と実装型を別にしても意味ないです。
それって実行時まで型が分からないって場合はメリットありますが、var はコードを書いているとき、そしてコンパイル時には型が分かっていないと駄目です。
なので、インターフェースやスーパークラスで型を宣言する事と var で型を宣言する事を並べて比較できません。それぞれ別用途です。

# re: 型推論っすかー 2007/12/27 17:24 じゃんぬねっと

フフッハw に釣られてやってきました。

私もεπιστημηさんにほぼ同意かな。
var がある今でも VB の As New は何かうらやましいのですね。

なんでだろ。

# re: 型推論っすかー 2007/12/27 17:30 シャノン

> で children の型は List<Child> だと、コードを書いている時点ではっきりしています。

List<child> であっても実害は無いんだけど、なんか気分的に嫌よねー。ねー。

ってことなのかと。

# re: 型推論っすかー 2007/12/27 17:51 επιστημη

> ICollection<Child> children = new List<Child>();
> で children の型は List<Child> だと、コードを書いている時点ではっきりしています。

ICollection<Child> children = ガキ共を連れてくる();

だったとき、メソッド"ガキ共を連れてくる”がどんな実装型を返そうがあたしゃICollection<Child>であること以外興味ないもんねー。

ってプログラマの思いが表せてる思うんよ。

同様に:

ICollection<Child> children = new List<Child>();

いっちゃん無難なList<Child>を使うけど、ICollection<Child>だったらなんでもいいのよぶっちゃけ。

ってゆー思いを以下省略。

# re: 型推論っすかー 2007/12/27 18:04 囚人

>ICollection<Child> children = ガキ共を連れてくる();

そういう場合
var children = ガキ共を連れてくる();
としたら、children は ICollection<Child> なわけですよね。

なので、var を使ったとしても、
「だったとき、メソッド"ガキ共を連れてくる”がどんな実装型を返そうがあたしゃICollection<Child>であること以外興味ないもんねー。」
に変わりないかと。

まぁ何度も言ってますが、こういう書き方したときに「人間が推論する必要があるかどうか」ですな。メソッドの戻り値を var で受けると「人間推論」が若干入るので、意見が分かれるトコ。

# re: 型推論っすかー 2007/12/27 18:14 NyaRuRu

>ICollection<Child> children = new List<Child>();

こっちの方が,なんか情報捨てていない感じがして好きです.
わざわざ情報捨てるより,呼び出し元に残っている情報は積極的に使いつつ,基本的にはインターフェイス相手にプログラミングできる,と.

static void foo<T, U>(T arg, U dummy) where T : ICollection<U>
{
  // T の具体的な型を利用できる
  // U の具体的な型を利用できる
  // T は ICollection<U> である
}
static void Main(string[] args)
{
  foo(new List<Child>(), default(Child));
}

# re: 型推論っすかー 2007/12/27 18:14 επιστημη

うんうん、「読み手の推論」が「書き手の思惑」と一致し、
かつ「読み手が書き手の思惑通りに推論するのが容易」ならvarで構わんです。

# re: 型推論っすかー 2007/12/27 18:15 NyaRuRu

こっち = 「コメントに書いたメソッドfoo」,ということで.

# re: 暗黙的型付け(その4) 2007/12/28 14:11 R.Tanaka.Ichiro's Blog

re: 暗黙的型付け(その4)

# re: 型推論っすかー 2007/12/28 15:53 Gushwell

「C#3.0:varの是非」

# [.NET]アップキャストと型推論に見る思想の違い 2008/03/09 20:50 NyaRuRuの日記

C++ でメソッドチェインが流行らなかったのは参照の寿命管理が厄介だったからじゃね? いやまあ適当に言ってみただけです気にしないで下さい.実は単に偶然の産物という気もします. struct Odd { int dummy; }; struct Even { int dummy; }; Odd ToOdd(Even&#38; source) {

タイトル  
名前  
URL
コメント