Interfaces.C
私は、Adaを、言語自体のポテンシャルは最強と推して憚りませんが、標準ライブラリについてはかなり駄目駄目と言わざるを得ません…。
で、駄目駄目具合が最も集約されていると思われるのが、Interfaces.Cです。
http://www.adaic.com/standards/95aarm/html/AA-B-3.html
http://www.adaic.com/standards/rm-amend/html/RM-B-3.html
たとえば文字列。
type char_array is array (size_t range <>) of aliased char;
C言語ってば文字列ことchar配列の添え字がsize_tでしたっけ…？
a[i] == *(a + i)ですからptrdiff_tが正しいような気がします。負の値を禁止したいならそういうsubtypeにすればいい筈です。Adaなんですから。
件のwchar_tも、
type wchar_t is <implementation-defined character type>;
implementation-definedとされているわりには
function To_Ada (Item : in wchar_t ) return Wide_Character;
こんなのがあるせいでAdaのビット幅が定められたWide_Character*1と同じ16ビットになってしまってインターフェースユニットの用を足してませんし…。
Stringsのchars_ptrと演算用のPointersが別々に用意されているものですからchar*に対して演算ができない馬鹿げた話になってますし…。
色々用意されているわりにはDelphiで言うところのPCharへのキャストが無いため、事あるごとに文字列全部複写しろって話になってますしね…。メモリイメージ同じ筈なのに。
更にGNAT@gccの場合、strlen等をlibcからImportしてこずにfor-loop文で実装するやっつけ具合。*2
「性能悪い」「こんな定義ではAdaの機能をフル使用できない」「C言語の定義に一致してるかも微妙」「そもそも目的を果たさない」、要するに使えねえわけですが、恐ろしいことにこの使えねえInterfaces.Cが標準で、しかもこれを使ってインポートされたlibcやAPIやなんかでライブラリの他の部分は実装されているわけです…。
つまりAda.Text_IOの下にあるFILE構造体を弄ったりするときには、使わざるを得ないという話で…。まあ、これに限らずGNATの実装は、Ada.Text_IOにしたって随分効率悪そうなんですけれども。
私は、ちょっと標準入出力をバイナリモードにして、それからさくっとiconvのインターフェースを書いてしまいたかっただけなのに…。
