2008/8/13 - 2011/7/27
Pen Jr.D言語なんてやってみそWelcome BeginnerWelcome
開発モデル
D言語 ではソースコードが数行の小さなものから、数千行のファイルがいくつもある大きなプロジェクトでも、基本的な開発手順は同じ、
  1. ソースコードの記述
  2. ビルド(コンパイル/リンク)
  3. 実行(デバッグ)
コンソールアプリ なら ツール は テキストエディター と コマンドプロンプト だけで OK。
ソースコード
ソースコード は テキストファイル に記述しますから、既存の テキストエディター が使えます。
文字コード
文字コード が違うと コンパイラ は正しい解析が出来ません。

ほとんどの プログラムコード は ASCII だけで記述できますから、コメントも含めて日本語を使わない限り問題が起こらなかったりしますが、どこかで日本語などの ASCII 以外を使う可能性があるなら正しい指定が必要です。

  • ASCII
  • UTF-8
  • UTF-16BE
  • UTF-16LE
  • UTF-32BE
  • UTF-32LE

のいずれかとなっていますが、UTF8 以外を選ぶ必要はないでしょう。

BOM とか細かいことは テキストエディター の問題ですから、余程おかしな エディター を使わない限り気にする必要はないと思います。

テキストエディター
日本語 Windows だとデフォルトが Shift-JIS なのが普通だったりしますから、最低 文字コード の指定が出来るものが必要。
Notepad(メモ帳)
「名前をつけて保存」で文字コードを UTF-8 に指定して保存する。

Windows にはついてきますから面倒はありませんが・・・

