東方算程譚

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

記事カテゴリ

書庫

日記カテゴリ

VB嫌い [1]

手始めに毎度おなじみCounterをこしらえる。

CounterのInterface:IObservableCounterとそれをImplementsしたCounterModelを作る。これはよし。
Coutnerの見てくれCounterView(Form)を作る。これもよし。
CounterViewにIObservableCounterなメンバ:model_を追加。よしよし。

これでぢゅんびおっけぃ。
ViewをNewしてModelをNewして二つを繋いでApplication.Run(びゅー)すりゃ出来上がりだ。

…… Sub Main() はどこでぃすか!?

アプリの初期化はどこでやるですか?
まさかとは思うがForm-Loadイベントで、ですか?
そんな愚かしいコトさせますか?

VBくんってばことごとく僕の常識を打ち砕いてくれます orz

投稿日時 : 2006年11月17日 11:58

コメントを追加

# re: VB嫌い [1] 2006/11/17 12:13 じゃんぬ

非難する前にプロジェクトのプロパティを見ましょう。

# re: VB嫌い [1] 2006/11/17 12:20 επιστημη

ごめんなさい、プロジェクトプロパティ見てもSub Main()の在り処がわかんなかったのです。

# re: VB嫌い [1] 2006/11/17 12:37 επιστημη

あー、非難してるように読めますね...すんません。
いやね、C#にしろC++にしろ、すべてがソースとして現れるやないですか。
スタートアップコードもちゃんとそこにあるから、それいじくればおっけぃですよ。
で、VBはっつーと、ないのよ。僕の常識から外れてるのは確かなのです。

# re: VB嫌い [1] 2006/11/17 13:19 じゃんぬ

1. [アプリケーション フレームワークを有効にする] のチェックを外す。
2. スタートアップ オブジェクトに Sub Main が加わる。

# re: VB嫌い [1] 2006/11/17 13:28 επιστημη

ホントだー。
で、Sub Main が加わったけど、そのコードはどこにあるんでしょか?

# re: VB嫌い [1] 2006/11/17 13:47 恣意の

VBがどんな構造になっているが知りませんが

はじめてMFCを触ったときに
「WinMainはどこ(゚Д゚;≡;゚д゚)」
と自動生成されたソースを探していたのを思い出したw

# re: VB嫌い [1] 2006/11/17 13:51 επιστημη

そそそ。それそれ。
WinMain見つかんないもんだからMFCのソースにgrepかけたよー。
XXXApp::InitInstance/ExitInstanceで初期化/後始末できるんだけど、VBは? って状態です。

# re: VB嫌い [1] 2006/11/17 14:44 じゃんぬ

Sub Main は自分で書く。
C# にならえば、Program という静的クラスでも作ってそこに書く。

# re: VB嫌い [1] 2006/11/17 16:27 επιστημη

うー、やっぱり(今んとこ)嫌い。
スタートアップのデフォルトがFormなんてありえねーです僕的には。

要するに「Sub Main()はどこでぃすか?」の答は
「ありません/作んなさい」だったわけね。
別に見えなくてもいいのよ、アプリの初期化/後始末をどこに書くのか明らかならば。
言い換えれば、それがはっきりしてないなんて嫌い。

1. [アプリケーション フレームワークを有効にする] のチェックを外す。
2. スタートアップ オブジェクトに Sub Main が加わるので、それを選択。
3. Program という静的クラスでも作ってそこにSub Mainを書く。

これってVB界では"常識"なんですか? いやなんせVBオンチなもので。
# んなもん、ハナっからそんな雛型吐いてくれたらえぇやないのん。

言語仕様そのものにはさほどの不満はないみたい。
気に入らないのはIDEなどの取り巻き連中による"小さな親切/大きなお世話"なのかな。

「ルート名前空間がコードに現れないってどーゆーつもりよ!」とかも。

# re: VB嫌い [1] 2006/11/17 16:36 じゃんぬ

初期値がそうなっているのは、そういう言語だからというだけです。
設定さえ変えれば、柔軟に対応できる言語なので、それだけで嫌いになる方が難しいですね。

VB6 以前だったら話は別なんですけど。

# re: VB嫌い [1] 2006/11/17 16:37 じゃんぬ

> # んなもん、ハナっからそんな雛型吐いてくれたらえぇやないのん。

雛形を作っておけばいいんじゃないでしょうか。

> 「ルート名前空間がコードに現れないってどーゆーつもりよ!」とかも。

これも、書けばいいんじゃないでしょうか。
ルート名前空間という意味では、C# でも同じことができますけどね。

# re: VB嫌い [1] 2006/11/17 17:02 επιστημη

じゃんぬさんの仰ること、ごもっともです。

僕が気にしているのは「誰もが簡単にその答にたどりつけるか」なんですよ(実際僕にはわかんなかった「プロパティ見ろ」だけでは)。
そうでないとアプリの初期化やりたいとなると、安直にForm_Loadの中でやっちまうんじゃないか、と。

なんかね、VB6な人達に敷居を低くせんがため必要以上にVB6っぽくしてるように思えてならない。
商業的にはそれでいいのだろうけど、僕はそこが嫌いです。

# re: VB嫌い [1] 2006/11/17 17:22 R・田中一郎

僕のブログでも、似たような話題がありました。

