Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

ForLoopの挙動は、VBとC#では異なる

「プログラマは言語に拘るな」から「複数の言語を知った方がいいよ」にトーンダウンしました。(諸般の事情により..って単なる変節なんですがwww)
開発者が「バグだバクだ」と騒いでいました。
ループ回数が、想定したように回らないそうです。

For 初期 to 終了
    処理
next

単純なLoop....バグる要素も無い位です。
「Loopか、10回しか回らないのはバグだ」と言うのです。よくみたら、Loop内で、終了判定の値を更新している。 (実際は DBから取得した結果の値で変えているのですが)
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim max As Integer = 10
        For i As Integer = 0 To max
        For i As integer = 0 To max - 1
        If i = 5 Then max = 40
            Debug.Print("i=" + i.ToString())
        Next
    End Sub

バグ以前の問題として、Loop内で終了条件を触る設計は不作法でダメジャンと思います。がそこは目を瞑るとして。
終了条件の評価のタイミングを誤解しているようです。 VBのFor文は、Loop最初に終了値が評価され、確定されます。よって10回しか回りません。
しかしC#では、終了条件の判定は、Loopの度にされます。よって40回回ります。
   int max = 10;
   for (int i = 0; i < max; i++)
   {
       if (i == 5) max = 40;
       Console.WriteLine(i.ToString() + ":max:" + max.ToString());
   }
バグではなく、言語仕様です、Loop処理は言語の基本要件なのですが、挙動に差があるので、このような、終了条件の操作は、すべきでないと思ってます。
上記のような単純なソースの場合、バグだと騒ぐのではなく、動作確認して、挙動差を、確認して欲しいものです。
この特性を生かして(?)意図時にトリッキーなコーディングする局面もありすが、業務アプリでは不可としてます。

確認用のサンプルを 試行部屋につくりました。

http://www.ognogn.com/KOMONO/COMPILE/VB_AND_CS.aspx?Loop_ForLoop_EndEval

投稿日時 : 2008年9月10日 0:57

Feedback

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 1:33 出水

本件とは横筋になりますが…
VBは0~10の11回ループするんじゃなかったかしら

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 2:39 Pasie.

 仰るとおり、作法の問題と動作確認の問題ですね。まあ悩むのはよいことなんじゃないでしょうか。
 ところでFor~Nextの挙動はBasic系内でも異なったりしますよね。例としては、
 For i=1 To 0
  logic()
 Next
とあったとき、logic()が実行されるかどうかは処理系によって変わります。最近実装されているものは実行されないケースが多いですが、古典的なインタプリタだと実行されることが多かったように記憶しています。

 ところで私は以下のコードがすばらしいと思うものの大嫌いです。
 > while (*d++ = *s++); // strcpy(d,s)
 > for (;;)
 こういうコードが礼賛された結果としての、今回のネスト内終了判定値変更なんでしょうね。whileで処理すべきです。Cの罪の部分だと思います。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 8:19 Ognac

>VBは0~10の11回ループするんじゃなかったかしら
あ! そうです。 max - 1 は定石ですね.....orz

>処理系によって変わります
処理系依存という意識がなかったりしますね。
>while (*d++ = *s++);
私も、美しいと思ってましたが。業務系がメインになってからは、疑問ですね。 Perlもなんですがwwww。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 8:29 れい

> バグ以前の問題として、Loop内で終了条件を触る設計は不作法でダメジャンと思います。

もうぜんぜんアリ。
終了条件は触りまくりですし、
中にif+break入れる場合も当然あります。

ポリシーは無し。

・手がどう打つか、
・どう書いたらわかりやすいか、
・どう書いたら実行速度が速くなるか、

それらの兼ね合いで決めます。

> Loop処理は言語の基本要件なのですが、挙動に差があるので、このような、終了条件の操作は、すべきでないと思ってます。

全然思いません。

言語間で差異があるのは当然で、他にもたくさんあります。
すべての言語の共通項だけでプログラミングすべき、なんていうのはナンセンスというか、不可能です。

なら、なぜLoopだけなぜ共通の振る舞いにしなけれいけないのかを説明しなければ論拠になりません。

