UTF-32 が内部文字列に使えないことがわかったので、 UTF-8 を内部文字列に使用するというルールで libiconv によるエンコーディング操作と Boost.Regex による正規表現の両方を同時に試すサンプルを作成してみました。
Makefile は作ってません＼(^O^)／。試してみたい人は頑張ってコンパイルしてねｗ
$ g++ -std=c++0x -o regex-test regex-test.cpp EncodeString.cpp -lboost_regex
まともな環境 (Linux + GCC4.5 とか) なら上記コマンドで通るはず。libiconv を (glibc に上書きする形で) インストールしている場合は -liconv を末尾に入れる必要があるかも。そして MinGW を使う場合は更にもう一工夫必要かも (((;/^^)/
(さらに…)
C++0x では UCS に対応し、専用の型やリテラルの記法が導入されました。その関係で、以下の点について調査を行っていました。
char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。<regex> は利用可能か。<regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。
(さらに…)
ご無沙汰ぶりです…。
以前、wchar_t はどうにも使い物にならないからどうしよう、といった記事を書いたのですが、その続きのお話です。
表題の通りで、 libiconv を用いて文字セットを自動認識する処理のサンプルを書いてみました。詳しい経緯はTicket 内で逐次コメントしています。
(さらに…)
Boost セットアップ中… orz
実は先日 HDD に物理的損傷らしきものを見つけてしまいまして、必要なデータだけ抜き取ってフォーマットを試みたら見事にエラーで止まりやがったのでやむなく新しいのに交換したのですよ。
ここ最近は忙しかったり体調も安定しなかったりだったので otoco の方の作業はずっと停滞してました…。やっと朝まともに起きれるぐらいに体調は戻ってきたので、そろそろ otoco の作業も復活したいなぁと思いつつ…。
ああそうだ、Linux も使えるように grub 入れ直さないと…。
今メインでやっているお仕事を紹介してくださった友人に、CiNii という論文検索サイトを教えて頂きました。むしろ今まで知らなかったのかよぐらいの勢いなのですが…(^_^;A それはさておき。
個人的に気になっているのは、今 otoco でやろうとしている、楽譜情報と演奏情報 (シーケンス情報) を融合するデータ表現に関する研究が、MML なりそれ以外なりのアプローチで行われているのか、ということです。別に、既に行われているなら otoco を作るのはやめようとかそういう話ではないのですが、先行研究があれば参考にはさせて頂きたいな、とは思うわけです。
今のところそれらしい研究成果はまだ見つけられていないのですが、music macro language で検索してみたところ、面白いものを見つけました。かなり画期的な概念に基づく MML、その名も「PMML」です。
(さらに…)
otoco に限らず、 PC 上で動作するプログラムの多くは、テキストを処理することを目的の一部またはすべてとしています。 otoco の場合は特に、どこの誰とも分からない人が MML を書き、それを読み込んで XML やら SMF やらオーディオやら楽譜やらに変換することを目的としているので、どこの誰が MML を (あるいは XML を直接) 書いても問題なく処理できるよう、文字セットの扱いには丁重でなければなりません。
当初の方針として、 otoco では内部コードに Unicode を使用し、その物理型は wchar_t で扱うつもりでいました。この辺、C/C++ でのクロスプラットフォーム開発に慣れていないと陥りやすい罠であるように思うのですが… 現状の wchar_t ははっきり言ってクロスプラットフォーム開発には向いていないものといわざるを得ないようです。
とりあえず確認しているのは Windows の VC++ 2008 と Linux の gcc だけなのですが、それだけでも調べた限りで以下のような相違点がありました。
Boost ライブラリの Ubuntu へのインストールは容易でした。単に libboost-dev パッケージを aptitude install してあげるだけです。
問題は、前回も書いた通り、 apt からインストールできる Boost のバージョンは通常で 1.34.1、最新のものを選んでも 1.37.0 になってしまう、ということです。
そこで、 otoco の開発に影響する範囲で、バージョン間にどの程度の差異があるのか、調べておくことにしました。
とりあえず今思いつくのは正規表現まわりだけだったのでまだそこしか調べていないのですが (空文字列マッチは何気に影響範囲大きそうですが…古いバージョンで統一しておけばとりあえず問題にはならないかな…)、実際に開発が進めば利用範囲が広がり、都度気づく部分も増えていくかもしれません。上記ページはその都度更新して行く予定です。
昨日、一昨日はメインの仕事の都合で朝が早かったので、こっちの作業はちょっと pending してました。
cl.exe コマンドを直接呼んでビルドする方法については調査完了しました。必須オプションが何気に多いですね…。実際にはあれに最適化オプションなりデバッグオプションなりがくっつくことになります。
で、今度は Ubuntu でのセットアップを調べているのですが、ここで問題発覚。どうやら Ubuntu での boost ライブラリのメインバージョンはまだ 1.34.1 で止まっているようです…。もしかしたら Debian を始め、多くの Linux ディストリビューションにおいても同様の状況なのかもしれません。当初は最新の 1.39.0 を利用する予定でしたが、事実上の汎用性が損なわれる可能性もあるので (さすがにライブラリを手動でインストールしてくれ、とやる訳にもいかないですからね…)、互換性を確認しつつ、バージョンについては考慮しなければならないかもしれません。
インストールして動かして、というあたりはまだこれから調査するところです…。