開発

DirectX 系譜図 メモ

DirectX や Media Foundation 周りの関係性がいつも分からなくなってしまうので整理して系譜図にまとめた。
DirectX系譜図


メモ

  • DirectX には基本ランタイム(Windows プリインストールや Windows Update で入る)と追加ランタイム(Windows 8.x 以降で特定のバージョンがプリインストール)がある。
  • DirectX 1.0 は Game SDK として発表された。
  • DicrectInput は DirectX 1 から存在していたという記述もあるし、DirectX 3 で統合されたという記述もある。
  • DirectX 4 は欠番。
  • XACT 終了時の DirectX バージョンは不明だが、Windows 8 で廃止。
  • XAudio は Xbox 専用で、PC で使えるのは XAudio2。
  • D3D は 11 からビデオ再生ができる。

参考資料



Windows 10 で Visual Studio が動かない

Windows 10 に Visual Studio 2015 Community をインストールしたところ、何度やってもうまく動かないので、症状を整理しておく。

PC 環境はこちらの通りで、OS を Windows 7 Professional から Windows 10 Pro にアップグレードし、その際、クリーンインストールしている。

第 1 回インストール

LP初回は、Windows 10 インストール後、もろもろ必要なソフトをインストールした後に、VS 2015 をインストール。当時はまだ VS 2015 Update 2 の時だった。

英語版をインストールが無事に完了し、引き続いて Language Pack をインストールしたところ、Language Pack のインストールが終了しないという事態に。中止することもできず、強制終了させても、再起動すると再びインストールが始まって終了しないの繰り返しなので、やむなく Windows 10 を再インストールすることに。

第 2 回インストール

Windows 10 再インストール後、同じ手順を繰り返したが、やはり Language Pack のインストールがうまくいかない。

システムの回復で、Language Pack をインストールする前の状態に戻し、VS 2015 Update 2 を英語の状態で運用する羽目になった。

第 3 回インストール

時は進み、VS 2015 Update 3 が登場。

ここで再び、VS 2015 の英語版と Language Pack のインストールを試みた。

しかしやはり、Language Pack のインストールが完了しない。

第 4 回インストール

ここで、vs_community_JPN.exe(最初から日本語版)があることに気付く。

記憶が曖昧だが、VS 2015 英語版がインストールされている状態で日本語版をインストールしてみたところ、インストールが上手くいかず、では英語版をアンインストールしようとしたら、アンインストールもうまくいかず、だったと思う。

仕方が無いので Windows 10 をまた再インストールし、何はともあれ最初にと、他のソフトを入れる前にいの一番で VS 2015 日本語版をインストール。

するとインストールが無事に完了し、めでたしめでたし。

Splash……と思いきや、起動してみると、スプラッシュスクリーンの状態から進まない。

試しに、2 つ目のインスタンスを起動してみたところ、今度は普通に起動した。

2 回起動すれば良いなら、それで我慢するか、とも思ったが、よく見ると、1 つ目のインスタンスが CPU 1 つをフルロードにしている。しかも、2 つ目以降のインスタンスは、終了させるとゾンビになってやはり CPU をフルロードにしてしまう。

これでは実用にならない。

第 5 回インストール

実環境はあきらめて、仮想環境の Windows 10 に Visual Studio 日本語版を入れてみた。

するとすんなりインストール&起動できた。

仕方なく、今はこれで使っているが、やはり仮想環境での VS はかなりストレスである。

第 4 回その後

VSIXAutoUpdateいつの間にか、VS が 1 つ目のインスタンスから起動するようになっていた。

とはいえ、終了後にゾンビ化して CPU を食うのは相変わらず。

また、VS を起動しなくても、VSIXAutoUpdate.exe が CPU 1 つ分を消費している。




おすすめプログラミング言語を考える(UTAU プログラマー向け)

「UTAU プラグインを作ろうと思うんだけど、プログラミング言語は何が良いんだろう?」

このようなお悩みをたまに見かけますので、今回はそれを考えてみます。

ちなみに、UTAU 以外で既に十分なプログラミング経験のある方は、普段お使いの言語で作れば問題ありません。プラグインの仕様や、各言語での実装例(半音上げプラグイン大会のエントリーなど)を見れば、あっという間に作れるでしょう。

