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/
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:040253デフォルトの名無しさん
2006/11/15(水) 19:49:50まだ。みたいだね。
アメリカは来週感謝祭で休みだから，大きな変化は月末から12月頭に来る予感。
日本側は（藤井氏の Blog を見る限り）今日の発表を知らなかったようだけど，
デベロッパキャンプは続行かな？
0254デフォルトの名無しさん
2006/11/15(水) 20:40:26事実と意見を分けて発言できない所が幼稚だ。
0255デフォルトの名無しさん
2006/11/15(水) 21:16:460256デフォルトの名無しさん
2006/11/15(水) 22:00:33以下感想
って分けて書かれているけど？
0257デフォルトの名無しさん
2006/11/15(水) 22:07:08〜こちらは日本語訳が出たようです。
ってしか言わない高橋 Ken ちゃんとか
誰も見てない役立たず Blog で，分社化の話しをしている Iwamoto さんとか
ほんとにみんあ役立たず
0258デフォルトの名無しさん
2006/11/15(水) 22:08:48ボーランドがIDE事業を完全子会社化、売却へ向けてのステップか
... このことから、一度子会社として分離することによって資産価値を明確化したうえで売却しようという考えと見られる。 ...
ま，こういう分析が普通だな。
さすが TurboPascal 時代から Borland とつきあいのある北郷氏だけある。
0259デフォルトの名無しさん
2006/11/15(水) 22:08:57根拠のない感想文をくっ付けて読ませようとするのが、姑息。
チラシの裏は、更新をさぼっているブログにでも書けと。
0260デフォルトの名無しさん
2006/11/15(水) 22:10:160261デフォルトの名無しさん
2006/11/15(水) 22:13:18ALM もどこかに売却されるかもなんて話もあったから
そのうち返してもらえるかも。
0262デフォルトの名無しさん
2006/11/15(水) 22:15:080263デフォルトの名無しさん
2006/11/15(水) 22:15:58全員、私人としてやってますという複線を張ってるからなｗ
まあ本社の人間じゃないから、答えようがないってのはありそうだけど。
0264デフォルトの名無しさん
2006/11/15(水) 22:20:20258 よんだ？
0265デフォルトの名無しさん
2006/11/15(水) 22:25:06結構な値段でサポート契約したら，「その機能は BDS2006 で無くなりました」だとよ。
あぁそうですか。けどそんなこと知りたくて金払ったんじゃないのに。
でよく見たら「サポートに連絡したら」と薦めた高橋某が，担当でやんの。
最初から，バグだと言ってくれりゃいいのに。
0266デフォルトの名無しさん
2006/11/15(水) 22:28:030267デフォルトの名無しさん
2006/11/15(水) 22:39:020268デフォルトの名無しさん
2006/11/15(水) 23:10:33SE としてならともかく，一般の場での発言で，その言い方がどれだけ負の影響を周りに
与えているのか考えてみればいいのに。と思ったけど，藤井氏もあんなスタンスだしな。
>Developer Tools Group は CodeGear に
>ついにプレスリリースが出たようです。
>Developer Tools Group は「CodeGear」になるようです。
mixi ですらこれだしな。おまえの会社だろ？それとも「私はボーランドの社員のようです」とでも言うんだろうか wwww
0269デフォルトの名無しさん
2006/11/15(水) 23:52:24いろいろ伏線張ったり、逃げの姿勢をアピールするのは仕方ないかも。
0270デフォルトの名無しさん
2006/11/16(木) 00:59:10だからお布施しろよ。
0271デフォルトの名無しさん
2006/11/16(木) 01:25:42もう Borland にぁ期待してないんだが、いままでお世話になったし、
フリーのものも色々リリースしてくれてるし、
お布施しとこうか。って思ってたのに忘れた。
思い出させてくれてありがと。
# 俺としてはもうなんか気分的には wikipedia の運営資金募金とかのそんなノリ。
0272デフォルトの名無しさん
2006/11/16(木) 01:33:120273デフォルトの名無しさん
2006/11/16(木) 01:35:100274デフォルトの名無しさん
2006/11/16(木) 01:46:47お布施してやるからちゃんとVista対応にしろよ。
0275デフォルトの名無しさん
2006/11/16(木) 03:56:02バカだな。 Vista 対応は 2008年の Delphi Vista で。と RoadMap にあるだろ？
0276デフォルトの名無しさん
2006/11/16(木) 03:56:580277デフォルトの名無しさん
2006/11/16(木) 04:32:42IME サポートも、RTM 後のサービスパックで対応。ということになったし。
0278デフォルトの名無しさん
2006/11/16(木) 08:19:33BDS2006パスしてHighlanderパスしてその次か。
0279デフォルトの名無しさん
2006/11/16(木) 08:23:35普通に使える程度のVista 対応はされてるのではないだろか。
0280デフォルトの名無しさん
2006/11/16(木) 08:25:08■ このスレッドは過去ログ倉庫に格納されています