秀丸エディター( 秀まるおのホームページ
強調表示 や 単語補完 なんかも出来る、高機能エディター。

有料ですが バージョンアップ なんかは無料ですし、コメントのネストなんかの色分けも正しく出来たりおすすめです。

広く公開できるような出来じゃありませんが、試してみるならご自由に。

D-Setting.hilight のダウンロード

その他のフリー
フリー の テキストエディター は結構いろいろありますし、出来の良い エディター はあると思いますから、いろいろ試してみると良いでしょう。

プロジェクト管理とか出来るのもありますが、ぜひ 単語補完 が出来る テキストエディター を見つけましょう、つまらないタイプミスが 激減 しますから。

フォント
人にもよるでしょうが、フォント がナイスだとやる気も違ったりするかもで、

O0 がちゃんと違うやつは、Windows7 なら

Consolas

でも日本語が入っていないから、

M+2VM+IPAG

とか、

UmePlus Gothic

差が微妙ですが、まあ、好みとこだわり方の問題ですわ。

好みの フォント を見つけて、色分けすれば ソースコード は別物。
作業ディレクトリー
ソースファイル と 実行ファイル 以外の ファイル が出来ますし、リソース などの ファイル、補助ツールのための ファイル など、1つのプロジェクトで多くの ファイル を扱いますから、プロジェクトごとの フォルダ に出来るよう、プログラム専用の 親フォルダ を用意しましょう。

D Compiler などはいつでも再インストール出来ますが、自分が書いたコードは失ったら最後ですから、守りやすいところに、

Welcome
import std.stdio;

void main()
{
  writeln( "Welcome Beginner" );
}

これを適当なところに、任意のファイル名 test.d とかで 保存 します。

その際 文字コード(エンコード)を UTF-8 に 指定 できれば OK。

ビルド
コンパイル( Compiler Arguments and Switches
ソースコード の ファイル がある フォルダ で コマンドプロンプト を開いたなら
dmd ソースファイル名
D:\Pen-Jr\My Programs\Welcome>dmd test

D:\Pen-Jr\My Programs\Welcome>

コンパイル は問題がなければ無言で終了します。

ソースファイルが test.d なら、test.objtest.maptest.exe が出来ますが、

実行時に必要なのは test.exe だけです。

リンク
dmd は何も指定しないと自動的に リンク を実行しますが、

コンパイラ の仕事は オブジェクトファイル を作るところまです。

必要な オブジェクトファイル や ライブラリ、リソース を集めて 実行ファイル を作ることを リンク と言い、リンカー は標準で付属しています。

複数のファイルやリソースを使った場合でもほとんどのことは コンパイラー の引数で指定でき、リンカー は自動的に実行されますので、リンカー を意識することもなく link コマンド を使う必要があることは少ないでしょう。
コンパイルエラー
コンパイラ はちょっとしたタイプミスでも違反は絶対に見逃してくれませんが、わかりきったことでも自動補完などしてくれません。
inport std.stdio;

void main()
{
  writeln( "Welcome Beginner" )
}

見た目は同じ?ですが

D:\Pen-Jr\My Programs\Welcome>dmd test
test.d(1): semicolon expected, not '.'
test.d(1): no identifier for declarator .stdio
test.d(6): found '}' when expecting ';' following statement
test.d(7): found 'EOF' when expecting '}' following compound statement

コンパイラは大騒ぎです。

1つのミスが原因で、エラーメッセージ に埋め尽くされることなど珍しいことではありません。

初めはコードを書き換える度、いくつもの エラーメッセージ を見ることになるでしょうが、相当コードを書き慣れても一発で コンパイル を通ることの方が希だったりして、あまり進歩できなかったりもします。

コンパイル などほとんど瞬時に終わりますから、エラーの理解と修正が速くなれば良いわけですが、最近はかなりまともになったとはいえ、エラーメッセージ の指摘が的確ではなく、難解なヒントに過ぎないことはよくありますから、慣れないうちは苦労するでしょう。

また、コンパイラ の許しを請うのに苦労すると勘違いし勝ちですが、肝心なアルゴリズムはもちろん、計算ミス、参照先やデータの間違いなど、コンパイラ にとってはどうでも良いことらしく完全にスルーですから、

「コンパイラを通ったから正しいプログラムコード」

ということには残念ながらなりません。

実行・デバッグ
コンソールアプリ
D Compiler も前出の簡単なサンプルも コンソールアプリ です。
もちろん GUI アプリの方が一般的ですが
  • それなりの環境や ライブラリ などがないと簡単ではありませんし、その場合、その環境を構築するのが難しかったり、使える コンパイラ の バージョン にも制約が出来ます。
  • 統合環境などはそのツールの操作方法を覚えることに忙しくなりがちだったり、その環境の限界と言語本来の限界は別物なことも忘れがちにもなります。
  • D言語 では コンソールアプリ が最も簡単ですし、簡単に組もうと思ったら D言語 が簡単。

コンソールアプリ で見せられることは知れてますが、環境は簡単に整いますし、ごく基本的な コマンドプロンプト 及び コンパイラ の操作方法と、基本的な ライブラリー の使い方を覚えれば、純粋に プログラム言語 を学ぶことが出来ます。

また、コンソールアプリ は卒業して GUI アプリというようものではなく

  • 言語仕様など簡単な動作確認
  • 簡単な自家用ツール
コマンドプロンプト もそうですが、結構便利に使い続けると思いますから、しっかり身につけて損はありません。
コマンドプロンプト
コンソールアプリ は コマンドプロンプト で実行しますから、ビルド(コンパイル)と実行(デバッグ)を同じ コマンドプロンプト で出来ます。
MS-DOS エミュレータ
Windows の コマンドプロンプト は MS-DOS エミュレータ で、MS-DOS の コマンド が使えますし、特殊なアプリケーションでなければ MS-DOS用で使えるものもあります。

D言語 と違って日本語情報も豊富ですから、統合環境なんかより遙かに簡単に使えるようになるでしょうし、そこそこのプロジェクトでも困るようなことはありません。

デバッグ なんかでも、要は工夫次第です。

履歴
上下キー を使うとそれまでに打ち込んだコマンドの履歴が表示されます。

同じコマンドを何度も打ち直す必要はなくなりとってもラクチン、知らないとかなり損。

[F7] で履歴がポップアップ表示されますから、これも便利。

強制終了
コンパイラ も時々、自分で組んだプログラムを実行させれば簡単に無反応になったり、終了しないプログラムになったりします。

そんな時は

Ctrl + C

間違った処理を中断したい時も使えますし、ほとんどは解決するはず。

実行
自己責任
自分が書いたプログラムの実行は、言うまでもなく、何が起ころうと、原因が何であろうと自己責任です。

D言語 でシステムを壊すプログラムを組むことは可能ですから、そのリスクもあります。

専用マシン
無理なく使えるなら使った方が良いでしょうが、あえて用意する必要もないでしょう。

もちろん、ファイルを扱う場合など十分な注意が必要ですし、それなりのプログラムを組めるようになった時などは、専用環境が必要になったりもするでしょうが、それなりのスキルがないことには何かを壊すことも出来ません。

コンソールアプリの実行
間違いがあれば、多くは何らかのエラーで安全に中断されます。

無反応や出力表示が止まらなくなったりとかは、珍しいことではありませんが、強制終了 も出来ないようなことになることはまずないでしょう。

指定がなければ、実行ファイル( test.exe は カレントディレクトリー にあります。

そのまま test と入力すれば実行出来ます。

Test Run

実行時にエラーが出るようなコードではないはずですから、

大丈夫でしょう!?

デバッグツール
実行時にソースコードを参照しながらいろいろ出来る高機能なツールもありますが、

「自作プログラムの実行は何が起こるかわからない」

ということが普通ですから、実行ファイル を直接起動するのではなく、なにがしかの 仮想環境 で実行する必要があります。

GUI アプリ の場合、それなりのツールが別途必要になりますが、コマンドプロンプト も 仮想環境 になりますから、コンソールアプリ なら 特別なツールがなくても大丈夫です。

標準ライブラリ
ほんの数行のコードですが std.stdio なんてののお世話になってたりします。

ライブラリ など読み込むことなく基本的なことは出来る 言語 もありますが、その多くは 特定の環境 に依存します。

C言語や C++、D言語などのネイティブコンパイル言語は多目的ですから、特定の目的のための機能、特に OS などのプラットフォームに強く依存するものなどは 言語 に組み込まれていませんから 標準ライブラリ なしでは先に進めません。

Phobos
D言語 の コンパイラ に付属する 標準ランタイムライブラリ で、簡単な手続き( import )だけで使うことが出来ます。
std
中核。

基本的なものから専門的なものまで、用途別に分類されてます。

std.stdio にある

writeln( , 区切りの値 );
文字列値 でも 数値 でも、受け取った 値 を順次表示してくれます。
std.c
C言語 への インターフェイス。
std.windows
Windows の API への インターフェイス。
Tango( The Developer‘s Library for D
Phobos に代わる標準ライブラリと言うことですが、その登場は Phobos が相当ダメダメで使い物にならなかった(筆者自身も困っていたような記憶がありますが、どんなにダメだったかは忘却)頃で、確かに機能が豊富で欲しかったものが手に入ったように記憶していますが、

最近は、

  • Phobos が頻繁にメンテナンスされるようになり、機能も充実してきた
  • 別途インストール、環境設定が必要
  • 更新頻度が不安定で最新バージョンを使うにはパッチ(修正)を当てる必要があったりする
  • Phobos と互換性がなく、併用も出来ない
  • 最新情報が少なく、将来も不透明
  • ライセンス問題とかよくわからない
  • 最新版の D を追うのことが出来ない

メリット より デメリット の方が多く、Phobos を補完する形で使えれば良いのですが、入れ替える必要があるためどちらかを選択することになりますから、現状は環境構築やらが煩雑になり混乱するだけ。

2011年3月10日

E-Mail : open@pen-jr.org

ご意見やご指摘は大歓迎ですが、質問など返信は期待しないでください

pen jr.
D言語研究
わかったつもりになるD言語
D言語友の会
News&Days
はじめてのブログ選び