◇2002/10の日記◇

New← 生きてますよ? / C#と.Net / Pascal規約 →Old


2002/10/31 生きてますよ?

だいぶ間があいてしまいましたが……。
修羅場の2/3が終わって、開放感溢れるシェラです、こんばんは。ヽ(´ー`)ノ
サイトも移転して、気分一新です。


と思ったら、ROは課金ですか……。
課金前に転職は、確実にムリだと思います。(泣
まぁ、さんきゅー期間は、様子見で続けますので、その間に頑張りますよ〜。


さて、私が修羅場で二葉亭た間も、世間はいろいろ動いていたようで……。
今日は、その遅れを取り戻すべく、リンクの整理をして終わりたいと思います。(ぇー


11月頭は、もう少しまめに更新する予定ですので、もうしばらくお待ち下さい。
11月中旬からは、おそらく今年は最後であろう修羅場が始まりますが。


2002/10/16 C#と.Net

再び修羅場の2/3が始まって、ちょっと溜息なシェラです、こんばんは。
まだまだ、本格的にミドガルドに戻れる時期は遠い気がします。(泣


なんだか、Псиさんに丸投げされかけたので、ちょっと触れてみることにします。
もちろん、泥沼確定ですが。(何


というわけで、今回はちょっと、ヨシミさん風にいってみようかと。


この英語っぽい書式のおかげで、プログラマは意図した機能をそんなに苦労することなく実装することができます。


ありがたい話です。
今さら、「もっと機械に優しい書式で書け!!」なんて機械に怒られた日には、裸足で逃げ出して再就職先を探さねばなりません。


しかし、稀にですが、「コンパイラ」が、麻宮騎亜先生の「コンパイラ」に登場する「コンパイラ」よりもアレだった場合、もしくは、「コンパイラ」が機械に優しい書式を全部把握しているわけではなかった場合には、より涙ぐましい努力が求められます。


その翻訳プログラムを「コンパイラ」とか「インタプリタ」とか呼びます(両者の違いは割愛)。


軽く説明しますと、「コンパイラ」は事前一括翻訳「インタプリタ」は実行時翻訳の違いです。


Sunが作ったこの言語は、コンパイル時にプラットフォーム依存の機械語に翻訳するのではなく、当たり障りの無い中間言語に翻訳・圧縮します。


この、Javaの当たり障りの無い中間言語を、「バイトコード」といいます。
これは要するに、Javaのソースコードを、Java仮想マシン(JavaVM)上での「機械に優しい書式」である「バイトコード」に「コンパイル」。
実行時には、バイトコードをJava仮想マシン上で実行(ということは、実際のマシン上ではインタプリタによる実行になる)、ということですね。
JIT(Just-in-Time)コンパイラというものを導入すると、実行前に全体を、機械に優しい書式に変換してから実行するので、速度が向上します。


さて、本題のC#は、C/C++を拡張した書式で書かれたプログラムをMS独自の中間言語に翻訳し、.NET Frameworkという部分がそれを更に翻訳、実行


そしてこの、C#の中間言語を、「MSIL(MicroSoftInterMediateLanguage)」といいます。
Javaの、JavaVMにあたるのが、.NetFrameworkというわけです。
ちょっと違うのは、.NetFrameworkは、最初からJITコンパイルの仕組みを備えているので、インタプリタとして動くことはないということでしょうか。


どう見てもC#がJavaの仕組みと機能をパクっていて、構文もちょっと似通っていて、更に後追いの特権としてJavaの欠点を出来る限り潰し、高速化し、そんなものを全く同じ市場に向けて提供したとしても、それも仕方がないと思います。


ここでは、C#とJavaを対象として見ていますが、これが、JavaVMと.NetFrameworkを対象として見た場合、恐ろしいことが発覚します
JavaVM上で動くものは、Javaでしか作れません。
しかし、.NetFramework上で動くものは、C#.NetでもVC++.NetでもVB.Netでも、その他色々な言語でも作れるのです


なんと恐ろしい陰謀でしょう。
これでは、JavaVMで動作するバイトコードを吐く、CやBasicのコンパイラが出てこない限り、Microsoftの勝利は決まったようなものです。


シェラ0x19歳は、Microsoftの策略に怯えつつ、やっぱり泥沼になってしまって、ちょっと後悔しています。


2002/10/10 Pascal規約

ようやく修羅場の1/3が終わって、ちょっと一息なシェラです、こんにちは。
まだまだ、本格的にミドガルドに戻れる時期は遠そうです。(泣


修羅場ってる間に、いつの間にか、季節はもう冬
ストーブを使用する時期になってしまいました。
バーチャルな世界で季節を求めても、しょうがないんですけどね。
そこはそれ、風情というヤツです。


さて、この間、投稿フォームで、このような投稿をいただきました。

こんばんは、ラグめぐりでプログラム教授を受けられとは思っても見ませんでした。
Pascal規約のこともう少し教えてください。VBプログラマよりw


……こんな話でも、需要があってよかった。(ぇ
というわけで、今回は、Pascal規約について少々語ってみたいと思います。


このPascal規約というものは、簡単に言うと、関数の呼び出し方や、関数からの戻り方等が定義されているもので、他にもたくさんある規約の中の一つです。
「たくさんあっても覚えきれね〜よ」という声には、全く賛成ですが


では、この規約で一体何が変わるのかというのを、軽くまとめてみましょう。

●規約による違い
関数装飾名の、大文字小文字を区別するかどうか。
関数装飾名の前に、アンダースコア(_)をつけるかどうか。
関数装飾名の後に、アットマーク(@)と引数の格納に必要なバイト数をつけるかどうか。
引数を、左から右の順序で渡すか、右から左の順序で渡すか。
引数を、レジスタを使って渡すか、スタックを使って渡すか。
スタックのクリアを、呼び出し先で行うか、呼び出し元で行うか。
等々……


装飾名というのも、聞き慣れない言葉だと思いますが、これは、コンパイラが関数の定義時に生成する文字列のことです。
どのように装飾されているかは、VCでは、MAPファイルを生成することで確認できます。


では、試しに、以前の「WinTest」プロジェクトで、MAPファイルを生成してみましょう。
MAPファイルには、たくさんの情報が出力されますが、とりあえず以前に説明したWinMainだけ。


 0001:00000000       _WinMain@16                00401000 f   WinTest.obj
			

アンダースコア(_)がついていて、装飾名の後に、アットマーク(@)と引数サイズの16バイトが書いてあるのがわかりますね。
まぁ、このように装飾されるわけです。


ところで、なぜ、このような規約がいろいろあるのでしょう?
実は、プログラム言語の設計上の理由により、それぞれのプログラム言語では、関数の呼び出し方が違います


しかし、ここで困ったことが起こります。
Aというプログラム言語で作ったDLLを、Bというプログラム言語から利用したいときに、関数の呼び出し方が違っていては、きちんと呼び出すことが出来ないという問題です。


というわけで、DLLを作成、使用する際には、問題を起こさないようにするために、常にこの呼び出し規約を意識して、プログラムを組むのが吉ですね。


シェラ0x19歳は、ネタをくれる投稿に感謝しています。