Delphiの人が聞く他の言語でのプログラミング用語

Delphiを使ってると、他の言語(主にC++)でワ
あたりまえに使われる用語がよくわからない。

世の中から取り残される気がするぞ

というわけで、さあ、皆さん、思い切って聞こう。
2chだから　知らないと恥ずかしい事でも聞けるぞ。

イテレータってなんですか？

とっても「痛そう」な言葉なのですが
わかりません。

「繰り返し作用子」かな？＜イテレータ

僕は「反復子」って習いました。

勉強不足をツールのせいにしてはいかんぞ。

>5
どうやって実装するんですか？＞＞繰り返し作用氏

iterate:繰り返すから作った用語みたいですね。
当然何かを繰り返す事です。
オブジェクトに対して繰り返しの部分を抽象化（つまりどれに対しても同じに）
したものをイテレータと呼んでいるようです
Ｃ＋＋なら＋＋で次のデータが得られるような演算子とかね
まあこれが奇麗かどうかは主観でしょう

DelphiのＶＣＬでは繰り返しは
with xx do fori:=0　to count-1 do YY(items[i]);
てな感じで繰り返しを操作する事が多いですね
これはYYという手続きをxxの全部に行うという処理ですから
xx.each(YY);とかやれば同じように出来れば
ループを書かずにループさせる＝繰り返しの抽象化＝イテレータ
と言えるかもしれませんね

数式処理系の言語なんか変数の範囲をオブジェクトとして
扱うものがありますよね。

Speakeasy とかなら

x=grid(-pi＠｀pi)
y=sin(x)
graph(y＠｀x)

で、ループを使わなくても sin のグラフが描画できます。
こーいうのも反復子と呼べるんでしょうか？

>>8 似てるけど 'iteration' とは違うな

内部イテレータってやつでは？
詳しい人教えて

イテレーターは言語と直接は関係ないよ。
デザインパターンの本を読んで送れ。

イテレータねえ・・・
Inc＠｀ Dec＠｀ Pred＠｀ Succ
Table1.next;

C++はテンプレート関係は他にもありそうだな。

Javaからはなんかねーか？

>12
Delphiってリフレクションとかあるの？

>13
ないじゃない？

図書館でＣマガの今年のバックナンバーを調べてみては？
中村の里で有名な人がＶＣＬ解体新書とかで連載してた中に
その手の情報が掲載されていましたよ。
たぶんあの情報が一番まとめられた情報でしょう

けど、あれって洋書のぱくりなんだよね....

リフレクション：自己反映計算
「Javaプログラムデザイン」て本に書かれていた。
でもそれ以上は書かれていない。実行時型情報と関連あるの？
TObjectの派生クラスにはメソッドアドレスとかの情報が
あるようだけど。

親愛なるD使い様
当方普段はBCB使いなのですが、たまにDelphiで書かれた
Unitを改変しなくてはならないことがあります。
そこで、困ったことをふたつほど質問させてください。
どちらも外部参照の関連です。

１．Unit外の関数の呼び出し方
　ObjectPscalで書かれた他のUnitの関数の呼び出し方は
　Uses節にUnit名を書けばよいということはわかりました。
　わからないのは他言語(BCBなんですが‥)で書かれた関数です。
　　function c_func(Val:integer):Integer; cdecl; external;
　などとinterface部に書いてはみたものの
　「forwardまたはexternal宣言された'c_func'が見つかりません」
　と、おこられてしまいます。

２．Unit外の変数の参照のしかた
　同じく他言語で宣言定義された変数です。
　　c_val:integer; external;
　などとinterface部に書いてみましたが、こちらは文法的に
　エラーらしく、相手にもされませんでした。(涙)

スレ違いかとも思いましたが、他に適当なＤスレが
見当たらなかったもので‥（さすがにＤｖｓＶＢには‥）
どうかよろしくご教授願います。

私はDelphiで作ったのをC++ビルダで使う事が殆どで、逆をする時はDLLにしてしまう事が
多いので間違ってるかもしれませんので、ヘルプファイルから関連する個所を
[手続きと関数]->external 宣言(OBJ ファイルのリンク)


変数の参照はやり方は判りません。というか出来ないのでは？
やるなら、変数のポインタを返す関数を作って参照するのが速いかも

>19
相手が*.objなら{$LINK ファイル名}
ですね。VCだと関数名がマングルされている可能性が
あるのでTDUMPで確認しましょう。

>18
cdel要らないんじゃない?
BCBではfastcallにする場合がほとんどだから。