ここでは、あまりプログラミング経験のない方のために考えることにします。

言語選びのポイントは以下です。
  • 世間で人気の言語であること
  • GUI が作りやすいこと
  • プラグイン利用者側の追加ソフトインストールが不要であること
各項目について、次節以降で詳しく見ていきます。

世間で人気の言語であること

夢も希望もない話かもしれませんが、初心者であるほど、長いものに巻かれるほうが無難です。

世間で人気の言語(利用者が多い言語)であれば、入門書や入門サイトも数多く存在しますし、ハウツーやトラブル対策の情報も豊富です。あなたがトラブルに見舞われたとして、人気の言語ならば、他にも多くの人が似たような経験をしているはずなので、すぐに対応策を探せるでしょう。

逆に、マイナー言語の場合、そもそも開発環境自体のバグが残っていたりすることもあり、余計なトラブルに巻き込まれかねません。

TOIBE_201601人気の言語は、TOIBE が定期的に測定しています。クローズドソースも含め、世界で使われている言語を推定しているランキングです。古めの言語の順位が上がってしまう傾向にありますが、十分参考になります。2016 年 1 月のランキングでは、以下の順位です。
  1. Java
  2. C
  3. C++
  4. C#
  5. Python
  6. PHP
  7. Visual Basic .NET
  8. JavaScript
  9. アセンブラ
  10. Ruby
Java は最近ずっと 1 位をキープしています。パソコンの世界だけ見ると Java で作られたアプリはそこまで多く感じられませんが、スマホ(Android)アプリは Java がメインであり、スマホ開発が盛んになっていることの現れでしょう。

C と C++ は順当に高ランキングを獲得していますね。歴史の長い言語なので、直近の勢いという意味ではそれほどではありませんが、しっかりしたライブラリなどの多くは C/C++ ですし、普段使っているようなパソコンソフトだけではなく、裏方(ドライバ、ライブラリ、ファームウェア等)としても様々な場面で使われています。

4 位の C# はメジャー言語の中では後発組です。短期間でランキング上位にのしあがったのは、マイクロソフトの影響力が大きいです。とはいえマイクロソフトの影響力 があるのはパソコンの世界の話で、スマホではあまり影響力はありません。スマホ全盛の時代に高ランキングを獲得しているのは、C# そのものの良さがあるからでしょう。

5 位の Python は、日本ではそこまでメジャーではありません。プロの求人ランキング(横軸)を見ても、マイナー言語と同等の求人件数しかありません。しかし、世界に目を向ければ、Google 先生が Python 押しであることが大きな追い風となり、ホットな言語と言えます。

6~10 位は、アセンブラを除いてお手軽系の言語が並んでいます。

これら 10 言語をおすすめ言語候補として、以降でさらに絞り込んでいきましょう。

GUI が作りやすいこと

ほとんどの UTAU プラグインには GUI(ウィンドウやボタンなどの画面)が必要になってきます。GUI を簡単に作れるかどうかは、生産性に大きく影響します。

言語ランキング 1 位の Java は初期の頃から GUI に力を入れてきており、GUI は作りやすいと言えるでしょう。私自身は Java での GUI 開発経験はありませんが、例えば Java の統合開発環境として使える Eclipse であれば、RAD ツール(GUI をドラッグアンドドロップで簡単に設計できるツール)の Swing Designer が標準搭載されているようです。

言語ランキング 2 位の C での GUI 開発は地獄です。仕事でやむを得ずというのならともかく、UTAU プラグインの GUI を作るために C を用いるのは正気の沙汰ではありません。

言語ランキング 3 位の C++ での GUI 開発は微妙です。

C++ 開発環境の鉄板である Visual Studio において、GUI 開発は以前よりはマシになりました。RAD ツール付きの Visual Studio が無償で利用できるようになったためです。しかし、付属の C++ ライブラリの使い勝手は悪く、慣れるまでにかなりの時間を要するでしょう。

別の C++ 開発環境として C++Builder が挙げられます。優秀な RAD ツールで、効率的に GUI 開発が行えます。しかし、価格が高いこと、バグが多くサポート力も弱いこと(昔のセキュリティーホールが放置されたままになってたります)、(言語としてではなく)ツールとしてのユーザー数が少ないことから、おすすめはできません。

