./index.html ../index.html

Delphi Note

• 意外なところで
• returnとresult
• 待ち切れないモード
• 投函
• スプラッシュ更新
• こっそり…
• 実行保護属性
• Win32版の行方
• class helperのめも

意外なところで

こんなところでこんな話を書いて貰えるとは…メモメモ。 この人何やっておられる御方なんだろう、と、検索してみたのですが、特に見つからず。

なお、要望そのものは、「どうせ無駄だろうけどDの仕様が固まる前に書いちまえ」ってぐらいの気持ちでしたが… そして予想通り、多勢を占めると思われるC系言語派の方々には反対されましたが(でもそれって、演算子の優先順位とかもそうですけど、いつまでもC互換を続けるのは負の遺産でしかないような、と、Delphiのページに分けたのをいい事に好き勝手書く。Dのページでは、C互換は重要と書く私は蝙蝠野郎)…

なんかこのレス貰えただけで満足してしまったような。

returnとresult

…それでもまあ、「二行節約する以上の意味がありますか」、とか言われて、こっちも内心熱くなってきたので、考えをまとめるために書いてみる。 このページ、いきなりこんな話ばっかで恐縮ですが…。

最適化無しのケースを考えると、返値がレジスタで返せる場合はreturnが、それ以外の場合はresultが効率がいい…(大抵のコンパイラは呼びだし元が無名のローカル変数を準備してアドレスを渡すが、returnの場合改めてそこへのコピーが発生するのに対し、resultの場合はそのまま領域への参照にしてしまえるから)

でも、最適化するならば、結局どちらも同じようなコードにできるので、大した問題じゃ無い。 C++の場合は、静的なコンストラクタに引数を渡したいケースがあるから、returnしか考えられないかもしれないけれど、classは全部ヒープに取るDelphiやDの場合は関係無い。

値が確定してもすぐに返さない時や、関数からvar/out引数などで受け取る場合は、resultのほうがコードが短くなる。 一方、何種類もエラーチェックをしてはその都度エラーコードを返すようなケースはreturnのほうが短くなる。 ただ、結局ジャンプ文なので、else ifで繋げるべきだし、そうしてる人間は多そうなので、これは推奨されないスタイルと言ってしまうこともできる。 (むしろ、私はずぼらなのでreturnの使える言語では遠慮無く使う…)

resultは別に構文糖とは思わない。 returnも構文糖とは思わないが、返値を確定するのと、脱出とふたつの機能を持っているので、機能を組み合わせた結果使いにくくなった制御文であるのは確実と思う。

…それでも、Cのfor文が、同じ変数名を都合三回も書かないといけないのと同じように、わざわざ必要の無い回りくどいことをしている、と感じてしまうのだ。 どう考えてもresultの方がセンスが良く思える。

コンパイラなら問題ないが、インタプリタの場合は、関数末尾にジャンプする無駄な処理が入るし…。 かといって、Haskellみたいな、ジャンプしないreturnが、間抜けに見えるのも事実だ。 (もちろん、Haskellのreturnは値を返す意味すら無くて単にIOモナドで返せる型にするだけってのは承知してます。見かけ上の話ってことで…)

…だらだら書いていて思いつきました。 「もしresultが先に実装されていたら、皆はreturnを構文糖と呼ぶでしょう」

待ち切れないモード

Every .NET language has such a language binding library. VB.NET's Microsoft.VisualBasic.dll weighs in at 300k. JScript's Microsoft.JScript.dll runs about 700k. C#'s language binding library is between 3 and 20MB, depending on whether you draw the line at mscorlib.dll and System.dll or count all of the .NET Framework as C#'s required minimum install. Delphi's Borland.Delphi.dll is less than 64k in size.

これは実験予定項目に追加ですな。

数日前に実家の方にバージョンアップのsnail mailが届いたそうなのですが、Fwしてくれるまでの速度が遅いため、まだ手元には来ていません。 噂によるとバージョン7がついてくるらしいので、やはり7はすっ飛ばして正解でしたね…。

投函

今日バージョンアップの申し込みをしました。 その実7が目当てです。 今のIDEには飽きがきているといこともありますが、いずれ新IDEでWin32の開発も出来るようなOpenToolsも誰か作ってくださるでしょうし…なんて目論見もあります。

スプラッシュ更新

色々あって延びていて、今日になって、やっとDelphi8をインストールをすることができました。

インストール作業が進むにつれ、なんとなく.NETに嫌気がさしてきましたので、気分転換にとスプラッシュを更新しました。

こっそり…

Delphi7&8での初のキワモノ実験は、期間限定ですが、なかなか自分でも衝撃的でした。

「implementsとclass helperがある言語」…私はやはりDelphiを捨てられないようです。 …いや、D言語もやめませんけどね…しかし、Delphiが消えたらDに移行するか…なんて浮気心は飛び去りました。 もっとも、Walterさんが対抗心を燃やして、Dにそれ以上の何かを投入されたらまた変わるかもです。 予定は未定、I do D at my own pace. :-)

ちなみに、Delphi8のヘルプにも、まだObjectPascalという表記が残っていますので、それならばと、一旦はdelphipascal_～にしたファイル名も、objectpascal_～に戻していく予定です。 私のお気に入り度は、ObjectPascal > DelphiPascal > Delphi Language。 (またそーやって気分でリンク切れを生む奴)

実行保護属性

情報ソースは、k.inabaさんのw.l.o.g経由でITmedia News経由でMSDNです。

.NETだけ抜けがあるところが、あざというというか、何というか…。 古いアプリを動かなくして、買い替えを促す作戦じゃないだろうかと勘繰ってしまいますよ…。

…逆に言えば、ilによってネイティブよりも安全になったはずの.NET(中の、unsafeやInteropコード)が、今度はネイティブよりも危険になってしまうんじゃ！？

なお、DelphiのVCLのうち、実行時にコード生成をしているMakeObjectInstanceはきちんとVirtualAllocで属性が指定されてますので(きっと)大丈夫です。

それよりもやばそうなのは私のコード…。

Win32版の行方

Anders OhlssonさんによりますとIDEの統合はDelphi9らしいです。 Delphi7をC#のIDEにしてしまうアドインもあった事ですし、絶対それよりも早く、誰かが8のIDEから7のコンパイラを呼ぶアドインは作ると、私は信じてますが。

第二四半期に7がアップデートされる… dcc32.exe version 16.0と期待していいのか！？ これで15.1とか15.2とかだったら泣きますぜ。 class helper, final, sealed, strict, class var, class property, namespaces, operator...夢想は果てしなく。

class helperのめも

複数のクラスヘルパーを定義して 1 つのクラス型に関連付けることができます。ただし，ソースコード内の特定の場所では，最大 1 つのクラスヘルパーだけが適用されます。最も近いスコープで定義されたクラスヘルパーが適用されます。クラスヘルパーのスコープは，通常の Delphi の方法（ユニット内の uses 節の右から左の順）で決定されます。

邪魔な制限だ…。 幾つでも同時に適用させて欲しい。 Canvasに足りないメソッドを補うclass helperをふたつ作ったとして、同時に使えないって事ですから。