JAVAリフレクション
http://www.sfc.wide.ad.jp/~ts/docs/ja/guide/reflection/index.html

DelphiのRTTI情報は　メソッド名からメソッドを検索出来たりと
C++のRTTIとは少し違います。　簡易インタプリタを走らせたりする時に便利ですね

ご教授ありがとうございます。

じつはわたくし、Delphiは使ってないんでして‥
マニュアルすら見たことも無いんです‥
PascalのUnitは他人が過去に書いたものがまわってきてしまったものです。
BCBは、PascalのUnitをプロジェクトに追加してコンパイルできて
しまうので‥書くのもコンパイルもBCB上なのです。
幸いBCBにはObjectPascalのヘルプが付いているので(全部ではないのかも‥？)
なんとかそれ見ながら奮闘してます。

Pascalは不慣れなもので、コードを増やすのはできるだけC側でやりたいので
C側に変数のポインタを返す関数をつくるというアイディアも考えたのですが
肝心のその関数をPascal側から呼び出せないという、なんともイタタタな
状態だったのです。

{$Link ファイル名}早速試してみます。ありがとうございました。

cdecl をはずしても結果は同じでした。 ＞２１

{$L filename.obj}試してみましたが、結論から言うとダメでした。

これは既に完成した‥というかプロジェクト外のコンパイル済みの
objが存在する場合にしか使えないようです。
なるほど、ObjectPascalでは、コンパイル時点で存在しないコードへの
参照は禁止しているということなのでしょう。
これがCではexternキーワードひとつで簡単に作れてしまうところですが
さすがPascalは固いといわれるだけのことはあります。
（もちろんCでもコンパイルが通るだけで、リンクは通りませんが‥）

私の場合、CのUnitもPascalのUnitも同一のプロジェクト内にあるので
objが無いとのエラーが出てダメでした。
先にC側のObjを作っておいてもダメでした。以前と同じエラーが出ます。
とりあえずはプロジェクトを切り離してしまえば何とかなりそうなのですが、
いまさらそれをするのは、かなり大きな変更になってしまいますし
CとPascalの両方の修正がほぼ同時に起こるので、できれば一つの
プロジェクトですませてしまいたいところです。

もう少し別の方法を検討してみます。
ポインタを使えば何とかなるんじゃないかという気がしてきました。

追記：
ObjectPascalではどうやら外部の変数の参照はできないようですね
少なくともヘルプにはDLLに対してはできないとの記述がありました。
objに対する参照は関数についてしか見つかりませんでした。

状況が良く判らないけど、
という事は殆ど作業をビルダでやってるんでしょ？
そしたら、コールバックで渡したらいいんじゃないの？

ありがとうございます。
ほとんど、というか、全部ビルダでやってます。

C側から直接呼び出す関数については、こちらはあまり数が無いんで
おっしゃる通り関数や変数のポインタを渡すようにすることにしました。

悩んでいたのはPascal側のTFormやTButtonのイベントメソッドの中から
C側の関数を呼び出したり変数を参照したいというとこなんです。
こちらは、C側から呼び出す関数ってわけではないんで‥なにしろ
メインフォームまでもがPascalというとんでもない状況だったんです。
もともとはPascal側から呼び出すDLL作るだけのはずだったのになぁ‥
泣きそう‥ああ、いかん、愚痴になってます。

すったもんだの結果、結局PascalのUnitのInterface部に参照したい
変数と関数のポインタを定義し、プロジェクトソース中で(こちらはCです)
からそのポインタを初期化してやるという方法を使ってなんとか
Pascal側からCの変数や関数が参照可能にはなりました。

これでとりあえずはなんとか動く算段はつきました。
あとはひたすら、必要なポインタを作っていく作業です。
ここのところ以外はほとんどC側で書けそうですので
あとは何とかなると思います。
ご親切なＤ使いの皆様、ご協力感謝します。ありがとうございました。

かなり汚い方法ですが、いまのところ他に方法が思いつきません。
他になにかいい方法を思いついた方がおられましたら
ぜひともご教授くださいませ。
あと一週間くらいはこの作業やってますので‥

あ、なんだ、両方とも貴方がいじってるのですね>28=18
それなら全部PASCALコールにしちゃえば解決しないかな??
（これまた余り誉められない手口だが)
タイプセーフリンケージで引っかかっているのは明白なんだが。

それで解決する問題ではないと思うぞ、経緯を読んでミソ。

