C/C++

[C++/CLI]Stringの糸口

出水洸太郎 — Fri, 28 Nov 2008 06:11:00 GMT

意外に、C++/CLIで検索する方がいるようなので、
C++/CLIを始めたときに混乱していたネタを投下します。

C++/CLIを始めてから、よくわからない印象を持ったのが文字列の扱いです。
ハンドル型なのに実体のような動きをする存在で、不思議に見えました

System::String ^str1 = gcnew System::String("abc");
System::String ^tmpstr = str1;

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

str1 = gcnew System::String(str1 + "def");

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

初期化はchar*と同じようにできますが、なぜか足し算もできます。
演算子オーバーロードでうまくやっているんでしょうと理解していました。

そして、いちばん混乱したのがこれ。

System::String ^str1 ="abc";
System::String ^tmpstr = str1;

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

str1 += "def";

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

もし、char *のように振舞うのであれば、
2回目のWriteLineでは両方とも"abcdef"が出力されないといけませんが、
実際には、str1は"abcdef"、tmpstrは"abc"と出力されます。

しかし、ハンドル型なので実体を持ち運んでいるわけではないはず。
Stringだけ特殊な扱いを受けている？？

どうにも解せないときに出会ったキーワードが以下の2つ。
・ボックス化
・String不変

キーワードにしたがって、上のソースを書きなおしてみます。

System::String ^str1 = gcnew System::String("abc");
System::String ^tmpstr = str1;

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

str1 = gcnew System::String(str1 + "def");

Console::WriteLine(str1);
Console::WriteLine(tmpstr);

まず最初の変数初期化ですが、ボックス化によりgcnewが付与されます。
ですから、char*のように先頭ポインタだけを指しているわけではありません。

そして、+=演算子。
これがもう一つのString不変です。
Stringの内容が変化を受ける場合、そのつど新しい領域が確保されます。
ですから、後半のstr1とtmpstrでは指しているアドレスが違うわけでです。

String不変の観点でSystem::Stringを調べてみると、
ハンドル型の変数を書き換えられない状況では、ReadOnlyになっています。
（たとえば、[]演算子）

StringはUnicodeを格納するクラスなので、char*やstd::stringとは違い、
固定文字列を持ち運ぶもの、と理解しておくといいでしょう。

[C++]進数いろいろ

出水洸太郎 — Fri, 07 Nov 2008 22:13:00 GMT

C言語には10進数以外にもいろんな進数表現で数値を指定できます。
それを今回まとめてみました。

#include <iostream>
using namespace std;

int main(){
  // 10進数指定
  cout << 123 << endl;

  // 8進数指定
  cout << 0123 << endl;

  // 16進数指定
  cout << 0x123 << endl;

  // 謎進数指定
  cout << 0e123 << endl;

  return 0;
}

本当にいろんな指定ができますね～。

#片桐さんに感謝しつつ、混乱させるエントリーを書いてみる

[C++]隠された引数

出水洸太郎 — Wed, 01 Oct 2008 22:45:00 GMT

C言語のmainで、こんなコードを見ました。

int _tmain(int argc){
  ...
  return 0;
}

Visual C++ 2008なので_tmainになっています。
0個や2個のパターンは多いですが、1個は初めてです。

調子に乗って3個目をつけてみます。

int _tmain(int argc, _TCHAR* argv[], _TCHAR *env[]){
  for (int i = 0;env[i] != NULL; i++){
    printf(L"%s\n", env[i]);
  }
  return 0;
}

なんと、環境変数が入ってます！

4個目はどうだ…コンパイル通っちゃった！！

int _tmain(int argc, _TCHAR* argv[], _TCHAR *env[], int *value){
  // これは実行できる、ただ意味のありそうな値は入ってない
  printf("%x\n", value);
  // こっちはアウト、アドレスじゃないみたい
  printf("%d\n", *value);
  return 0;
}

でも、実行すると無効なアドレスを指しているということで落ちてしまいます。
たまたまメモリにある、適当な値を拾ってきているだけっぽいですね。

ちなみに、こんなmainでもコンパイルエラーにはなりません。

void * _tmain(){
  return 0;
}

要は、mainと名がついていれば細かいことは気にしない性格みたいですよ。

[C]おもいこみぽろぽろ

出水洸太郎 — Fri, 19 Sep 2008 02:44:00 GMT

今日見かけた不思議なコード。

convert(buffer, szMoney);
total += buffer;

別段普通のコードです。

ところが、ファイル名を見るとxxxx.c なんですね。
Cの場合は参照渡しがないので、bufferの値が書き変わることはありません。

ということは、すでにポインタを渡している？
もしくはbufferは配列？
どちらにしろ、直後の構文が意味不明。
ただ単にバグっているコード？

grepしてもconverは出てこず…近くのソースにはない様子。
bufferはlong long だということが判明。
64bitだとこのコードが動く？　それはないよな…

仕方なくgrep範囲を全ソースに拡大！

何のことはない、convertは#define でした。
思い込みって怖いですね。