言語ランキング 4 位の C# および 7 位の Visual Basic .NET(以降 VB.NET)は GUI の開発がやりやすくなっています。開発環境は C++ の時と同じく Visual Studio ですが、使い勝手は大きく異なります。C#・VB.NET の場合は GUI が作りやすいように整備されており、また、付属のライブラリ(.NET)も扱いやすいです。

言語ランキング 5 位の Python は、標準では GUI の開発は大変です。RAD ツールとしては Monkey Studio が利用できるようですが、日本語の情報がほとんどありません。しかし、IronPython という、.NET と組み合わせたバージョンの Python は、GUI を開発しやすくなっています。ただし、日本語の情報はあまり多くないようですので、プログラミングに不慣れな人が挑戦しようとすると困難が待ち受けるでしょう。

言語ランキング 6 位の PHP と 8 位の JavaScript はウェブ専用のプログラミング言語なので、今回は除外します。

言語ランキング 9 位のアセンブラでの GUI の開発は……理論上は可能ですね。しかし現実は無理でしょう。

言語ランキング 10 位の Ruby での GUI 開発は、Python と似たような状況です。標準では GUI は作りづらいものの、.NET と組み合わせた IronRuby があります。ただし、IronRuby の開発は止まっており、Python よりも状況は悪いです。

以上により、人気の言語でかつ、標準で GUI 開発を行いやすいのは、Java、C#、VB.NET であることがわかりました。

プラグイン利用者側の追加ソフトインストールが不要であること

UTAU プラグインを使うために、プラグイン以外にも別途あれもこれもソフトをインストールしてください、だと、プラグイン利用者としては不便ですし、インストール作業を面倒くさがってプラグインの利用を諦めてしまうことも多いでしょう。

まず Java ですが、実行ファイルを生成することはできず、別途、JRE(Java Runtime Environment)と呼ばれる追加ソフトが必要となります。残念。

とはいえ、ウェブブラウザのプラグインをインストールする際に一緒に JRE を入れている利用者もいますので、減点要素はそこまで大きくありません。

C#、VB.NET は実行ファイルを生成できます。別途 .NET Framework という追加ソフトが必要となるのですが、Windows に初めからインストールされていたり、あるいはすでに別のソフトを使う際に利用者が自分でインストールしていたりと、たいていの場合はインストールされていることでしょう。とはいえ、.NET Framework のバージョン違いによってインストールが必要になることもあり、減点要素はゼロではありません。

以上により、これまで絞り込んだ言語の中で、この項目を完璧に満たせる言語はありません。

(2024/06/08 追記)
最近の C# は「自己完結型」といって完全に追加インストール不要で配付可能になりました。

総合評価

ここまでで、有力候補は Java、C#、VB.NET の 3 つに絞られました。この 3 つに順位を付ける場合、私は以下のようにします。
  1. C#
  2. VB.NET
  3. Java
Java は実行ファイルを生成できないので 3 位。実際に UTAU プラグインを配布する際に、一手間必要になってきます。それとは別に、Java は起動が遅いので(一度起動してしまえば早いのですが)、プラグイン利用者がちょっとイライラするかもしれません。

C# と VB.NET を比較すると、機能としては同等なのですが、C# の方が簡潔にプログラムを記述できます。また、よく言われることとして、VB プログラマーの質が低いというのがあります。VB で開発していると、ネットの「知恵」が実は微妙な情報で、それを信じてドツボにハマる、というリスクがあります。

以上により、UTAU プラグインをこれから開発するなら、最もオススメのプログラミング言語は「C#」という判断にいたします。

懸念事項としては、「プログラミング経験の少ない人が C# にチャレンジするのはハードルが高くないか」という問題です。順当に C やあるいは軽量系スクリプト言語の方が習得しやすいかもしれません。とはいえ、UTAU プラグインを作るのが目的であれば、それらの言語では目的を達成するのが困難というのがこれまでの流れです。

これから C# を勉強しはじめる場合、きちんとした書籍を購入して、体系的に C# を理解するのが結局は一番近道だと思います。C# に限りませんが、プログラミングの概念をきちんと理解するのはなかなか大変で、ウェブの Tips をつまみ食いした程度ではその場しのぎの知識しか手に入りません。