C++BuilderとDelphiの呼出規約の対応を挙げておきます。

Delphi C++Builder
--------------------
stdcall＠｀ __stdcall
register(*)＠｀ __fastcall
cdecl＠｀ cdecl(*)
pascal＠｀ __pascal

(*)は両言語でのデフォルト

また、スタティックリンクの場合、Cのライブラリ関数
をリンク出来ない為、DLLにした方がよさそうです。

C側の関数はC++による名前変形を避ける為 extern "C"
ブロックで囲みます。呼び出し規約はstdcallが一般的です。

「Delphi３ Q&A 150選」という本に詳しく書かれていたのですが
残念ながら今では入手困難です。

１８さんのケースは以前、私もはまりました。
Delphiはコンパイル時に存在しないｏｂｊへの参照ができないようだ。
タイプセーフリンケージの問題ではないのでいくら型をかえても無駄。
私の場合プロジェクトとは別に小さなＣのソースをひとつ用意して解決した。

//int hogeはプロジェクトの中のC++にある
extern int hoge;
//Pascalからのhoge参照関数
int get_hoge(void){return hoge;}
//Pascalからのhoge書き込み関数
void set_hoge(int Val){hoge=Val;}

// int giko(p1＠｀p2)はプロジェクト中のC++ある
extern int giko(int p1＠｀int p2);
// pascalからのgiko呼び出し関数
int call_giko(int p1＠｀int p2){return giko(p1＠｀p2);}

こんな感じ。
このソースだけはプロジェクトに入れず、別に先にコンパイルしておく。
参照したい関数と変数分だけを作ればよく、実際の中身はプロジェクト
内で記述できるから、改変が何度も繰り返されても楽。
（呼び出し規約が頻繁に変わるようなときはさすがにダメだが‥）

あたりまえだが、以上の問題はDelphiでは発生ない。
（DelphiではC++のユニットをプロジェクトに加えられないからであって
　問題が解決されているからというわけではない。）

テンプレートはマクロみたいなもんってホントですか？
展開ソフトを作ってユニットファイル作るような感じを自動化してるだけ？

と言われたら　そうだな

う～む。

>33
クラスの定義はマクロみたいなもんかもしれないけど、呼び出す側の処理
も含めると、マクロの範囲を越えてるんじゃないかな。

テンプレートをマクロで表現するならば、

#define max(a＠｀b) (((b) > (a)) ? (b) : (a))

じゃなくて

#define def_max(type) \
static type \
max_##type(type a＠｀ type b) \
{ \
　　return (b > a) ? b : a; \
}

みたいなもの。

ただしこの例では実際に使用する際に
def_max(int) とか
def_max(double) とかいう具合に
実際に使いたい型毎に一々関数定義を作成した上で

max_int(m＠｀ n); とか
max_double(s＠｀ t); とかいう形で呼ばなければならない。

一番上の古典的なmaxマクロとの違いは、max_intやmax_double
が本物の「関数」であり、従ってこのレベルでは型安全性や
その他もろもろのことが保証されるということ。

テンプレートは、このようなものを自動化して使いやすくしたものだと思えば
いいと思う。自動化されて裏に隠れてはいるけれども、
結局は上とほぼ同じようなことが行われており、その結果生じる欠点や
問題も、上のマクロと似たようなもの。

＞max_int(m＠｀ n); とか
＞max_double(s＠｀ t); とかいう形で呼ばなければならない
テンプレートを表現できてないじゃん。

おいらのばあいどっちかっていうと古典的なマクロが欲しいんだよな。
ＩＤＥから直接使えるプリプロセッサって存在するんでしょうか？
それがあるならそれで十分なんだけど‥

プリプロセッサを導入することに何か問題があるから、 Java や C#
では採用されなかったんだけれど、どんな理由があるの？

「プリプロセッサ」は要するに文字列置換ソフトでしかないから
言語構造とは無関係に処理が行われる。
これを利用して、文法の拡張とかをする例も多かったのだが、
言語処理系の能力が上がってきた現在では処理系自身に拡張
のためのメカニズム（OOP なりテンプレートなり）が実装されて
きたため、上記の「言語構造とは独立に」というのが欠点と
なってきた。

たとえば（極端な例だが）
#define char int
と書いても、プリプロセッサは処理を拒絶できないし、
コンパイラは素直にコードを吐くしかない。

だから、プリプロセッサが担っていた機能を分解し、言語構造に
取り込んでいくことが近代的な言語設計の基本となる。