[C++]魔法少女マジカル☆リスト

出水洸太郎 — Wed, 10 Sep 2008 21:38:00 GMT

私リスト、魔法の国から来た11歳の女の子だよ！♪
…という話じゃないです。

以前、単方向リストの話題を振りました。
単方向リストは双方向リストほど自由度がない反面、
要素に付与しているポインタが半分で済むため、メモリ消費量が抑えられます。

要素が10000個あれば、32bit環境だと40KBの節約になるわけです。
~~40KB分のメモリを増設すれば解決ですね。~~

これを丸く収めるいい方法があります。
それがマジックリスト。
単方向のメモリ消費量で、双方向の自由度！
つまり、正方向、逆方向のどちらでも辿れるのに、
要素毎のポインタが１つだけというリストです。

ってなわけで作ってみました。[download]
要点を抜粋したソースが以下です。

template<typename T>
class _magic_Node{
  unsigned int addpointer;
  T value;
  _magic_Node<T> *otherside(_magic_Node<T> *p){
    unsigned int io = addpointer ^ ((unsigned int)p);
    return (_magic_Node<T> *) io;
  }
  void setptr(_magic_Node<T> *prev, _magic_Node<T> *next){
    addpointer = ((unsigned int) prev) ^ ((unsigned int) next);
  }
  void changeptr(_magic_Node<T> *before, _magic_Node<T> *after){
    addpointer ^= ((unsigned int) after) ^ ((unsigned int) before);
  }
  _magic_Node(T t, _magic_Node<T> *prev, _magic_Node<T> *next):value(t){
    setptr(prev, next);
  }
  ~_magic_Node(){}
};

見てのとおり、Tの他にはunsigned intしかメンバ変数を持っていません。

setptr()はprev, nextのポインタを受け取り接続情報として格納します。
othersize()は、片方のポインタを受け取り、もう一方のポインタを返します。
changeptr()は、接続情報を変更します。

リストは基本的に先頭か末尾から順に辿ることしか出来ません。
つまり、prevとnextのどちらかの情報は持っているわけです。
そこで二つのポインタのアドレスを重ね合わせた値を持っておいて、
片方の情報を受け取ることでもう一方の情報を取り出すようにすればいいのです。

本来のマジックリストは加算を使うのですが、ここではXORを使ってみました。

アドレスをただの整数としてみなした計算を行っているので、
セーフティを謳う言語ではこれを実装することはできません。
分かりやすく言い換えると、フリーダムなC言語万歳。

なお、イテレータの前後で要素が追加/削除された場合、
イテレータの移動が未定義になってしまいます。
また、イテレータ側で要素の前後の面倒を見ないといけないので、
イテレータのサイズが通常の双方向リストより大きいです。
end()の生成コストも大きくなっているのが問題ですね…。

[C++]リストカット(メモリ的な意味で)

出水洸太郎 — Mon, 08 Sep 2008 01:39:00 GMT

ネタ元＞[C++] C++0x forward_list

C++0xに単方向リストが実装されるという話なのですが、
その際、size()が実装されないということらしいです。
理由として、size()を持つメンバ変数領域が無駄だそうで。

これは100歩譲って認めるとしても、push_back()も実装されないそうです。
単方向なのでend()からは辿ることができないから無理もないのですが、
size()のメンバ変数を持つことを嫌う人が、
push_back()のためにbefore_endをメンバ変数にもつとは思えません。

となると、push_front()を主に使ってプログラムを組むことになるのですが、
今までのSTLのコンテナがpush_back()を中心に作られている上、
先頭から物が詰め込まれるというのはなかなか使い勝手が悪く思えます。

そうなると、この辺を実装したrich_flistが欲しいわけですが、どうやって作るか問題です。
ですが、デストラクタにvirtualが付いていませんので、これでは派生はできません。
virtualをつけてしまうとvfptrが付いてしまうため、size()のメンバ変数を嫌う…(以下略)

となると、所有で解決するか、一から作り直すことになるでしょう。
どちらにしろ、forward_listとrich_flistの両方を受け入れる関数を作るには
テンプレートを使ったプログラムが必要になります。

もっとも、forward_listの発端がメモリの節約なので、
メモリ消費量が増える機能拡張はなし、というのはわかるのですが…。

要素毎に逆方向ポインタがつくのは嫌だけど、size()やpush_back()は使いたい、
そういうニーズをうまく解消する方法はないものですかねぇ。

#そこで、マジックリストを標準ライブラリに！！

[C++]ChronoがTrigger

出水洸太郎 — Wed, 03 Sep 2008 00:25:00 GMT

C++Dayで、アキラさんからChronoという日付/時間型が入るという話を聞きました。

日付/時間だったら、DateTimeという名前が一般的です。
ただ、これだといろんなプログラムで競合しそうですから避けるとしても、
Chronoという名前が出てくるところがいいですね。

私がプログラムを作る時、よく使う名称があります。
あまり聞きなれない単語で、そのものを表すのにいい言葉をちょくちょく捜しています。
そんなのをちょこっと紹介。