とはいえ、まず少し作ってみたいんだ、という場合は、
はいかがでしょうか。GUI アプリを C# で実際に作ってみることができます。また、
の C# の実例(エントリー 3、15、22、27(GUI))も参考になるかと思います。C# 言語の詳細については、プログラミングの基礎的な知識を前提としていますが、

がオンラインの情報としてはまとまっていると思います。


余談

今回は C# 押しということになりました。確かに C# は素晴らしい言語です。
  • 他の言語の良いところを取り入れていて使いやすい
  • GUI・ネットワーク・同期プログラミングなど周辺のライブラリも充実かつ整理されている
  • Visual Studio の支援機能がずば抜けて強力(他の環境を使う気になれないくらい)
しかし、つまるところプログラミング言語なんて何でも良いというのもまた一理あるところです。

最初にメジャー言語で絞り込みましたが、情報収集にもっと労力を注ぎ、不足するところは自分で考えることにすれば、マイナー言語でもいいわけです。例えば Lazarus は無料で GUI を簡単に構築できます。Lazarus に限定するとユーザー数は多くありませんが、Lazarus は言語としては Object Pascal でありそこそこの順位にいますから、悪くない選択肢かもしれません。

今回 1 位と 2 位の C# と VB.NET を比較した場合、VB.NET の良いところは一つも無いと言っても過言ではありませんが、C# と 3 位の Java を比較した場合、UTAU プラグイン以外にも目を向ければ、Java のいいところもたくさんあります。将来 Android アプリも作りたい、ということであれば、その準備を兼ねて Java を選択する、ということも考えられます(逆に Android アプリを C# で作る方法もありますが)。

世界の潮流で言えば、Python は「来てる」言語です。Google のクラウドサービスで何かしようとしたら Python は有力でしょう。その意味では、IronPython も挑戦しがいがあるかもしれません。

C# ももちろんですが、他の言語にも是非目を向けてみてください。

CodeIQ の「グループを作ろう!」にチャレンジ

目次

現役のエンジニア・企業がプログラミングの問題を出してくれる CodeIQ というサイトがある。問題を解くと、正解不正解の判定や、フィードバックなどを行ってくれる。ジャンルや言語などはさまざまある。

グループを作ろう!

今回は結城浩さんの「グループを作ろう!」という問題に挑戦してみた。アルゴリズムの問題で、プログラムを使って解いても使わずに解いても構わない。プログラムを使う場合、言語は何でも良い。解答(とコメントなど)を送ると、フィードバックをもらえる。

問題の概要は以下。

Bill=Billy
Mick=Michael
Billy=William
というように、同じ人物を表すニックネームのペアが 444 個与えられる。同じ名前をすべて連結し、
Bill=Billy=Will=William=Willie=Willy
Michael=Mick=Micky=Mike=Mikey
というようにグルーピングする。ただし、各行の順番および、同一行内の名前は ASCII 順に並べなければならない。

自分の解答:STEP 1 グループ番号割り振り

C++ でプログラムを組む前提で。

どうやってグループを寄せ集めていくかと考えたとき、グループ毎の配列(vector)を用意してしまう、というのは最初に思いつくが、さすがに効率が悪い(名前を読み込む度に、すべてのグループ配列を見て、すでにグループ化されているか調べる必要がある)。

漠然と、木を使えばできるのではないかとイメージしたが、残念ながら、木を簡単に実装する方法を思いつかなかった。

CodeIQ_グループ割り振りそこで代わりに、グループ番号を割り当てていく方法を採った(右はイメージ図)。

ペアの両辺を読み込み、それぞれの名前に既にグループ番号が割り当てられているか調べる。両辺とも未割り当てであれば、新しいグループ番号を割り振る。いずれかが割り当て済みであれば、もう片方に同じグループ番号を割り当てる。

CodeIQ_グループ変更両方とも割り当て済みで、かつ、違うグループ番号であれば、今までは別のグループとして扱ってきたが、実は同じグループであることが分かったということなので、片方のグループ番号をすべて書き換える。

名前→グループ番号の対応を格納するのは、STL の map を用いた。

自分の解答:STEP 2 結合

すべてグループ分けできたら、同じグループ同士を連結していく。string 型の vector を用意しておき、1 行に 1 グループを突っ込んでいく。