C++ でいうと、定数定義の能力は const 定数とコンパイラによる
最適化（への期待）となり、型の置き換えは（初期の）テンプレート
で提供するようになった。

Javaの場合は
プラットフォームの非互換やバージョン違いを
#ifdefマクロみたいんで対応するヤツが絶対出てくるから
「バイナリレベルで互換性をとる」っつー錦ノ御旗がもろくも
崩れ去るから、、、

って邪推してたけど。

#ifdef関連はマクロの中でも別格
さすがにこれの有用性を否定する人はいないよ

よく知らないけどJavaには#ifdef相当の機能って無いの？
そんなはずはないと思うけど...

ageないで

たぶん同じ名前のPart2を作んない限り一生やってるよ
こいつら

まちがえちゃった
ごめんね

>43
ないです。#ifdef使う必要ないから｡

デバッグバージョン作るんでも、プリプロセッサなんか使いません｡
デバッグ出力取得用デーモンオブジェクト作るだけ｡

>43
そんくらい自分で作れ｡Perlか何か使えば簡単だろ｡

ありがとうございます。
という事は文法チェックのしっかりしたプリプロセッサという解釈で
そんなに間違ってない訳ですね。
じゃ、インクルードファイル機能を使った
http://piza.2ch.net/test/read.cgi?bbs=tech&key=970606624&st=97&to=97&nofirst=true

みたいなやり方も立派なテンプレートって言っていいのかな？
でも、それだったらCでも
typedef した後でインクルードファイル呼べば同じように出来る訳で
ワザワザテンプレートって新しいものを持ち出した意味が今一つ判りません

>>48
でも言語の進化というのは
今までみんなが経験的にやってたことを吸い上げて
文法化して安全に厳密にやろうって事ですから
プリプロセッサの進化形がテンプレートで
あるのはそんなに悪いことではなと思います。

問題なのはこのアプローチが安全な
コピー＆ペースト支援でしかないということで、
OOPの具象クラスを抽象クラスで束ねて統一的に扱うという考えと
真っ向から対立してしまいます
（結果的にできることはそれほど違わないにしても）。

それでDelphiへの導入に難色を示す人達が多いんだろうと思います。

>38
まあ確かに関数テンプレートの場合は

1) max<int>(a＠｀ b);
じゃなくて
2) max(a＠｀ b);
と書けるけれども。

テンプレートの本質はそこじゃねえべよ。
クラステンプレートの場合は型パラメータの省略は出来ない訳だし。

>48
(ある言語で)
「ある機能を実現することが出来る」
というのと
「ある機能がサポートされている」
というのは明白に違う。
「実現できるんだったらいいじゃん」というのであれば、つきつめれば
じゃあ何でもアセンブラで書きなよ、という話になる。

>50
つーことは、テンプレートの本質はマクロで代用できるってこと？

別スレの97はtemplateが登場する前にgeneric.hで使われていた形だね。
「型をパラメータとする(Parameterrized Type)関数テンプレート」。

Pascalにはプリプロセッサがないから、それぞれの型別に
インターフェース(ソース)を用意する必要がある。
generic.hでも、インラインで済まない場合
実際に使用するときには、型別に実体を作成する必要があった。

関数テンプレートが実現され、
型をパラメータとして必要としない、
実体を確保する手間が必要ない、となった。
そういった経緯を経て、templateのメリットが強調され、
実装される事になったんだとと思う。

いーや。
マクロでできることの多くはテンプレートでもできるし、
テンプレートでできることの多くもマクロでできる。

けど、マクロの本質は文字列置換でしかなく
テンプレートの本質は型の扱いを静的な物から動的な物に変えた、と
いう点で、本質はまったく異なる。

だからテンプレートはマクロで置き換えることはできない。

全然対立しない。
実行時にしていたことが
コンパイル時にできるようになったということ
だけ。

テンプレートでプログラミングをするとJavaがひどく伝統的で
古くさく思えてくる。

53の言う本質とは実装の方法。
本質というのは利用者側から語るべきではないかと思うぞな。

従来マクロで書かれていたものをより安全に／高度に使えるようにしたもの
がテンプレートである以上、中身がどう動いているかはさておき、
同じように書けるものは、本質的には同じと考えて差し支えないと思う。

もちろん中身について知ることの重要性は否定するつもりはないが‥

>>54 全然対立しない。
そうでしょうか？

