【ドキュメント】Delphi8 for .NET 2【どこ？】

すこーし遅れて Delphi 8 for .NET「日本語版」が出ました.

これは、あなたが欲しかった Delphi ですか？

これは最後の「デルファイ」になるか。

前スレ
ttp://pc2.2ch.net/test/read.cgi/tech/1073688379/

関連
ttp://www.borland.co.jp/delphi_net/
ttp://www.borland.com/delphi_net/
バージョンアップ　ttp://store.borland.co.jp/upgrade/Delphi8_upgrade_0889.html
IDE Integration pack　ttp://bdn.borland.com/article/0,1410,31918,00.html
Win32API←→.NET対応表　ttp://www.microsoft.com/japan/msdn/net/general/win32map.asp

言語は所詮ツール。

適用範囲が変わった以上、その地位は少なからず変動する。

徹夜でヘルプ読んでたよ…

unsafeが目次から辿れないってどういうこっちゃ！
(キーワード検索から到達した)

…こういう、隠された項目が、大量にあるのだろうか

Pascalってそこまで執着するような言語か？

言語仕様の変更点とか、新規追加部分はインデックスがついていないみたいですね。

ドキュメント ＝ DQメント

ドキュンメント

Update#2 は今週。
ttp://groups.google.co.jp/groups?hl=ja&lr=&ie=UTF-8&oe=UTF-8&selm=404a0555%40newsgroups.borland.com

日本語版の Update「#1」は何年後？

//宇宙仮面のパクリ
program Sample.Thread.Console1;

uses
System.Threading;

type
MyThread=class
private
number:integer;
public
constructor Create(no:integer);
procedure Run;
end;

var
myThread1,myThread2:MyThread;
thread1,thread2:Thread;

{ MyThread }

constructor MyThread.Create(no: integer);
begin
inherited Create;
number:=no;
end;

procedure MyThread.Run;
begin
while true do begin
Console.WriteLine('Thread Sleep = {0}', TObject(number));
Thread.Sleep(number);
end;
end;

[STAThread]

begin
myThread1:=MyThread.Create(500);
myThread2:=MyThread.Create(1000);
thread1:=Thread.Create(myThread1.Run);
thread2:=Thread.Create(myThread2.Run);
thread1.Start;
thread2.Start;
Thread.Sleep(5000);
thread1.Abort;
thread2.Abort;
thread1.Join;
thread2.Join;
Console.WriteLine;
Console.WriteLine('MyThread.Run has finished');
end.

>>4
unsafe使うのやめてMarshal使えという暗示。

>>9
日本語版には既に#1は含まれている気がする。ファイルのバージョン番号とか

>>14
デマでしょう。どこにもそんなことは書かれていない。

>>15
いや、だって、修正項目のはずのVariantからAnsiStringへの変換も動くし…どうなんだろ

ttp://www.borland.co.jp/delphi/devsupport/

ですよ。

#1適用済みですか。

それはそれとして、IEコンポーネントをVCL.NETにインポートできた人いる？

>>Delphi 8 アップデート1は日本語製品版に含まれています。

ということは、アップデートでも例の日本語フォルダでアボーンのバグは
直されてなかったのね。ひどいね

うまくいかなくて不満ばかりの人もいるみたいだなぁ。
俺はCLR+APIの万能さに惹かれてしまって、Updateとか興味ない。

> 俺はCLR+APIの万能さに惹かれてしまって

で、なにつくってるの？
いままでそんなに無能だったの？

オーソドックスにはじめはメモ帳作って勉強中。
正規表現の逆方向検索が便利だったり、
RichEdit.pasなんかで拡張したり、
CLRではできないプレビュー付きオープンダイアログをAPIで書いたり。

いままでは無能とはいえないまでもS-JIS問題がどうしても気になってた。

おいおい。VB.NET使いが2年前に勉強してたことを今さらやってるの？ｗ

俺の周りはvb.net使いが未だに一人もいない。

VB使いが2年かかる学習をDelphiなら数日で終わりますよ

C#はやってるけどVBはやってないので煽られても反論できないが、
もしC#と同じなら、D8みたいにAPIヘッダはついてこなかったはずだ。
今回みたいにプレビュー付きダイアログ作ろうとしたら、
構造体の宣言も定義済みのD8だと楽できるよ。

>>26
漏れはVB.NET使いなのだが、Win32APIを呼び出すときはDeclare Functionを
使う必要があるのだが、Del8ではその必要がなく宣言ナシにいきなり使用できると解釈
していいの？
それはかなりいいかもしれないな。

>>27
Uses Windows;
と書けば膨大なDeclareを書いたのと同じ。
いくつかの特殊なAPIは別ユニットだが、
Uses Windows, Imm, ActiveX;
などと追加する。
さらに、Messagesは大量のウィンドウズメッセージを定義してある。
もちろん、使わない関数や定数の分まで実行ファイルが大きくなることはない。

とは言っても、VB.NET使って満足ならあえてマイナーに行くべきではない。

ちなみに今回のWindows.pasは約25500行、1.5MBある。

.NET で API つかいやすくなってることに矛盾を感じない？
「なぜ、.NET でプログラミングする必要があるのか」を考えたことない？
.NET Framework をたんなる共通ライブラリだと思ってない？
Delphi.NET が今後メジャーバージョンアップされる、と勘違いしてない？

>>30
思いこみすぎ

>>31
現実を知らなさすぎ

>>31
疑問文だと気づかないのはアフォだから？

すまん、しょうもない質問させてください。
前スレで話題に上がっていたマニュアルのpdfなんですけど、どこにあるの？

>>34
かわいそうに.. よく読め。
「もしドキュメントの PDF があったなら」「印刷して読みたい」
としか書いてないだろ？

もともと PDF がついていないんだよ。

>>32-33
一言で返されるとつらいみたいだね

>>27
Delphiなんか買わなくても無料のサンプルが転がってるけどね。(嘲笑禿藁
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=f1dd70e4-c212-4a6f-bff7-c82e34c8836f

>>37
自分で貼った先くらいちゃんと調べてから嘲笑禿藁したら？

>>36
> 一言で返されるとつらいみたいだね

そう、つらい。自分もDelユーザだが、ここのヤツらのDQNぐあいは、まじめに物事を
考えたことがないように見える。

>>39
Delユーザと告白した時点で貴様もボーっとしてる。

>>40

Delユーザだが、Delphi8 は買ってないし、買うつもりもない。

だじゃれにマジレス必死だな

41 です。 >>42 あっ、そうかぁ。（照れ笑
Del8 ユーザでもないし、もうここには地下図鑑。スマソ

外出かも試練が、むちゃくちゃ文字化けする。
ソースコードをUTF8で保存したら直った。

Borland Shared\Images\GlyFX
↑XP風ビットマップのフォルダ

>>44
Shift-jis のソースはコンパイルできません。
って Readme に書いてあるでしょ？

Readmeなんか読むわけないじゃん

Readmeをどうせ読まないんだから、Del8の起動時のスプラッシュ画面とか
エディタのバックグラウンドに「Shift-jis のソースはコンパイルできません」
とでもデカデカと書いてくれよ。
万人が間違えないように。

コンパイルは通るんだけどね。
UIが化ける。

それ、VCL じゃなくて WinForm アプリだろ？
Readme 読みな

Delphi8 にもついている「統合翻訳環境」なるものを使った人っている？

日本語版ともインターナショナル版とも言い難いな。
あえて言うならハック英語版だ。

Del8って、前DelのVCLソースみたいに、
WinFormsのVCL互換的(？)ライブラリのソースってついてるんでつか？

>>53
誤解。Delphi から Win32 API が使えるからといって、Win32 API のソースがついてきていたわけではないだろう？

Move手続きとFillChar手続き(0クリアに使用)はどうやって書き換えたらいいか悩み中。
知ってる人教えてください。

Move( PChar(src)^, PChar(dst)^, length);
は
System.Array.Copy(System.Array(src), 0,
　System.Array(dst), 0,
　length);

FillChar(buf, length);
は
System.Array.Clear(System.Array(buf), 0, length );

でどうだ？

>>53
VCL.NET(これまでのVCLにあたるもの)は全部ソース付き。
.NETクラスライブラリで再現できるものはクラスライブラリで、
できないものはWin32APIで書かれている。
これまで通りTApplication、TWinControlなどのVCLを使ったアプリ構築が可能。
しかし、動作速度や実行可能ファイルサイズの点でおすすめできない。

新しく、.NETクラスライブラリでウィンドウを作る方法も用意されている。
こちらを使えば他の.NET言語でのプログラミングと全く同じものを作ることになるが、
VCL.NETのユニットをusesして使うこともできる。
.NETクラスライブラリはWin32の後継なので、以下>>54

Binフォルダ内ファイルバージョンが軒並み7.1です

>>57
Win32の後継はWinFXでは？ :-)

VCL/NET の動作速度が遅い。って話は初めて見るが、出典は？ >>57

>>58
Delphi7 の修正版を出す。って聞いたことあるでしょ？

>>60
出典なくてもビルドすりゃ一目瞭然

>>60
そりゃ.NET Frameworkに加えてVCL.NETのレイヤをかぶせたら動作速度が
どうなるかは一目瞭然のような気が…
VCL.NETはあくまでも.NETへの移行用なのかな？
ただ、Windows Formsを使ったときにいままでVCLを使っていたときほど
DBクラス/コントロールの使い勝手がよくなるのか悪くなるのかが知りたい。

>>63
そんなレイヤーで遅くなる環境じゃ、クラスどころか関数も使えんな。

>>64
それよりもWindows Forms自体のパフォーマンスが(略

Windowsフォームのラッパじゃないよ

言語ガイドにはdcc32とdccilの両方について書かれているし、
RTLソースには{$IFNDEF CLR}とかが見られる。
D7のアップデートはどうなるか知らないけど、
D8のWin32コンパイラwith.NETライブラリは望みがあるようだ。

>>そりゃ.NET Frameworkに加えてVCL.NETのレイヤをかぶせたら
かぶってないってば。
ビルドしたら、ってコンパイル速度の話をしているのか？

スマン初心者(D6Per)なので申し訳ないのだが、
Windows Formsのラッパーじゃないということは、
VCL Formsのフォームやオブジェクトは直接Win32APIにアクセスしているという
ことなのか？
ということはどの部分で.NetFrameworkを使っているのか？そもそもFramework
を使わなくてもよいのではないか。

全く理解できないおいらに誰か。…

>>56
ありがとう。参考にはなったけどまだ解決はできていません。

procedure Move(const Source; var Dest; Count: Integer);
begin

end;

procedure SetZero(var X; Count: Integer);
begin

end;

それで、いまだに begin endの中のコードを試行錯誤中。
つーか、D8でなくなった関数などの移植方法、ヘルプに全然載ってないからわからん。
せめて互換のためのユニットだけでも提供してくれると楽なのに。
というか、俺に互換ユニット作れということなのか?

>>69
.NETというのは、共通言語ランタイム(CLR)とクラスライブラリでできている。
中間コードをフレームワーク内でマネージされて動かす部分と、
OSを超えて共通に使える（かもしれない）API部分ということだな。
中間コードを吐くかネイティブコードを吐くかではメモリ管理が違っていて、
Win32APIを使うか.NETライブラリを使うか、または両方使うかはターゲット環境による。
どちらのタイプのアプリからでも双方のライブラリを呼び出すことができる。

D8のVCLはマネージドでも32ビットコードでもコンパイルできるように書かれているが、
32ビットコンパイラはアップデート待ち。
マネージドアプリを作る意味は今のところないかもしれないが、
クラスライブラリは便利なので使う意味はあるんじゃないかな。

という感じでどうよ？

>>70
おまえのやりたいことはCLR向きではないってことだ。
FillCharをGrepしてみたが、非CLR環境では使えるようになってるな。
ほかは探してないけどたぶん同じだろう。

今はすべてが過渡期。
WinForm も、Win32 API の上で動いているし、ちょっと複雑なことをやろうとすると
（たとえばカスタムコントロールを作ろうとか）Win32 API を呼ぶしかない。
Java と異なり、UI / Display の仮想化のメカニズムがないからだ。

これは OS のシステムコールレベルで .NET VM 化されるといわれている
LongHorn OS になる 2006年以降になるまでは解決しない。

だからといって、そのときまで今のまま。ということはないわけで、OS のいろんな
サービスが .NET でしかサポートされない。ということが増えていくだろうよ

>>70
PASCAL は強い型付の言語。といわれているけど、実際には
　(var X; Count: Integer);
の X のような型無しの宣言ができて、型チェックをはずすことができる。

.NET では完全に禁止となった。

だから、書き換えなきゃいけないのだよ

>>71>>73
アリガ�d。大体わかった。
もっと勉強するわ。

まだD6だが

今回は文字列型がnilの場合もあるので戸惑った。
S.LengthもLength(S)も使えるが、
nilの場合でもエラーにならずに0を返すのはLength(S)だ。

>>71 >>73 の解説はオレにも参考になった。サンキュー

> 今はすべてが過渡期

好き嫌い、善悪を別にして

Win32 → WinFX

ということだよね。.NET に参加する、ということはこのことを
認めたか、あるいは、MSのいうことは信じないが万一に備えて、
とか、純粋に興味があるので、といったことだろう。

であれば、新規プロジェクトで VCL.NET 使う意義はゼロです。
.NET は次期プラットフォームへの足慣らしですから、これを
使わずに独自のライブラリを使うことは過渡期であっても後ろ向き
のものであり、ベクトルは Win32 の方を向いていることになります。
同じ理由で、Win32API を積極的に使うのも間違いです。出来るだけ
.NET Framework のライブラリでカバーして、どうしてもカバー出来
ない部分を補うときくらいで使うべきです。

いずれにしても、この過渡期に Delphi8 が出てきたことの意義を
考えるべきです。過渡期が過ぎて本番の WinFX になったときに
それまでのコードが本当に役に立つのか、そのころまでちゃんと
Delphi が WinFX に対応して存在しているのか、とかね。

１）Delphi8 を買って準備する
２）もうすこし様子見する。
３）VC# や VB.NET など VS.NET で準備する

４）上記の「過渡期」であることを認めないので .NET は完全無視する

いろいろな対応の仕方があると思います。

>>77
現状では「どうしてもカバー出来ない部分」ってのはそこら中にあって、
Ｃ＃やってると、Win32なしではろくなものは作れないことを実感する。
あれはまだサブセットだ。

俺は「D8を使う＝.NET完全移行」ととらえないで、
両方のライブラリを手軽に使える唯一の環境ととらえている。
数年後の準備ではなく、
今、使えるものを最大限使う目的でいじり倒している。

>>70
http://homepages.borland.com/dthorpe/blog/delphi/2004_03_01_archive.html#107801808873575778
こんなのがあったが、参考になるかな

> 今、使えるものを最大限使う目的でいじり倒している。

そう、これも一つの対応ではあるね。
でも、どうせ現状では実用的なモノはつくれないでしょ。Win32アプリを越えるような。
公開しても使ってくれるユーザだっていないし。

だったら自分の将来に対する投資に徹底したほうがいいよ。

またきたか

.NET批判にしかなっていないのには、笑える

Delphi8 を使っている人は、みんな .NET マンセー なんだよね。きっと。

Delphi8 を使っている人はいろいろ自己矛盾を抱えて苦しんでる、か
なにも考えていないのだよ。だから、もうこれ以上説教はやめろ

色々調べた結果、MoveやFillChar互換を実装することは無理だとわかりました。
言語の仕様上、構文の見た目は同じでも色々とできないことが沢山あったりと。
もっとコンパイラが賢く振舞ってCLRの制限を上手く回避してくれればいいのに・・・。

これも参考になるよ。

なぜVCL.NETか？
http://bdn.borland.com/article/0,1410,31983,00.html

>>83-84
>>31

>>85
FillCharって構造体を初期化するときに使うじゃん、形無しで。
そういう使い方もしたいの？
ArrayだけならDelphiのArrayじゃなくてSystem.Array使えばいい。

>>86

Conclusion

Microsoft's Windows Forms application architecture for the
.NET platform is a sound architecture intended solely for
new application development. Getting into WinForms is expensive,
though, since there is no migration path for existing source code.

Borland's VCL for .NET architecture offers the best of both
worlds for Delphi developers: it enables you to capitalize
on your existing source code and developer experience to
target a new and growing .NET platform with a minimum of
downtime lost to retooling and retraining.

ユーザの少なさはこれを信じる人が少ないことを示しているな。

その結論だと、ほかからの新規参入のメリットなんてない、と読めるし。
最大限成功しても現DELユーザの数より増えるわけない、と思ってるようだね。

.NETライブラリはOS依存なクラスが貧弱だが、
OSが変わっても使えるクラスは充実している。
たとえば、ビジュアルコンポやそれを拡張するための機能は貧弱で、
文字列操作や算術や型操作などは完成されている。
無理にDelphiの機能を使う必要はないし、
.NET流の書き方のサンプルはVCLソースみればいい。

>>91

禿道。で、なぜ Del8？ サンプル豊富だから？

>>90

VCL.NET は既存コード移植以外メリットなし、とも読めるな。

>>92
クラスライブラリにもVCLにも不満だから。
クラスライブラリに不満ってのは言い換えれば、OS依存機能使いたいから。
つまりXP/2K向けアプリを作りたいから。
で、AnsiベースでXPに不具合も出るVCLにも不満と。
両方使えて非常に手に馴染んでるよ。

>>94
> つまりXP/2K向けアプリを作りたいから。

Delphi7 使えばいいじゃないの。

> で、AnsiベースでXPに不具合も出るVCLにも不満と。

文字列操作のためだけで .NET アプリをつくってるわけ？

>>95
いや、もうD7には限界感じた。
D8はじめたらD7もう要らないって感じたし。
D7でムカつかない人はD7使えばいいんじゃない？
俺はもう使わないだろうけど。

>>96
>D8はじめたらD7もう要らないって感じたし。

そうなんですか。
D8 のほうが D7 より出来ることが多い、と。

わかりました。ありがとう。

>>88

TRecord = packed record
a: Byte;
b: Byte;
c: Byte;
end;

こういう構造体があったとしたら、今までは
FillChar(Rec.b, 2, 0);
のようにbの位置を指定してbとcを同時に代入できたけど、D8ではFillCharのように手続きとして実現できませんよね。

出来ることが多いかとか言うことより、
ムカツクのはむしろ、TApplication使う限り修正出来ない不具合だったり、
ロケール依存な内部処理なんだよね。
95系OSで動作可能な時点で不便すぎ。

>>98
できない。
でも、そういうコード使うこと自体が自己満足にすぎないと必死で反論しておく。

JPEg ユニットはどこに行きましたか？

散歩

TBitMap が JPeg も Gif も読み書きできるようになったのでなくなった。

ダミーのユニットくらい入れておけばいいのにね

Del8とそれ以前のバージョン両方で動作するソース書くのって現実的？
フォームのファイルとかには互換性あるの？

>>104
8で作ったnfmの拡張子をdfmに変えて7に読ませたら読んでくれたので、互換性はあるのだろう
ポインタ/型無し操作関係が全滅してることを考えたら、Delphi7以前/Kylix、よりも、{$IFDEF}の嵐になりそうだが
それでもまったく完全に不可能というわけでも無さげ

どこまで実用的かは知らない

三つ同時公開上げ

Delphi8 .net Update#2
Documentation Update
InterBase 7.1 Service Pack 2

あー、日本語版には反映できない模様。

これはとても良いものだが、
.NET素人にもDelphi素人にもおすすめできないな。

Update#2 の修正点は
ttp://community.borland.com/article/0,1410,32020,00.html
に。

だが韓国語のバグは直っているのに日本語のバグらしきものはまったく記録がないぞ。

http://bdn.borland.com/article/0,1410,32024,00.html
（Excite web翻訳）

デルフォイ8およびWin32は詳細を更新します。 - Anders Ohlssonによって


アブストラクト: .NETとWin32のためのデルフォイの将来に関するマイケルSwindellコメント

マイケルSwindellはこの威厳のあるポストを記入しました、の中で、delphi.non-技術的、
それは.NETだけでなくあなたのうちの多数が待っていたものの将来について話す―Win32。
それを読んで幸福にしてください!:-

主題:デルフォイ8およびWin32は詳細を更新します。
発信者:マイケルSwindell
日付:10:53amに03/11/2004

私の初期のメッセージから上昇して1か月以上前に少し続くこと-デルフォイ8最新版2
は今週の終わりまでにダウンロードに利用可能になります。この第2の最新版は、
デルフォイ8の既によい品質のを改良し、200以上のアドレスされた問題を備えた年
の私たちの最高品質のデルフォイの障害を上げます。すべての詳細を備えた完全な
readmeで見つけることができます。

AndersのWeblog .さらに、私たちはさらに完全なドキュメンテーション最新版を同時に
利用可能にするでしょう、それはデルフォイ8ドキュメンテーションを改善する、
の中で、役に立つ内容および容易さの両方の中で。見ることを期待することができる
次の最新版はデルフォイ7(Win32)に向かってあるでしょう。

私たちは、第2・四半期にリリースされると予想されるデルフォイ7.1パッチを処理しています。
この7.1の最新版は、特にdbExpressエリアで、様々なデルフォイ7が出すアドレスへ計画され、
すべての公認のデルフォイ7およびデルフォイ8顧客への無料のダウンロードのように
利用可能になります。

（…つづき）

私たちは、Win32支援が特に既存の適用の維持のために、だがさらに新しい適用開発
のために、多くのデルフォイ開発者にとって引き続き重要であることを認識します。
そういうものとして、私たちは、さらに当分の間新しいデルフォイWin32特徴を支援し
開発することを継続することを計画します。私たちの計画は、次の主なリリース
(それは同じIDEへWin32および.NET特徴の両方を組み合わせると計画される)
での側面のデルフォイ.NETに沿った「ガリレオ?ﾌ」IDEへWin32支援を移動させること
を含んでいます。 したがって、あなたがまだ6を通ったデルフォイ3上にいて、
あなたが、v7を越える、v7最新版あるいはWin32コミットメントに関するニュースの
ために?Aップグレードするのを待っていたならば、今はデルフォイ8で大きな改良価値
を利用する時間です。

http://shop.borland.com/delphi

(…つづき)

私たちはWin32開発を支援し続けることを計画しますが、
そこに、私たちの.NET勢いの中に下へ全く遅くないでしょう。私たちは、デルフォイで
ますます多くの.NET技術を支援し続けることを計画します―ロングホーンまでずっと、
コンパクトなフレームワーク、.NET Whidbeyおよびユーコンのように、WinFX、そしてを
越えて。そのように、あなたは長い時間デルフォイWin32開発者ですか、あるいは1つの
.NET開発者あるいは両方ためにすぐに―あなたがv7またはv8にまだアップグレードして
いなければ、私は高くそれがそうであるデルフォイ8(それは箱にWin32のためのD7を含んでいる)
に改良を推薦します、Win32および.NET開発者の両方に対する大きな値。一方の方法、
.NETあるいはWin32、私たちは質デルフォイ・リリースおよび最新版であなたを支援し
続けるでしょう。

デルフォイ開発チーム全体を代表して、感謝、デルフォイ8の使用のために再び!
敬具

―行く、デルフォイ!

マイケルマイケルSwindell管理者開発者
ツール-デルフォイと.NETボーランド・ソフトウェア株式会社

某 ML には何日後に転載されるか？
あっちは日本語版出るまでは動かないかな？

長々と貼ったみたいだけど、つまりどういうこと？

次は Delphi 7.1 のアップデート。
その後に Delphi8/W32.

BCB7は？

Delphi8未購入です。教えてください。
VCL.NET では GDI+ の機能にアクセス出来るように TCanvas TPen TBrush など
が従来のものより拡張されていますでしょうか。また、リージョンやパスについて
はどうでしょうか。お願いします。

7.1ってD8のことじゃないの？
Binフォルダもレジストリも全部7.1になってるんだけど。

>>116
いいえ。
VCLのコントロールはWin32で制御します。
System.Windows.Formsのラッパではありません。

別に混ぜて使っても問題ないし。TCanvasが拡張されているかとなれば否だけど。

>>117
7.1は、Delphi8のIDEを作るのに使われたDelphi7のマイナーバージョンアップ版のことらしい。
今度のアップデートでそれが公になるのだろう。

つまり今度のアップデートでは、日本語パスが使えないD7が公開されるってことだ。

VCL.NETアプリってユニコードウィンドウ作ってるけど、
それって、98/Meじゃ動作しないってことだよね。

まだ日本語パスを使おうとしているど素人がいるのか。PGやめれば。

>>118 >>119
ありがとうございました。

>>120
D8で日本語が通らないのはデバッグ情報を吐いてる部分のようなので、関係無いだろ

>>121
Windows.Formsだって同じじゃん
CharSet.Auto属性付けてインポートしている限りは、.NETランタイム側でA/Wを呼び分けてくれる

今日Delphi8が到着。
やっぱ.NETのAPI使うよりVCLが楽だべ。

なんか脱力するな〜

ASP.netでMySQLは使えないの？

>>127
ttp://sourceforge.net/projects/mysqlnet/

わーい
ありがと！

>>124
お仕事ご苦労様。

صصڥڥܓܓةةڪڪއއޝޝ

>>130
オマエモナー

7.1はユニコードウィンドウ作ってくれるのか？

D7アップデートはいいことだけど、
D8のネイティブコンパイラって出ても意味なくない？
ガベコレ無しでクラスライブラリ使ってもなぁ。
速いネイティブライブラリやWIN32APIで全部やるべきだよ。

ガベコレって楽だし、ベンチマークでも速度出るけどさ、

結局メモリ使いすぎて最終的に重くなるでしょ？

OSレベルでガベコレやってくれればいいんだろうけどね。

>>135
Longhorn(WinFX)がそれに当たるのでは？
まちがっていたらｽﾏｿ

>>131
>7.1はユニコードウィンドウ作ってくれるのか？
tnt 使えば昔からできるってばよ。

IDEのエディタにどこの国の言葉かもわからない文字を入力したら、
ユニコードで保存するか聞いてきた。

ところでさ。WinForm化したい場合、アクション関係はどうやって移植する?
これが非常に悩みどころ。全書き換えしかないのだろうか。
同等の機能をサポートするクラスがあればいいのだが。

情報を集約して質的な向上を図る為に話題は2chではなくMLに書き込んでください。
異論はあるでしょうが日本でのDelphi.NETの活性化の為ですのでご理解ください。
（あまりこのスレが伸びるようなら削除以来を出すことになると思います。）

*** 終了 ***

MLって、よく知らないんだけど、そんなに廃れてるの？

>>139
そんな新機能使ったこともないからモウマンタイ。

>>139
http://www.codeproject.com/cs/miscctrl/actionlist.asp?target=Action

Controlをから単純なコントロール作ったんだけど、
いまのところ、ソースをメインフォームにusesして動作確認している。
ほかの言語からも使えるDLLにする方法がわからない。
パッケージだとdcuilしか作ってくれないしどうしたものか。
っていうか作れるの？

あ、できた。
どうやら今回は、「暗黙のうちに組み込まれた」は致命的エラーで、
明示的に追加しないとDLL作ってくれないということだったみたい。

>>142
だからお前は所詮そこまでだって言われるんだよｗ

>>146
いや、あなたと一緒にされても... ;-)