Persona
操作する対象のクラスです。
STGなら自機、格闘ゲームならキャラクタ、パズルならフィールドとかを総合的に扱います。
そもそもCharactorという名前がC言語だと使いにくいし、
Humanは人間じゃないものはどーするんだとか、Playerはコンピュータが操作しても？ということでこれ。

Prologue/Epilogue
初期処理/終了処理。
何かが始まる予感がして、いまだに使い続けています。
元ネタはmaster.lib(Bio_100%が出したライブラリ)のサンプルプログラムです。
このサンプルプログラムは関数ポインタを覚えるきっかけにもなりました。

Catalog/Jollet
どちらもデータの集合体を指しています。
ItemCatalogやEquipCatalogなど。
Catalogはゲーム開始時に読み込まれて、終始変化のないもので、
Jolletは数が減ったり増えたりデータが書き変わったりするものに使ってます。

pluck
カードゲームを作ってた時、ある動作で困って辞書をひっくり返して出てきた単語。
必ず存在する「カードを引く」という動作は「ドロー！モンスターカード！！」で人気のdrawですが、
どう考えてもdrawは描画メソッドの名前以外につけるのはまずいですので探しました。
勇気と幸運の剣でバグを撃つ！という気持ちで。

[C++]日輪の存在

出水洸太郎 — Mon, 01 Sep 2008 02:44:00 GMT

元ネタ＞C/C++ の将来性

「将来性がない」だなんてしけた釣りだクマね。
そんな餌に俺様がクマー！！！！！
#わんくま同盟だから釣られるのは仕方ない

そもそも、将来性ってなんでしょうね。
AdaとかB言語あたりはほぼ絶滅といっていいんでしょうけど…。
COBOLはいまだに生き続けてますね、両津勘吉並の生命力です。

C/C++が低レベル層の開発に使われるのは間違いなく、
ここに代替できる言語がアセンブラぐらいしかない以上、この分野では死なないでしょう。

ですが、それは死んでないだけで今のCOBOLと何ら変わりありません。

ネットゲームで誰かが言った言葉です。
「面白いネトゲがあるわけではない、面白い"人"がいるネトゲがあるだけだ。」

将来性は言語的な仕様が作るものではなく、人が作るものだと思います。

[C++]君の名をつければ

出水洸太郎 — Sat, 30 Aug 2008 00:14:00 GMT

今日は横浜勉強会ですよ
今回はみんなこようよ～とは言えないのでこんなのやるよ～って話を。

テンプレートの解説で、どういう場面で使うべきかというのを
無い頭を絞って出した結果、こんなの出ました

defineで実装していたマクロの代替
式を関数に変換
ビット幅や整数・実数を可変にした数値型
拡張版 void *
実質的兄弟クラスとしての利用
インライン展開

なんか、かっこわるい
なに、拡張版void*って！

で、GoFデザインパターンみたいに名前付けたらかっこいいのかも！

safety macro
functor
numeric
carrior
ringer
inline

お、意外にいけてるんじゃ？

#そもそも分類がおかしい気もしないでもない
#GoFで思い出したけど、ぐろー部ハマり中なんで対戦する人いないですかね？

[C++]終端のない文字列をうたおう

出水洸太郎 — Wed, 13 Aug 2008 23:27:00 GMT

C言語で文字列を扱うときは、終端ありきでほとんどの関数が構成されています。
たとえば、最大で12文字入る場合は、13文字分のバッファを用意するのが普通です。
ですが、バッファを12文字しか取らず、最大長だった場合は
終端がないという形態で組む場合というのも往々にしてあります。

void foo(){
  //C++だとこの表記駄目らしい
  //char name[5] = "Izumi";
  char name[5] = {'I','z','u','m','i'};
  char message[20] = "hello";
  // NGパターン
  {
    // これだと後ろの文字と連結して10が入ってしまう可能性が！
    int len = strlen(name);
    // 当然これも駄目
    char str[100];
    strcpy(str, name);
    //stringに代入するときも当然アウト
    std::string s = name;
  }
  // OKパターン
  {
    // ちゃんと5がはいる
    int len = strnlen(name, sizeof(name));
    // コピーした先にも終端がつかないことがあるので注意
    char str[100];
    strncpy(str, name, sizeof(str));
    // stringに入れるときはコンストラクタで長さを指定
    std::string s(name, sizeof(name));
  }
}

この辺は簡単なのですが、何より困るのがprintf。
終端なしの文字列を流し込めればなぁ…と思う人に。

void foo(){
  char name[5] = {'I','z','u','m','i'};
  char message[20] = "hello";
  
  // 長さとして小数点以下の値を使って指定
  printf("%-.5s\n", name);
  // 長さを外部から与えたいときは*を使う
  printf("%-.*s\n", sizeof(name), name);
}

なお、バッファオーバラン対策にもなりますので、
終端ありの場合もこういう造りにしておくと安心です。

#コメントの指摘を受けてソース部分修正