「対立」という言葉がまずければ
ソースの共有を行う機能が継承と重複してしまっている。
といい換えられます。
重複してしまう以上OOPLへの導入メリットは薄いと言わざるを得ません。
実際、むこうのスレッドでは楽だし読みやすいシンタックスシュガーである
という以上のメリットが説明されていません。

C++があえて非OOP的なテンプレートを導入したのは
バーチャルメソッドのオーバーヘッドを嫌って、
インライン展開も有効にしたかったからだと想像します。

>55
>同じように書けるものは、本質的には同じと考えて差し支えないと思う。
よく考えていないので、間違っているかもしれないが、
マクロでできること＞テンプレートでできること
だと思っている。（とりあえずソースだけ考えてね）
でも、何でもできる方が良いってわけではないのは、
Java の single inheritance からわかる。（例が良くないかな）

>56
継承ってのは、インタフェースが同じでもアルゴリズムが違う場合に使われるもの。
総称は、アルゴリズムが同じでもインタフェースが違う場合に使われるもの。

というわけで、両者の重複は弱いのでは？

>55
テンプレートが不要だと思うのなら
STLをテンプレート無しで実装してみればいい。

マクロは守備範囲は広いが、プリプロセッサの管轄にあるのがマクロの
能力の源であるとともに、最大のネックだろう。

おお！私の書き方が悪かったようだ。
私はテンプレート否定派でもないし、マクロ＝テンプレートとも考えてはいない。
マクロの、今で言うテンプレート的使い方という側面のみを取り出せば、
（その実装はともかくとして、利用者側から見れば）本質的には同じではないか
と言いたかっただけなんである。
言語的側面からみると脆弱なマクロも、プリプロセッサとしての守備範囲の広さ
や自由度を切り捨ててまで、その利用を制限する必要はないと考えている。
私はそういう意味でプリプロセッサ擁護派なのであるが、しかし
テンプレートのように、マクロの特定の側面を言語仕様としてとり入れて
いくことには何の異存もない。

>57
>アルゴリズムが同じでもインタフェースが違う場合に使われるもの。
は十分継承の守備範囲内だと理解しています。
例えばTObjectStack(こればっかり:-P)や
親クラスのprotectedメソッドを利用する
全く別のインターフェースを持つクラスなどがあります
(最近は委譲するのが流行りですが)。

「総称」の意味をよく知らないのですが、templateとの対比で言うと
総称＝出入口部分のごまかし技術(言葉が悪いですが)
テンプレート＝>>37のようなマクロ支援(総称も含む)
ということですか?