>>146
actionが無いから組めないソフトウェアってのは無いからね。モウマンタイ。

無事にVS2003のフォームに貼り付けできたが、
純粋にクラスライブラリだけ使った場合のサイズ24.5KBに対し、
Borland.Vcl.WindowsからAPI一つ使っただけで、500KBになった。
DLL作成には明示的なContainsが必要で、
Windowsを追加すると、Typesも入れなきゃいけなくなり、
明示的な追加をするとパッケージ内で使用していない型も含まれてしまう。
そういうわけで、APIを使うコンポを公開する場合は、
Windows.pasを使わないで、Windows.pasから関数をコピペした方がいいみたい。

>>148
Actionが必要なんじゃなくて、ショートカットキーの処理が必要なのでは？
非表示のTActionにショートカットを持たせて、、、っていうことをやったことがある。

>>149
…本当だ。
dllの場合は、package/libraryのどちらを使ってもスマートリンクはされないみたいだ。
何が使われるのかがわからないためなんだろうけど、
実際目にすると、やっぱexportsを明記したくなる…(貧乏性と笑われるのかな？)

exeの時はスマートリンクされるんだよなあ。やっぱ、exeひとつで完結させるのがDelphi文化か…？

Helpをみると
「ユニット '%s' は暗黙のうちにパッケージ '%s' に組み込まれました」
は警告ということになってるし、無視しても構わないことになっている。
実際dcuilまでは作られるわけだから、あとはリンクだけなんだよな。
激しくバグ臭い。

作ったDLLは、公開したいコントロールのみをメインのユニットにおき、
内部データを扱うクラスなど公開する必要のない型を、
はじめから別ユニットにおいて設計したんだけど、
結局全部明示的に追加することになってしまい、
ネームスペースが増えて逆に使いにくいDLLになってしまった。
privateのものも含めて、公開したいコントロールのプロパティや関数は、
integerとstringしか扱っていないので、
メイン以外のユニットの型もネームスペースも全然公開する理由はないんだけどね。

>>140
> 情報を集約して質的な向上を図る為に話題は2chではなくMLに書き込んでください。

どこに書き込もうと書き込むほうがきめることだろう。

> 異論はあるでしょうが日本でのDelphi.NETの活性化の為ですのでご理解ください。

ここでは十分活性化している。ML のために Delphi があるのではないので、そこを
よろしく。

> （あまりこのスレが伸びるようなら削除以来を出すことになると思います。）

めちゃくちゃな論理ですね。ML があまりに活性化するならスパムメールを流しますよ、
と同じ論理。

>>141
> MLって、よく知らないんだけど、そんなに廃れてるの？

昨日１通、今日はここまで２通、どちらも Del8 とは無関係。
廃れてるかどうかは見方による。

>>154
煽りにマジレスするなよぉ--

すまん

WinFormアプリの開発についてですが、タブルクリックなどでソースに追加されたイベントコードを簡単に削除する方法はないでしょうか?
VCLなら今までは空のイベントコードはコンパイルすると自動で削除されますよね。そんな感じにさくっと削除したい。

>>157
あれも考えもんだけどなぁ。

ダブルクリック、取りあえずせーぶっとー＞くがぁ！

>>157
VS2003でもおなじだけど、
オブジェクトインスペクタから削除する。

デルファイ８.NETアップデート版、宅配で届いたまんまだった・・・
素朴な疑問ですが、これのインストーラには.NETframeworkのインストール
も含まれているんでしょうか？

入っています。

>>161
おお賛楠。これからインストールします〜

俺はWindows Updateに陳列されたものは全部入れないと落ち着かない性格なので、
どいつもこいつも.NETインストール済みなんじゃないかと誤解してた。

俺は未だに入れてない

>>163
俺も Update で入れとくけどね。
ただ、SKU は Update では入らないから..

デルファイ８.NETなんとかインストール完了しますた。どうもでした。

SKU -> SDK

Win32コンパイラも出るということで、今まで通りtry...finallyで解放しているのだが、
それって.NETではなにか不利な点はあるのかな？
たとえば遅くなったり、資源消費したりとか。

俺みたいに、開放したからといってホントに開放されているかどうかまだわからない素人が言う事じゃないんだろうけど

.NETがベンチマークでまあまあ良い成績を出せるのも
一つはガベコレで、開放作業を遅延してるからってのもあると思うよ。
開放作業を遅延してるからNewも穴の空いたメモリを検索しなくてよいから速くなるし

Delphi.NETのfinallyでFreeって、C#で言うusingみたいなもんで、デストラクタの類は呼ばれても
実メモリは開放されないんじゃ無かったっけ？勘違いか？

>>169
インスタンス生成・廃棄しないベンチでもそこそこのパフォーマンスが出てるよ。
それなりに新しいアセンブラの命令生成するし最適化もそれなりにやってるよ。

CPUやメモリの動きを意識しないで書くべきなんだろうけど、
それにしても、同じことをやらせるのに速い書き方と遅い書き方があると思うんだよね。
その辺がわかってないせいか、どうしても.NETは遅く感じる。

record型のプロパティをオブジェクトインスペクタに公開するにはどうするの？

>>173
Delphi８ではできるんですかねぇ
すくなくても Delphi７ までではできませんね。ヘルプより

published が指定できるプロパティは特定のデータ型に限られます。
順序型，文字列型，クラス型，インターフェース型，およびメソッド
ポインタ型は published が指定できます。

あの、たとえば

procedure TWinForm1.Button1_Click(sender: System.Object; e: System.EventArgs);
begin
Console.WriteLine('test');
end;

とした場合Delphiではどのウィンドウに出力されているのですか？

勝手に生成されたresxファイルを削除したが問題ある？
再生成してくれないんだけど。

>>175
プロジェクト-オプション-リンカ
でコンソールアプリケーションにチェックすればそれ用の窓が出る。

シンプルなアプリを作ってみたんだけど、
心当たりのないのにスレッド数が6まで増えたし、
メモリ使用量が40メガまで増えて下がらない。
大丈夫か？

.NET Framework が立ち上がったのでは？

>>177
最小化してみましょう。

お前らDelphi8使ってて恥ずかしくないの？
以前はあれだけ.NET叩いてたくせに。ｗ

ここで書くのも変ですが、Delphi8のASP.NET開発では、
・必ず最初はワーカープロセスにアタッチできないエラーになる
　※Readmeに書いてあります

・デバッグ時に、不安定となりIDEごと突然落ちる
　※最悪はWindowsも落ちます（2000とXPで経験）

・Pro版にはDB WEBが付属していない
　※最初の案内にはそんなことは書いていなかった様な気が。。
　　DB WEBが付属しているENT版以上を買うのがお勧めかも。
　　付属のサンプルでちょっとだけ試しましたが、かなり強力です。

・付属のComponentOneは英語版
　※サンプルは豊富ですが、ライセンス情報を付加しないといけないなど
　　ちょっと面倒な部分があります。
　※１回限りのバージョンアップ権利が付属

・ComponentOneを使った時の、今後のバージョンアップが心配
　※Delphi9でこのコンポが同梱付属しなくなれば大変なことに。。

・Delphi7のIntraWebからの移植は不可能
　※サードベンダーコンポが付属していないプロジェクトの移植は難しい

・データベース接続にはBDP.NETを使うことが前提になっている
　※SQLDataAdapterなどもツールパレットに追加できますが、
　　ウィザードが起動できないなど、妙な制約があったりします。

全体的には、IDEの安定性がかなり低いという気がします。
また、コーディングについては、C#でのアプリケーションコードの記述を
Delphi言語に変換した感じで、従来のDelphi言語の特色はあまり見えない
ように感じました。

> 従来のDelphi言語の特色はあまり見えない

いや、だから、なんで....

> ・必ず最初はワーカープロセスにアタッチできないエラーになる

「* .NET Framework のインストール後に IIS をインストールした場
合は・・・・」でしょ？

> ・デバッグ時に、不安定となりIDEごと突然落ちる

うちでは突然おちたことはない。メモリが足りないとか？
たしかに以前のIDEよりは不安定というかもっさりだけど。
IDEの開発担当者は変わってないみたいなのになんでだろね？

> ・Pro版にはDB WEBが付属していない

これは痛いよね。でも今までもENT版以上にしか付いてなかったコンポが
後になってPro版にも搭載された事があったと思うんだけど次のバージョン
あたりでそうなるんじゃないかなぁ、と希望的観測。かなりの売りというかアピールできる要素なのにね。

>・ComponentOneを使った時の、今後のバージョンアップが心配

個人的には使わない。確かにバージョンアップも今後も心配。

> また、コーディングについては、C#でのアプリケーションコードの記述を
> Delphi言語に変換した感じで、従来のDelphi言語の特色はあまり見えない
> ように感じました。

PascalというかDelphi言語に元々それほど際だった特色はなかったと思うけど。VCLは特色合ったけどさ。
個人的にはC#のサンプルでもVBのサンプルでもライブラリが統一されて移植が簡単になったのでうれしい。

＞個人的にはC#のサンプルでもVBのサンプルでもライブラリが統一されて移植が簡単になったのでうれしい。

移植の必要すらないと言うことに気付いてあげないとMSのしたことが無駄になります・・・。

>>179
最小化したら500KBまで下がった。
で、元に戻したら15MB位になり、動かしてるとまたどんどん上昇。
.NETってそんなものなのかね。
こういう動作をするアプリばかりになるなら、
長角時代には必要メモリが十倍以上に跳ね上がるだろうね。

そりゃだって5年先ですから

>>185
二つ起動したら30M使うの?

一つ起動したら40MB、二つ起動したら両方とも40MBで計80MB、
たくさん起動したらそれぞれ40MBで、スワップが発生して引っかかるようになる。

>>184
でも言語依存の所はちょっと移植いるし・・・・・

>>184 >>189
かみ合ってないし。

やっぱりなんかさ、C#って見かけがきちゃなくね？

きちゃないのはむしろDelphiのほうだな。XMLDOCもないし。

C#
System.Security.Cryptography.DESCryptoServiceProvider des = new System.Security.Cryptography.DESCryptoServiceProvider();

Delphi
var
des : System.Security.Cryptography.DESCryptoServiceProvider;
begin
des := System.Security.Cryptography.DESCryptoServiceProvider.Create;
....

XMLDOCってC#独自のクラス？

with System.Security.Cryptography.DESCryptoServiceProvider.Create do try

・・・・

finally free end; <-- これって書いた方が安心なんだけど、書いていいよね？

いらないんじゃないの？
ってどこまでGCが面倒見てくれるのかわかんね。

長い識別子で思い出したんだけど、Delphiの場合省略できるよね。
みんなフルネームで書いている? それてとも省略形?
どっちで書いていいか基準がわからん。
省略するとすっきりして見やすいが、ありきたりのクラス名だったりすると
どこのクラスかわからなくなるんだよな。

>>195
今月のCマガにDelphi8でFreeしたときの動作について書いてあったので読んでみては。

>>195
書いたり書かなかったりで試してみるといいよ。
でかいメモリーを連続で要求する場合なんか、解放していかないとスワップする。

自分で試したり雑誌を買わないとオブジェクトの開放という
最も基本的な動作についての情報が得られないんですか?

人として基本的な動作ができない方ですか？

.NETってのはそういうもんだろ。
というかソースが無い世界ってのは、巨大なブラックボックスの迷宮。
番地は割り振られているが明かりの無い路地をランタン一つで探ってゆかなくちゃいけないのさ。

言われ尽くされてきたことだが、関数ならまだしも、
クラスライブラリでソースなしってのは、致命的。
やっぱ、パクリが多くて公開できないのかな？

釣られたい人はもうちょっとふざけてください

>>200

Delphi8 を選んだ時点でそういう道を選んだ、ということ。
自覚してください。



まっ、別の道もあるがな。

>>205
おまえ、分かってて言ってる？

> 明かりの無い路地をランタン一つで探ってゆかなくちゃいけないのさ。

自分でやらなけらばならないのと、先人が努力して残して置いてくれた地図があるのと
は大きな違いだろうね。冒険したくて、地図がないほうがいい、その方がすき、って
いう変わった人たちが Delphi8 を使ってるんでしょ？

だれがDelphi8使ってるって？売ってもいないのに。

どっちかいうと地図だけを頼りに旅行するようなもんじゃないの？