CodeIQ_行番号割り振りmap を先頭から読み込んでいき、同じグループ番号の文字列が既に vector にあるか調べる。あれば、文字列の末尾に新しい名前を追加する。無ければ、新しい行の先頭に名前を追加する。

グループ番号と行番号の対応も、やはり map で覚えておく(……が、今から思えば、配列の方が高速だった)。

map を使うことにより。キーが自動的に ASCII 順になっているので、新しい行ができた時は、単純に配列の末尾に加えれば良く、ソートの必要は無い。また、1 つの行に名前を追加する際も、末尾に追加するだけで良く、ソートの必要は無い。

注意点

注意すべきはグループの統合で、最初はこれを見逃していた。できあがった解答を眺めていて偶然気づいた。グループ統合のコードを後から付け加えたので、これだけ異質な感じがする。

計算量は、入力のペア数を N として、グループ統合がなければ恐らく O(NlogN) だが、グループ統合があると最悪 O(N^2) になるのだろう。

ソースコードの抜粋

// グループ番号割り当て
while ( aInFile && getline(aInFile, aLine) ) {
    get_names(aLine, &aName1, &aName2);

    // 名前のペアをマップに登録していく
    p1 = aGroupMap.find(aName1);
    p2 = aGroupMap.find(aName2);
    if ( p1 == aGroupMap.end() && p2 == aGroupMap.end() ) {
        // 新規登録
        aGroupMap[aName1] = aGroupIndex;
        aGroupMap[aName2] = aGroupIndex;
        aGroupIndex++;
    } else if ( p1 != aGroupMap.end() && p2 == aGroupMap.end() ) {
        // aName1 が登録済み→aName2 を同じグループに登録
        aGroupMap[aName2] = p1->second;
    } else if ( p1 == aGroupMap.end() && p2 != aGroupMap.end() ) {
        // aName2 が登録済み→aName1 を同じグループに登録
        aGroupMap[aName1] = p2->second;
    } else {
        // 両方登録済み
        if ( p1->second != p2->second ) {
            // 違うグループとして登録されているのでグループを統合
            change_group(&aGroupMap, p1->second, p2->second);
        }
    }
}

// A=B=C=D というような結合行を作成していく
while ( aGItr != aGroupMap.end() ) {
    aRItr = aResultMap.find(aGItr->second);
    if ( aRItr == aResultMap.end() ) {
        // 新規に結果行に登録
        aResult[aResultIndex] = aGItr->first;
        aResultMap[aGItr->second] = aResultIndex;
        aResultIndex++;
    } else {
        // 既存の行に追加
        aResult[aRItr->second] += "="+aGItr->first;
    }
    aGItr++;
}


模範解答

CodeIQ_木模範解答では、やはりグルーピングに木を使っていた。

面白かったのは木の実装方法。木を map で実装していた(模範解答は perl と思われる言語で実装されていたので、実際には連想配列)。

map のキーに、葉っぱの名前を入れ、値に、根っこの名前を入れる。根っこの名前は、値を空文字列にでもしておく。

こうすることで、数回 map を探索すれば、一番根っこの名前にたどりつける。1 つの根っこから出てくる名前はみな同じグループで、グループの数だけ、根っこ(空文字列)があることになる。

木をこうやって実装するのは定石なのだろうか。シンプルでいいな。

木の良い点は、グループの結合が楽ちんなこと。2 つのグループの根っこのうち、片方の空文字列をやめて、もう片方の根っこの名前を入れるだけで良い。どんなにグループが巨大でも、1 つの書き換えで済む。

感想

単にグルーピングするだけというシンプルな問題なのに、やってみるといろいろ考えることがあって面白かった。Union Find アルゴリズムとか Union Find Tree データ構造などという問題らしい。

実装言語を問わないこともあり、いろんな解答があったと聞く。なかにはエクセルで解いた人もいるとか。

他の人がどんな解答をしているのか気になっているのだが、残念ながら、ググっても自分の解答を公開している人はほとんどいないようだ。

結城さんがせっかく公開 OK に設定してくれているのだから、自分の解答を公開する人が増えてくれればいいなと思う。


文字コードを指定してメモリから文字列を読み込む(C++Builder XE3/TMemoryStream)