http://blogs.wankuma.com/rti/archive/2006/11/06/43835.aspx

とさり気なく URL を落として宣伝していくテスト^^;

# re: VB嫌い [1] 2006/11/17 17:42 επιστημη

あー、VB6の流儀なのか > Form_Loadで前準備

VB6をはじめとする VBnotNET が嫌いだったわけで、
それに歩み寄ろうとしている VB.NET に"なんだかなー"と感じるのも無理ないのかな。

でもいいこと教えてもらいました。
じゃんぬさん、ありがとです。

# re: VB嫌い [1] 2006/11/17 17:59 R・田中一郎

VB出始め頃って、イベントドリブンとか言って、コードはイベント内に書くもんなんだよー、という感じでした。

これを見て、Windowsのアプリケーションって、Windows のサブルーチンを書くイメージなのかなー、なんて思った頃が懐かしい(遠い目)

僕がまだピチピチだった頃w

# re: VB嫌い [1] 2006/11/19 10:54 じゃんぬ

えぴさんの言わんとしていることはわかっているのですが、
VB には VB なりの特性があって、それがえぴさんに合っていないに尽きると思います。

でも、今の VB って C# と大差ないですよ。
VB の常識が、自分の想定を超えるというのはあるでしょう。
しかし、VB が好きな人からみると、C++ は想定を超えているという感想を持つでしょうね。
所詮、慣れだとかその程度のものですよ。いまや。

ちなみに、私はどの言語も適当にやっているので、
言語が変わってもあまり違和感なく組めています。
あーでも、最近、C で静的ライブラリ書いたとき、
LPBYTE と LPLONG あたりの取り扱いを間違えそうになりましたね。
やばいやばい。

# re: VB嫌い [1] 2006/11/19 11:12 επιστημη

> えぴさんの言わんとしていることはわかっているのですが、
> VB には VB なりの特性があって、それがえぴさんに合っていないに尽きると思います。

そうですその通りです。
だから"VBダメ"じゃなく"VB嫌い"って看板なの。

> でも、今の VB って C# と大差ないですよ。

これにも同意。VB.NETの"言語自体"はよくできてると思う。

# re: VB嫌い [1] 2006/11/19 16:24 じゃんぬ

嫌いというレベルにしても、

> まさかとは思うがForm-Loadイベントで、ですか?
> そんな[b]愚かしいコト[/b]させますか?

こりは過激に見えたわけで、実際アンマッチーじゃないっすか?

# re: VB嫌い [1] 2006/11/19 23:57 επιστημη

過激ですねぇ ^^;
とはいえ下策であるのは否めない。
舞台の幕があがってから大道具を運び込むよなもんで、
そりゃ順序が逆だろ! って。

# re: VB嫌い [1] 2006/11/20 11:42 じゃんぬ

下策に見えてしまうのは、私たちがデベロッパーだからです。
たとえば、今回の場合、どうしてもエントリ ポイントというのを意識しないという概念的な互換があるのですね。

ただ、プロジェクトのプロパティは確かにわかりにくいと思います。
あれは、VB プログラマにしてみても変えて欲しいところでしょうね。

# re: VB嫌い [1] 2006/11/28 10:10 シャノン

普段から拝見してないので(失礼)、古い記事にレスつけさせてもらいます。

> スタートアップのデフォルトがFormなんてありえねーです僕的には。

俺的にはもっと突っ込んでありえねーです。
なんで Application クラスが System.Windows.Forms 名前空間にあるですか?
なんで Application.Run が Form を引数にとりますか?
だから俺はどんな小規模なアプリでも、Application.Run は ApplicationContext を引数に取るほうに書き換えます。

これはもっと突っ込んで言っちゃうと .Net Framework の域を超えちゃって、なんで Win32 アプリはウィンドウとメッセージキューが密接に関連していやがりますか? ってところに行っちゃう。
(昔の Windows がどうだったかは知らないけれど)メッセージキューはスレッドに関連づくものだと思うの。
その点では CWinApp が CWinThread から派生していた MFC が好ましい。

# re: VB嫌い [1] 2006/11/28 21:57 επιστημη

> なんで Application クラスが System.Windows.Forms 名前空間にあるですか?

あー、うん。それは僕も常日頃から感じてた。
なーにが哀しうてApplicationがForm族なのよー

> どんな小規模なアプリでも、Application.Run は ApplicationContext を引数に取るほうに書き換えます。

これ、ちょっとサンプル見せてもらえませんか?

# アプリケーション・エントリポイント 2006/11/29 23:18 東方算程譚

アプリケーション・エントリポイント

# スプラッシュスクリーンに物申す 2007/01/11 9:55 .COM -どっとこむ-

スプラッシュスクリーンに物申す

# You have the monopoly on useufl information-aren't monopolies illegal? ;) 2012/01/28 19:37 Lonitra

You have the monopoly on useufl information-aren't monopolies illegal? ;)

# You have the monopoly on useufl information-aren't monopolies illegal? ;) 2012/01/28 19:37 Lonitra

You have the monopoly on useufl information-aren't monopolies illegal? ;)

# You have the monopoly on useufl information-aren't monopolies illegal? ;) 2012/01/28 19:37 Lonitra

You have the monopoly on useufl information-aren't monopolies illegal? ;)

タイトル  
名前  
URL
コメント