基本的だからとするなら、基本的なものが全く同じであるべきだと思う発想が理解できません。

> ところで私は以下のコードがすばらしいと思うものの大嫌いです。

これもアリ。アリアリ。

> こういうコードが礼賛された結果としての

礼も賛もしませんが、これも上記3項目の兼ね合いで、平気で使います。
罪だとは全く思いません。

そんな節操無しの私ですが、コードが読みにくいと言われたことはありません。

なにしろ見せることが殆どないですから!
(ひとりぼっち。ショボン

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 10:29 シャノン

> VBのFor文は、Loop最初に終了値が評価され、確定されます。よって10回しか回りません。

知りませんでしたorz

> ところで私は以下のコードがすばらしいと思うものの大嫌いです。

同じくー!

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 11:43 Ognac

>中にif+break入れる場合も当然あります。
これはOKかな

>どう書いたら実行速度が速くなるか、
>すべての言語の共通項だけでプログラミングすべき、なんていうのはナンセンスというか、不可能です。
>基本的だからとするなら、基本的なものが全く同じであるべきだと思う発想が理解できません。

難しいなぁ。
業務アプリを手がける以前は、外部IOや制御絡みの仕事の影響からか、可読性よりも、1msecでも1CPUサイクルでも早いほうが、良いと思ってました。
その分野では、通じる論理のようです。
一般的な複数の人の塊が関わる業務アプリではソースの可読性が重要視されるのは周知の通りです。処理時間1秒が1.5秒になっても、可読性を優先するプロジェクトもあります。
業務設計者の視点からみると、コーディング言語は不問で、ロジックが明確であれば良いとされます。
実装言語によって、処理ロジックが変わると困るとされます。ForLoopは業務ロジックでなく、実装問題だ...との見方もできますが。
C系アプリ、C++系のアプリ、Cobol系のアプリのように、言語によってアプリケーションのが作り方や外枠がが決まる分野があります。
一方で.Net.Framework系だと、FrameWorkwでアプリケーションの外枠が決まります。こ分野たと、C#/VBは独立した言語でなく、一つの方言にならないでしょうか。

 処理ロジックは言語依存か、言語不問か
 可読性維持は開発者範囲か保守要員の範囲か
 速度と実行効率アップのためのトリッキーなコーディンの可否
それぞれの立場でコーディング作法の定義は異なり、相反する主張も出てきます。
現在私は、業務アプリ開発者で、完成後は、保守要員にソースを引き継いで、現場を去ります。そのため、業務的な可読性を第一にしています。
業務的な可読性としたのは、言語レベルの可読性が一致しないことも指摘されるからです。

.net.Frameworkの仕様として、日本語(マルチバイト)変数・関数名の使用を許しているのに、禁止するのはへんである。「使わせろ」と主張してます。
これは、「言語仕様として、終端値の変更を認めているのだから、禁止するのはヘン」と自己矛盾してますね。
でもね。(以前CUKIさんが指摘されたように) 「Loop 内に外から goto文で入るのを許してる」のをOKとするのは抵抗あります。
自分の判断基準もアヤフヤな面がありますね。お作法も個人主観に左右されそうだし。

>while (*d++ = *s++); 
私は「当然のスタイル」と思います。が、対面したことのない(スキルを伴わないかも知れない)保守要員にソースを渡すことを考えると躊躇します。
後日「ワカランコードを書きやがって」と批判されているのを聞くと尚更です。......これって保身に走ってますね。開発者の意地が見えないなぁ。....orz;
でも、保守のしやすさからみると、保守し難いのは、アプリ全体としてはマイナスだと思うのです。

こう考えてくると、関係者全体のスキル問題に行き着くのでは、ないでしょうか、OS差、言語さ、アプリケーションの性質の差を認識できれば、言語仕様の差は小さなことになります。
特定の人の開発分だけ、ピカピカに光っても、全体としてくすんでいると、価値が在ると評価されるか否かも評価者次第だし、「そんな特定の人は不要だ」という人もいるし..
でも、業界は逆方向に流れている....ああ....

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 12:34 uskz

可読性と言えばぼくとしてはループという構造そのものがちょっと苦痛なんですよね 笑
loop invariantや停止性を考慮しながらの形式的推論は面倒くさいし(そもそもこの辺考えて書かれたコードで無ければ証明なんて考えもしないし),indexが不要なら本来必要無い変数を導入するのも気持ち悪いし,必要でも整数のsequenceとzipすりゃ良いじゃんとか思っちゃう.

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 13:35 Pasie.

>・手がどう打つか、
>・どう書いたらわかりやすいか、
>・どう書いたら実行速度が速くなるか、
 十分ですよ。-_-; それが出来てないから以下略、という話なので、それだけ考えていればOKかと。

>すべての言語の共通項だけでプログラミングすべき、なんていうのはナンセンスというか、不可能です。
 これには全面的に同意です。
 ただ、while文がありながら無限ループにforを使うとか、まあCのイディオムなんでしょうが、言語非依存な考え方で十分対処できる問題については、わざわざユニークに走らなくてもよいのでは?とは思います。

>外部IOや制御絡みの仕事の影響からか、可読性よりも、1msecでも1CPUサイクルでも早いほうが、良いと思ってました。
 これは嘘だと思います。無条件に速いほうがよいに決まっています。可読性のために性能を犠牲にするというのはお客様に対する背任だと思います(極論-_-;)
 ただ"高速"を標榜して、実は速くもないコードを自己弁護するとかあるわけで。
 VBで言うと、MsgBoxよりもMessagebox.showのラッパーなので、Messagebox.showほうが"速い"からそちらを使うべきだとか言う割に、while内でRedim preserveを使っているとか。
 真摯に考えてコードをかけば可読性がよく速度も最適なコードができるはずです。その上でパフォーマンスが足らないならチューニングすればいい。でもそうしてチューニングしたコードは読みにくくは絶対になりません。読みにくいコードの共通点は考えていないこと、だと思っています。
 それが証拠にstrcpyのコードは美しい。Cの知識があれば読み解けるし速度も速い。理に適っています。たった一行ですがよく考えられたコードだと思います。しかし私は嫌いなんですね。4つの要素を一文に入れるというのは好きじゃない、一意一文にしたいというのが私のポリシーだからだったりするからですが。まあこれは個人的な話。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 16:18 Ognac

>可読性と言えばぼくとしてはループという構造そのものがちょっと苦痛なんですよね
新鮮な見方に感じました。そういう意見も面白いですね。

>言う割に、while内でRedim preserveを使っているとか。
一円二円を節約して、数千円の無駄使いをする人がいますね。
「stringはGCをおこしやすく遅いからStringBuilderを使え」と強制しているのを見かけますが、StringBuilderの生成コストを考慮してなかったりします。

>これは嘘だと思います。無条件に速いほうがよいに決まっています。可読性のために性能を犠牲にするというのはお客様に対する背任だと思います(極論-_-;)
れいさんやPasie.さんと話がかみ合わないのは、「誰にとっての可読性か」の気がします。
御主張ご尤も。可読性の判定視線が開発者視線なら、同じ思いです。
洗練されたコードは、コメントも不要なくらい読みやすい。処理の意味も掴めます。
しかし、判定視線が、保守要員も含めた全体の管理者視線だと、異なるようです。
長くなりますが、実例で補足。

Dim sw As Boolean = False
...(処理)
If sw then 処理

このように書くのが普通と思いますが、「読みにくい」と判定されます。「if sw = true then 処理 」に直されます。
その上に ' {swが正のとき処理をする。xxxがyyyの処理...}とコメントまで要求されます。
同様に i++; は読みにくく、 i = i + 1; が読みやすい..だとか。この感覚は伝え難いのですが、このような思考の人にとっては、速度と可読性は別次元のモノになります。

可読性保持のため 「一つの処理は一意に限定する」 というルールがあったりします。
「n行m列のマトリクスがあります。各行の総和と値が0の個数を求める」というのがあったとします。
(実際は 総和と個数の処理箇所に、業務処理が入るのですが)。
________With_"レビューNG"
___________Dim_n_As_Integer_=_10
___________Dim_m_As_Integer_=_10
____________Dim_data(n,_m)_As_Integer
____________'_.....data()格納処理...
____________For_r_As_Integer_=_0_To_n_-_1
________________Dim_sum_As_Integer_=_0
________________Dim_kosu_As_Integer_=_0
________________For_c_As_Integer_=_0_To_m_-_1
____________________sum_+=_data(r,_c)
____________________If_data(r,_c)_=_0_Then_kosu_+=_1
________________Next
________________Console.WriteLine("{0}行の和={1}_値0の個数={2}",_r,_sum,_kosu)
____________Next
________End_With

一回のLoopで解決するのが合理的.....可読性も速度も共に満たす....と主張したいし、そう書きたい
しかし、一処理一意に反するので「可読性に欠ける」とみなされ、レビューに落ちたりします。

________With_"レビューOK"
____________Dim_n_As_Integer_=_10
____________Dim_m_As_Integer_=_10
____________Dim_data(n,_m)_As_Integer
____________'_.....data()格納処理...
____________'行の和を求める
____________For_r_As_Integer_=_0_To_n_-_1
________________Dim_sum_As_Integer_=_0
________________For_c_As_Integer_=_0_To_m_-_1
____________________sum_+=_data(r,_c)
________________Next
________________Console.WriteLine("{0}行の和={1}_",_r,_sum)
____________Next
____________'要素0の個数を数える
____________For_r_As_Integer_=_0_To_n_-_1
________________Dim_kosu_As_Integer_=_0
________________For_c_As_Integer_=_0_To_m_-_1
____________________If_data(r,_c)_=_0_Then_kosu_+=_1
________________Next
________________Console.WriteLine("{0}行の和={1}_値0の個数={2}",_r,_sum,_kosu)
____________Next
________End_With
(インデントように半角blankを_で表現してます。)
For r のループを1回にし、 For c のループを二回連続したときの判定は聞いてません。(もう聞けないですが)
その人のプロジェクト思想では、こちらが可読性が高いとされています。
理由は、{言語に詳しくない人でも、コメントで処理の箇所が追いかけられ、保守がしやすいから]だそうです。
当初は、見る人が解ればよい」と考えていたのですが、「スキルが高くない、業界2~3年生がアプリケーションの保守をする」のが現実なので、プロジェクト事情も解ります。

製品性能の判定基準は、可読性と保守性という非デジタル要素(主観要素)が入ってくるので、職人視点だけでは、ダメだと...言われ続けてウン十年。
最初、違和感一杯だったのですが、慣れてしまった自分がいます。......orz.


# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 17:58 Pasie.

 読んだけど。
 レビューアが間違ってんじゃないの?
 レビューアの質の向上を要求します。に一票です。

>スキルが高くない、業界2~3年生がアプリケーションの保守をする
 かくてこんなカットペーストコードが正しいと教えるわけ?ってOgnacさんにあたっても仕方がないわけですが -_-;

 ところで私がこのコード(上)にいちゃもんをつけるとしたら変数名でしょうか。こんなかんじ。-_-
  n : rows(またはrowMax)
  m : columns(またはcolumnMax)
  r : rowCount
  c : columnCount
  sum : rowsSum
  kosu : isZeroRowCount
 n,m,r,cに対する認識が関係者で統一して使われていれば別にこれでもいいんですけどね。kosuは、工数?ああ個数?何の?とは思いましたが。
 なお、Console.WriteLineの箇所はデバッグ文と認定し仕様でないと判断しました。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 18:19 Pasie.

> このように書くのが普通と思いますが、「読みにくい」と判定されます。「if sw = true then 処理 」に直されます。

一方でこれ(右辺に論理値を記述)は私も指示します。
さらにコメントも…といいたいところですが、私は変数名の変更を要求します。SW = True、がなにを判定しているかわからないためです。SWは事象を述べる変数名であるべきだと思います。(例: isSignalGreen = True)
(どっちかというと、右辺Trueがないから、というよりは変数名が悪い、って気持ちの方がこの例では強いです)

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 20:25 Ognac


変数名の問題は、安直に記述したのでご容赦を、 boolean 変数は 「is_xxxxか has_xxxxを使いましょう」などとBlogでも書いてるように拘る方てす...保身を計っておいて。
1文字変数の可否は、それだけで、議論になりそうなので、今回はパスしてください。機会があればその時に。

変数名を充実させたら、コメントが少なくなる.........1票。
レビュアー/PJの向上が大事..........................1票。

愚痴モード。愚痴を聞いて下さい。こんな世界もあるんですよ。>Pasie.さん

>かくてこんなカットペーストコードが正しいと教えるわけ?
例は極端ですが、大きな括りでは、似たようなものです。クラスモジュール化するより、コピペして一部修正する指示が飛び交ったり。
追求すると。「クラスモジュールの作成工数を計上していない」と言われたり。

上記にも記したように、Pasie.さんが卒倒しそうな実情があるわけで。

・開発要員は書類審査や面接官のスキル不足の影響でレベル差が大きい
・2~3年生が保守する
 下を引き上げるのでなく、全体レベルを落として、開発を進める
・納品物の書類生成に、ソースドキュメントツールを使う。
その関係で、コメント書きを強制される。

これは、特異ケースでなく、ありがちなケースです。そこそこの規模で、プロマネが金融系のSIer要員だったら、要注意です。
違うエントリーで頂いたコメントのように「魔法じみた正規表現は使うな。」と真顔で言う人もいます。

開発者として見たら、とっても悲しいことです。
顧客に取って大事なのは、稼働後は業務要件通り動くこと。 開発工程は、開発計画通りこと。これは共通認識ですが。
彼らSIerの言い分は、個々のアプリソース品質は、動作が大事で(Blackテスト)。これもOK。
で、ソースの品質は、保守要員が認識できること。
開発チームの低スキル者を引き上げで、バグを誘発するよりも、高いスキル?のコードを避けるほうが安全・確実と考えているようです。
ソースの品質は、顧客にとっては「意味が薄い」とまで言う人もいます。

とっても愚痴モードになっちゃいましたが、こういう世界もあるということで。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 21:37 れい

> とっても愚痴モードになっちゃいましたが、こういう世界もあるということで。

大変ですねぇ

ループもろくに使えないんじゃDiffとかパターンマッチとかのコードみたらスパゲッティとか言われるんでしょうか。

アルゴリズムは既存のものを組み合わせて。
ループすら煩わしい。

というと、もう部品を組み合わせるだけで出来上がる彩色済みプラモデルな感覚ですね。

誰がやっても同じ。かかる時間も仕上がったものも。

それはつまり「人月」で数えられる職業、そうなるよう皆が望んでいるということですね。

良いとか悪いとかは議論するきは無いですが、一般に、普及というのはそういうものですよね。
「誰でも」「手軽に」。

#話は以前のエントリに戻りますが。

なら、今後Cがたどる未来も、推して知るべし、ということかと思いますが。
組み合わせることだけしかしようとしない人が、安全にCを使えるようになる時代は来ないですよ。
そーゆー言語じゃないですから。

> 「使えるけれど、仕組みは知らない」的な開発者の増加は健全な将来像とは思えないのですが.

> 挙動に差があるので、このような、終了条件の操作は、すべきでないと思ってます。

この辺に、ずいぶん温度差がありますよね。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/10 22:22 れい

あーそうそう。Pasieさんに反論。

> 真摯に考えてコードをかけば可読性がよく速度も最適なコードができるはずです。

そうじゃないと思いますよ。

悪いコードを作ってしまう理由は様々です。
論理が組み立てられない人、可読性を勘違いしている人、そもそも考えることが出来ない人など、いろいろです。
真摯に考えても出来ない人もいます。

出来ないことを括れる言葉は唯一「出来ない」です。

「真摯に考えていない」と括っては横暴です。

> でもそうしてチューニングしたコードは読みにくくは絶対になりません。

そんなことないです。

> 読みにくいコードの共通点は考えていないこと、だと思っています。

Perlのマッチング部分のコードなんか、よくよく考えられてますがかなり読みにくいですよ。

「何を」考えていないのか、そこが重要です。
考えるべき点はたくさんあります。
相反するものもたくさんありますし、時間は有限です。

問題は「何を重要視するか」です。

たいていの出来ない人はそれを間違っているだけです。

とりあえず今仕上げることだけを重要視したり、
言語間の差異を意識しすぎていたり、
変数名の英語がわからなくて辞書引いていたり、
定時退社を重要視しすぎたり、
冷蔵庫のpinoの融け具合が気になったり。

出来ないことや出来ることの責任を「努力」とか「真摯さ」といったものに押し付けるのは横暴です。
蔑視に近いですよ。

> それが証拠にstrcpyのコードは美しい。

それはたまたまうまくいっている例でしょう。

よくよく考えられていて、且つ読みづらいもの。
チューニングされていて、且つ読みづらいもの。
両者とも敢えてあげるまでもないほど数があると思います。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/11 1:53 Pasie.

 れいさんの意見に対する反論はないです。

 一応言い訳しておくと、上記の私の意見は多分に精神論が含まれるのは事実です。言いたかったことは、
 (1) 速度を言い訳に読みやすさを犠牲にしたり、読みやすさを理由に速度を犠牲にしたりするのはどうか?
 (2) 要件(pinoの融け具合を含む)を相互的に検討したときに、真摯にそれに向かい合っていれば最適解はあるはず
 といったことで、普遍的な読みやすさとか速度とかを意識していたわけではなく、帰属する集団の中でのローカルな読みやすさなり速度なりを求めた結果を書いたつもりです。そういうことを意識して仕事をしているという意味を真摯と表現しました。

 しかしこの手の議論、場の設定が難しいですね。読みやすさとか高速の定義も人それぞれ違うわけだし当然ではあるんですが。

 とりあえず冷凍庫のpinoは残り一個(アーモンド味)なのでこれからかたづけようと思います。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/11 1:57 Ognac

>> 「使えるけれど、仕組みは知らない」的な開発者の増加は健全な将来像とは思えないのですが.
>> 挙動に差があるので、このような、終了条件の操作は、すべきでないと思ってます。
>この辺に、ずいぶん温度差がありますよね。
私のなかでも、矛盾する事なんですが、一人の開発者として、納得出来るコードを書く、しかし、ビジネスとしては「要求される品質で納品する」「言語による動作の違いと仕組みを知った上で、共通項で作る」ですかね。
処世術化して、狡いのですが、飯の確保も重要なので....orz;

> 真摯に考えてコードをかけば可読性がよく速度も最適なコードができるはずです。
お二人がが仰る通り、「ある程度の力を持つ人」が前提ですよね。この前提が崩れがちなのが実体で....

伝統芸能のように、「型を積み木で積み上げるシステム」で業務要件が満たされのも現実で....そこに、C/C++のスキルが発揮できる隙間が小さくなるのも事実。
業務アプリの世界は、どんどん孤立化していく希ガス。
だからといって、「C/C++の開発者を制約すべし」とはならないし、してはいけないと思うのです。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/11 21:08 れい

> とりあえず冷凍庫のpinoは残り一個(アーモンド味)なのでこれからかたづけようと思います。

もう1週間もpino断ちしてるのに。
ずるいですね。

> 私のなかでも、矛盾する事なんですが、一人の開発者として、納得出来るコードを書く、しかし、ビジネスとしては「要求される品質で納品する」「言語による動作の違いと仕組みを知った上で、共通項で作る」ですかね。
> 処世術化して、狡いのですが、飯の確保も重要なので....orz;

こっちはずるいとは思いません。
飯は確保しないと死にますから。

> しかしこの手の議論、場の設定が難しいですね。

そうですね。
自分の経験が大きなウェイトを占めてしまうので。

「自分の業務」を仮定すると「共通項で作る」と言い、
自分の業務でないC/C++は「制約すべきでない」と言う。

C/C++に対して「夢」が篭められてそうです。

同じことが他の人、他の場合にもいえますし、だからこそ人と話すのは楽しく有意義です。
Ognacさんの話や皆さん話は、私には違う常識、世界がみれて「ものめづらし」かったりします。

# re: ForLoopの挙動は、VBとC#では異なる 2008/09/13 12:16 Pasie.

>もう1週間もpino断ちしてるのに。

チョコアート補充しました。
おいしいですよ?(アーモンド味がよけいだが)

タイトル
名前
Url
コメント