C++Builder は、ファイルの読み込みがとても簡単で、TStringList::LoadFromFile() により、文字コードを適切に処理して読み込んでくれる。

LoadFromFile() は見ただけで使い方が分かる。しかし、その親戚である、メモリからの読み込みを行う LoadFromStream() については、まとまった説明が見当たらなかったので試行錯誤。

で、以下が結果のコード。メモリに格納されている文字列を、文字コードを指定して TStringList に読み込む。

void __fastcall TForm1::Button1Click(TObject *Sender)
{
    const char                  UTF8_STR[] = { 0xE6, 0x98, 0xA5 };
    unique_ptr<TMemoryStream>   aMemStream(new TMemoryStream());
    unique_ptr<TStringList>     aStrList(new TStringList());

    aMemStream->Write(UTF8_STR, 3);
    aMemStream->Seek(static_cast<long>(0), soBeginning);
    aStrList->LoadFromStream(aMemStream.get(), TEncoding::UTF8);
    ShowMessage(aStrList->Text);
}


UTF8_STR が文字列が格納されているメモリ領域。今回は定数にしてあるが、通常は、どこかから持ってきた内容を格納しているバッファになる。

TStringList::LoadFromStream() は、TStream 型(の派生クラス)からしかデータを読み出せない。メモリ領域をそのまま読むことはできないので、仲介役の TMemoryStream が必要になる。

TMemoryStream にメモリ領域の内容を書き込んでいるのが aMemStream->Write(UTF8_STR, 3); TMemoryStream にメモリ領域の内容を読み込むというイメージだったので、最初 Read() を使いそうになってしまったが、Write() なので注意。

Write() 後に、読み書き位置を先頭に戻しておく。

あとは、LoadFromStream() に TMemoryStream へのポインタを渡せば、文字列が読み込まれる。

文字コードの指定は、
  • UTF-8……TEncoding::UTF8
  • UNICODE(UTF-16)……TEncoding::Unicode
  • 指定無し……自動判別
など。TEncoding についてはここが詳しい。

以上、コードを実行すると、メモリ領域から 3 バイトを読み取って、「春」を取得できる。

LoadFromStream

C++Builder XE3 のインストール方法まとめ

目次


概要

CBuilderXE3メイン画面Windows(など)のアプリをビジュアルに開発できる C++ 開発環境、エンバカデロ社の C++Builder XE3 のインストールのやり方をまとめておく。

今回使用したのは C++Builder XE3 の、Starter ESD バージョンアップ版(約 14,000 円)だが、他のエディションでも参考になるのではないか。

Starter 版は、数あるエディションの中でも一番機能が少ない代わりに安い。比較表はこちら。通常のアプリを開発する分には困らないが、データベース接続やマルチプラットフォーム(Windows & Mac)機能などが省かれている。

ESD 版はいわゆるダウンロード版のこと。Starter には ESD 版しかない。他のエディションにはパッケージ版もあるが、ESD 版の方が安い。

ダウンロード

C++Builder XE3 の ESD 版を購入すると(今回は SE Shop.com にて購入)、(購入先からではなく)エンバカデロからメールでダウンロード情報が送られてくる。「Order Confirmation: C++Builder XE3 Starter Upgrade/Competitive Upgrade」というような英語の件名だ。

メール本文に C++Builder XE3 のネットインストーラ(約 51MB)のダウンロード先が記載されているのでダウンロードする。

インストール

インストールは簡単だが、それなりに手間暇がかかる。

ダウンロードしたネットインストーラ(cbuilder_xe3_win_esd.exe)を起動すると、言語選択画面になるので「Japanese」を選んで OK ボタンをクリック。

CBuilderXE3JSharpC++Builder のインストールには、JSharp のインストールが前提となる。JSharp がインストールされていない場合は、最初に JSharp をインストールすることになる。

CBuilderXE3DownloadFolderファイルのダウンロード場所を指定する画面になるので、空のフォルダを指定する。このフォルダにインストールされるわけではなく、あくまでもダウンロードしたファイル群を保存するだけのフォルダだ。

前提ソフトウェアのインストールが完了すると、いよいよ C++Builder XE3 のインストール。

CBuilderXE3Regist製品登録画面の Serial Number の欄には、エンバカデロから送られてきたメールに記載されている「インストール番号」をコピー&ペーストする。