結局CreateしたオブジェクトをFreeすべきかどうかについて
明確な指針を示すことが出来る人はこのスレにはいないんですね(ﾌﾟｹﾞﾗｯﾁｮ

かりに、2ch でその「明確な指針を示すこと」ができたとして、きみはそれを
信用するのかね？ Delphi.NET の情報は 2ch に頼らなければならないほど
不足してるのかね。なにを好んでそんなものを使ってるのか問いたい。

D8の使用許諾読んだ？

1.ユーザーは煽りにマジレスしなければいけない

最悪です。

おまえらあほですね。
デストラクタ呼びたいときにFreeするんだよ。

こりゃあＯ野さんも見放すわな。こんな低レベルなユーザ連中じゃあ。

パーソがない分、厨房率が下がると思いきや、
紙マニュアルがない分跳ね上がった。

そういえば正規表現ライブラリｲﾗﾈとかのたまってた奴は
Delphi.NETでも相変わらず使ってないんだろうか。

>>216
買わないと思うけど

> パーソがない分、厨房率が下がると思いきや、

それは違う。厨房しか買わないからほぼ１００％と見た。

>>180
放置されてるみたいだから一言
「.NETを叩いてたのはJava信者でしょ」

DEL厨は叩けるほど知識ないよね

>>220
両極端かも
.NETもうやってます派と.NETｼﾗﾈｰﾖ派

いつの間にかオペレータオーバーローディングもサポートされたのね。

多い奴ではもうどれくらいいじってるだろうか？
俺は6000行くらいあるUserControlを作ったが、もうかなりやる気なくした。
このコンポをC#など、他の言語からも使えるDLLにするには、

1、ボーランドのランタイムをrequiresする。
2、単体使用出来る形にする。

だが、2を選択すると、ネームスペースBorland...がDLLに含まれることになる。
この状態でC#等で問題なく使えることを確認したが、
肝心のDel8ではネームスペースの競合が起こって使えなくなる。
かといって1にしたら、普及するかどうかもあやしいランタイムなしでは動作しない。
D8インストールしてない環境で動作させてみて気がついた。

おまえら、Windowsフォームはあきらめるか、
ある程度.NETに慣れたらC#に移行すべきだよ。

http://qc.borland.com/wc/wc.exe/details?reportid=7591

ここに報告されてるみたいだけど今のところ反応ないみたいね。
なんかやり方あるのかなぁ。

ランタイムっていってもBorland.Delphi.dllの90KBが必要なだけ。
普及しなくても同梱して問題ないサイズだろう。

>>223
> ある程度.NETに慣れたらC#に移行すべきだよ。

ある程度のDelユーザなら、Del8スルーして、C# から .NET 入門できるでしょう。

>>225
美しくない

>>227
たしかにDLLがいっぱいついてくるC＃アプリや、
OCXに頼りぱなしのVBや、
スタンダード版で構築したMFCアプリは美しくない。
しかし、無駄に大きいVCLアプリやUPX圧縮も美しくない。

>>195
[Borland Help]-[Delphi8 for ...]-[リファレンス]-[Delphi言語ガイド]-[メモリ管理]-[.NET プラットフォームのメモリ管理の問題]

「ユーザーがそのオブジェクトに対して明示的に Free を呼び出さなかった場合，オブジェクトは解放されます」

ガベコレって便利なんだけどなんとなく気持ち悪いね。

Cマガで、ﾅｶﾑﾗたんが D8 の悪口書いていると聞いたんだけど、誰か教えてくれません？

自分で買うか立ち読みしろよ。ヒッキー？

立ち読みしたが、たしか、ドキュメントが最悪って。
その他はの不具合は、まだ.NETの一発目なので大目に見るような感じだったかな。

Delphi1初登場のときってそんなに品質悪かったかな？

そんなにってなんだよ。

nyにも出回らないDelphi8って終わってるね♪

>>236
俺は買ったけどタスクに入れてる。
代々全部買ってるけど認証がどうしても嫌いなのでD6からはいろいろとね。
D6では認証コード生成ツールだけで通ったけど、D7はクラック版EXEだったな。

次スレ（あればだけど）のタイトル決定！！

【ユーザ】Delphi8 for .NET 3【どこ？】

>>238
作者には内緒だよ
http://up.isp.2ch.net/up/178c5364d3e4.png

これは何？ > 239

.NET製のメモ帳っぽい

たぶん、ぎょえだよ。
そう書いてあるから。

.NETではないんじゃない？
BackgroundImageってTextBoxやRichEditには使えないよ。

Avalon使ってるんだろ

VB.netスレってふいんきいいね
まるで昔のDelスレを見るようだ
何でこっちはこんなに寂れうらびれてるんだろうね
未来がないからなのか
それとも単に高くて使い道がないからなのか
Delphiが終わってるからなのか
Borlandが終わってるからなのか
このスレ読んでて涙が出てきたよ

ttp://pc5.2ch.net/test/read.cgi/tech/1078134703/15-19

15 ：デフォルトの名無しさん ：04/03/04 08:51
VB.NETのProffesionalとStandardって、
VB6.0のときなみに機能差がありますか？

16 ：デフォルトの名無しさん ：04/03/04 10:55
>15
機能差があるから名称が違うんだとオモワレ
恐らく機能差を書いて欲しいんだと思うけど
自分で調べれ

以上

17 ：デフォルトの名無しさん ：04/03/04 14:50
>>15
VisualStudio.NETと間違えてないか？

18 ：デフォルトの名無しさん ：04/03/04 22:06

就職の関係でVB.NETをやろうかと
考えているのですが、VB.NETって
現行バージョンで打ち止めなんでしょうか？

19 ：デフォルトの名無しさん ：04/03/04 22:11
釣り警報

ユーザーは一人か

>245
ふいんき？腐陰気が漂っているのはよくわかった。

VBは知らないけど、.NETはどの言語使っても結果が同じなんじゃないの？

> .NETはどの言語使っても結果が同じなんじゃないの？

そりゃ Win32 でもアセンブラでメモ帳を作ることはできる。Delphi なら半日くらい
でききるけど、アセンブラなら大変。結果に差がなくても、開発の効率は言語に依存
するよ。

早けりゃいいならVBの圧勝じゃん。

ここはDelphi.NETとVB.NETの比較を
Delphiとアセンブラに例えるインチキ野郎のすくつですか？

ここは抽象とか比喩とかを理解できない、アホの巣靴ですか？

Ｃ＃でいいでしょ。
開発効率ならDelphi.NETは論外。情報なさ過ぎ。

C#≒VB.NET>>>>>>>>>>>>>>>>>Delphi.NET

まぁ次世代Delphiで軽く逆転するのは目に見えてるけどな。

次世代ではドキュメントがありますか？（藁

来世の間違いでは？

M$　　　vs　　某
--------------------
MS-C△　　Turbo Pascal△
MFC○　　　　OWL×
VB×　　　　Delphi○
MFC△　　　　BCB△
C#？　　　Delphi.NET？

>>259
お前の分類能力にだいぶ不安があるな。
一度精神科医に診てもらったらどうだ？

>>260
9.自分の見解を述べずに人格批判をする

260は一度ではなく通院中

VBもC#もろくなもの作られてないのは開発効率に問題あるからだよな。
D8より前のDelphiに比べて。

> VBもC#もろくなもの作られてないのは開発効率に問題あるからだよな。
D8より前のDelphiに比べて。

ちがう。現行の .NET がスカだから。開発効率関係なし。

> D8より前のDelphiに比べて。

D7以前ではそもそも.NETが作れないので比較にならん。頭確か？

×　.NETが作れないので
○　.NETアプリが作れないので

.NETがスカなのに.NETアプリ作れなきゃ話にならないってどういうことよ。

わざわざスカな.NETで何が作れるかが偉い基準かもしれないし

> .NETがスカなのに.NETアプリ作れなきゃ話にならないってどういうことよ。

.NET 上での開発環境・言語について議論してる。
Win32 アプリは無関係、ってことでしょ

わざわざスカなVBが偉い基準だと思ってたヴぁかも多かったし





MFCもスカだった

>.NET 上での開発環境・言語について議論してる。
>Win32 アプリは無関係、ってことでしょ

頭カチカチだな。




.NET使うにはWin32呼ぶ局面が必要な今

>>267
そうだね。今はスカだが、.NET 構想 → WinFX がスカかどうかはもう少し時間が
経ってからでないと分からない。

> .NET使うにはWin32呼ぶ局面が必要な今

頭ふわふわだなぁ。そんなアプリなら Del7 以下でつくれよ。
なんのために .NET アプリつくってるの？

まっ、アホはWin32API使いまくりで .NET アプリつくってればいいよ。

つでに VCL.NET も使いまくって、もうキワモノ路線で突っ走れよ。
だれも相手にしないがな。

>>274
おまえみたいに十分に相手してくれる奴もいる

.NETを学習する意義はあるかもしれない。
CLRを利用する意義はある程度ある。
クラスライブラリを利用する意義は結構ある。
将来の互換性次第では.NET用アプリを作る意義はある。

しかし、Ver1.1をAPIなしで利用する意義はない。
俺はアホだからAPI使いまくりがちょうどいい。

>>276
ログがとんだ分に書き込んだひとと同じひとだね。
そう、レスを書いてるおれも同じだけどね。（藁

一応、あのときと同じ 禿道 ってことで。

単一EXE以外は美しくないって思わない人は、VC＃併用がオススメ。
D8やってからVC＃に戻ってみて、補完、ジャンプ、F1などの快適さを痛感した。
VC＃のみでもいいくらいだが、uses Windows,Messages,Classes,SysUtils;も捨てがたい。

>補完、ジャンプ、F1などの快適さを痛感した。
ってのは VStudio の完成度のほうが高い。っていみだよね？

>uses Windows,Messages,Classes,SysUtils;も捨てがたい。

これだけのためにDel8つかうのもなんかなぁ。
WinFXになっても使い続けるんだろうか？

もうそれぐらいしかDelphi.NETのメリットはない、ということなんだろ。
あほらし

D8使う理由を問い続ける、D8欲しくてたまらないけど、自分で理由が見つけられない人

帰れや

> 帰れや

どこに？

学校に決まってるじゃん

学校か！　病院とかいうとおもた。傑作。春休みだねぇ。

バレバレ

Del8 ユーザ、ネタまだぁ？　って、いないのか？........

そもそもどうしてそこまで粘着するほど欲しいんだよ？
おまえが自分でさんざん言っているとおり、買う理由なんかさっぱりないぞ。
それでも好きでやってるアフォ共と話がかみ合うわけがないだろうが。

某から封書で尻が届いたんだけど、そもそもこれ何？
ttp://www.borland.com/opt_profiler/
だれか使ってみて感想言え。

感想教えてあげるから、尻、教えろ。

届いてないやつの感想は参考にならない

Delphi8 Personal
ttp://www.borland.co.jp/delphi_net/personal/

フリー版リリースされてる!

>>292
ﾔﾗﾚﾏｼﾀ

日本語版が出荷されてから一ヶ月。
だーれもなんにも作ってないんか？
これじゃＣ＃やVBと同じで開発出来ない開発ツールに終わるな。

.NET拡張されたWin32版まだ？

>>295
そう、それ早く出せ。

それとDelphi64。

>>295-296
どっちも出さない。
.NET対応してないけど、ユニコード対応などがされたWin32版じゃなくて？

.NETでVCL作り直せ

VCLで.NET作り直せ

>>298のいうVCLが、過去のビジュアルコンポを指すなら無理。
RTLも含めるなら、現状で既にClassesなどおおかた.NET。
新しいOS向けの新しいVCLを作り直せ、旧式OS互換ライブラリ切り捨てろ、なら禿同。

対象OSが全く違うDelphiとKylixで互換性があるVCLを作れたんだから、
同じように.NETでも互換性があるVCL作れるでしょ？

64ビット版が欲しい子はどのOS向けに開発したいのか、
APIは何を使うつもりなのか、その辺考慮してるんだろうか。
考慮した上で、やっぱりVCLでやりたいんだろうか。

>>301
それが現在のVCL.NETだよ。
これ以上どうにかするには、某の努力じゃなくてMSの努力が必要。

ということはWin32でも.NETでも同じように使えるVCLでは、
.NETだけで新たな機能が追加されてもVCLでサポートされ無さそうだな。
これ以上.NETの親和性を高めたいのならWin32を切り捨てなきゃならないのか。
なんか「VCLって死滅しちゃうの？」って感じだな。

>.NETだけで新たな機能が追加されてもVCLでサポートされ無さそうだな。

この前提が間違ってる。
VCL/CLXはそれらの固有部分も入ってるし。足りないものは足したりもされてるし。
もっとクラスライブラリの知識を付けてね。

>>304
オーバーロードで結構な機能追加があったようだ。
例えばTStringListの文字エンコード指定読み書きとか。
Win32用（というか95系用）に作られたVCLはもう切り捨てて死滅して欲しいが、
ライブラリ肥大という形で今後も互換性を引きずって存続しそうだから困る。
Kylix用の{$IFDEF}まで残っているし。

Delphi6で作ったフリーウェアをゼロから書き直そうと思ってんだけど
どのWindowsでも動く（含Longhorn）Delphi7で行くか
Longhorn以外では.NETもインストールしてね、というDelphi8で
行くかすごく迷ってる。

LonghornでもWin32が動くなら.NETなんかいらないというか
ユーザーにも開発者にも手間なだけな気がしてるんだけど
今後のことを考えると.NET使っといた方がいいのか・・・混乱。
Win32アプリが切り捨てられるのはずっとずっと先のことだろうしなぁ。

お前ら本当に雑談が好きですね

>>297
それがでるんだってばよ・・・
Delphi7のアプデト扱いだっけか？

次は、高階関数の実装を頼むよ
関数内関数をもっと使いたい

>>307
>今後のことを考えると.NET使っといた方がいいのか・・・混乱。
>Win32アプリが切り捨てられるのはずっとずっと先のことだろうしなぁ。

WinFX でも Win32 アプリは動作する。けれども、新しい機能にはアクセスできない。
たとえば、WinFS で導入される新しいファイルシステムの機能にはいっさいアクセス
できない。ＭＳの思惑を考えてみてよ。好き嫌いは別として、WinFX をプラットフォーム
として認知させたいので、今後、新しい機能は WinFX 以外ではアクセスできないよ
うにするだろう。ユーザがたとえば、新しく作ったドキュメントファイルを名前を
つけて保存しようとする場面を想像してみると、従来のコモンダイアログからは
アクセスできない領域があることを知って、もう、二度とユーザはそのアプリを使わない
ようになるかもしれない。Windows 上の開発者として、.NET 上での開発を無視
することはできない。ただ、今から始めるかどうかは、人それぞれだろう。
おれはもう少し様子見する。

>>309
Del7 のバグフィックスだけじゃないの？ Delphi7.1 になる予感

>>307
長角におけるWin32アプリは、「Win32互換モードで動くけど古いアプリ」だ。
長角におけるD8で作ったアプリは、「.NET1.1互換モードで動くけど古いアプリ」だ。
.NETはまだFXになってないことをお忘れなく。
Win32が切り捨てられるときが来るより先に、.NET1.0と1.1が切り捨てられるはず。

>>304
> なんか「VCLって死滅しちゃうの？」って感じだな。

確実に死滅するでしょう。
ＶＣＬは非常に優れたクラスライブラリです。それは、Win32 に特化したすばらしさ
です。WinFX は、ライブラリレベルでＡＰＩになります。現状の VCL.NET は、.NET
Framework のライブラリを従来のＶＣＬに当てはめたもので、クラスライブラリを
ラップして別のクラスライブラリを作ったようなものです。過渡期で移行専用の
意味しかありません。ちゃんとした WinFX への準備として、現状の .NET を学ぶ
のなら、むしろ有害といってよい存在です。

>>312
>Win32が切り捨てられるときが来るより先に、.NET1.0と1.1が切り捨てられるはず。

これは当然です。まぁ、平たく言えば有料で　WinFX のベータテストしてるようなもんです。

過去バージョンが切り捨てられるって言っている意味がわからないな。
Delphi6でVCLがバージョンアップしたので
それ以前のVCLが切り捨てられたと言っているようなもんだ。

>>315
Delphi の過去のバージョンのことは誰も議論してないでしょ。
Win32 → .NET → WinFX の変化、つまり、ＯＳの変更のことを言ってる。
しらないなら茶々入れないでね。

>>316
＞しらないなら茶々入れないでね。
>>313にいってやれ

殺伐としてまいりますた

WinFX は .NET を置き換えるものではない
.NET は Win32 API を置き換えるものではない
Win32/.NET/WinFX とも OS とは関係ない。

さて。どうする？

>>317
いや、313 には間違いはない。OSの変更とクラスライブラリの変更が同時である
ということを理解してないらしいのは315のほう。.NET ってなんだか知らない
人が多いのには驚くね。

>>313
WIN32API学びたくてＶＣＬ使ってたわけじゃないだろ
.NETのライブラリより短く書けるのならＶＣＬは死なないさ

>>320
319も知らないみたいだね。

>>321
>WIN32API学びたくてＶＣＬ使ってたわけじゃないだろ

そりゃそうだ。むしろ学ばなくてもよいようにＶＣＬが作られたわけだ。
Win32 がなくなったらその役目が終わったとおもわないの？ＡＰＩが変わるのに
従来と見かけだけが同じで新機能にアクセスできないＶＣＬを使う意味なんて
ないでしょ。しかも新しいＡＰＩは、クラスライブラリと同等なんだから。

>>323
ああ、VCL.NETは死滅するって言ってるわけじゃないのか

>>324
VCL.NETは死滅するって言ってる。

>>312
>Win32が切り捨てられるときが来るより先に、.NET1.0と1.1が切り捨てられるはず。
これは比べる対象がおかしい。
Win32だっていくつもバージョンがある。
Win95バージョン。Win98バージョン。Win2000バージョン。Longhornバージョン。
それらの一緒くたにしてWin32とし、.NETの場合は特定バージョンで比べるのは無意味。
Win32と.NETで比べればWin32の方が先に切り捨てられる。
またWin98バージョンがでたらWin95バージョンが切り捨てられるという言い方は普通はしない。

あと他の人もそうだが、どの部分が.NET Frameworkで提供されるライブラリで、
どの部分がOSが提供するライブラリなのかはっきり区別した方がいい。
Longhornで搭載されるWinFXはAPIと言われるようにOSが提供するライブラリ。
もちろん.NET1.0でWinFXを使うことも可能。

半可通がDelphi8の役立たずっぷりを糊塗しようと必死です

>>326
>Longhornで搭載されるWinFXはAPIと言われるようにOSが提供するライブラリ。

どうもね、これを知らない人が多いので驚きます。知っていれば、VCL.NET の
価値についても分かるはずだと思うんだよね。

> もちろん.NET1.0でWinFXを使うことも可能

これは、WinFX で .NETv1.0 互換アプリが動作する、という意味ですね。
WinFX 上で動作するわけではない。

VCL.NET は死滅するかどうか知らないが、意味がなくなるのは確実

>>326
それはちょっとあやしい。
例えに出してる古いOSのバージョンアップはケースが違いすぎる。
たとえば1.0でWinFormsだったものが、1.1でWindows.Formsになり、
実質、1.1をインストールすると1.0のライブラリもインストールされる現状だよ。

FXや、その前にも一回入るかもしれないバージョンではまた変わるだろうし、
そしたらもう一つフォルダが出来、GACにも似たようなDLLが増え、
長角で、下位互換性がいらない人は旧.NETインストールしないオプション出来てもおかしくない。

VCLはWin32という貧弱な手続き型APIをラップする
オブジェクト指向ライブラリ＋GUIコンポーネント
という位置付けだったからなぁ。

API自体がオブジェクト指向ライブラリ＋GUIコンポーネントとなる
WinFXが出てしまったら確かに死滅するだろうな。

それ以降は過去の遺産継承とかKylixとの遺産共有とか
そういう位置付けにしかならないだろうね。

>>330

>>312 の言ってることが一番マトモだと思う。v1.1 アプリは WinFX では
旧バージョンの v1.1 があれば動作可能、という意味しかない、と思う。
デフォルトで v1.1 が入っているかどうかは、まぁ、実際上は重要だがね。

ふーん。じゃ LongHorn ではどこまでが Framework でどこからが OS なんだい？

今だって、Windows は（おそらく）VC でコンパイルされていて、多くのモジュールで
MFC のライブラリを使っているわけだが、こういうのもはっきり区別できるものなのか？

>>330
> 長角で、下位互換性がいらない人は旧.NETインストールしないオプション出来てもおかしくない。
旧.NETをインストールしなくても新.NET(WinFX含む)だけで全て動きます。

旧.NETをインストールするのは、新.NETとで稀に発生する
互換性が無い部分を解決するためだけです。

(新.NETで完璧な互換性が無いのか？ と言わないこと。
　修正が入る以上、現実的には完璧な互換性を保つのは不可能。
　これはJavaやLinux等の場合を含めたソフトウェア全般の過去の事例であきらか。)

>>330
妄想。技術的根拠がないぞ。仮定の上に仮定を続けるな

>>334
それで？今までと同じじゃないか。
特定のバージョンのライブラリをアプリが必要とする。って以上の話なのか？

重厚長大なVCとお手軽簡単なVBを統合したC#はもう無敵だな

>WinFXが出てしまったら確かに死滅するだろうな。
WinFXはバージョンアップ時に大幅変更全面書き直しが続けられるのでラップが必要。

MFCのDOC-VIEWなんて、DOCが勝手にいじられてクッションの役割を果たしてなかった。
DOCも自作が良かったように、ラップはm$と切り離すのが良い。

Apache、Microsoft IISをさらに引き離す--ウェブサーバソフトの市場シェア調査
http://japan.cnet.com/news/ent/story/0,2000047623,20063630,00.htm

データベース開発市場で、オープンソースソフトが急成長
http://enterprise.watch.impress.co.jp/cda/foreign/2004/01/06/987.html

どうするIISやSQL鯖とダンゴのWinFX

というとき、IISやSQL鯖に繋がるVCL.netの出番かも。

>>338
>WinFXはバージョンアップ時に大幅変更全面書き直しが続けられるのでラップが必要。

一段薄く抽象化する意味はあるかも知れないね。ただ、現状のＶＣＬとは無関係。
「大幅変更全面書き直し」があればラッパも大幅変更全面書き直ししなければならない
のであまり有意義じゃないかも。API=クラスライブラリなら、それをそのままつかった
ほうがいいかもね。

> IISやSQL鯖に繋がるVCL.netの出番かも。

だからもうＶＣＬは関係ないでしょ。そんなのはコンポーネントレベルで解決できる。

上位バージョンDLLで過去バージョンDLLを上書きしないことを一つのウリにしている.NETで、
過去バージョンDLLを全部GACに入れて新OS出荷するってとても無駄なんだけどね。
ほんとに.NETアプリは動くのか？

Apache、Microsoft IISをさらに引き離す--ウェブサーバソフトの市場シェア調査
http://japan.cnet.com/news/ent/story/0,2000047623,20063630,00.htm

データベース開発市場で、オープンソースソフトが急成長
http://enterprise.watch.impress.co.jp/cda/foreign/2004/01/06/987.html

どうするIISやSQL鯖とダンゴのWinFX

というとき、IISやSQL鯖以外にもシームレスに繋がるVCL.netの出番かも。

>>336
今までと違うのは、新.NETがインストールされているだけで旧.NETで作られた物がほとんど動き
新.NETで稀に動かないものも旧.NETをインストールすると完璧になるということ。

今までは、ライブラリ名が同じ場合は確かに
新DLLがインストールされているだけで旧DLLで作られた物がほとんど動くが、
新DLLで稀に動かないものは対処の仕方が難しく場合によっては不可能だった。

そういうわけで、新旧互換性だけしか考慮しないならWin32アプリを作るべき。

>>345 どういうわけだよ？ｗ

Windows向けアプリの一番のお手本はやっぱりMS製アプリだよ。
MSの主力（？）であるオフィスシリーズがWin32だったらWin32で作るのが一番無難＆長寿。
本格的に.NETクラスライブラリで出してきたら、初めて信用していいと思うね。
アピ混じり.NETで出してきたら.NETはスルーした方がいい。

>>345
新旧互換性というか、個人的には.NETで作った場合の
サポートが気になります。

現状でもWin98ユーザーが沢山居ることを考えると
LonghornがでてからもXPやその他のWinユーザーは山ほどいるわけで
その人たちすべてに.NET Frameworkを別途インストしてくれ
って言ったら初心者からの「どうやってインストールするの？」
「動きません」「どこでダウンロードするの」「インストール失敗しました」
「Windows Updateってなんですか？」とかメールが殺到しそうで
サポートを考えるだけで死にそう。ホムペにFAQ書いてても絶対に
山ほどメールが来るわけで、コピペ対応だとしてもそんなメールが
毎日来たら精神的にかなりつらい。
Win32で作ればとりあえずその心配はない。
でも技術的には.NETに行っといた方が後々楽そうなわけで。。。

っていうか.NET Frameworkをインストーラに含めればいいのかなぁ？
つかdotnetfx.exeって23Mもあるよ。今のランタイム配布みたいに
全部コミコミ版とアプリのみ版みたいにしないといけないのかなぁ。

MSの主力はWindowsだろ？

> 全部コミコミ版とアプリのみ版みたいにしないといけないのかなぁ。
ご自由にどうぞ。

>>307まで思いっきり戻ってみるが、
D7でもD8でもなく、フリーのＣ＃開発環境を試してみるといいかもしれない。
で、現在の.NETへの移植は不可能であることを知ると。
そのD6で作ったものがよっぽど幼稚なおもちゃでない限り、絶対不可能だから。
それでもWin32APIも使って無理矢理.NETアプリにしたきゃD8も検討していい。
たとえ検討することになったとしても、まだバグ多いので来年あたりで。

>>348
>Win32で作ればとりあえずその心配はない。
>でも技術的には.NETに行っといた方が後々楽そうなわけで。。。

まっ、ここが悩みどころでマ板で激論が続くわけだが、そんなことは無視して、
自体は着々と進んでいるようなので、

短期的に現実的なプログラミング ＝ Win32 　このスレ的には Delphi7 以下で作る
中期的で視点で唾をつけとく　　　　＝ .NET アプリ Delphi8 やら Ｃ＃　やら

をやっておけばいいんじゃないの

> で、現在の.NETへの移植は不可能であることを知ると。
まあC#をマスターするまで時間がかかるのなら不可能でしょうね。

> たとえ検討することになったとしても、まだバグ多いので来年あたりで。
D8はまだバグが多いのか。

>>351

その感じに禿同

>>348
すごいね。
おまえの作るアプリは、初心者が初インストールする.NETアプリになりうるのか。
俺の作ったものを初心者が使う頃には類似品が複数入ってて、
油断してたらボーランドのランタイムも入ってて、
そろそろ初心者名乗るのもどうかなって思うぐらいになってるかな、
というくらい俺はマイナー路線なのでもうどうでもいい。

>>349
最近の初心者は、基本ソフトとか応用ソフト等というわかりにくい用語使ってるらしいよ。

> おまえの作るアプリは、初心者が初インストールする.NETアプリになりうるのか。

企業の社内システムとかね。企業の社内が一番ハードについては保守的なので、
そこを基準に考えると、果てしなく Windows95 までいってしまうことも

>>357
へー、そいつらが毎日のように質問メールよこすんだ

社内システムとかだったら俺だったら間違いなくWin32でGO。
よほどの理由がない限り.NET版は普及してからずーっと後で問題なし。
パッケージやフリー、シェアなど不特定多数向けが悩みどころ。

おれのところは初心者質問は週一くらいだが、
ウイルスとWarez販売とヤミ金と雑誌収録が毎日何件も来てうざい。
質問メール殺到を体験してみたい。

> パッケージやフリー、シェアなど不特定多数向けが悩みどころ。

ＭＳ製以外で
メジャーなのがあるでしょ。ＣＡＤとかPhoto屋とかベキとか秀ちゃんとか、
そんなのがぽつぽつ出てきたら、考えどころ。

>>355
俺は348だけど≠357

> おまえの作るアプリは、初心者が初インストールする.NETアプリになりうるのか。

なりうるかどうか知らないけどここ半年以内に.NETアプリ出せば
どのアプリでもそうなる可能性は高そうじゃない？
初心者ユーザーは割合的には1−2割だけどサポートにかかる時間は
残りの8−9割のサポートにかかる時間を上回る勢いなので危惧してる。

でも確かにわざわざ先陣を切って俺が.NETのサポートまがいのこと
するのもあほらしいのでWin32で行こうかな。

>>362
>半年以内に.NETアプリ出せば

使ってくれるユーザがいるだけでも奇跡のようなもんだろ

>>363
俺の場合考えてるのは旧版のバージョンアップにあたるので
使う人は結構いると思う。

初心者って誰かに勧められないと新しいものは使わないよ。
友人ならそいつがインストールして、使ってみせるだろうし、
雑誌ならCD入れてインストール出来ないものは収録しない。
問題は窓の杜と2chみたいな掲示板なんだよなぁ。
他人の情報に踊らされて読まずに使う初心者が多い。

>>364
>旧版のバージョンアップにあたるので

それなら、なおさら .NET あぷりにしない方がいいよ。現状では。
評判おとしてユーザ激減、目にみえてる

>>364
それはありえないよ。
バージョンダウンは可能だけど。

>>366 >>367
やはり当面はWin32が無難のようで。
Delphi7でいきます。
すっきりした。

既存アプリの移植はやめた方がいいな。
V.2.00から起動重くなったね、ダサくなったね、メモリ食い過ぎ、
仕様変わりすぎだね、インストール面倒になったね、は間違いなく言われる。
VCL.NETなら、デカくなったね、も言われる。
安全になったね、解放しなくてすむね、とか言うユーザーは自作自演作者。
便利になったね、新機能満載だね、とか言われるかどうかはやる気次第で可能かも。

>>369
>　安全になったね、解放しなくてすむね、とか言うユーザーは自作自演作者

大笑い。

かなーり通なユーザかもしれないね。（笑

フリーソフト作りたいやつって設定ファイルどうする気？
.NETにはINIファイル扱うクラスはないよ。
レジストリいじられるの嫌いなユーザー多いし。
TMemIniFileは.NETに移植済みだけど、Classes参照するから結局Win32使うよ。

XML、かな？

現状、XMLのパースはINI以上に激遅。

> XMLのパースはINI以上に激遅。

そもそも激遅なんだから、そんなつまらんことで.....

設定ファイルくらいいべ。
どんなに大量のデータがあるんだよってかんじだし。

今の .NET だけでは Win32 のすべての機能をカバーできない。むしろできない
ほうが多いかもしれない。だから、設定ファイルがどうの、とかでごちゃごちゃいう
のは、むしろなんだか、変な感じ。

つーかXMLでいいじゃん。
わざわざ旧式のiniファイルを使う必要ないでしょ。
iniは64Kしか保存できないし、単純なデータしか保存できないし。
それでも時代を逆行したいのなら、時代を逆行して.NETからWin32API使えばいい。
iniのためだけにわざわざ全部をWin32にする必要もないしね。

ini程度の小容量で単純なデータなら
XMLにしても遅さを感じることは無さそうだけどな。

独自形式。
あるいはCSV。

まぁ、実際シリアライズしてみればあきらめきれないほどの遅さに気づくと思うが。

、、、等々、いろいろあきらめなきゃいけないことが多いので、
ある程度有名になってるアプリは.NETに完全移植できないわけで。
結局MS製アプリが今後どういう形態になっていくのかに注目したい。
IEもWMPも移植無理だし、メモ帳もワードパッドもネイティブだし。

Officeとかも死ぬほど大変そう。
OS部隊の直接支援があるから大丈夫なのだろうか？
直接支援がないサードパーティは死んじゃうの？
PhotoShopとか気が狂いそう。

>>381
大丈夫も何も、Win32使わないとキャレットを表示できないからWord移植出来ないよ

YAMLが手書きが楽でいい

結局MSが自らの肉を切ってサードパーティの骨を断つ作戦なのだろうか。

TIniFileって無くなったの？
TStrings::IndexOfNameは？

IMEの通信も出来ないからOffice2004は字が打てない
だからキャレット不要

>>382
キャレットならどの.NETアプリにも表示されてるじゃん。
それとも例え表示が同じでもWordの独自のキャレットの
実装方法じゃなきゃ認めないとでも言うつもりかな？

>>380
シリアライズってｗ
設定ファイルの話だろ。

Pure.NETにこだわる人って多いのか…
(VCL.NETを避けて)Windows.Formsを使うにしろ、Windows.Formsが提供するメンバの名前からして
現状ではWin32が下にあるのは前提じゃん…

Delphiって、いつの時代も「現状最強」「将来絶望」と言われ続けて来たんだし…
使えるものは全部使えばいいと思うんだけどね

>>387
OSのキャレットAPIのラッパーが今のとこ.NETには無いって程度の意味では？
独自に表示することは無論可能だが、拡大鏡とかが追従してくれなくなるし

とりあえず、D8使ってないやつはお帰りください。ウザイです。

>>389
それではこれはどういうことでしょうか？
拡大鏡の追尾とキャレットとは関係ないと思いますが？

http://homepage3.nifty.com/takubon_world/software/IMEWatcher/faqC007.html
> Microsoft Wordに限らず，一部のソフトはキャレットを独自で作成し管理しているようです．
> そのため，キャレットの場所を取得することができません．ごめんなさい．

>>390
そしたら誰もいなくなるじゃんｗ

おまえら死滅とかいってないで普及につとめろよな

普及？ 不急だと思う。

D8のUpdate#2まだー

>>391
拡大鏡に限らず他社製のWXGもWordのキャレットに追従できていますよ
…だから、単にその作者の勘違いか何かでは？

> 拡大鏡に限らず他社製のWXGもWordのキャレットに追従できていますよ

えっ、Word ってもう .NET アプリのが出てるの？

>>389
俺もおまえも、サードパーティーもPureにこだわる必要はないが、
MS製品だけはこだわってもらわないと困るんでわ？
LongHornの機能をすべて使えるのはMS製品だけ、ってなったらやだし。
MSがキャレットやIMEを扱い始めるまでサードパーティーむけAPIが公開されないのも。

>>398
成程。納得しました。
キャレット程度ならWin32 API呼べばいいけど、
WinFXでは.NETでしか新機能を提供しないと言ってる以上は確かにこだわってもらわないとまずいね

すみません、NETというのはなんですか？

　　　　　　　　　　　　　　＼　　　∩─ｰ､
　　　　　　　　　　　　　　　 ＼／　●　､_ ｀ヽ
　　　　　　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　　　　　　|　　 X_入__ノ 　 ミ　そんなエサでは釣られないクマ・・・
　　　　　　　　　　　　　　　　 ､　(＿／　　　ノ
　　　　　　　　　　　　　　　　　＼＿＿＿ノﾞ
　　　　　　　　　　　　　　　　 ／ 丶'　⌒ヽ:::
　　　　　　　　　　　　　　 　/ ヽ　　　 /　/:::
　　　　　　　　　　　　　　　/　/へ ヘ/　/:::
　　　　　　　　　　　　　　 /　＼ ヾミ　 /|:::
　　　　　　　　　　　　　　（__／| ＼___ノ/:::

VBプログラマよ誇りを持て
――　C#でもなくJavaでもなくVB.NETこそ未来の本命言語と断言する理由　――
http://www.atmarkit.co.jp/fdotnet/vbcheer/vbcheer01/vbcheer01.html

ひょっとして「VBプログラマは誇りを持て」ないのか？
いちいち励まされないとダメなのか？



まぁ、そうだろね。

当分Delphi7でOK

Longhornのデビューは2007年に？
http://www.itmedia.co.jp/news/articles/0404/02/news032.html

OSが発売される時期も重要だが、エンドユーザーのメモリ搭載量が上がってもらわないとな。

2007年かよ！
http://www.itmedia.co.jp/news/articles/0404/02/news032.html

二つ前のも見ないで書くか

>>289のOptimizeit Profilerを使ってみた。（尻届いたので）
すばらしい。
できあがったEXEファイルを選んで実行するだけ。
メモリ監視モードとCPU監視モードがあり、
メモリモードでは、各オブジェクトの現在のインスタンス数がわかり、
既存Delphi流のコード書いているせいか、stringだけやたらとメモリー使ってた。
どんどん使っていけばそのうちガベコレが発動するから問題ないが。
CPUモードでは、記録ボタンを押して、何かアクションをさせて、もう一度記録ボタンまで、
どのメソッドがどれだけCPU食っているかが、呼び出し順ツリーでわかる。
自分で書いたコードだからこんなモノ使わなくてもボトルネックがわかりそうだが、
あらためて数字で出されると、とてもわかりやすい。
ILなのでメソッドやオブジェクトがわかるというのが.NETの利点なんだろうな。
D8よりこのオマケがオススメ。
あ、でも、学習用途で小規模なアプリしか作ってない人には不要かも。

＞Delphiって、いつの時代も「現状最強」「将来絶望」と言われ続けて来たんだし…

そういえばさ、.NETがでたころ、DEL厨がDelphi最強！とかネイティブ、メモリー食いすぎとか
荒らしてたけど、そういうやつらぱったり見なくなったよね。
今そいつらこのスレにいるわけ？

いまでも「Delphi最強！」なんでは？
.NET アプリが「メモリー食いすぎ」は事実だし。
ネイティブよりおそいのも事実だし。

> そういうやつらぱったり見なくなったよね。

もう、みんな知ってることなんでいちいち言わなくなったのでは？

出始めの頃に比べると .NET Framework は普及したかも知れないが
.NET アプリは全く普及してない。煽るのもアホらしくなるほどね。

へえじゃあ、君なんで.netのスレにいんの？W

けっきょくさあ、
deL.NETってのはパスカル.NETだろ？

お前らそんなにパスカル好きなの？

Delphiは最強のまま逝ってしまわれました
次の世代に期待しましょう

> 君なんで.netのスレにいんの？W

アホバカの観察が趣味なんです。

スレ違いっぽいが、Longhornが延期になればなるほど、空白を埋めるWin32向け開発環境が…
VBが事実上使えなくなったし、VC++やDelphi7だけで後3〜4年持たせろってことか？

>VC++やDelphi7だけで後3〜4年持たせろってことか？

事実上そうなりそうだね。
おれのようなアンチ .NET にとってはめでたし、めでたし。

MS はCPUパワー、メモリ搭載量などハードの行く先を見計らって、ちゃんと
出す時期を計算してるんだと思うよ。表向きは、現プロジェクトにリソースを
さいた、とか言ってるけど。いちいち、内部情報をそれらしくリークしたり、
延期をにおわせたりして、ユーザを誘導してるんだと思う。それはそれでいい、
とは思うけどね。

>>416
で３，４年後はどうするわけ？アンチ.NETでどこかへ逝くの？

> ３，４年後はどうするわけ？アンチ.NETでどこかへ逝くの？

アンチだけど、C# ユーザでもあるし、４年後でもべつにどうってことはないですけど。

wwwwwwwwww

アンチでC#ユーザーだと？
よく人格破綻しないな。

> アンチでC#ユーザーだと？
> よく人格破綻しないな。

厨房じゃないので、アンチかマンセーかで人格が形成されているわけじゃないのでね。
アンチ、というのは、できれば .NET は普及しないでほしい、消滅してほしい、と思ってる
ということで、ＯＳをつくってる会社がそれをＡＰＩにしてしまったら、それはそのとき
また順応するといい、と思ってる。

アンチかマンセーかに人格を賭けるのは、アホ・バカの特徴だと思ってる。

今日の出来事：長い自己紹介を見せられる

今日のまとめ

「アンチかマンセーかに人格を賭けるのは、アホ・バカの特徴」

今日はJava祭りでDelphiどころじゃないようだな。

Delphiやってた奴は勝ち組。
Java厨よりは。

何かあった？
何の祭りかわかるところを教えてください

SUNとMSの和解で厨房が一人で大騒ぎして
みんながそれに釣られまくってるだけなので気にしなくてもよいかと。

>>426
面白そうじゃないか、逝ってくる。

ここまで死滅スレ化してるよ
http://book2.2ch.net/test/read.cgi/bizplus/1080919003/l50

長角延期はどうなってもいいから、Win32API呼ぶ必要がなくなるまで.NETアップデートして欲しい。
WinFXじゃなくて、.NETを。
そうすればもう心おきなくDelphi忘れてＣ＃に専念出来る。

> Win32API呼ぶ必要がなくなるまで.NETアップデートして欲しい。

それでは、Win32 アプリと同等な .NET アプリができるだけで、やはりだれも
つかってくれません。WinFX になって、Win32API からつかえないような新機能
がないと、ユーザを獲得出来ないでしょう。

自分が使わない＝誰も使わない

MSDNドキュメントに書いてない名前空間もあるので、ググらなきゃだね。

>いまでも「Delphi最強！」なんでは？
>ＯＳをつくってる会社がそれをＡＰＩにしてしまったら、それはそのとき
また順応するといい、と思ってる。

つまり、今の最強（脳内）がすぐに終わって、C#使いになると。
こういうのは最強でもなんでもない。

いまでも最強＝最強でも何でもない

ネイテブ系の中ではDelphiは最高

・コンパイル速度が最高速の部類
・インラインアセンブラを使ってもC系のように外部アセンブラが呼ばれる事はない。
・言語仕様が簡単でシンプル。低レベルから構築するのに向く。
・VCLが良いＯＯＰの教師となっていて C++系のような混沌が無い
・フリーのソース付きコンポーネントも多数ありさらに学習機会に恵まれている
・IDE上での支援機能、デバッグ機能も十分過ぎる状態でなおかつ他ツールに比べて軽い。

>>431,433,434
なんか、頭悪そうな書き込みだな。まぁ、ガンガレよ。

Ｃ＃もDelphiも分かるっていうやつ多いみたいだから、
というかこのスレにしかいないみたいだから教えてくれ。
DelphiのvirtualつけるかどうかはＣ＃ではどう書くんだ？

>>437

そのまんま。

http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/csspec/html/vclrfcsharpspec_10_5_3.asp

C# 言語の仕様

10.5.3 仮想メソッド
インスタンス メソッドの宣言に virtual 修飾子が含まれる場合、そのメソッドは仮想メソッドと
呼ばれます。virtual 修飾子が存在しない場合、そのメソッドは非仮想メソッドと言います。

非仮想メソッドの実装は 1 種類だけです。メソッドの呼び出し元が、宣言元のクラスのインスタン
スであるか、派生クラスのインスタンスであるかに関係なく、実装は同じです。対照的に、仮想メ
ソッドの実装は、派生クラスに取り替えることができます。継承仮想メソッドの実装に取り替える
処理は、メソッドの "オーバーライド" (10.5.4 を参照) と呼ばれます。

VSではオーバーライドの補完が便利だよね。
特にインターフェイス実装時は、Delphiでは補完効かないので手間。
俺がやり方知らないだけ？

普通にクラス宣言中でCtrl+Spaceでリストが出てくると思うんだけれど

Update#2はまだなのかなぁ。
たしかこの前までダウンロードページに「近日中に公開予定」って書いてあったのに
いまはそれは消されてしーんとしてるよ。

ひっそりと放置モードに入ったのでは？

消されてないけどね
ttp://www.borland.co.jp/delphi/devsupport/

.NETマガジンに吉田某のレビューがあったよ。
Delphi.NETはC#よりも進んだ言語仕様を持っていて
現時点で最高かつ唯一実用に耐える開発環境だって。

あの爺さんに言われてもな･･･

http://www.shoeisha.com/mag/dotnet/pdf/870405/dotnet0405_086_Feature2.pdf

>>443
お、消されてなかった。勘違い。
期待して待ちます。

吉田老はかつての切れがないだけでなく、ぼけ始めているとしか思えない。
Delphi7 で作った簡単な Win32 アプリが訂正なしで Delphi8 でコンパイル
できる、ってことは確かに素晴らしいが、そんな簡単なアプリは、アホでも
一から作れるだろうに。カスタムコンポを使ったり、文字列の操作したり、
メッセージ処理ハンドラを使ったりしたことないのだろうか？移植の容易性なんか
最初だけのメリットであり、しかも、ほとんどの大規模アプリでは役に立たない。

まぁ、VCL.NET を使って「現時点」でっていう限定では、唯一実用に耐える、かな？
しかし、それも .NET アプリが全く無視されている現時点での実用性はなんの意味もないし。
情報なさ過ぎで将来も開発効率の高さは望めないし。Delphi が好きで趣味で .NET
アプリつくりたい、って人だけに Delphi8 は意味があるだけでしょう。

>>448
はじめてまともなことをいったな。
.NETツールの中ではD8が一番実用的だが、ネイティブの足元にも及ばない。
しかも、ユーザーは好きで使っているアホばかりなので、実用は重要ではない。
信者以外には何ももたらさない。

Delphi7とDelphi8で現時点での生産性はどっちがうえ？

ねっ、>>450 みたいな質問をするヤツが Delphi8 買うんだよね。

真面目に答えると、Delphi８ 買うと Delphi7 がついてくるら自分で確かめなよ。

>>451
お前には聞いてないんだよ。
氏ね。

>>452

なにを生産するの？ Win32 アプリなら Delphi8 では作れないよ？
質問自体がアホすぎ。

>>453
まだ生きてたのかよ。
早く逝けや。

残念ながらこれが真実…
>.NETツールの中ではD8が一番実用的だが、ネイティブの足元にも及ばない。

現状、完成品に差ができてしまうんだから、開発効率を云々してもしょーがない。
GCが目当てにしてもD7にBoehm GCでも併用した方がましに思える。

.NETならではって用途があればなー。
テラリウムに間に合ってれば…とか思ってテラリウムのページ見てたら、staticコンストラクタがあると却下されるとか。
Del.NETだけでなく、A#(Ada)とか、初期化節を持った言語は使えなかったわけね。残念。
そもそも間に合って無いが。

誰か、.NETならではって用途、くれ。
このままHDDで眠らせておくのが勿体なさ過ぎる。

アホはDelphi8を買ってくださいね。

>>455
>　誰か、.NETならではって用途、くれ。

WinFX への「準備体操」と割り切るのが現実的。

海外の比較的マイナーな文学作品を翻訳出版する
小さな出版社がある。そして文学ファンはこういった出版社を
潰さないため、今後も翻訳を続けてもらうために
１人で同じ本を２・３冊買うことが良くある｡

我々もこういう時だからこそDelphi8を買って
.NETを支えるべきなんじゃないだろうか。
Delphi8の売り上げはより充実したWinFX用開発ツールの開発資金となるし、
.NETの普及に大きな影響をもたらすだろう。

現在の.NETの出来のみを云々するのは
あまりにも近視眼的ではないだろうか？

つーか、「ならでは」という用途というものは存在しない。
Javaならではって用途もC++ならではの用途もLinuxならではって用途も。
どんなことにも代替策はある。

奈良では東大寺が見られる。大仏もある。

>「ならでは」という用途というものは存在しない。

WinFX への「準備体操」ができるのは、.NET ならでは。（藁

>>460
ﾂﾏﾝﾈ

また国語争いかよ。ｗ

>>461

.NET がそもそもツマンネからなぁー。
次のバージョンアップ（Whidbey)まで無視するのが正解だと思う。

ツマンネの意味を理解できてないのか。
やっぱり日本語が不自由みたいだな。

Whidbeyには便利な拡張は多くあるけど本質的には何も変わらん

糞だなとか思いながら、我慢して.NET続けてると、ダメな部分はあきらめがつく。
絶対ならではが見つかるから新規アプリどんどん作れ。

> 絶対ならではが見つかるから新規アプリどんどん作れ。

無駄、無駄、ver1.1 なんかやっても無駄。

>>467
なんかその後のバージョンなら無駄じゃないような言い方だなｗ

ここに帰れよ
↓
http://pc5.2ch.net/test/read.cgi/tech/1081147731/

ＶＣＬ．ＮＥＴなら無駄じゃない

> 絶対ならではが見つかるから新規アプリどんどん作れ。

そういうあなたは「ならでは」が見つかったんだよね？
じらさないで教えてよ。

生産効率爆高＜ならでは

他人にはもったいなくて教えられないよね

ないものは教えられない。

> ＶＣＬ．ＮＥＴなら無駄じゃない

これが一番無駄。「準備体操」にもならない。

.NET は時期尚早。これ定説。

どうせ買ったのは金と暇もてあました奴ばかりだし、D8までもてあましたら最悪。
一般人にはオススメ出来ない。

D8買うのは法人と盲目的信者とライター（は買わないだろうけど）くらいのもんだろ

あとなんもしらない○ホとか。

ＶＣＬ．ＮＥＴがあれば．ＮＥＴなど要らない

Ｃ＃やVB.NET買ったヤツにもいえることだけどな

C#はDelphi8と違って只だけどな
Visual Studio.NETも非常に安価だしな

開発環境に金払う＝プログラマになる、と思ってる素人には厳しい時代だ

まぁ無料で道路を歩くのと金出してセグウェイ買って
スイスイ進むのとどっちが快適かってこった

なにしに来てるんだお前

誰に勧められなくても買う奴は買うし、それ以外の人には勧められないシロモノだ。

今月号のdotNETマガジンに約10ページを割いてDelphi8の特集記事があったけど。
基本的にマンセー記事。
最終的には.netをやるのかどうかというところに行き着いてしまうのだが。

アンチのふりして隠蔽し、独り占めしようとしてるやつ前に出ろ

出ないってことは、そんな奴いないってことかな

ユーザも見かけないね

アンチでもマンセーでも、スレのびた方がいい

まあDelphi8.NETのユーザなんかいないだろうね。ほとんどはC#に移行しているから。

じゃあ、

マンセー

>>491
C#に移行したような節操の無い奴はDelphi8にも手をだすよ

>>493
そんなことはない。

頭のいいヤツ　　　　　　　Delphi8 スルーして C# へ
そうじゃないないヤツ　　Delphi8 → ダメだこりゃ → C# へ

これ定説。

おりょ、

×　そうじゃないないヤツ
○　そうじゃないヤツ

Delphi 3.1〜7　マンセー、 VC++ 6 マンセー
↓
VC＃ 2002　スタンダード ダメダコリャ
↓
VS 2003　ステップアップグレード ダメダコリャ
↓
先月　Delphi 8 マンセー
↓
現在 VS 2003 マンセー、Delphi 8　ダメダコリャ

Delphi 8がきっかけでC＃とVSの完成度を思い知った。
VCL.NETソースをみて、使ったことがない.NETライブラリをたくさん知った。
とりあえずVC＃がいい感じだが、アップデート次第でDelphi 8もアリ。
VCL.NETはナシ、コンポネントワンもナシ、オプティミなんとかはアリ。

↑　なんか「そうじゃないヤツ」の典型みたいだな。投資したわりに身について
なさそう。来年あたり、マッタリと C# 始めたほうがよさそう。
人柱レポートありがとう　>>496

「ダメダコリャ」の説明がないと、説得力のかけらもないが。

いや、結論に反対するわけではないけどね。

それに VC# Standard がだめで、VS2003 が OK ってのもよくわからない..

こういうのを人柱というのもなんというかｼﾞｻｸｼﾞｴﾝのにおいがプンプン

> 説得力のかけらもないが。

説得する必要なんかない。レポートでよし。

> Delphi 8がきっかけでC＃とVSの完成度を思い知った。

これに尽きる。

近頃の学校は「面白くありませんでした」でもレポート通るのか。
ゆとりのある授業は大事だね

>>499

４９７＝５００＝おれ　だが、４９６はおれじゃないよ。鼻が悪そうだね（藁

ここは学校じゃない。あたま悪すぎ

ダメダコリャ。
VC＃2002は好奇心で買ったが.NET糞だなと思った。
2003はステップアップグレードっていうやたら安いセールがあって買ったが同じ。
D8は.NET版VCLソースを見るのに2万1000円は安いと思って買った。
したら.NETの糞な部分に対するあきらめと、美味しい部分への興味が目覚め、
今は「バグのせいで」使いにくいDelphiよりもＣ＃がおもしろい。
それでもVCLソースはお買い得だった。
VS2003はC＃単体の方がアップグレードに金かからないことを考えれば失敗かな。

>>503
ここは２ちゃんねるです。２ちゃんねるではレポートではとおりません。

> ２ちゃんねるではレポートではとおりません。

なんにもとおらないだろ。何ならとおると思ってるの？
説得したくなきゃ、べつに説得する必要もないだろ。

>>505
近頃の２ちゃんねるは「説得する気がない」と書き込みできんのか。
ゆとりのある２ちゃんねるは大事だね

”そうじゃないないヤツ”の巣窟ですか？

興味があるのに買わないでいると、買うまでろくなことしないんだよ。
前スレに書き込みしながら自分でかっこわるいと感じたし。
”そうじゃないヤツ”として買ってしまったけど、今回はお得なお布施だったよ。
これまでの無駄なマイナーアップグレードと同等の料金にしては。

新規で買わせてみせる

それは悪質だ

> ”そうじゃないないヤツ”の巣窟ですか？
>>494 によると ”そうじゃないないヤツ”以外のユーザはいないでしょ

>>509
>今回はお得なお布施だったよ。

ふせ【布施】

（名）スル
〔仏〕〔梵 dna〕
(1)他人に施し与えること。金品を与えることに限らず、教えを説き示すこと、
恐れ・不安を除いてやること、また広く社会福祉的活動を行うことをいう。
仏教の基本的実践徳目。施。檀那(だんな)。
(2)僧や巡礼などに金品を与えること。また、その金品。特に、仏事の際の僧
に対する謝礼。「お―を包む」

三省堂提供「大辞林 第二版」より

お布施に損得はない。しょせんは無駄、信心があるだけ。他人に強要しないこと。

> 前スレに書き込みしながら自分でかっこわるいと感じたし。

そんなにかっこわるいこと書いたの？ それはいけませんね。

> ”そうじゃないヤツ”として買ってしまったけど、

こっちのほうがかっこわるいような気がするが。

人目が気になる奴は買わないって

とりあえず明らかにユーザーじゃ無いのに煽ってる奴は出てけ。
それこそ意味が全く無い。

次スレは真面目に立てて欲しいな
煽りあいよりは、スレが伸びないほうがまだいいよ…落ちなければだけど

いいじゃん
みんなで楽しくやってるんだから、一緒に楽しもうよ

おまえらの大好きなＣ＃ってのはコンパイルはやいのけ？

C++に比べたらね。

体感だと、Delphi7まで > dmd(D言語) > (壁) > Delphi8 > C# > (壁) > C++ ってとこかなあ？
C#は分割コンパイルができないから、大規模になれば遅くなると思うけど

やっぱり単一EXE配布ってスマートだよなぁとか思うけど、
結局、本体が大きいってJITでもGCでも不利な気がするんだよなぁ。
大規模アプリほど、起動時は不要なクラスをDLL化して、必要なときにJITしたい。
それが.NET流でもあるし。
でもDelphiでは既出のネームスペースの関係で単一EXE以外は実質ムリなんだよな。
コンパイル速度に差が感じられるほど大きいときはやっぱりＣ＃で分割かな。

>でもDelphiでは既出のネームスペースの関係で単一EXE以外は実質ムリなんだよな。

ん？Delphi製のアセンブリを同時に複数使いたい時は、
「Borland.Delphi.dllを使わなければならない」んじゃなかったっけ？
俺が勘違いしてるのかな？

現在俺が困っているDLLの問題をいくつか書いておく。
WindowsやSysUtilsなど、Delphiで受けられる恩恵を使ったDLLは、
小さいBorland.Delphiだけじゃなく、大きいVCLのDLLも使わなければネームスペース競合。
DelphiプロジェクトにDelphi製DLLを参照させると、
参照したソースに変更がある度に内部エラーがでるバグがあって、
そのたびに参照から外し、追加しなければコンパイル出来ない。
ユニット＝ネームスペースなので、内部で使いたい非公開クラスは、
別ユニットではなく実装部に書かなければならない。
公開したいクラスが複数ある場合でも、実用を考えると一つのユニットに書かなければならない。
KeyFileを埋めると参照出来なくなる。
（KeyFileについてのプロジェクトソース内コメントも間違っている）

ただし、Ｃ＃で作ったDLLをDelphiのEXEで使う場合はなんら問題なし。

> ただし、Ｃ＃で作ったDLLをDelphiのEXEで使う場合はなんら問題なし。

全部 C# でつくればよし

サンクス。現状、dll作るには難関どっさりって事ね。
やっぱ、単一exeの文化なんだなあ…>Delphi

VCLをリンクして1M強のexeにまとめるのと、小さなexe＋2MのWindows.Forms.dllと、
どっちがメモリを食わないか…なんてのもちょっと悩む

DelphiのDFM形式をJavaは受け入れずにコンストラクタでコンポーネントの初期値設定だったよね。
.NETの標準はどうなってんだろう。Java方式？

>>523
その通りだけど信者な上に資産があるからね。
若い上にナメられているＣ＃に完全に移るにはもうしばらく時間がかかる。
金も時間も余裕があるから両方やるよ。

Java方式。Delphi8でWindows.Formsを使った時もやっぱりJava方式。
でも、XAMLというXML版dfmが登場するかも知れないそうです

>>525
.NETの標準なんてモノはない。
VCLフォームアプリはDFM（名は違うが）、
Windowsフォームアプリは言語問わずコンストラクタ+XML。

>>528
なるほど、標準は無いのか。
言われてみれば、Delphi/Win32は既に、標準ダイアログエディタのrc→resを無視してたね。

D8を使い込むほどＣ＃の利点が見えてくるね。
そのＣ＃さえもD7以下だけど。

> そのＣ＃さえもD7以下だけど。

D7 では .NET アプリつくれないでしょう。無意味な比較なのでは？

> 無意味な比較なのでは？

無意味な比較をするところが、まぁ、２ちゃんねらの面白いところ。
言語を比較してに勝った／負けた、とか言い出すのもいるし。

みてるとおもしろいよ。

>>532
見てないで参加スレ。

いやん・・・といいながら、ときどきウチワで煽ってるけどね。

何回も回る

>D7 では .NET アプリつくれないでしょう。
.NETアプリにすることにどういう意味が（ry

ガベコレやJITを備えたWindowsアプリとして、同等に比較することはできる。

Delphiって小規模アプリ専用だろ？

そうするかどうかは貴方の選択だけど、何が聞きたいの？

まあ、ワンマンアーミー的なプログラマはＤｅｌｐｈｉ好きが多いようだけどね。

ガベコレって、開発者が楽するためのもので、アプリケーションユーザからみると
訳の分からんタイミングで待たされるんで、デメリットだよな。ガベコレは、開発者
が楽するために、ユーザにデメリットをしわ寄せしたもので、コードできちんと開放
できるならそれにこしたことはない。リークはタコなプログラマのせい。

でも、現実はタコなプログラマが圧倒的に多いので、メリットになってるけどね。

>>540
そうだね。
VCLなどの巨大ライブラリも開発者が楽するためのもので、
ユーザーにしたらデメリットのはずなのに、
そのタコなプログラマとやらのせいでメリットになってたりする。

>>541
なるほど。程度問題というわけか。

おなじく程度問題なのが、.NET Framework (WinFX) 。これも、オブジェクトな
ライブラリをＡＰＩにして、開発者を楽にするが、大きなＣＰＵパワー、大量の
メモリを必要とする、という意味でユーザにしわ寄せ。今の段階だと、まだ、
ユーザが許容する範囲に入ってないので、アプリユーザはほとんどいない。

>>541
無理があるな

.NETは戦略なんだよ。
いきなりガベコレなOS出しても、XPまでの動作用件とのギャップがありすぎる。
そこで何年も先行して未完成なガベコレ環境を公開し、
完成時までに必要スペックを用意させる戦略。
マイナーなコンパイラ屋にも協力を求める必要があるし、
自社アプリも.NETでいく必要がある。

このスレ、今日で１ヶ月かよ。発売直後だというのに、ほんとに盛り上がらないねぇー

ユーザは１００人というのは本当らしいな。そのうち何人がいまでもユーザなんだろうか？

494 ：デフォルトの名無しさん ：04/04/06 15:29
>>493
そんなことはない。

頭のいいヤツ　　　　　　　Delphi8 スルーして C# へ
そうじゃないないヤツ　　Delphi8 → ダメだこりゃ → C# へ

これ定説。



だそうで、全滅にちかいんじゃないの

いまの .NET がつまらんのが原因。

Delphi8 の発売時期 は Whidbey とシンクロするくらいでよかったのに、早すぎ。
あいかわらずボーランドはわけわからんことする。

.NET版を急いだ代償が、現在のバグ放置Win32版だから始末が悪い

つまらんかい？
IExtenderProviderとかおもしろいんだけどなぁ。

>>549

激しく同意。それが一番腹立つ。

デバッグ手伝ってやれよおまえら

>>552
GPLなら手伝うから、某に要求してきてくれ。

おかしい。
もっと信者、擁護派がいてもいいはずだ。

>>549
で、４月末までには D7.1 が出る。ってのは既出のネタだが。

ちゃんと手元の D7 のバグ、QC にレポートしておかないとどれも直らないぞ。ってもう遅いが。

それよりupdate2

ftp://ftpd.borland.com/download/delphi/d8/d8_patches/update2/japanese/
ディレクトリはできている。

ディレクトリをつくるのは簡単だからな。社員なのか？
書き込む暇があったら、ドキュメントつくってね

ドキュメントはもう別にいいや。
C#と一緒だ。

> C#と一緒だ。

だから C# やっとけ。

D8はWin32の常識が通じるが、
C#ではやり方がわからんことが多くて移行出来ん。
C#でダイアログボックスをリソースで持たせるにはどうやるの？

ドキュメント,ドキュメントとここで騒いでも変化はおきないと思うが。
QC に入れろ。

QCにバグ報告しても１年半以上放置されているが、何か？

某はもうダメ！！

どのバグだ？
１年以上、ってことは D7 のか？

春休みでしょ
四月に入って動きがない

＞式が複雑すぎます
＞ソースコードの中に複雑すぎてコンパイラが処理できない式がありました。
＞一時変数を使って式を簡略化してください。

inherited Create;

どこが複雑だと思いますか？
どれを一時変数にすべきですか？

藁田

訂正

inherited Create;
// TODO: コンストラクタのロジックをここに追加

>>566
D8 / Winform アプリだろ？俺のとこではおきないが。

もしほんとにおきるのだとすると、なんか、エラーメッセージがひとつふたつずれているようなきがするなぁ

詳細書かなくてごめん。
これ、たぶんバグね。再現性はないけど何回か出た。
出た場合はそのまま保存し、IDE再起動で出なくなる。

うん。どう見てもバグ。
Update#2 当ててコンパイラ変えても再現する場合は QC にレポートしてください。

UPX効かないね

いい加減意地を張るのをやめてC#に統一しようよ。
リソースの分散はあまりにももったいない。
C#に対する明確なアドバンテージを示せないなら今すぐ開発をやめるべきだと思うがいかがかな？

VB.NET も屑だと。そういいたいのだね >> 573
C/C++ も無駄だと。そういいたいらしいね。

>>573
>>561
よろしく

まぁ、いろいろあってもいいんじゃないの？
ダイアログの作り方がわからんから D8 使うひとがいてもいいし。
ダイアログリソースの持ち方は、言語というより開発環境に依存する。

似たようなリソースの話だが全然違う話で、
D7まで、フォームのアイコン指定しないと自動でアプリのアイコンになったが、
D8ではどうやる？
1.デザイナで指定→リソースの無駄
2.Win32APIで読む→なんだかなぁ
3,????

あれからずっとC#でのやり方を模索している。
Delphiでは{$R}を使って普通にリソースを埋めれるのだが、
VSではできあがったバイナリにあとで追加する方法しかわからん。
しかし、あとから追加するとKeyFileの署名が壊れて使えなくなる。
（KeyFileをあきらめたらダイアログは動作する）
で、やっぱりD8も使い出があったりするのだが。

D8 Update#2 日本語版でました。

>>579
どこ？

登録ユーザーならアクセスできるでしょ？
ttp://www.borland.com/products/downloads/download_delphi_net.html

Readme.txt
ttp://altd.borland.com/download/delphi/d8/d8_patches/update2/readme_upd2_Japanese.txt

これ本当にアップデートか？
今まで何ともなかったところで落ちたり、
うざいほどエラーダイアログ出たり、
デザイナが使えなくなったり、不具合ばっかりなんだけど。

> これ本当にアップデートか？

はい、そのつもりです。なお、今回のアップデートのバグフィックスは、また、のち
ほど（１年以内）に出しますので、期待しないでお待ちください。（某担当者）

新手の嫌がらせですかね？特に問題なく動いていますが？ >> 583

問題があるなら QC か newsgroup にポストしろ。>> 583

>>577
どーも、System.Drawing.Iconは、型に関連づけられたリソースしか読めないらしい…。
MAINICONは普通のリソースとして格納されてるので、やっぱAPIしかないかも。
(VCL.NETの方は何もしなくても今まで通りでけた)

あちこちのスレで囁かれている小回りの利かなさを実感した瞬間

確かに問題なく動いてる…というか#2で何が変わったのかわからん。
オブジェクトインスペクタの並び順が、今まで名前順にしても戻されてたのが、
戻されずに済む場合が増えた(でも時々戻されてしまう)のが、わずかな改善点？
あと、補完が速くなった？気のせいかな？

そんなに劇的なわけでも無かった。updateで劇的に変わっても困るけど

>>587
README くらい読んどけよ...

Delphi8 Architect Trial / 日本語版も公開されてますね。

日某のサイトは動きなしか...

俺たちが待ってるのはPersonal版なんだよｯ！！

いつかは出るかもね。 >>590

>>579
情報提供ありがとうございました。

>>589
以前Borlandサイト(もちろんUSA)から英語版Trialを落としたら、
日某社からすぐメール＋電話がきたよ。数日後には分厚いパンフレットが郵送。
いちおう注視はしているらしく、担当者はそれなりにがんがっているみたい。
「日本語サイトを充実してほしい」と漏れから言っておきました。

>>593
なんだそれ、イヤだな

以前Borlandサイト(もちろんUSA)から英語版Trialを落としたら、
日某社から「深夜」なのにもかかわらず、すぐメールがきたよ。

システム作りは良いと思うけど、手書き風の DM みたいであまり良い気持ちは無かった。

Raveレポートってのは使いやすいんですか？
例えば、亡くなりつつあるQuickReportと比べて。

使ってみて自分で判断 > 596

使っている人居たら教えてＹＯ！

QuickReportって死滅しちゃうの？

>>599
バージョンアップしているし、今のところすぐ死滅する気配はない。

>>600
了解。

では逆に、Raveレポートが超便利で流行りそう、という気配は無いんでしょうか？
RaveとQuickとどちらを選ぶべきか。

>>601
別のものなんだから、「べきか」ではなく、どちらがあなたのニーズに合うか。
ニーズは人によって違う。

> 俺たちが待ってるのはPersonal版なんだよｯ！！

C#Builder にはあるんだけど、Delphi8 にはない、ってことに
なにか作為的なものを感じるのは漏れだけですか？

某は Delphi より、C# が大事なのか？
それともＭＳへのオベッカ？

>>590>>603
激しくムダかもしれないけど、日本ボーランドの営業および、USAのﾃﾞﾌﾞGPに対して
かなり激しく文句言っておきました。
心が動けばいいんだけど。難しいだろうなぁ。でも抵抗しなければ何も始まらないから。

乙 >> 604
....デブGP って誰だ？

といっても Personal 版の要望かぁ。
C#Builder で Personal を出したのは .NET Framework SDK がフリーで出ているためでは？
非 Delphi ユーザーかつ VS を買えない C# ユーザーに入り込むには値を落とすしかなかった。
ということでは？成功したとは思えませんが。

VCL.NET がなくて、Windows.Forms アプリしか作れない Delphi8 Personal が
あってもいいだろうね。その論理だと。

>>605
デブGP＝Developers Groupの略と思われ。
それにしても誤解を招きそうだな。
>>606
確か煮そうだ。

おまいらの言うパーソってもちろんパッケージ版だよな。

D6のDL版もパッケージ版共通で、商用以外で成果物配布OK。
CSBのDL版はこの板でも何度か出ているように、成果物配布禁止。
学割版も成果物配布禁止だし、某のライセンスはトリッキーすぎ。

今の .NET Framework v1.1 をつかった成果物なんか配布する意味なんかないだろ。
禁止でもなんでもいいから、C#Builder personal と同等なのがあればいいなぁ。

>>609
体験版じゃダメなの？

> C#Builder にはあるんだけど、Delphi8 にはない、> パーソ

新規なら C# やっとけ、という某のご託宣なんだろ。きっと。

貧乏人で素直なあたしは、ボーさんのおっしゃられるとおりに C#Builder を DL して、
本にお金をかけて有効利用。VS とうり二つなので、らくらく簡単 .NET プログラミング。
おすすめ。

コンパイラまでは作ってない品。

D8のコンパイルはVC＃より遅いね。CSBはほとんどいじってないから知らないけど。
以前の爆速イメージがあるから速いんだろうと思って気がつかなかったけど、
ちょっとアプリが大きくなってきたら待ち時間イライラするよ。
メニューアイテムが多くなってきたら特に遅いと感じる。

>>614
メニューが多いと速度が落ちる。って気はしませんが？
何か間違ってませんか？

中間ファイル作る分C#より有利なはずなんだが…
というか、最近「新手のいやがらせ」(上の方参照)との区別がつかないのが困り者だな
本物の不具合も結構あるし

そろそろだれかD8でフリーソフトでも出してくれ。
泣けてくるよ。

>>617
D8というか.NETでなければできない、ということが無い限り、
今まで溜めた経験と部品が充実しまくったD7使った方が、何を作ってもいいものができると思えるよ
完成品のメモリ消費量とかは圧倒的に差がつくし、開発も慣れてるだけD7のほうがまだD8 or C#より楽だし

でも、買った以上は、準備運動とかだけじゃ勿体ないとは常に思ってる。
アイデアくれ。アイデア。フリーソフトなんてアイデアだ。
鷹影なんか、縦書きが面白いから、Javaで遅いとか細かい不具合とかそんなの全部気にならなくなってる。

GDI+を活かして全般に渡ってグラデーション描画ができるペイントとか、考えることは考えてみたんだが
GDI+を使わなくてもグラデーションを実現しているペイントソフトは既にいっぱいあるし

Win32APIに.NETが太刀打ちするんなら、APIで用意してないライブラリ使うくらいだからな。
.NETがD7より有利に出来ることといったらとりあえずGREPだな。
各種文字コードの変換が出来るし、正規表現はユニコードネイティブだし。
それから、GDI+使わなくても型変換が充実しているから画像の変換ソフトとか。
あ、俺はとりあえずバナー作成ソフトを作ってみようかな。
楽出来そうなクラスが充実してるみたいだしな。

> でも、買った以上は、準備運動とかだけじゃ勿体ないとは常に思ってる。

買ったのが失敗だと認めると楽になれるよ

準備運動だけの人はD8を有効利用できるつもりかよ。
実際に使っていけば分かるけど、バグだらけで使い物にならないよ。
特にupdate2あてると酷くなる。
一番困るのは、デバッグで止めて変数の値をチェックしてるとよく落ちる。
うかつにマウスに触れない。
あとはResxにアクセスできない、というビルド失敗が多いな。

> 準備運動だけの人はD8を有効利用できるつもりかよ。

だから、買ったのが失敗だったと認めると楽になれるよ
準備運動なら、無料のＣＳＢで十分だし、むしろその方が良いくらい

別にデバッグ中じゃなくてもエディタ内にマウス持って行くと、
ツールチップで何か表示しようとして、勝手に失敗して保存できないまま落ちるよね。
どうも自動的にやってくれる部分で失敗が多いらしく、
ふとしたはずみで失敗が起こり、気がつけばエディタが書き込み禁止になってる。
どんなはずみで失敗してるのか分かれば対処できるんだろうけどね。

>勝手に失敗して保存できないまま落ちるよね
落ちたことないんだが。

Update2 でそんなにひどければもっと大騒ぎになっているはずなのだが。

>>624
あまりいじってないんでしょ？
大騒ぎするほどいじってる人もいないし。

マジな話なら、こんなとこで文句言うよか、ニュースグループにでも投稿した方が…

あ、625はちょっと煽り気分で書いちゃったけど、
実際の話、どこに報告すべき？なんて報告すべき？
俺はDllImportやインターフェース、キャッチ中の例外に
カーソルあわせると落ちやすい気がするが、あくまで気がするだけで、
一瞬で閉じられるのでエラーの瞬間が見えないんだよね。

単語にマウスポインタあわせるとエラーが出るってのは、
D7以前から続く歴史と伝統のバグで、
今回はそれがいきなり落ちるようになっただけ。
まぁ、D7以前でも大して使ってなければ遭遇してないんだろうけどね。

> D7以前でも大して使ってなければ遭遇してないんだろうけどね。

Dephi3.1 のユーザを５年近くやってるけど、通算するとたぶん２０００時間以上
使ってると思うけど、IDE が自動で落ちたことは記憶にないね。

>>627
QCか本国ニュースグループが一番いいのだろうけど、英語ができないとかなら、
日本のニュースグループでも、致命的なら伝えてくれるんじゃないでしょうか？(期待薄)

自分が遭遇しないのは支援機能のオプション弄ってるせいなのかな…
D8はたいして使い込んでいないけど、D7以前でも遭遇したことない。
(5か6あたりで入力支援中にIndex Errorはあったけど、いつかのupdateで直ったし)

日本語で日本のニュースグループに投稿しても無意味。
英語でQualityCentralに投稿すると、１年後くらいには治るかも。
でも、面倒だし、酷ければアチャラの人が投稿しているはずなので、放置してればよし。
日本語版特有のバグは、どうしても報告するしかないが、フィックスしてくれるかどうか
は分からない。Ｄ７の例では、２年近く放置された２００以上のバグが 7.1 でフィックス
されるそうだ。酷い対応だね。

そのバグが日本語環境だから起きるとしたらどうする >630
自分からあきらめて何もしないのなら、バグが直らないことに愚痴るな。

とにかく行動しろ。したくないならでしゃばるな。

>>627
日本語でもいいよ。QC に投げろ。

> そのバグが日本語環境だから起きるとしたらどうする >630

ちゃんと書いてあるけど、読んでないの？

> 自分からあきらめて何もしないのなら、バグが直らないことに愚痴るな。

愚痴ってないですけど。

> とにかく行動しろ。したくないならでしゃばるな。

はぁ？　それって、631 が報告するってことだよね。
わざわざ出しゃばってきたんだから頼むぜ。
よかったね　>>627

> 日本語でもいいよ。QC に投げろ。

って書いてあるから
６３１は自分では何もしないようだよ。

とにかく行動しろ、とかえらそうだけど、
Ｄ７のバグが２年近く放置されたのも事実だし。
６３１はボーランドに、「とにかく行動しろ」と言えばいいのにね。
あっ、日本語でいいから、ＱＣにそういう内容で投げてね >>631

とにかく、って英語でなんというの？

兎に角だから、horn for rabit かな。＜バカ

>>628
漏れは5.0(Update2)をかなり長く使っているけど、やはりIDEエラーで落ちたことはない。
どうも７or８にアップデートする気が起こらない。
3.1でも十分な気がするけどTActionがないのとサードパーティVCLのサポートが
4以上からというのが多いからね。

俺も7はイラネ派だったが、8に付いてきたので入れてみたら、エディタの配色が固定色じゃなくて
フルカラーから選べるようになってるじゃないですか

特に不具合は見当たらないし、7まんせー

日本語特有のバグもまだまだあるかと。
致命的ではないけど、エディタのカーソル移動がおかしい。

//
// TODO: InitializeComponent 呼び出しの後のコンストラクタコードを追加
//

と書いてある部分を上下に移動すれば分かるが、全角文字に対応しきれていない。
上の例では、追加の後ろにカーソルおいて↓や↑押すとカーソルがずっと右に移動する。

６３１は大忙しで、行動してるんだろうね。頼むぜ。

うちはupdate2当てたときから$REGIONで折りたためなくなり、
解決できないままあきらめてるけど、
そういう話題もないようだし、みんななんともないのか？

エディタの配色が増えてよかったね。>>637

> そういう話題もないようだし、みんななんともないのか？

ユーザ１００人以下で、ここ見てるのは１割としても１０人。
みんな、といわれてもなぁ。

> そういう話題もないようだし、みんななんともないのか？

６３１が行動して、QCに日本語で投げるから大丈夫だよ。たぶん。

$REGION でたためるって、どんな機能？
VS.NETに似たような機能があったような気がするけど、もしかしてMSはパクリ？

逆。MSの機能をDelphiがパクった。

IDEのデザインとかもほとんどMSのパクリだからなぁ。
よくMSが訴えないと思う。MSは大人だな。

MSはMacのデザインをぱくったとみなされて訴えられて何年もの間その件で裁判で争って
いたからね。
そういう経験があるから(IDEを含む)デザインのことで延々と争うことが
ムダなことだと認識しているんだろうし、「うちのデザインが業界をリードしている」
という自負もあるだろうし。
現にLinuxのXWindowのデザインはWindows95系統のものに落ち着いてきつつあるし。

MS としては、サードパーティーで .NET に開発環境を提供してくれるだけでも御の字。
訴えるどころか、大歓迎なんでは？
MS にとっては、とにかく、.NET → Longhorn の成功が第一の優先事項。

> MSは大人だな。

大人というより、メンツより商売、というのが真実。

鳴り物入りの.NETだったけど、乗せられた方はみんな
損してるんじゃないかという気がしてならない。

なんだ８買えば７も付いてくるのか？
なら７持ってないなら８買って７使えば
いいじゃん？７のマニュアルが無いとかで不便
する？ＶＣＬとオブジェクトパスカルの位は
欲しいな。

> 鳴り物入りの.NETだったけど、乗せられた方はみんな
> 損してるんじゃないかという気がしてならない。

気のせいでしょ。時期尚早ではあるけど。

> ７持ってないなら８買って７使えばいいじゃん？

ほとんどの人はそうしてる。

みんなDel7スルーしたからなぁ。
餞別代わりにDel8買うとかいってたのもいたな。

>>647
だな。GUIで著作権侵害を認められることはほとんど無い。
昔Appleが著作権侵害だと訴えて認められなかった事件がある。
http://japan.cnet.com/news/tech/story/0,2000047674,20065158,00.htm
>　Appleの主張は、HPがNewWaveで使用していたごみ箱とファイルフォルダの
> アイコンについて以外、全て認められなかった。

しかも、逆にMacがGUIをパクったと訴えられる始末。
> さらに、自社の研究所でGUIが発明されたことで有名なXeroxが
> Appleを相手取り、GUIの全ての著作権はXeroxにあるとする訴訟を
> 起こしたことから、事態はいっそう複雑になった。

笑えるよな。GUIをパクったと訴えていたAppleがパクってた、
Appleには著作権自体ありゃしないわけなんだから。

まだAppleは懲りずに、今度は特許にしようともくろんでいるみたいだが。

>>649
> 大人というより、メンツより商売、というのが真実。
商売だったら、自社のGUIを保護するはずでしょ？

…

特に話題もないし、ユーザーも少ないし、使い道もないので、
スレ違い迷走でもまったく構いませんよ。
たまにバグ情報やUSの動きが書いてあるぐらいでも別にいいよ。

> 商売だったら、自社のGUIを保護するはずでしょ？

君は優先という言葉の意味を知らないのか？

知らないので説明しろ

辞書も知らないらしいな。（藁

消防なんじゃないの

ゆうせん(イウ‥)【優先】
他に先んずること。また、他より先に行うこと。
他をさしおいて先に扱うこと。「御年寄を優先的に腰かけさせて下さい」


全く関係ないじゃん。これ持ち出した奴どう関係するのかちゃんと説明しろ

>>648

辞書は知ってるようだぜ

結論

MacはどうでもいいGUIの権利なんかを
保護してばっかりだからシェアがのびない。

Mac はハードウェアライセンスをPCのように公開して無料にしなかったのがシェアを
奪えなかった原因。IBM は偉かった。

IDEもいったん最小化するとずいぶんメモリー解放してくれるなぁ。
ひょっとしてIDEはVCL.NET製なんじゃないか？ネイティブじゃなくて。

>>668
ネイティブでもそうならないか？
仮想メモリを表示させてるか？

>>IBM は偉かった。
えらかったけど、IBM には一円も入らずコンパックが掠め取ったのも周知の事実。
Mac の AppleII が成功したのも回路図丸ごと、ROM のコードごと出したせいだし、
だから OrangeII とかコンパチ機が大量に出回った。
PS2 も Mac もその反動。

ところで Apple が主張したのは Finder / GUI の著作権であって、特許ではなかろう？
そもそも Apple は MS に 描画系 API のコードを売ったのだから。デバイスコンテキストとか
GDI の API の仕様はほとんど Mac の丸写し。しかしこれは論点ではなかった。
MS が Windows 1.0 で Mac/Finder という製品を丸写ししたことが、著作権上、意匠上、パクリか否か。
それが正当な商行為か？が争われたのであって、あの時点ではまだ特許論争ではなかった。

この反動で、MS にしろ Apple にしろ、その実装方法を特許にすることで他社が簡単には参入できないように
している。
たとえば MS は、マウスがどのウィンドウの上にいるかどうかをすばやく見つける方法として
リージョンにインデックスをつける方法。というのを特許として持っている。
こんな感じだ。

スレ違い

爺は昔話が大好きだな。(ｹﾞﾗ

アホは (ｹﾞﾗ が大好きだな。

(ｹﾞﾗはD8が好きだな

ホントにネタ無いしね。
煽りでも入ってくれるとうれしいよ。

ﾅｶﾑﾗたんが何かいうまで子羊どもは D9 は放置らしいし。

Delphi for T-Engine
が欲しい。

> D9 は放置らしいし。

D9 に何を期待してるの。D5-7 で十分なんだけど。

> D9 に何を期待してるの

Begin Endを{ }にできる

>>678
改悪すんなｳﾞｫｹ

> Begin End

begin end だろうふつう。（藁

フリーソフトのネタ思いついたよ。
だれか軽めのIDE作ってくれ。D8は遅いし挙動不審だし。
ウチの環境では、D8起動後、すぐさまVS2003起動すると、
まだD8がスプラッシュ出してる間にVSはプロジェクト開いて入力可能になる。

軽めのOSのほうがいい

それで、$REGIONでたためるっていうのは、いったい...

ググってもみつからないよう。

VSは実はサービス起動してる。

ググルより体験版入れてみたら？

VSのサービスはデバッガ？
停止しても起動出来るよ。

.NET Frameworkとかいうランタイムをスタティックリンクするのはどうやりますか？

>>687
kernel32.dllをスタティックできると思いますか？

>>688
出来ます。

>>689
お前マジレスか？ さすがDel厨ｗといわれるぞ。

689とは別人だけど、dllというかPEには再配置情報が含まれてるんで
スタティックリンクしようとしてやってやれないことはないんじゃなかろうか、と思ってみるテスト
既存のリンカじゃ無理だろうけど

思ってみるテストなら、おれにもできるな

>>689

さすがDel厨ｗ

>>690-693
いくらなんでもネタって気付け。

>>694

さすがDel厨ｗ

>>695

さすがDel厨ｗ

XboxはカーネルもDirectXも全部スタティックリンク。
無知って怖いよな。

Delphi8 のVCLでパッケージを使わないで構築する方法
ってどうするの？今のままじゃ、納品する機械すべてに
パッケージDLLを入れなきゃならない。
っていうか.NETは使いづらい。Delphi8もMicrosoft C++.NETも
慣れれば使いやすいんだろうが・・・。

>>697
だれもXBOXの話なんてしてませんが？

>>698
プロジェクトマネージャでVCLパッケージを右クリックするとメニューが出る

>>700
プロジェクトマネージャでVCLパッケージというものが無かった。
色々右クリックしたが、それらしき所は見当たらず・・・。
昔はメニューバーのプロジェクト→オブション→パッケージを使って構築
のチェックを外せば良かったのにDelphi8はそう簡単にいかない。。。
俺は本当にVCLアプリケーションを作っているのだろうか？いや、作っているはず。

>>701
その問題が解決されたとき、実行ファイルサイズの大きさに絶望し、
次にWinFormでサイズダウンを目論むが、そのクソッぷり絶望。
たとえ、絶望を乗り越え、いや、我慢してプロジェクトが進んでいったとしても、
結局バグの多さで一年ぐらい待とうかということになる。
まだよくわかっていない今が一番幸せだろうな。

市販PCの性能がぐぐんとあがれば、悩んでた事なんて
すっかり忘れるさ

お客様には、PCがオンボロだからと言っておけば良し
お客様も新しいPC買ってもらえて、大満足

ビバ、Ｍｉｃｒｏｓｏｆｔ商法！！！

>>701
参照先の下に、System.なんちゃらに並んで、Borland.なんちゃらがあるはず。
それを右クリックして、「Delphiユニットにおけるリンク」
もしBorlandなんちゃらが無ければ既に静的リンクされてる。exeが1M超えてるはず。
その場合また動的リンクしたくなれば参照を追加してやればいい。

今さらながら入れてみたOptimizeit Profilerなんすけど、
ポート云々って、ひょっとしてLAN環境に無いと使えなかったりするのでしょうか…

555 ：デフォルトの名無しさん ：04/04/09 12:44
>>549
で、４月末までには D7.1 が出る。ってのは既出のネタだが。

ちゃんと手元の D7 のバグ、QC にレポートしておかないとどれも直らないぞ。ってもう遅いが。

-----------------------------

もう五月ですが。 D7.1 は音沙汰なしですか？

>>706
もうすぐじゃん
http://homepages.borland.com/aohlsson/blog_beta/archive/2004_05_02_archive#108371801808805124

>>707

But don't quote me on that just in case it takes a day or two longer. ;-)

４月じゃないね

>>704
どうもありがとうございます。何とかできました。
やっぱり、実行サイズは軽く1M超えてますね。
昔は軽かったのになぁ。Delphi2.0を入れて起動するとメチャクチャ
はやいねん。Delphi8はすんげー遅い。しかし、2.0はWin2000以下しか
まともに対応してくれないけど・・・。

7.1って既存ユーザーは無料なの？
いいね。

なんだか、.NET アプリとネイティブ Exe を同じに見てるような

> 7.1って既存ユーザーは無料なの？

さぼってたバグフィックスをしただけ。金取ったら暴動が起こるでしょ。

.NETアプリは起動時に中間ファイルからコンパイルされるから、
サイズが大きいのはご勘弁なのに。
あえてVCLって何考えてんだか。

初めに、謝っておきます。
あまりにもヘタレな質問ですいませんが
コンパイルエラーで、『System.Drawing.dcuilが見つかりません』
とエラーが出てしまいます。
これは、初めのインストールMISSなのかどうかも私には判断がつきません。

場違いな質問かと思いますが、お答えを頂きたく質問させて頂きます・・・

コンポーネントのインストールに失敗していたようです。
スレ汚しすいませんでした。

>>714
�dﾞマイ

ゴ㍒

>>708
D7.1きた〜
http://bdn.borland.com/article/0,1410,32337,00.html

でも駄目ぽ（エラーでまくりらしい）

談話室でサポート中

D8スレでD7のアップデートを期待したり報告したり。
もう8はダメか？

>>719
客引きｳｻﾞ

IDEでマウス動かすと、単語にカーソルが止まるたびにツールチップが出るが、
このときdcc71il.dllの読み込み違反が頻発するようになった。
これが出るとIDE再起動するまで、編集も実行も、プロジェクト開き直しもできない。
以前は一時間に一回くらいだったので、そのたびに再起動していたが、
昨日あたりから数分に一回くらいだ。
なんか、もう一万行以上あるし、いまからC#移植も大変だから秀丸で書こうかな。

>>722
ひどいなそれ。製品として成立していないじゃん。
マジな話、数分に一回再起動しながらプロジェクトを完成に持っていく時間と
精神的ストレスを加味すると、C#に移植したほうが全体の時間のことを考えると
スムースに行くんじゃないの？将来的なことも含めて。

支援機能切るのが一番手っ取り早い気がしますが、中間ファイルやら.NETのキャッシュなんかが壊れてそう

単体EXEで作ってないので、dcuil、dcpil、pdbあたりは別ディレクトリに吐かせて、
DLLの方を更新するたびにまとめて削除してるから、逆に頻繁な削除が良くないのかも。
中間ファイル削除後は、ソース内コンポの宣言順番によって勝手にプロパティが変わるから、
わりと気をつけて作業してるつもりだけどね。
とりあえず識別子定義OFFでまたしばらくいじってみようかな。

問題が発生したため、Borland? Developer Studio for Windows を終了します。 ご不便をおかけして申し訳ありません。

はぁ、またか。

俺はそんな現象にはぶち当たってないんだが。
すなおにレポートを Borland に送ったら？
ここでなにいっても無駄だし

と、書き込むこともやはり無駄なわけで

と、書き込むこともやはり無駄なわけで

(以下、繰り返し）

落ちるのも楽しんでるんだろ。しかし、Delphi8 ユーザはＭとしか思えんな。

.NETでTStringListにあたるクラスって何ですか？

ArrayListが一番近いが、stringに特化していない

>>731
System.Collections.Generic.List<String>

StringCollection は？

TStringListもないなんて.NETって低機能ですね

>>735
てか、あるし。

おちやすいコードがわかったかも。
いま、その部分だけをC#で書いてDLL参照して安定してるように見える。
まだ確証ないのでまた今度。

リフレクションでDelphi8製アプリを見るとDebuggableAttributeっていうのがあるが、
第一パラメータはpdbファイルを作成しないことにすればfalseにできるが、
第二パラメータはどうやってfalseにするんだ？
コレを両方falseにしないとデバッグ版なんだが。

>>738
へー…知らなんだ…。
で、直接[assembly: DebuggableAttribute(False, False)]って書いてしまえばFalseになったけど…？

>>739
うちのは直接書いたのとコンパイラが勝手に書いたのと二つのDebuggableAttribute属性がつく。

自分で書いたfalse,falseとコンパイラがつけたtrue,trueがある状態で、
ブレークポイントが生きているので、結局自分で書いたものは無視されるようだ。
ということは、ILまでは最適化されたとしても、JITで最適化されないことになる。

それでもう一つ気になる属性を発見したが、
[assembly: RuntimeRequiredAttribute(TypeOf(TWinForm))]
これってヘルプにも載ってない謎の属性。
コメントアウトしても問題ない気がする。

D8コンパイラはデバッグ版アセンブリしか吐けないでFA?

んー。やっぱりVB.NET使った方が良さそうだな。

最適化されないってもうダメじゃん

あの、いちお、煽ったりしてる身ととしては、信者の皆さんもある意味お友達な訳で。
これしきのことでDel厨卒業されたら張り合いがなくなるわけで。
いままでどんなデメリットも無視してやってきた信者の方々には、
ぜひとも「趣味だからオプティマイザ無効でも問題ない」などのとんでもない発言して欲しいです。
おまいら、これくらいどうってことないよな？

んー、米ニュースグループにでも聞いてみようと思うんだが…どなたか英語ください

ニュースグループだのMLだのQCだの、どこにあって、どうやって見るんだか教えれ。
2chしかコミュニティしらんから、もっと棒に近いところ教えれ。

>>747
http://www.borland.com/　とか http://bdn.borland.com/ から辿れ

英語な時点でどうしようかね。
俺、update2当てた日から、二回以上継承したWinFormでデザイナが使えなくなった。
パッチ当てなきゃ大丈夫だからバグだと思っている。
で、そういう場合にどこになんて書いていいのか、どうしたらいいやら。
わかる人には簡単なんだろうけど、報告しろと言われてもよくわからん。
だから気軽に書き込めるこの場所に書くよ。
解決のためではなく発散のために。

日本にもれっきとした法人があるのにね。それをユーザはまったく信用してないとは情けない。
無理もないけど。バグ報告の仲介くらいしろよなー

信用しないんじゃなくてどうしていいのかがわからないんだよ、俺は。
サポートが必要なら金払えみたいなことも読んだ気がするし。

>>751
ニュースグループなら金要らないよ。基本的に単なるユーザー同士の相談場所で確実性も無いけど。
newsgroups.borland.com にポストして、名前の後ろにTeamBって書いてる人に見て貰えばいい

>>750
同意。日本語でバグ報告できる場所が欲しい。

Windows フォームアプリを新規作成。
Unit1を新規作成。
WinFormのinterface部uses節にUnit1追加。
Unit1のinterface部に以下のコード追加。
uses System.Runtime.InteropServices;
[DllImport('user32.dll', CharSet = CharSet.Auto, SetLastError = True, EntryPoint = 'SendMessage')]
function SendMessage(LongWord: LongWord; Msg: LongWord; wParam: Longint; lParam: Longint): Longint;external;
マウスカーソルを[]内で動かす。
ツールチップヒントが出た時点で、エラーダイアログが出てエディタが書き込み禁止になる。
再現性アリ。
場合によっては「ご不便をおかけして申し訳ありません」で瞬殺。

上記はWindows.pas等をusesして肥大したくないから書いたコード。APIを使った天罰。
DllImportは危険度大。必要なAPIはC#でDLLにすべし。
他にもAPI以外で普通に補完中にエラー出たこともあるがまだ再現性なし。
withも結構危険。あとあやしいのはwhileやrepeatも。

>>753

それ本当なの？ 新規の煽りじゃなくて？
もし、それが本当だとしたら、IDE として機能してないということだよ。
使うのやめなよ。

>使うのやめ「な」よ。

やってみたが大丈夫だった。
何か心当たりない？ >> 753
ウィルスチェッカとか複数の .NET ランタイムを入れているとか

愚痴を言うのなら、US newsgroup に日本語で書いてしまいな。
文句いわれたら、日本法人は何もしないからだ。って書いちゃえばよし。

いま、別のパソコンにインストールしてやってみたが再現した。
書いたことが伝わってないのか？

EntryPointのツールチップは何がでるん？
俺はdcc71il.dllの読み込み違反ダイアログだよ。

ココデイイノカシラ？
http://newsgroups.borland.com/cgi-bin/dnewsweb?cmd=xover&group=borland.public.delphi.winforms.controls.using&utag=

もしかして、news reader 持ってないの？

Outlook Express くらい使えるだろうに

DllImport アトリビュート内だろ？>>759
なにも出ないんだが...
ちなみに俺のは英語版だが、翻訳ミスとかかなぁ

もうちょっと簡略化。

D8起動し新規プロジェクトを作る。
WinFormユニットのinterface部usesにSystem.Runtime.InteropServices追加。
implementationの一行上に
[DllImport('user32.dll', CharSet = CharSet.Auto, SetLastError = True, EntryPoint = 'SendMessage')]
マウスをEntryPointというワードにあわせ、ツールチップ待つ。

んー、XPと2Kと二台の別のパソコンでテストしたので、
これでエラーが出ない環境のほうが俺は信じられないんだが、
その環境では補完時の強制終了なんかも遭遇してないんだろうなぁ。
うらやましい。

>>761
おまえの作ったソフトは使い方がさっぱり分からんと言われてきたはずだ。
何度説明してもさっぱり分からんと言われ続け、挙げ句の果てにやって見せたはずだ。
当然分かっているだろうことを分かってないヤツを想定してないからな。
で、俺いまさっぱり分からないよ。
結局日本語のページはどこ？IEじゃみれないの？
書き込むには専用ブラウザかなにか必要なの？

>>764 誤爆？
まずは、Netnews ってのを調べてみろ。な。
Internet は Web だけじゃないんだよ

URLをしめしてあげればいいのでは？
まあ確かに、今時 news:// なんて、あんまり見かけないよって話はあるけど。

>>760
GJ!

爆撃効果なし？

俺、きみのいってることがいまさっぱり分からないよ... > 768

>>769 折角ニュースグループに書いたのに反応がないことだろ
>>768も焦るな。2chとは時間の流れが違うw

やり方さえわかればどこにでも爆撃できるのに

D8のFreeはデストラクタがないオブジェクトに対しては何もしないのね。
逆にデストラクタの有無をチェックしてる分だけ損しかねない。

最適化できないんじゃなくて、デバッグに最適化されるのな。
もっと遅くなるってことだが。

スレあってるかどうかよく分からないけど、
もうちょっと人が多いところに書き込んできた。
で、そこをちょっと下の方まで見ていったら、
そこでも一時間で５回くらいcrushするっていう人と、
update2で安定したので一日一回か二回crashの人がいる。
crush/crashの違いではないだろう。

> update2で安定したので一日一回か二回crashの人がいる。

ほほう、一日に１，２回落ちるだけだと、安定なんだぁ。つかえねぇー

起動しても見てるだけなら絶対落ちないよ

見てるだけで、なんかアプリが自動でできたり、おもしろいことがあるのか。
エスパーなら役にたつかな、D8。

そういう人もいる。ってはなしでしょ。
落ちる人は大声で怒鳴り、安定している人はわざわざ書き込みしない。

そういうひとがいるってことが問題なんでは？

開発環境の安定性が問題になるようじゃ、まだ、使えないってことだね。

ここにはわざわざ安定してるって書き込みが多いのが疑問だがね。
どっちにしても、英語版でもバシバシ落ちてるんだから、
落ちるっていう報告はしなくてもいいってことだ。

落ちて当然、って.....やっぱり変。

ここでは、落ちる報告もバシバシたのむぜ。情報としては貴重。

バグ情報があったところでデバッグ版しか吐けないんじゃどうにもならん。
.NET対応言語でダントツのビリ。

>デバッグ版しか吐けない
なにを言ってるの？バカじゃない？
デバッガ内で見るとデバッグ版の Native コードに変換されるのは IL の仕様で
C#/VS 環境下でも同じだ

D8がバカ

> D8がバカ

そうじゃなくて、D8 をあえて使っているヤツらが（略

C#への移植はわりとスムーズに出来たよ。
違いを意識したのは、
stringが0ベースか1ベースか、
charは16ビットの符号なし、
typeof()でインスタンス指定出来ないのでGetType()、
caseで1..10など範囲指定のやり方がわからない、
ifでandやor使ってる場合に注意が必要、
ぐらいかな。
この作業で、いくつか無駄なことしてるコードを発見出来たし、
ヘルパークラスなんかがなくなったせいかバイナリサイズも半分以下になった。
なんかもう、今後D8は何に使うかなぁなんて。

Del厨の為のC#講座は需要があると思う

大野ﾀﾝにリクエストしたら？

> Del厨の為のC#講座

ふーむ、Delphi8 は文法が拡張されてかなり C# に近づいたので、ほとんど機械的に
読み替えできるのでは？ 文法レベルでは C# はむしろ Delphi より簡単なような気
がする。.NET プログラミングの難しさはむしろライブラリレベルにあって、これは
Delphi8 も C# も共通。（VCL.NET はこの際、無視）

私的感覚では

C# = [Delphi 40%] + [Java 40%] + [C++ 20%]

C#　= Delphi似クラスライブラリ + Java似言語

Team B のレスついたよ。

私はそうです、嫌悪する、それが不可能であると言うために、しかし、Iは、それをまだ行う方法を解いていません。
Iには、今日それで遊ぶさらにより多くの時間がありません。しかし、Iはネット上でC#にあるコードを見つけて、それをデルフォイに字訳しました;恐らく、それはこれで実験したい誰か他の人にとって有用になります:

procedure TForm1.Button1Click(Sender: TObject);
var
dbg: DebuggableAttribute;
sTrackingEnabled, sOptimizerDisabled, sMessage: string;
begin
dbg := Attribute.GetCustomAttribute(
System.Reflection.Assembly.GetExecutingAssembly(),
TypeOf(DebuggableAttribute)) as DebuggableAttribute;
if Assigned(dbg) then begin
sOptimizerDisabled := TObject(dbg.IsJITOptimizerDisabled).ToString;
sTrackingEnabled := TObject(dbg.IsJITTrackingEnabled).ToString;
sMessage := 'Debug Mode' + #13#10
+ 'IsJITOptimizerDisabled = ' + sOptimizerDisabled + #13#10
+ 'IsJitTrackingEnabled = ' + sTrackingEnabled;
ShowMessage(sMessage);
end else begin
ShowMessage('Release Mode: Use an INI file to dicatate the '
+ 'IsJITOptimizerDisabled and IsJITTrackingEnabled debug flags.');
end; // if
end;

（DebuggableAttributeの件を否定か肯定かしろというのに対して）
「できない」とは言いたくないんだけど、どうしたらできるかまだわからん。
デバッグ版かどうか判定するコードを移植したので誰かよろしく。

ちょっと興味があるのだが、もともとどこで出たネタなのか教えていただけますか？

TeamB なんだから NewsGroup だろうね

もともとこのスレで出たネタじゃん>>738-741

BabelCode is a C# to Delphi for .NET code conversion utility
http://dotnet.borland.com/babelclient/BabelClient.aspx

> C# to Delphi

方向が逆

逆は難しいんじゃない？
ボーランドのランタイム分コードが増えそう。

> 逆は難しいんじゃない？

行ったきり帰ってこれない、どこかの国みたいですね。
なにもわざわざマイナー環境にコンバートする必要ないと思うんだけど。

文字列比較するだけでも旧製品との互換性のために独自関数使っていて、
その独自関数が結局.NETのライブラリを呼ぶ。
逆の移植で動作が変わらないためにはこの冗長部分も一応書かなきゃいけない。
こういう部分が複数あるわけで、JITの最適化が不可欠なんだがなぁ。

> 旧製品との互換性のため

過去の遺産は大事なのは分かるけど、そのために未来を犠牲にするのはどうかと思うよ。

.NETなだけでも遅いと言われているのに、そのことへの対抗要件であるJIT最適化が無効。

きっと最適化オンだと不都合があったんだよ

Reflectionなんてよけいなツール添付しなければデバッグ版でもバレなかったのに。

現実問題としてDelphi8のJIT最適化が無効だとして
いったい誰が困るんだ？

ユーザ

最適化の存在意義が分からんヤツもいるみたいだな

D8で最適化されなくても、C#やVBは最適化されるから誰も困らないと言いたいんでは？

とりあえず今は.NETアプリユーザなんかいないんだから困るヤツはいない。
将来、D8以降でも最適化オプションが使えるようになるといいね。

本来なら返品されても文句言えないくらいなのに、おまえら愛があるね

TeamBを名乗る人たちはボーランド関係者なの？
できないってばかり言ってるけど、だからって修正しようという話もなく、
危機感みたいなものもなく、出来ませんが何か？的に見えるんだけど。

> TeamBを名乗る人たちはボーランド関係者なの？

ボーランドから認証されたボランティア

> 出来ませんが何か？的に見えるんだけど。

えーとですね、Delphi が .NET 対応することに賛成の人はアチャラでも少ない
その雰囲気が出てるでしょ

バグレポートは QC へ。

QCは2chよりあてにならないがね

ボーランドはボランティアよりあてにならないがね

そもそもバグなのかも疑問。
デバッグ属性つけちゃったことに気がついてないだけなら修正されるだろうが、
必要があってつけた属性なら修正されないだろう。

バグではなくて仕様です

一番重要な点、D8アプリは他より遅いのか否か、誰か訊いて欲しい。
場所はここ
http://newsgroups.borland.com/cgi-bin/dnewsweb?utag=&group=borland.public.delphi.language.delphi.dotnet&xrelated=2899&cmd_related=Related+Items

> 一番重要な点、D8アプリは他より遅いのか否か、誰か訊いて欲しい。

あのね、これを訊くのは、JIT最適化で実行速度が速くなるかどうかを訊くのと
同じ。訊くまでもない。

Del7以前もたいていO-I+R+でやってるけどな〜

某のコンパイラは昔から最適化が甘かった。コンパイル速度のほうを重視してたん
だね。いままでのネイティブコンパイラと決定的に違うのは、Del8 が吐く IL を
実行するときにJIT最適化ができないこと。JIT部分は各言語共通なので、それ以前
にDel8だけが勝負の土俵にも立てないことは、もはやコンパイラとして論外。

つまり、Delphi7までもJIT最適化無効にしたのとおなじくらい速度面の欠陥があると？

VBはほとんど最適化無しの中間コードでずっとやってきたわけだが。

http://www.microsoft.com/japan/msdn/net/general/dotnetperftechs.asp
これだけのことをやってくれるJIT最適化を放棄するなんて。

>>825

はぁ？ ちゃんと読んでね。

>>826
VB5以降のプロジェクトプロパティのコンパイルタブを何と心得る？

過去のバージョンも最適化が甘いと書いてあるじゃないか

クリティカルな部分を別の言語で書けば問題ないだろう。
すこしずつでもC#に移植していってDel厨卒業だ。

甘いと無効の違いがわからんヤツもいるな

> クリティカルな部分を別の言語で書けば問題ないだろう。

クリティカルなのがどこか分かるのかよ。
そんなことしてまで、Delphi8 につきあう必要はないだろ。

Delphi8のスレだからそこまでしてつきあう人ばかりでしょ

そこが間違い >822
コード中に明示的に DebuggableAttribute を指定した場合、それが優先される。
あなたの確認方法は、デバッガで止まるかどうかで判断しただけでしょ？
デバッガでとまるかどうかは JIT 最適化とは関係のない（しかし VStudio IDE ではコントロールできない）話。

そんなわけないでしょ。
コード中に明示したものが優先されるなら、pdbファイルが効かなくなるじゃん。

コンパイラが
[assembly: DebuggableAttribute(true,true)]
.dprファイルに
[assembly: DebuggableAttribute(false,false)]
の状態で、どちらが優先されているかはどうやって調べるんだろう。
IsJITTrackingEnabledがtrueかfalseかで何が変わるのかわからんし。

そんな瑣末なことで大騒ぎするなよ。
Perlは実行速度は速いとはいえないけどDelphiの1000倍は使われている。

2chの、しかもDelスレでしか生きられない人にはさぞかし大騒ぎに見えるのだろう

>>835
なぁ、何で最適化されると思ったわけ？
意図的に最適化が起こらないようにしてるのに。

>>838
PerlがDelphiの1000倍使われている？
そんなわけないだろ。これを見ろ。
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
C (13503 projects)
C# (1511 projects)
C++ (13599 projects)
Delphi/Kylix (1482 projects)
Java (12175 projects)
Perl (5563 projects)
Visual Basic (1849 projects)

sourceforge でさえ４倍近いんだから、一般では１０００倍とはいかないまでも
１００倍は楽勝だろう

>>836
いや、CLSCompaliantも同じような属性だし。
デバッグ中は最適化は行われないんじゃなかったっけ？
だからデバッグ中はコード中に付けたのは無視されてるのかも。(あくまで可能性)

C#でデバッグ時とJIT時で速度が変わるコードを書いて、移植してみて、
速度が同じかどうかで試すしかないのかな

じゃぁD8の何倍になるんだろう

0では割れません。

D8でコンパイラ最適化なし、pdbオン、コード中にfalseでステップ実行して、
挙動を見ればいいじゃない。

比較ベンチなんて10分もあれば書けるだろ。
お前らほんとにDel8持ってんのか？

８４１の数字で興味深いのは、C# と Java の数値。

あと、C# と Delphi/Klylix が同じくらいだと、D8 は限りなくゼロだろう、
と推測できる、かなぁ？ .NET がいかに普及してないか分かるね。

> お前らほんとにDel8持ってんのか？

もってませんが、なにか？
16:19 には結果がわかるね。報告よろしく。コードつきで。
結果次第では買ってもいいかな。

D8はJIT最適化オンに出来ないので持ってても比較版を作れないのに

C#ではソース中にDebuggableAttributeを明記できないっぽいので
とりあえずC#のコマンドラインオプションと属性の関係を調べてみた

オプション無し: false, true
/debug: true, true
/optimize: DebuggableAttributeそのものが消える(false, falseと思われる)
/debug /optimize: true, false

>>848
sourceforgeってUNIX系ばかりだよーん。

program Project1;
{%DelphiDotNetAssemblyCompiler '$(SystemRoot)\microsoft.net\framework\v1.1.4322\System.dll'}
{%DelphiDotNetAssemblyCompiler '$(SystemRoot)\microsoft.net\framework\v1.1.4322\System.Windows.Forms.dll'}
uses
System.Diagnostics,
System.Windows.Forms,
Windows;
//この行アリかなしかで比較しても変化なし
//[assembly: DebuggableAttribute(false,false)]
var
l1,l2:int64;
i,j,k:integer;
[STAThread]
begin
QueryPerformanceCounter(l1);
i:=0;j:=i;k:=j;
while i<10000 do begin
k:=((i*2)+2);
i:=k div 2;
dec(i);
j:=i;
inc(j);
i:=j;
end;
QueryPerformanceCounter(l2);
System.Windows.Forms.MessageBox.Show(Convert.ToString(l2-l1));
end.

コード内に属性書いてもJIT最適化されない

using System;
class Jit_Cs
{
static string IntToStr(int x)
{
return System.Convert.ToString(x);
}
static void Test()
{
for(int dummy = 16 * 256; dummy > 0; --dummy)
{
string x = "";
for(int i = 0; i <= 255; ++i)
{
string[] a = new string[2];
a[0] = x;
a[1] = IntToStr(i);
x = String.Join("|", a);
}
}
}
static void Main(string[] args)
{
int s = Environment.TickCount;
Test();
Console.WriteLine("{0}", Environment.TickCount - s);
}
}

program Jit_Del;
{$APPTYPE CONSOLE}
uses System.Diagnostics;
function IntToStr(x: Integer): string;
begin
Result := System.Convert.ToString(x);
end;
procedure Test;
type array_of_string = array of string;
var dummy, i: Integer; x: string; a: array_of_string;
begin
for dummy := 16 * 256 downto 1 do
begin
x := '';
for i := 0 to 255 do
begin
SetLength(a, 2);
a[0] := x;
a[1] := IntToStr(i);
x := System.String.Join('|', a);
end;
end;
end;
var s: Integer;
[assembly: DebuggableAttribute(false,false)]
begin
s := Environment.TickCount;
Test;
System.Console.WriteLine('{0}', [Environment.TickCount - s]);
end.

C#のほうは、オプションによって2%かそこらぐらい心持ち変化した
Delphiのほうは、DebuggableAttribute書いてもかわんねー

for(int i = 0; i <= 255; ++i)
{
string[] a = new string[2];

なんでこんなタコなコード書くかね・・・

>>858
タコなコードほど最適化の効果がよくわかると思ったんだよ
IntToStrも、インラインされるかなと思ってわざわざラップしてみたり

あえて書いた無駄なコードに文句つける奴もいるんだな

最適化のチェックにわざわざ重いインスタンスの生成コードなんて書くなって話だよ。
メモリマネージャやGCの性能測ったってしょうがないだろ。

んでも、NGと照らし合わせてちょっと面白いことは見つけた。
[assembly: DebuggableAttribute(false,false)]と書くと、属性が二重に付いてしまって効果は無いが、
beginの直前に、[DebuggableAttribute(false,false)]とだけ書くと、
Reflectionで見た時、属性が二重にならず、ユニット名.Unit.ユニット名関数(エントリポイント)に
(アセンブリの属性とはまた別に)DebuggableAttribute属性が追加される

で、結局、JIT最適化はできないと。てきとうなコードでも数パーセントは遅いと。

純数値計算ならもっと遅いんだろうな。

さらにひどいことに、コンパイラが吐いた中間コードをディスアセンブルし、
for文書き換えやResultの扱い、一時変数の嵐や文字列の操作など、
C＃が吐いたコードと比較するともっと不幸になれる。

あと、const使うと普通にリテラル同士の足し算が残っている様も拝めるよ

プロジェクトソースに書いても効いてる節が無いってNGにポストしといた方がいいんだろうなあ…

>>865-866なんてのも(もし真実でも)JITが効けば解決だろうし
(逆に一時変数の除去や定数のたたみ込みすらできないJITなら効いても意味無さげだし)

しかしこういう仕様というか挙動というかバグを一切知らせずに製品出荷してしまう某の姿勢には失望したね。

正直、いまだに某に希望を持つのはどうかと思う....

￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　 ∧,,∧ 　　　　　　　ｷﾎﾞｳ ｱﾙｶﾗ ｼﾂﾎﾞｳ ｽﾙ
＿＿ミ,,ﾟДﾟ彡,,,,,＿＿＿.　　　∀
　　　 ∩,,,,,,,,,,,,,,⊃⊃　　|　　　┷┳━
￣￣￣￣￣￣￣￣￣￣￣|　　┃
￣￣￣￣￣￣￣￣￣￣￣　　 ┻
Win32版D9まで放置

とりあえず、脳内ではDel.NETは無かったことにしますたが、何か。

ま。それでDelが消え去ったならそれもまた仕方なし。

単なるバグがらみならパッチで修正予定ってアナウンスもあるんだろうけど
それすらないってことは本質的に直らないってことなのかな。

急いでC#に移植中だけど、見つけたのでまたひとつ書いておきます。
C#で書いたpublic const stringの日本語がD8で読めません。
もちろん、C#のdll→C#のexeは問題なし。

public static stringでgetのみなプロパティにしたら読めました。
constのバグみたいです。

NGに書くとして…

It seems no effect that writing [DebuggableAttribute(false, false)] on project source.
Because I can debug it, and I measured speed, written and unwritten are same speed.

…だめだ。今頭が回んねえ。誰か頼む。

>>896
うぜえ、わかり切った事を繰り返すな。
もしノイズの書き込みを我慢できないというなら一回心理カウンセリングにでも見て貰え

未来にレスして面白いの？

> もしノイズの書き込みを我慢できないというなら一回心理カウンセリングにでも見て貰え

これ自己レスみたいだが

>>873
それ書くより>>853のコメントだけ英語にしてコピペ

ヘジたんがどっかで「Delphi のために .NET はファーストクラスを用意している」云々を
言っていたと思うのだけどあれはなんだったのかしらﾏﾏﾝ

ファーストクラスの座席は用意した。
しかし座席にたどり着くまでは自分の努力だ。

ってことでしょ。

プロパティやイベントの実装見ても、Delphiにとってはファーストクラスと言えると思う。

.NETの仕様のせいでimplementsが実装できなかったんだから、ファーストクラスなんて信じられないわけだが。
コンストラクタのinheritedを先頭に書かないといけないなんてわけわからん制限もできたし。
たまたまヘジ氏がC#をDelphiに似せたために、似てるところが上手く行ってるだけで
細かいとこ見れば.NETの仕様はC#のためにあるよーなもんだ。

JIT最適化で盛り上がって来ましたが、もう一つの最適化について。

コンパイラ最適化してもしなくても実行速度同じだった。

あっ、そう。
JIT最適化不可能なんで、その前がどうだって論外なことは変わらない

> 細かいとこ見れば.NETの仕様はC#のためにあるよーなもんだ。

禿同。
むしろ似ている分だけ Delphi.NET の存在意義がなくなる

>>869
>フサギコ
>Win32版D9まで放置
D9はWin32版になるのか？

>>880
となると、何か変だと思わない？
生成コードが変わることは ILDASM で確認できるでしょ？

コンパイラ開発者、たった3人なんだから何もできねーって。

ttp://homepages.borland.com/dthorpe/blog/delphi/2004_04_01_archive.php?show_id=108145135852831215#a393a353520616d
".... the Delphi compiler team has never been more than 3."

>>884
確認してくれ。
最適化オンにするかオフにするかでなにか変化するようなコードサンプル頼む。

コンパイラの開発とかは天才が1人いれば問題ないといってみるテスト

>>887

禿同。しかし、某の天才はあっちへ行ってしまったので今はいない。悲惨

アーキテクトは一人で十分（二人以上いると喧嘩になる）だが
その下に瑣末なことを担当する技術者が十分にいないと、天才が凡才のやるべき仕事を
やらなきゃいけなくなる。

ある程度から先は、無数の凡才がいる組織が勝つ。ってのは MS を見ていてもわかるだろ。

> MS を見ていてもわかるだろ。

無数の金持ちの盆栽だけに見えるんだが

gcc より性能良いコンパイラがなぜできるのか。考えたことあるか？ > 890

gcc がへぼ

> gcc より性能良いコンパイラがなぜできるのか。考えたことあるか？

無数の金持ちの盆栽ががんばった

たしかに VC++6.0 MFC なんかは無数の金持ちの盆栽がつくった感じがするな

手元じゃ違いがわからないのだが、ニュースグループによると
>>853 でJITの効果が確認できるらしい…

誰か確認できた人いる？

>>895
奴は数倍といっているのだが、コメントアウトしたかどうかでは差が出ない。
10回ほど起動して最速と最遅の値をみて見るとまったく同じだったりする。
おそらく、IDEから起動した場合とそうでない場合でそのくらいの差が出るので、
そういう勘違いらしい。
もちろん、コンパイラ最適化の有無を比べても同値。

D8の活用方法思いつきました！

VCLのランタイムをVC#から利用

> VCLのランタイムをVC#から利用

最悪の活用法だな

だってコンパイラがダメ、IDEがダメじゃ残るはVCL.NETのみ。

それも所詮は車輪の再発明だけど

言葉の意味間違ってない？

> 残るはVCL.NETのみ。

それが最悪。

バッシング中に申し訳ないが、技術的な話。
ちょっと納得いかない挙動があって、デバッグ中なんだが、
initializationにMessageBox.Show()をおいて実行したら、
起動時にそのメッセージボックスが二回表示されちゃったんだよ。
一回しかこないときもあるし、二回くるときもあるからよくわからない。
そんなわけで、initializationの記述は複数回きても大丈夫なように書くこと推奨。

またガセネタを.. > 903

実コード出してごらん？出せないでしょ？

>>904
そういってくるってことは、
やっぱりinitializationに二回くるのはおかしいことだったんだね。
それがわかっただけでも収穫。

それから、
バグとかの話題をすべてネタや嫌がらせとしてなかったことにしようとしてる>>904は何者？

>>905
>904はただのアマチュアなやつなんだろ。

どいつもこいつも俺もおまえもアマチュアですが？

プロがバグ報告を楽しむ余裕なんてないだろ（藁

D8 これだけダメダメケテーイなのに、まだユーザがいるんだね。シンジラレネー

普通は信じられないだろうな。
信じられるから俺は信者なんだよ。
だけど今回だけはプロジェクトをC#に移植してもうた。
OnPaintでわりと多めの計算させてるんだが、
信者としては残念なことに、開発者としてはうれしいことに、
バッチリ速くなったよ。
でもまだまだDelphiで遊ぶよ。

constructor TWinForm.Create;
var
s,ss:string;
begin
inherited Create;
//
// Windows Form デザイナのサポートに必要です。
//
InitializeComponent;
//
// TODO: InitializeComponent 呼び出しの後のコンストラクタコードを追加
//
s := 'aaaa';
ss:=s+#0;
MessageBox.Show(Length(ss).ToString);
end;

> 普通は信じられないだろうな。

はい、信じられません。信者には理屈がつうじないことは知っています。
しかし、これほどとは。もはや、先鋭化してカルト教団みたいですね。
早めに抜け出しておいてよかった。

電磁波かなんか防ぐために白い布貼ったり、教祖への失禁攻撃だとか、
空中浮遊を見たとか、もう、信者というのは、一般人から見ると滑稽なんだよな。

おもしろいから、ここ「お気に入り」に入れようかな、と思ったらもうすぐ1000か。

>>896
最初にキー入力待ちさせて落ち着かせてから計測しても同じぐらいの差が出るので、
スワップ云々でもなくて、デバッガに監視させるとそれだけで差が出るようだ。
デバッガを使うオプションを切ってからだと、IDEから起動してもコマンドラインからと変わらない。

試した限り、DebuggableAttributeは全く関係ない…。

英語版ではfalseで最適化されるのかも知れないね

だなあ、ちょっと食い下がってみたが、動作が違ってるとしか思えん。
Delphiの英語版なのか、.NET Frameworkの英語版なのかはわからないけど。

大体こんな属性用意せずに、デバッガにアタッチされてないときは問答無用で最適化すりゃいいのに＞CLR
…とか思ってみたくもなる

.NET フレームワークは全世界共通のバイナリですが、なにか。

>>916
とにかくデバッガで止めたら、その瞬間にデバッグモードのコード生成をするのが .NET
そういうものだと思うしかない。

一応隠し技。Delphi.NET に限らず応用可能。
速度を知りたいコードを DLL アセンブリに入れる。

ターゲットアセンブリを ngen で事前コンパイルし、アプリケーション起動後に JIT で止める。
アプリケーション起動前からデバッガに乗せると、アプリケーションがデバッガモードで動いてしまって、
GAC からデバッグ版の事前コンパイル済みアセンブリを探しに行ってしう。これでは結局最適化なしのコードしか
手に入らない。
だから、デバッガなしでアプリを起動させ、.NET ローダーに非デバッグ版の事前コンパイル済みアセンブリを
読み込ませる。
そのあと JIT で止める。こうやって初めてコードが実行時最適化されているかどうかわかるのだ。

あっ、そう。で結果は？

妄想ですが誰か試してください

最適化された実行コードがほしいんじゃなくて、最適化によってどれだけパフォーマンス
が上がるか、を知りたいんじゃないの、ふつうはさ。Delphi8 では属性制御ができないと。
それが問題。

違う。某社員に最適化を封じられることによってどれだけパフォーマンスが下がるか、だ。

属性ったって所詮はフラグ一個だろ。
バイナリエディタで1バイト修正とかでどうにかならないの？

次期バージョンでは、某謹製のバイナリエディタが付属するかもな

なんかここ、念入りで深ーいメクラマシをもった悪意ある煽りが張り付いているような感じがする

そうだね、見え見えじゃなくて、真面目な技術論を装ったのがいるね、ちょっとこわい

で、結局、D8はいいんですか、クソなんですか。
良くなる余地っていうか、棒にそんな余力はあるんですか。
D3からのユーザーですが、いまいち移行に踏み切れニア。
C#にいっちまおうかななああああああああああああ

>>926

どこでもおすきなところへいってください

>>924
俺のことかも知れん。
バッシングは訴えられるので起こった現象のみを書いている。
クソとか言ってるのは俺じゃないけどね。
が、あと3000行ほどでC#に移植し終わるからそれもなくなるだろう。
たぶんこのスレに書き込んだ人の中でいちばんD8使ったと思っている。

噂の真偽を確かめるために、ただいま、Trialおとしちゅう
おまぃらこころしてろ！

trialよりupdate2あたってからがひどいがね

>>930 工作員きたーーーーとかいってみていい？

VJ#...?なぜに...

[エラー] メタデータの生成中にリンカでエラーが発生しました

Trial版での話で既出だろうが、思いつきで。(Delphi6からの移行としてみた場合、
・VCLと、IDEに新しい可能性を見出せるが泥臭いかも
・旧Delphi系列のインターフェースが好きな香具師は、表示オプションからClassicUndockedを選択すれば、古き良き(r
・エディタ環境としてみれば、インテリセンスっぽいテンプレート挿入がいい(Ctrl+J)
・実装部分との分離でクラスの見通しが良いっていうメリットは、残ってはいるが、名前空間の参照とREGIONの範囲指定とかで以前よりは落ちるし、ｲﾝﾀｰﾌｪｽｰでいいやと
・with *.create doは健在
・ヘルプがやばそうだけど、Del6とかのWinHelpと比較すればマシ IEお気に入りに登録できる分、俺はこっちでいいかも
・IDEの起動に時間がかかるというのは、まぎれもない事実、つかｼｭｯｼｭ完走できそうできねぇか
・コンパイル速度は体感ではいつもどおりな感じ
・Windowの再描画に、もっさり感がある
・ブレークポイントのグループ化はおいしいかも
・旧コードの移行は、手を加えないとあれかも。ただ、事前の置換処理でけっこう稼げそう(PCharを削除とか)
・ECOサイクルがやっぱり気になる

IDEは全体的なもっさり感（エディタ部分自体はキビキビしてるが）と、起動時間をなんとかすれば、かなりよさげ
言語としてみた場合、.Netが入った分、粗雑さがなくなった部分もあればその逆も。
with文が、コード全域に適用できれば（名前空間の展開マクロみたいな）、、

信者にとっては、かなりいいんじゃない？と思う。また来るぜ！

体験版大成功のようだな

引数に文字列渡すとき、const付ければ速くなるってのはD7までの常識なわけだが、
C#にはvarに相当するrefとoutしかないわけで、D8では付けたconstはどうなるのだろう？
refの場合、.NETはポインタがないので、行きと帰りにコピー作成してかえって遅くなる。
packed recordと同じで下位互換性の為だけに残ってるのかもしれない。

そういえばD8で32ビットアプリ吐こうよはどうなった？

Delphi@WCIMH
http://hp.vector.co.jp/authors/VA028375/delphi/delphipascal_xx_delphi8_on_win32_preview.html

　　　∧,,∧　　こちらかも。
　　 ミ,,ﾟДﾟ彡　 ｺﾛｺﾛ
　　 ⊂　 ∪ﾐ　　
ｇ,,,　(~,,(~,,,ミ＠ 　　

>>938
> 先がある事が、私の中で確信になりました。

日本語が全般におかしくない？

>>939
そうでもない

サゲ進行はやめそう

D8はドットネットがダメでもネイティブがあるさ、ということ。

>>942 D7

ttp://www.unisys.co.jp/club/net_view/20030315.html
＞結論から言いましょう．成功できませんでした

D8なら、{$R WindowsXP.res}と書いとけば自動的に含まれる。

Application.EnableVisualStyles;

>>945
アホ

>>946 ｳﾞｧｶ

質問！
さいきんデルファイ８に興味あるんだけどさ
デルファイ５でつくったソースは使えんのかな？（変換とかやっぱあんの？）
いままでデルファイ３、５しかやったことないからその辺が心配なんだよね
誰かおしえてー！

あとデルファイ８と７の違いって何？

そういえばバージョンアップの申し込み葉書がきてた。
￥29,400- か……迷うな。

D8にD7がおまけで付いてくる。買って好きな方使えばいい。

926は体験版２時間さわって、カタログみたいなことを書いて終わりですか？

おしえてください〜！！

>>953
http://www.borland.co.jp/delphi_net/
メーカーのホームページを探せないほど馬鹿、
メーカーのホームページを読んでも分からないほど馬鹿、
どちらにしても馬鹿すぎですよ。トホホ。

> さいきんデルファイ８に興味あるんだけどさ
これだけで○●だと分かるでしょ。マトモならこのスレ読んでＤ８に興味持つはずない

普通ならそろそろ次スレだが、果たして必要か？
普通なら「使い物にならないので終了」というと反論も多いだろうが、
終了しなかったとして、バグ、煽り、VBやC#の話題、>>948みたいなアホ、
それ以外に何がある？
他のDelphiスレと別に存在していく理由ももうないと思うんだが。

次スレ
ミ,,ﾟДﾟ彡フサギコのﾌｻﾌｻ.NET談話室
http://pc5.2ch.net/test/read.cgi/tech/1033489735/

> 終了しなかったとして、バグ、煽り、VBやC#の話題、>>948みたいなアホ、
> それ以外に何がある？

何もないだろうね。

> 他のDelphiスレと別に存在していく理由ももうないと思うんだが。

いや、ある。D8 は他の Delphi と違って for .NET だ。他の　Delphi のスレに
紛れ込ませて、その良さ悪さを曖昧にしてならない。

×　その良さ悪さを曖昧にしてならない。
○　その良さ悪さを曖昧にしてはならない。

using System;using System.Diagnostics;using System.Runtime.InteropServices;
class Class1
{
[DllImport("kernel32.dll", CharSet = CharSet.Ansi, EntryPoint = "QueryPerformanceCounter")]
static extern bool QueryPerformanceCounter(out Int64 lpPerformanceCount);
[STAThread]
public static void Main()
{
Int64 l1,l2;
QueryPerformanceCounter(out l1);
int i = 0; int j = i; int k = j;
while (i < 10000)
{
k = ((i * 2) + 2);
i = k / 2;
i ++;
j = i;
j ++;
i = j;
}
QueryPerformanceCounter(out l2);
System.Windows.Forms.MessageBox.Show(Convert.ToString(l2 - l1));
}
}

上に出ていたDelphi8コードをそのままC#でやらせた。
csc /t:winexe /out:project1.exe project1.cs
110〜120程度
csc /t:winexe /out:project1.exe /debug project1.cs
330〜380程度
で、JIT最適化が伺える。

で、問題のD8は、
コメント付けてもとっても310〜320程度。
IDEから起動するとどちらも980〜1000程度。
デバッガの有無で差が出るが、属性の有無では差が出ない。
どちらにしてもC#でのリリースビルドに比べて3倍近く遅いコードが限界。

>>956-958
フサフサ.NETのほうが要らないスレのような気はするけどね
とりあえず向こうを仮の次スレとして使い果たして、両方が落ちてから、
改めてDelphi8 part3ぐらいでどう？

Delphiスレには質問スレと、雑談という名の叩きスレがあるわけだが、
D8は叩き尽くされて数字上の遅さも証明されたので、
雑談＝叩きスレはもう終わりにして質問スレに転向ってのは？

> 雑談＝叩きスレはもう終わりにして質問スレに転向ってのは？

質問です。Del8 はＪＩＴ最適化もできないのにどうしてユーザがいるんですか？

というふうに質問形式でも色々できるので、無意味。

つまらん原則論を言ってみる
・スレタイ変えても粘着嵐は消えない
・質問や議論がしたければすればいい。
嵐が常駐しているというのは質問や議論をしないことのいいわけにはならない
・嵐はスルー

>>966
たしかにつまらんな。

>>960-962

ネタじゃないよね？　本当だとしたらちょっともう絶望的だね。

>>968
自分で試してから絶望するなりどうするなりすればいいじゃない

また「本当だったら」か。
D8では「本当に」これだけたくさんの信じられないことが起こっているのに。

>>969
もってない。

> D8では「本当に」これだけたくさんの信じられないことが起こっているのに。

いや、ユーザがいるってことがそもそも信じられないんだが。

>>971
じゃぁDelphiが遅かろうがおまえが絶望することはない。
cscはWindowsUpdateで手にはいるからむしろ喜べ。

>>973
> じゃぁDelphiが遅かろうがおまえが絶望することはない。

はい、おれはむしろ自分の当初の判断が間違っていなかったことを喜んでる。
おれは絶望してない、絶望的なのは Delphi8。

> cscはWindowsUpdateで手にはいるからむしろ喜べ。

はい、とっくに喜んでいます。

で、なぜ、ユーザやってるんですか？

>>974
それって埋め立てだよね。
これもだけど。

>>853
>>960-962

テンプれ

むしろ、>>960のコードをニュースグループにポストするべき

そんなことはない

ニュースグループの方ではDelphi8でも最適化されてるからな

ねぇ、なんでハッキリさせないの？ すまんがオレはコンパイラ持ってないんだが
>>960-962 と同等なことをやって、結果を報告するのがどうしてできないの？
日本のユーザは、なんかアンチっぽい粘着に騙されてるの？ それとも >>960-962
は本当なの？

それともってなんなのさ。
なぜユーザーでもないのに必死で疑うの？

なんかここ異様な雰囲気だな
マジ変

嘘かも知れないし本当かも知れないし、でも持ってないし関係ない。
それでいいじゃない。
もしくは買う予定なの？だったら買ってから試せばいいじゃない。