Borland Developer Studio 2006 No.10
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/10/31(火) 11:44:29Borland Developer Studio 2006 ユーザーのための統一雑談スレッドです。
Borland Developer Studio 2006 についての技術的な質問、不具合のQC 報告依頼も歓迎します。
（注）本スレには被害担当艦としての機能はありません。
Borland Developer Studio 2006 についての、批判・怒りのバグ告発はアンチスレ↓へどうぞ。
http://pc8.2ch.net/test/read.cgi/tech/1153353434/
0153デフォルトの名無しさん
2006/11/10(金) 04:29:20Borland Developer Studio 2006 アンチスレ
http://pc8.2ch.net/test/read.cgi/tech/1153353434/
0154デフォルトの名無しさん
2006/11/10(金) 04:43:250155デフォルトの名無しさん
2006/11/10(金) 04:46:15でも、まんせって全然役に立ってないよね。
多少でも役に立っている人たちに文句を言う資格なし。
0156デフォルトの名無しさん
2006/11/10(金) 06:13:320157デフォルトの名無しさん
2006/11/10(金) 08:25:55つまりガンはあいつか
0158デフォルトの名無しさん
2006/11/10(金) 10:18:240159デフォルトの名無しさん
2006/11/10(金) 11:10:13Delphiのことなどほっときましょう
0160デフォルトの名無しさん
2006/11/10(金) 12:06:34確か年末だよね。
http://www.atmarkit.co.jp/news/200605/26/borland.html
Ruby on rail 用IDE も出ないかな。
0161デフォルトの名無しさん
2006/11/10(金) 12:28:34日本語化の予定が無いから宣伝できないみたいだね。
0162デフォルトの名無しさん
2006/11/10(金) 13:24:300163デフォルトの名無しさん
2006/11/10(金) 13:26:38ブログも書いてない。
0164デフォルトの名無しさん
2006/11/10(金) 13:33:02来週のデベロッパーキャンプに参加してデモを見たら？
一緒にロードマップの変更も発表するようだし
0165デフォルトの名無しさん
2006/11/10(金) 13:35:49なんか古いんだよね。
他所はリリース前から、ブログで盛り上げるのに。
0166デフォルトの名無しさん
2006/11/10(金) 13:59:160167デフォルトの名無しさん
2006/11/10(金) 14:00:18じゃないんだってば。
... デモと同時にロードマップ更新のお知らせから読み取れるのはなんだ？
延期だよ
0168デフォルトの名無しさん
2006/11/10(金) 14:05:06急遽 Peloton を先に出すと決めた。がやってみたら Eclips 側の予定にうまく合わず翻訳版が
まず延期。そしてとうとう Peloton そのものが来年頭に行った。
0169デフォルトの名無しさん
2006/11/10(金) 14:25:31あらら。
嘘かホントか分からんが、Eclipse 上にIDE を作るリスクというのもゼロじゃないわけだ。
やっぱり自前路線しかないのかねー。
0170デフォルトの名無しさん
2006/11/10(金) 14:27:260171デフォルトの名無しさん
2006/11/10(金) 15:00:54> Highlander が来年夏に延びたため
えぇー！
0172デフォルトの名無しさん
2006/11/10(金) 15:03:16前もこのパターンで騙されたぞ。
0173デフォルトの名無しさん
2006/11/10(金) 17:16:270174デフォルトの名無しさん
2006/11/10(金) 17:28:570175デフォルトの名無しさん
2006/11/10(金) 17:38:44http://www.asahi.com/obituaries/update/1110/003.html
0176デフォルトの名無しさん
2006/11/10(金) 21:34:29> ただいまスタジオ、音声収録中
文句ある？
0177デフォルトの名無しさん
2006/11/10(金) 22:55:54翻訳の才能がないのに絶望しかかったけどとりあえずレベルのものができたので
勝手ながら公開する。気になる部分やもっといい訳があればご指摘願いたい。
とりあえず転載自由で。
ttp://blogs.borland.com/abauer/archive/2006/10/31.aspx
2006年10月31日
Assignedか、not Assignedか、それが問題だ...
news://forums.borland.com/borland.public.delphi.non-technical ニュース
グループに、Assignedが単なるnilとの検査よりもよいのかどうかに関するかな
り興味深い議論があります。おなじスレッドには私が他のポストでカバーして
もよいようなFreeAndNilについての取り留めのない議論もあります。Assigned
については、それが導入されたいくつかの理由を明らかにしたいと思いました。
これはまた(あなたが沼に出会ったときにそれをふさいでいる)覆いの下でDelphi
(BDS) IDEのVCLデザイナの内部がどのように動いているのかを覗き見るという
ことでもあります。
'if PointerVar <> nil then'はポインタ変数が意味のある値を保持しているか
どうかをチェックするために使用されてきました(もちろん以前にnilで初期化
されたと仮定すればですが)。このステートメントは適度によいコードを生成し、
明確で、意図した目的によくかないます。ではなぜ"Assigned"を追加したので
しょうか？Delphi 1において我々は"メソッドポインタ"あるいは"クロージャ"
とも呼ばれる概念を言語に導入しました(実際に純粋な意味で完全な"クロージャ"
ではありませんが)。メソッドポインタは単に実行時にメソッドの実体、そして
これは非常に重要ですが、オブジェクトの特定のインスタンスに、結び付けら
れます。実際のオブジェクトインスタンスの型が任意であるという点は興味深
い指摘です。実行時に要求される型のチェックはメソッドシグネチャがメソッ
ドの型に適合するかどうかだけです。これによりDelphiのデリゲーションモデ
ルはうまくいきました。
0178177
2006/11/10(金) 22:57:44きWin64の実装で)のメソッドポインタの実装は2つのポインタで構成されます。
一つはメソッドのアドレスを、もう一つはオブジェクトインスタンスを指しま
す。簡単な"if methodpointer <> nil then"ステートメントは結局どちらのポ
インタもnilであることをチェックするということになり、論理的に見えます
(いいですか？)。そのとおり。しかしここにはちょっとした障害があります。
デザイン時にネイティブVCLフォームデザイナは帽子からいくつかのトリックを
取り出します。我々にはコンポーネントのメソッドポインタの実体に値を割り
当てる何らかの方法が必要でしたが、しかしコンポーネントは何が割り当てら
れたのかを実際には確認せず、すぐにメソッドを呼び出そうとします(ば〜ん！)。
Assignedの話に入ります。Assignedという標準関数を加えることによって、我々
は"<> nil"の動作を保護してひねりを加えることができるようになりました。
大胆にもあなたが検証できるとおり、Assignがメソッドポインタの2つのポイン
タのうち1つだけをチェックするだけであることがわかります。もう1つのポイン
タは全くテストされません。IDEのオブジェクトインスペクタ上でメソッドをメ
ソッドポインタに"割り当てる"ときには、デザイナは実際にはメソッドポイン
タ構造体の(割り当てられず、テストされない)もう一つのポインタに内部的に
生成したインデックスを詰め込む、ということが行われています。そこであな
たのコンポーネントがメソッドポインタを通して呼び出しを行う前に
"if Assigned(methodpointer) then"の判定を行うならば、コンポーネントのコー
ドはデザイン時におかしな振る舞いをすることはないでしょう。そこでDelphi 1
以降、我々は熱心に"Assignを使え...Assignを使え...Assignを使え..."とみん
なの頭に吹き込んできました。それは機能してきたと思います。コンポーネン
トの作者にとって、メソッドポインタを通して呼び出しを行う前にAssignedを
使用してその値をテストすることは重要です。それ以外のケースでは多少泥臭
0179177
2006/11/10(金) 22:58:33必ず使用しています。それはおそらく私が"古い"からかもしれませんが、わか
りません。しかし、上にあげたような理由から、メソッドポインタをテストす
るときには常にAssignedを使用しています。
なぜ通常のインスタンスの参照やポインタについても常にAssignedを使用べき
なのかについて、いくつかのかなり変わった根拠を見てきました。私が見かけ
た変わった理由の1つは、"将来、'nil'が全て0のポインタ値以外に定義される
かもしれない"というものでした。そのようなことになったらnilの"値"もまた
その状態を反映して変更されるとは思いませんか？別の要素としては、一体ど
うして非0の値をnilとして使用する必要があるというのでしょうか？PChar
(char *)が常に0で終端されるように、nilもまた常に0であるべきだということ
は、私にとっては、コンピューティングにおける不変の法則の一つです。さて、
Pascalでは必ずしも'nil'が0である必要はありませんが、0であることは便利で
一貫していて、新しいプラットフォームやアーキテクチャにおいて変更が要求
されるならば、非常に切実な再定義の理由が必要である、ということがわかり
ました。いくつかのポイントについて、その他の不明瞭な擬似事実を明らかに
し、Delphi、VCL、IDEに関係するいくつかの決定とデザインの背後にある論理
を掘り起こすために、タイムマシンで時間をさかのぼることにします。さしあ
たり、"Assigned(someinstance)"も"<> nil"もお咎めなしです...しかしメソッ
ドポインタでは常に"if Assigned(methodpointer) then"です！
0180177
2006/11/10(金) 22:59:382006年11月01日
例外安全
1992年の終わりか1993年か、そのころに我々にはジレンマがありました。Turbo
Pascal(じきにDelphi言語のベースとなりました)に例外を追加しようとしてい
ました。Windows NTは本格的に開発が行われていました。この新しいOSには構
造化例外(Structured Exception Handling/SEH)と呼ばれる新式のものがありま
した。ここにおけるジレンマとはなんだったのでしょう？Delphiの最初のリリー
スがWin16としても知られるWindows 3.1がターゲットであったということを思
い出してください。ここにはOSレベルでサポートされたSEHはありませんでした。
またWindows NTはマスマーケット向けのコンシューマベースのOSとしてリリー
スされる予定ではありませんでした。さて、なにが問題なのでしょう？単に言
語にSEHを実装して先に進みましょう。問題は"安全"に関するものでした。もち
ろん、そこで我々は16bit版のDelphi言語にSEHの特定のインプリメンテーション
を追加しました。例外はあなたのコードをより安全にするのではないでしょう
か？OK、ここで鈍感で少々曖昧な態度をとることにしましょう。
我々が直面していた基本的な問題は部分的に生成されたオブジェクトという概
念でした。オブジェクトのコンストラクタの途中で例外がライズされたらどう
なるでしょうか？コンストラクタの実行から、例外ハンドラが実行され、デス
トラクタが呼び出される時点までどれだけ離れているのかわかりますか？コン
ストラクタは順調にフィールドを初期化し、他のオブジェクトを生成し、メモ
リバッファをアロケートし、などなど…。突然、ドーン！これらの操作のうち
の一つが失敗します(ファイルを開けない、コンストラクタのパラメータに不正
なポインタが渡される、など…)。コンパイラがコンストラクタの実行を囲んで
暗黙の例外ハンドラを挟み込んでいるため、例外を捕捉して即座に忠実にデス
トラクタを呼び出します。一旦それが完結し、部分的に生成されたオブジェク
トが破棄され、リソースが解放されたら、例外は継続、言い換えれば再生成さ
れます。このシナリオにおける問題は、デストラクタにはなぜ呼び出されたの
0181177
2006/11/10(金) 23:00:26はわかりますが、だからどうだというのでしょう？)。インスタンスが完全に生
成されたのか、そうでないのか、どれだけ生成が進行していたのか、デストラ
クタにはわかりません。
解決策は非常に簡単で、同時にいささか賢明であることがわかりました。Delphi
の全てのクラスには関連付けられた仮想メソッドテーブル(VMT)があるため、そ
れぞれのインスタンスはそのテーブルを指すように初期化される必要がありま
す。Delphiのクラスではコンストラクタ内から仮想メソッドを呼び出すことを
許しているため、コンストラクタが実行を許可する前にVMTへのポインタは初期
化されます。コンストラクタが実行される前にVMTポインタがセットされる必要
があるなら、なぜ完全なインスタンスを既知の状態に初期化しないのでしょう？
これがまさに行われることです。完全なインスタンスは0に初期化され、VMTポ
インタがセットされ、インタフェースを実装するのであればそれらのVMTポイン
タもまたセットされます。オブジェクトのコンストラクタのユーザコードが実
行開始される時点で、インスタンスのデータは既知の状態になっていることを
知っておいてください。このことを利用して、デストラクタは世界がめちゃめ
ちゃになる前に初期化のシーケンスでどれだけものが確保されたのかを容易に
見分けることができます。昨日の記事でFreeAndNilプロシージャについて触れ
たのを覚えていますか？注意すべき別の項目は非仮想のTObject.Freeメソッド
です。インスタンスのフィールドが非nilまたは非0の値を含むならば、初期化
が成功裏に行われたに違いなく、逆初期化を行っても構わないという想定をし
てもいいでしょう。これはコンストラクタ内でメモリの確保やオブジェクトの
生成を行う場合には(さらには他のいかなるオブジェクトのメソッドでも)さら
に重要になります。有効なポインタがいつそのフィールドにあるのかをデスト
ラクタは知っていなければなりません。つまり非nilの値は、メモリを解放しオ
ブジェクトを破棄することを意味します。
0182177
2006/11/10(金) 23:07:01ければならないというのは非常に面倒であり間違いの元でもある、ということ
もまた理解しました。TObject.Freeの話に進みましょう。System.pasを開いて
Freeの実装を見てみると、"if Self <> nil then Destroy;"と単純です。これ
でnilや確保していないインスタンスに対してFreeを安全に呼び出すことができ
ます。なぜならメソッド内でチェックが行われるからです。必要なのは
"FField.Free;"だけで、これであなたのデストラクタは"例外安全"となります。
GetMemで確保したメモリでも同じことです。FFieldがnilであっても
"FreeMem(FField)"を安全に呼び出すことができます。話を戻します。最後に、
string、interface、動的配列、バリアントのような一部の"管理型"ではコンパ
イラが生成するメタデータを使って自動的に処理される、ということに注意し
てください。オブジェクトのインスタンスのメモリが解放される直前に、イン
スタンスと、解放の方法がわかるようにフィールドの型とオフセットを含んだ
メタデータテーブルを受け取るようなRTL関数が呼び出されます。繰り返しにな
りますが、それぞれのfieldがnilであれば、何もする必要がなく単に通過する
だけです。
FreeAndNilについてはどうでしょう？鋭いあなたはこのプロシージャの実装が、
渡された参照にまずnilをセットし、それからインスタンスを破棄しているとい
うことに気が付いたかもしれません。実際にはNilAndFreeという名前であるべ
きではないでしょうか？ええ、そうかもしれません。しかし言いにくく、同様
に混乱を招きます。"じゃあ最初に参照にnilをセットして...どうやって破棄す
るんだ？"ではなぜこのような実装なのでしょう？例外安全が大きな理由です。
別のかなり不鮮明な理由は密接にリンクされたオブジェクトと関係しています。
他のオブジェクトを順番にリストに保持しているオブジェクトが"オーナ"オブ
ジェクトへの逆参照を持っていると思いますか？オブジェクトが破棄される順
番に依存していることで、他のオブジェクトに破滅が迫っていることを知らせ
0183177
2006/11/10(金) 23:08:47リンクしているので、存続期間を通してお互いにメソッドを直接呼び合います。
しかし破棄中は、破棄を投げている間に有無を言わさず他のインスタンスのメ
ソッドを呼び出すのは非常に危険であるかもしれません。オブジェクトを破棄
する前にインスタンスポインタをnilにセットすることで、単にnilかどうかを
チェックすることでもう一方のインスタンスを破棄している間にメソッドが呼
び出されないことを確実にすることができます。
ということで、あなたのオブジェクトを"例外安全"にするいくつかの秘訣と、
FreeAndNilを使ったほうがよいという2つのヒントが得られました。覆いの下を
覗き込んでコードを試すことで、実装の理由と方法をより理解できるようにな
ります。したがっていつでも"if FField <> nil then FField.Destroy"パター
ンを使用することができますが、"FField.Free;"を呼び出せばなぜ全ての作業
が行われるのでしょうか？このパターンでは"if FField <> nil then
FField.Free;"や"if Assigned(FField) then FField.Free;"は冗長です。
以上
3本目のtry...finallyはまた週明けにでも。
0184デフォルトの名無しさん
2006/11/10(金) 23:22:462ch はログが流れてしまうので、ブログかWiki に転載した方が良いね。
0185デフォルトの名無しさん
2006/11/11(土) 00:45:080186デフォルトの名無しさん
2006/11/11(土) 01:26:06おまいら安心して Assigned() やら FreeAndNil()
つかうべし、ってことだ。
0187デフォルトの名無しさん
2006/11/11(土) 03:49:21やっぱ、コンパイラでWideCharToMultiByteとかのWindowsAPIの呼び出しに置き換えられてるんだよな？？
0188デフォルトの名無しさん
2006/11/11(土) 03:52:500189デフォルトの名無しさん
2006/11/11(土) 05:16:51転載しておいた。
http://delwiki.info/?%BB%F1%CE%C1%2FAssigned
http://delwiki.info/?%BB%F1%CE%C1%2F%CE%E3%B3%B0%B0%C2%C1%B4%C1%F5%C3%D6
問題がある場合は、削除してくださいな。
0190177
2006/11/11(土) 12:47:56ありがとん。フォーマットを多少いじって見やすくしといた。
あとは明白な誤訳や意味不明なところの修正など、気がついた点があれば指摘よろしく＞all。
0191デフォルトの名無しさん
2006/11/11(土) 12:55:090192177
2006/11/11(土) 13:52:37テクニカルなアーティクルというより読み物に近いからね。昔話というか。
翻訳もだめだめだし…。
0193デフォルトの名無しさん
2006/11/11(土) 14:11:15アレンの文書は、まず日本語にして、そこから何が書いてあるか考えないと
いけないから、大いに助かる。
翻訳は良く出来てるほうだよ。何が書いてあるか、分かるもの。
0194デフォルトの名無しさん
2006/11/12(日) 11:47:05わはは、最高の褒め言葉
0195177
2006/11/12(日) 12:15:10そういっていただけるとうれしい。
>194
いや、まじで1行1行はなに書いてあるかわかるのよ。でもつなげると…。
でも大意はわかると思うし、それなりに興味深い内容だと思ったので。
もうちょっと出来がよければ藤井さんに売り込んだんだが…。
転載、2次利用大歓迎なのでまともに直して公式に載せてくれ＞某の中の人
0196デフォルトの名無しさん
2006/11/12(日) 22:11:280197デフォルトの名無しさん
2006/11/13(月) 04:12:35自分らのアホさ加減に気が付けよ
間抜け
0198デフォルトの名無しさん
2006/11/13(月) 06:26:57逆にnilを先に入れる事よる不都合だって有り得るよね。
こんなの。
procedure HogeProc;
begin
ShowMessage(Form1.Name);
end;
procedure Form1.Destroy;
begin
inherited;
HogeProc;
end;
0199198
2006/11/13(月) 06:33:10nilを代入するのか。
>198は忘れて。
0200デフォルトの名無しさん
2006/11/13(月) 08:01:270201デフォルトの名無しさん
2006/11/13(月) 08:01:46実際あるよ
FreeAndNilではうまくいかず
a.Free;a:=nil;でうまくいくことは
0202デフォルトの名無しさん
2006/11/13(月) 12:26:380203デフォルトの名無しさん
2006/11/13(月) 20:21:06ttp://blog.goo.ne.jp/nobol-blog
精神を病んでいたのね...
0204デフォルトの名無しさん
2006/11/13(月) 22:39:590205デフォルトの名無しさん
2006/11/13(月) 22:58:090206デフォルトの名無しさん
2006/11/13(月) 23:04:580207デフォルトの名無しさん
2006/11/14(火) 07:58:18いや。例えばスレッド関係とか。
0208177
2006/11/14(火) 21:23:242006年11月03日
try...finally
ここ数日、例外に関して多少の混乱があることを示すようないくつかの興味深
いコメントがありました。より明確にはtry...finally構文です。"try...finaly"
の使用に関して、私を立ち止まらせ、なぜそのようにするのか不思議に思うよ
うな、いくつかのかなり興味深いねじれがあるようでした。例外を伴なうプロ
グラミングでは、ほとんど全ての場所でいきなり制御が離れた場所に移される
ということを常に意識していなければなりません。色々な意味で、マルチスレッ
ドのシナリオでどうするのかと非常に似た問題についてアプローチし、考える
必要があります。どちらの場合でも、潜在的な2つ(あるいはマルチスレッドで
はそれ以上)のコードの通過経路を常に意識のうちに留めておく必要があります。
一つは簡単で、プログラムの全体的なロジックと意図を定義するコード中の文
をあなたが書いている順番です。もう一つの、しばしば忘れられているコード
経路は、例外が実行される経路です。
例外がライズされた(C++や類似の言語の用語では"投げられた")とき、その動作
の背後では多くの隠された作業が行われています。プラットフォームや言語に
依存する傾向があるため、実際に何が行われているのかの詳細には立ち入るつ
もりはありません。プログラマの視点から何が起きているのかや具体的な
"try...finally"構文について焦点を合わせていきます。"try...finally"ブロッ
クについて考える一つの方法は、第2のコード実行経路で"邪魔をされる"という
プログラマのやり方です。しかしそこでは通常のコード実行経路で"邪魔をされ
る"ことから特異です。全体的な見地では、例外を使用するプログラミングにお
いて"try...finally"ブロックは最も多く使用される(そしてしばしば誤用され
る)ブロックの形式です。典型的なアプリケーションにおける"try...finally"
ブロックと"try...exception"ブロックの比率は100:1のオーダであるとしてお
きましょう。しかしなぜそれを使い、なにがよいのでしょう？リソース管理の
0209177
2006/11/14(火) 21:23:55のアプリケーションが使用したり関係したりする色々なリソースの例です。
"try...finally"ブロックの核心は、アプリケーションの取る実行経路に関わら
ず確保したリソースを適切に返却することを保証することにあります。
それでは"try...finally"ブロックの一般的な誤用をいくつか見て、綿密に調べ
てみましょう。
var
Obj: TMyClass;
begin
try
Obj := TMyClass.Create;
...
finally
Obj.Free;
end;
end;
ここには微妙な問題があります。最初に正常な実行フローを追ってみましょう。
制御がtryブロックに入り、TMyClassのインスタンスがアロケートされてコンス
トラクタが呼び出されます。制御が戻り、ローカル変数Objに格納されます。い
くつかの処理がObjに対して行われ("..."の部分)、制御がfinallyブロックに
入ってObjのインスタンスが解放されます。ここまでは大丈夫でした。いいです
ね？つまり、メモリが確保され解放され、TMyClassのインスタンスが必要とし
ているその他のリソースとともにヒープもうまく処理されています(適切に設計
されたクラスなら、です)。
さて、制御のフローのその他の可能性を見てみましょう。制御がtryブロックに
入り、TMyClassのインスタンスがアロケートされてコンストラクタが呼び出さ
0210177
2006/11/14(火) 21:24:31を使用したプログラミングでは、コンストラクタの呼び出しの間に何かが起こ
る可能性はほとんど無限にあります。最も明白なのは、メモリマネージャが新
しいインスタンスのデータを保持するだけの十分なメモリをヒープ上に確保で
きないというケースです。"Out of Memory"例外がライズされます。おい、でも
finallyブロックに例外の制御フローが渡されるのだからOK。でしょ？はあ、そ
のとおりです。メモリがアロケートされなければ、コンストラクタも呼び出さ
れず、ローカル変数Objにも格納されず、そして制御がfinallyブロックに入っ
てその中身は…あー、"Obj.Free;"です。見ましたか？ええ、そのとおり、Obj
の参照は適切に設定されていません。このため、"Obj.Free;"の呼び出しはあな
たのアプリケーションの健康にはよくありません。おそらく元々の例外に取っ
て代わって(多くの場合もっと致命的で扱いにくい)別の例外がライズされるで
しょう。
ではどのようにこれを修正すればよいのでしょう？はい、わかっています。も
しObjの参照をnilに事前に初期化("Obj := nil")していおいたらどうでしょう？
確かに。そのようにすることもできますが、コードに別の行を追加することに
なります。どうすればどちらの実行経路を通過したのかに関わらず常に制御が
finallyブロックに渡されることを保証するようにこのコードを修正できるで
しょう？実際には非常に簡単です。同じブロックを微妙に変更してあります。
var
Obj: TMyClass;
begin
Obj := TMyClass.Create;
try
...
finally
Obj.Free;
end;
end;
0211177
2006/11/14(火) 21:26:19必要ありませんが、理由を検討してみましょう。例外安全とAssignの仕様に関
する私の以前のいくつかのポストで、オブジェクトのコンストラクタが実行さ
れている間にもし例外がライズされると、デストラクタが自動的に呼び出され、
オブジェクトは解放されて例外の実行の継続が可能になるという事実を暗示し
ました。これは本質的に2つの主要な領域でうまくいかなくなるかもしれないと
いうことです。一つはインスタンスのためのメモリを実際にアロケートしよう
とする間です。メモリマネージャがインスタンスを保持できるだけの大きさの
ブロックを見つけることができないと、"Out of Memory"例外をライズするで
しょう。実際にはインスタンスがアロケートされなかったので、コードの
"Obj.Free;"の行は実行する必要が全くありません。try...finallyブロックに
入らなかったので、Obj.Freeは決して呼ばれないでしょう。もう一方のうまく
行かないかもしれない場所はオブジェクトのコンストラクタの中です。この場
合はメモリマネージャがメモリをアロケートし、インスタンスをセットアップ
するために制御がコンストラクタに渡されます。ここで何か致命的なことが発
生したら、デストラクタが自動的に呼び出されてインスタンスのメモリが再利
用のためメモリマネージャに返却されるということを、これらの過去のアーティ
クルから知っています。オブジェクトは解放されており、同様に制御はtry...
finallyブロックには入っていかないため、"Obj.Free;"の行は決して実行され
ません。これらのシナリオのどちらにおいても、TMyClassのインスタンスに関
係したりソースは適切に扱われているため、ローカル変数Objの参照に触れる必
要はないのです。メモリのアロケートが成功し、コンストラクタを実行し終わっ
たら、制御が戻ってきてローカル変数Objに設定され、その後で制御はtry...
finallyブロックに入っていきます。次に何が起こるかに関わらずObjで参照さ
れるTMyClassのインスタンスがきちんと解放されているようにというあなたの
変わらない要求はこれで満たされます。
0212177
2006/11/14(火) 21:28:01するにあたっての"ねじれ"をここ数年間見てきました。上記のケースはもっと
も共通の誤りとして記憶の中でも目立っています。これ以外のいくつかのケー
スを続くポストで書いていくつもりです。例外に関して自信がない特定の共通
のイディオムやパターンについての質問があるなら、コメントをポストしても
らえれば、将来のポストでそのことについて書くつもりです。
---
以上意味が通りにくいけど参考に。
wikiも更新しておいた。
ttp://delwiki.info/?%BB%F1%CE%C1%2Ftry...finally
0213デフォルトの名無しさん
2006/11/14(火) 21:55:200214デフォルトの名無しさん
2006/11/14(火) 21:57:000215デフォルトの名無しさん
2006/11/15(水) 00:29:50最近、ヘルプなどのドキュメント要員をかなり増員しているようだぞ。
0216デフォルトの名無しさん
2006/11/15(水) 01:34:56いっそ死んだらどうだ
0217デフォルトの名無しさん
2006/11/15(水) 02:08:36void hoge()
{
// ほげほげ
}
//---------------------------------------------------------------------------
void hoge()
{
// ほげほげ
}
//---------------------------------------------------------------------------
こんなかんじで200行くらいコピペしてくと・・・もう死にたい
0218デフォルトの名無しさん
2006/11/15(水) 03:31:140219デフォルトの名無しさん
2006/11/15(水) 06:31:16>コピペしてくと・・・もう死にたい
肝心なところを省略するなよ
0220デフォルトの名無しさん
2006/11/15(水) 06:34:40そのワーニングが出る理由を説明しているとおもわれ
0221デフォルトの名無しさん
2006/11/15(水) 06:34:57眠い頭で考えた改善点
> "try...finally"ブロックについて考える一つの方法は、
> 第2のコード実行経路で"邪魔をされる"というプログラマのやり方です。
"try...finally"ブロックについて考えなければならない唯一の事は、
プログラマのやり方によっては第２のコード実行経路の"邪魔をする"という事です。
> しかしそこでは通常のコード実行経路で"邪魔をされる"ことから特異です。
しかし、（第二だけでなく）通常のコード実行経路の邪魔にもなるという点もユニークです。
> "try...finally"ブロックの核心は、
"try...finally"ブロックの醍醐味は
> ここにものすごくうまくいかないかもしれないものがあります。
ひどい狂いが生じる可能性があるのは、ここです。
> しかしこれでTMyClassのインスタンスの生成は保護されなくなります！それは必要ありませんが、
でも、これじゃあTMyClassのインスタンスの生成は保護されてないじゃないか！そんなの必要ありません。
> これは本質的に2つの主要な領域でうまくいかなくなるかもしれないということです。
これによって狂いが生じる可能性があるのは、大きく分けて２つです。
0222デフォルトの名無しさん
2006/11/15(水) 06:35:180223デフォルトの名無しさん
2006/11/15(水) 06:53:21DevCo はCodeGear 社として2007年初頭に分社化するとの事。
CEO はBen Smith 氏。
http://biz.yahoo.com/bw/061114/20061114006381.html?.v=1
0224デフォルトの名無しさん
2006/11/15(水) 06:55:440225デフォルトの名無しさん
2006/11/15(水) 07:28:40/ ｛_ ｸ
,=- く__,,／
/ ／ ＿
/ ／ _〃― ヽ
/ /ヘ _/ | | =!|= ｝lヽ ウォォォォォォルハァイルブルィィィィィトァァァァァニィア！！
r' く彡 ＼r'´｛ ∧ rっ / |ヽ-､
＼ ""''''`l ／ﾍ｀,二´ミ､ﾉ丿丿）
/＼ | ´ | | | |＼_ノF＝= ､__
/;:;:;:;:ヽ / l | | | | ＼|| | | | | ||
/;:;:;:;:;:;:| r―''＼ ,'⌒i| || || |
/;:;:;:;:;:;:;:;:| || ヽ__ﾉ || || ﾍ
/;:;:;:;:;:;:;:;:;:;:| q=＝＝＝||ヽ＝=o || || ヽ
/;:;:;:;:;:;:;:;:;:;:;:;:| || || ヽ || || ＼
／|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|＼
／ | | ＼
／ | | ＼
0226デフォルトの名無しさん
2006/11/15(水) 07:45:21力説してたのがいたなぁ・・・・いま、どう思ってるんだろ？
0227デフォルトの名無しさん
2006/11/15(水) 07:52:32知らされてないんだろうなぁ
0228デフォルトの名無しさん
2006/11/15(水) 07:53:41製品だてたのに、分社化で何が変わるんだ？？
わらえる。Delphi終わった。
0229デフォルトの名無しさん
2006/11/15(水) 07:56:50もうできてるし
0230デフォルトの名無しさん
2006/11/15(水) 08:06:37クパティーノ（都会派） vs スコッツヴァレー（田舎派）の争いに
ようやく結論が出たというのは良いことだよ。
0231デフォルトの名無しさん
2006/11/15(水) 08:24:140232デフォルトの名無しさん
2006/11/15(水) 08:25:480233デフォルトの名無しさん
2006/11/15(水) 08:26:46ML は、また無反応でしょう。
0234デフォルトの名無しさん
2006/11/15(水) 08:41:39横浜 vs 湘南みたいなものかね。
0235デフォルトの名無しさん
2006/11/15(水) 08:50:15うーん、わかんない。別のにたとえると？
0236デフォルトの名無しさん
2006/11/15(水) 08:51:280237デフォルトの名無しさん
2006/11/15(水) 08:51:330238デフォルトの名無しさん
2006/11/15(水) 08:55:29BDS2006を買わせようとしてたが、早くもこれ。
俺は2006買わなかったけどさ。
0239デフォルトの名無しさん
2006/11/15(水) 08:57:56結局投資家には売却しなかった訳だし。
このばあいの投資家は、日本でいうところのハゲタカファンドで、おいしいところだけ
食い散らかしてポイする連中。
0240デフォルトの名無しさん
2006/11/15(水) 08:58:36将来性という点は分からなくなったが
ドナドナされないってのは、良い事なんじゃね。
とりあえず即死・と殺は回避して、あと２・３年はいけそうなら
Delphi 使いにとってはまずまずと行った所では。
0241デフォルトの名無しさん
2006/11/15(水) 09:00:39開発資金は沸いてでてくるのかな？
つまり、結局は何も変わってないってことか。
0242デフォルトの名無しさん
2006/11/15(水) 09:01:29StarTeam は悪くないけど、それがどれだけ売れるかといったら...
0243デフォルトの名無しさん
2006/11/15(水) 09:04:53> 問題は金だよ。
ALM に吸い取られなくなったので、現状でも自由に使える金は増えてるんじゃないか。
別会社になったという事で、資金調達も自己責任で出来ると。
0244デフォルトの名無しさん
2006/11/15(水) 09:08:50まあ、買収した会社がもともと持っていた市場・地域ではそれなりなんじゃね。
Borland ブランドの下で、バラバラの会社が勝手に商売しているというのが、
今のBorland の姿かな。
0245デフォルトの名無しさん
2006/11/15(水) 09:10:300246デフォルトの名無しさん
2006/11/15(水) 09:11:090247デフォルトの名無しさん
2006/11/15(水) 09:13:530248デフォルトの名無しさん
2006/11/15(水) 09:15:230249デフォルトの名無しさん
2006/11/15(水) 09:17:160250デフォルトの名無しさん
2006/11/15(水) 14:47:460251デフォルトの名無しさん
2006/11/15(水) 15:01:110252デフォルトの名無しさん
2006/11/15(水) 16:10:04■ このスレッドは過去ログ倉庫に格納されています