>60
私もよく理解していないんですが(^^;、言葉どおり「総称」は「総称」です。
つまり、

そうしょう 【総称】
（名）スルいくつかの物を一つにまとめて呼ぶこと。また、その呼び名。総名。「弁護士・作家などを―して自由業という」

ということ。
だから、Java の Object や Delphi の TObject も総称ってことで理解しとります。

>例えばTObjectStack(こればっかり:-P)や
>親クラスのprotectedメソッドを利用する
継承して、新しいインタフェースで包むってことですよね？
Delphi Tech でも同じこと書いてありますよね・・・。
う～む。

専門用語のばあい、単に国語辞典をひくんでなくて、和英辞典を
ひいてから英和辞典をひきなおすといいでしょう。
総称→generic→
【コンピユータ】　汎用の，　総称の．
generic class【コンピユータ】　汎用クラス．
generic function【コンピユータ】　総称関数，　汎関数．
など出てきます。

>「総称」の意味をよく知らないのですが、templateとの対比で言うと
いえ、日本語・英語の意味が分からなのではなくて(^^;
向こうのスレッドで出てくる総称ポインタやEiffelの総称(制限つきの総称)
がどのように機能するのかというテクニカルな疑問です。

>総称＝出入口部分のごまかし技術(言葉が悪いですが)
が正しいとすると57後半の設問自体が意味を成さなくなります。
あくまでテンプレートとの比較ですので。

57さん≠54さんですよね？

>>57

>マクロでできること＞テンプレートでできること
>だと思っている。（とりあえずソースだけ考えてね）
型安全は、制限ではなく「できること」としてカウントすべきでしょう。

>継承ってのは、インタフェースが同じでもアルゴリズムが違う場合に使われるもの。
>総称は、アルゴリズムが同じでもインタフェースが違う場合に使われるもの。
>というわけで、両者の重複は弱いのでは？

両者が違うものだという感覚が49には薄いのではないでしょうか。
そもそも総称はOOではないと思っています。
継承と総称を組み合わせてOOするというのが正しいのではないでしょうか。
継承してもポリモーフィズムをしなければOOではないのと同じ事です。
そして総称を組み合わせたOOはかなり強力だと思います。
継承だけでもいろいろできますけど、やっぱり弱いですよね。

>>60
C++のtemplateは、総称としてかなりいい線を突いていると思いますよ。
Eiffelのほうは使ったことが無いのでよくわかりませんが、
制約つきの総称は、別にC++での「メソッド（オペレーター）が
無かったらリンクエラー」で十分なんじゃないかって思うんですけどね。

そうそう。そのオーバーヘッドが決定的。
テンプレートで可能なことを
わざわざ仮想関数でする必要はないし、仮想関数でなければ
できないこともあるのでやはり両方が必要。

というか理由は全部C++言語3版に書いてあってひどくむなしい。

うーん、template推進派の人はC++のtemplateが完璧だと
思ってないですか？。そうは思えないんですけど。
安全でない部分が結構ありますよね。その点がDelphiに
向かない気が。多少遅くても安全な方法をとるのが
Delphi向きだと思う。欲しいのはtemplateそのものじゃなくて
templateと同等の機能をもったものだと。

質問させてください！
これからプログラムの勉強を始めようとおもってる、超初心者です。

CGIやJAVAなどのプログラムを作成する場合、
やっぱり言語は頭に記憶しておかなければ
できないものなのでしょうか?

今実際に作られている方々は、必要な言語を記述するたびに、
辞書を引いたりして作成なさっているのですか?

template の安全でない部分てどこ？
STLが危険だっていうんならわからないでもないけど、
それでも生のC++並みに危険だっていうだけだ。
効率を犠牲にしたSTLの安全な実装も可能だし。

>68
STLのイテレータって生のポインタよりは安全だけど、
けっこう危険な感じがする。

キミ、超初心者という自覚があるのなら
そういう質問は別のスレッドでしなされ。
そのほうが返りもいいと思うぞ。

>70
それさえもわからない初心者ということで。

よくよく考えればDelphiにテンプレートなんか
付けても意味ないな・・・

DelphiがC++テンプレートで作られてるかもしれんしな。

>>72
C++Builder は Object Pascal がコンパイルできる・・・
Delphi のコンポーネントを使える・・・
このことから考えるとどう考えても Delphi で C++Builder
作ったとしか思えないんだが(Delphi は Delphi で書かれて
るそうだし)。

ビルダのIDEはDelphiで作られているかもしれない。
当然DelphiコンパイラはDelphiのものが使われているだろう
でもC++コンパイラは以前からのものだと思われる。
案外Cかもしれない。

DCC32とBCC32、どちらもTASMで書かれている。
system.pasを見よ、アセンブラの塊じゃないか・・・

>>66
temlpateが完璧だと思っている人はほとんどいないと思うよ。
Ｃ＋＋を作った当人たちでさえそう思っているはず。

例えばイテレーターがとんでもないところを指す状況は簡単に起こりうるからね。
だけどあのアプローチで作れるものとしては最高のものだと思う。
今現在実用化されている言語の中で、総称をサポートしているのはＣ＋＋だけなんだよ。
現実的な選択の中で高いレベルの仕事をやり遂げた彼らの仕事は評価されるべきでしょう。

これ以上の安全性を求めるなら、根本的に構造を変えないとね。
最初から総称を考慮して言語を設計するしかないでしょう。
だから Java も Delphi も組込みあぐねているわけだし。
かといって Eiffel なんか使いたくもねぇしな。

>>75 DCC32とBCC32、どちらもTASMで書かれている。
出典は？根拠は？

>system.pasを見よ、アセンブラの塊じゃないか・・・
大抵の言語処理系の RTL、特にメモリ管理やシステム管理部は
アセンブラで記述せざるを得ませんが？ MS VisualC の RTL
でも読んで見なされ。MFC アプリケーションも「アセンブラで
書かれている」とでもいうのかな？

>77
100%ネタです。スマソ。
でも初期の頃はアセンブラだったかも知れん。
いや、パーサジェネレータとか使うのかな、やっぱり。

Delphiのコンパイラは一部アセンブラみたいですよ
Borlandのカンファレンスか何かでDelphiをDelphiで再構築する
デモンストレーションやってたときに言ってました。
多分TurboPascalのころからでしょう。
世界最速のコンパイル速度が売りですからギンギンに高速化した
アセンブラコード書いてるんでしょうね（＾＾

その話題、fj.comp.lang.pascalでも出てたな。