言語選択画面では既に Japanese が選択されているので、デフォルトのまま進んで良い。

CBuilderXE3Func続いて、プログラム機能選択の画面なども基本的にデフォルトのままで良い。必要に応じて変更する。

CBuilderXE3InstallDownloadインストール準備完了画面で「次へ」ボタンをクリックすると、ファイル群のダウンロードとインストールが始まるのでしばらく待つ。

CBuilderXE3DocExplorerC++Builder XE3 本体のインストールが完了すると、続いてヘルプのインストール。Microsoft Document Explorer が無い環境では、さきにそちらをインストールすることになる。

本体のインストール時と同様、機能やダウンロードフォルダ、インストール先フォルダなどを指定すれば、ダウンロードとインストールが行われる。

ヘルプのインストールが完了すれば、ひとまずインストール完了だ。

初回起動と製品登録

CBuilderXE3Regist2初めて C++Builder XE3 を起動する際は、かなり待たされた後で、製品登録画面になる。

Serial Number はすでに入力されているので、Developer Network のアカウント情報を入力する。アカウントをまだ持っていない場合は、ここで登録する。

CBuilderXE3FirstStart登録に成功すると、C++Builder XE3 が起動する。

アップデートのインストール

デフォルトの設定であれば、C++Builder XE3 起動時に、自動的にアップデートのチェックが行われる。アップデートがある場合は、タスクトレイのアイコンで通知が来るので、クリックしてアップデートマネージャーのウィンドウを開く。

CBuilderXE3UpdateDownload適用したいアップデートを選択して「Download」ボタンをクリックすると、ネットインストーラのダウンロードが始まる。

ダウンロードが完了すると、再びタスクトレイのアイコンで通知が来るので、クリックしてアップデートマネージャーのウィンドウを開く。自動でインストールされるわけではないことに注意。

インストールしたいアップデートを選択して「Install」ボタンをクリックすると、インストールが始まる。

CBuilderXE3HelpUpdateアップデートのインストール方法も、C++Builder XE3 本体のインストール方法とほぼ同じ。ファイルダウンロード用のフォルダ等を指定してインストールすれば良い。

CBuilderXE3Aboutアップデートのインストールが完了したら、C++Builder XE3 を起動し、バージョン情報を確認する。「インストール済みの更新」の欄にアップデート内容が記載されていれば OK。

また、アップデートマネージャーには表示されないものの、こちらの登録ユーザーページには各種 Hotfix 等が公開されているので、インストールしたいものがあれば、ダウンロードしてインストールする。

Hotfix はインストーラではなく zip ファイル。zip 内のドキュメントで指定されているパスに zip を解凍するだけで良い。

以上で、すべてのインストールが完了する。



感想

インストールは簡単なのだが、まどろっこしい。

CBuilderXE3DownloadFail一番の原因はネットインストーラ。インストーラを起動してから各種ファイルをダウンロードするので時間がかかる。しかも、ダウンロードが途中で失敗すると、ダイアログが出て止まる。インストールの間放置しておいて、そろそろ終わったかなと画面を見てみると、途中で止まっているのはがっくりくる。

ネットインストーラがあるのは良いが、フル版も置いておいて欲しい。

Delphi 用 RS-232C コンポーネントを C++Builder XE で使う

Delphi(および C++Builder の旧バージョン)で手軽に RS-232C(COM ポート)を使うためのコンポーネントに ComPort Library(TComPort)がある。C++Builder XE でも何とか動作したので、やり方を整理しておく。

【実行時パッケージの作成】

  • すべてのプロジェクトを閉じた状態で、[ファイル→プロジェクトを開く]メニューにて、ComPort Library の Source フォルダにある CPortLibCB6.bpk(C++Builder 6 用)を開く。
  • 自動的にプロジェクトが C++Builder XE 用に変換される。
  • ビルド構成を Release にする(右側のプロジェクトマネージャーペインで選択)。
  • メイクすると、CPortLibCB6.bpl ができあがる。


【設計時パッケージの作成】

  • [ファイル→プロジェクトを開く]メニューにて、DsgnCPortCB6.bpk を開く。
  • 実行時パッケージと同様にメイクし、DsgnCPortCB6.bpl を得る。

【パッケージのインストール】

  • CPortLibCB6.bpl を Windows のシステムライブラリフォルダ(Windows 7 64bit なら C:\Windows\SysWOW64)にコピーする。
  • [コンポーネント→パッケージのインストール]メニューにて、追加ボタンをクリックして DsgnCPortCB6.bpl を追加する。デフォルトにチェックを入れると毎回設定しなくて良いだろう。

【ComPort Library を利用するアプリケーションのメイク】

  • ツールパレットペインに「CPortLib」タブが増えていて、その中の TComPort をフォームに貼り付ければ RS-232C にアクセスできるようになる。
  • [プロジェクト→オプション]メニューで、ディレクトリと条件定義→ライブラリパスに、CPortLibCB6.bpl/DsgnCPortCB6.bpl のパスを追加する。
  • [プロジェクト→オプション]メニューで、ディレクトリと条件定義→条件定義に DONT_USE_WINSPOOL_SETPORTA を追加する。
  • winspool.h(include\windows\sdk 等にある)を開き、SetPortA/SetPortW を宣言している箇所を、#ifndef DONT_USE_WINSPOOL_SETPORTA~#endif で挟む
  • CPort.hpp をインクルードする。
  • CPort.hpp を開き、inline じゃない方の EComPort() の宣言 2 つをコメントアウトする。

以上でビルドができる。



≪参考≫

とわのっとリニューアル

情報共有型の Twitter bot「とわのっと」をリニューアル(癒やしがメインの bot なんじゃないかという噂もちらほら耳にするが……)。

新規に開発した Twitter bot プログラム「Chatty Stone Bot」をエンジンとして採用し、内部構造を整理した。

今回のリニューアルによる効能は、
  • うまく動かなくなっていた自動フォロー機能が復活。
  • 上記含め、最新の Twitter API 利用による動作の潜在的な安定性向上。
  • bot 同士によるリプライ無限ループ抑止機能の明確化。
  • 構造整理により、これまで付け焼き刃的に付加されていた機能をきちんと整理して取り込めた。
  • 将来的な拡張性の確保。


実装は PHP。メインとなるクラスを中心に、いくつかの補助クラスを作成して全体的な機能を構成している。


プログラムと設定値・つぶやき内容は明確に分離し、設定値・つぶやきを管理する補助クラスを作成。おのおの適切な派生クラスを用いてプログラム的に整理している。


一時的に機能減となっているところがあるので、今後、Chatty Stone Bot を強化していく。


なお、エンジンとしての Chatty Stone Bot はそのうち別途公開する予定。


【参考】


とわのっと再構築に向けて

実音とわの関連情報をつぶやく(というより最近は飯レスがメインになっている気がしなくもないけど)Twitter bot の「とわのっと」、プログラムとしては EasyBotter を使わせて頂いている。

しかし、とわのっとに必要な機能を追加するために、自分でいろいろプログラムをいじっていて、それがだんだんカオスになってきた。

この際、bot プログラムを新規開発しよう、と PHP と格闘中。クラスを作るのは初めてなのでちょっと戸惑いながら。自クラスのメンバを参照する時に必ず $this が必要とは……。

メンバ関数(PHP 的表現だとメソッド)をインラインでしか書けないのはちょっと嫌。宣言と定義を別にした方が一覧性が良いのに。

BCommandPipe

どこかへのレス記事みたいだけど、BCommandPipe なんてクラスがあるのか。標準入力からデータを取り込むのだとか。便利そう。

Daiku はどうやって標準入力を取得してたんだっけな……。もう忘れちゃった。

GUI なデバッガー?

r42255 など、最近の Haiku のコミットには、デバッガー関連が割と多い。

フォルダ名に GUI とか○○ウィンドウとか、GUI を示唆するような文字列が入っているのだけど、これって、bdb の後継となる GUI デバッガーが入るってことなのかな?

うたりす進捗状況

うたりすをバージョンアップして、UTAU Mode 2 用のピッチエディット機能(ピッチエディタ)を搭載する件の進捗。

ひとまず、音符とピッチを描画するところまで。

うたりす進捗_2011_06_14


うたりすをいじっている中で、Lib UTAU の修正が必要な箇所を発見。後ほど Lib UTAU をバージョンアップする予定。
月別アーカイブ
記事検索
最新コメント
  • ライブドアブログ