Programming Tips 1024

プログラムしているときに思いついた小ネタを書きます。このコーナーへの投稿もお待ちしてます＾＾
特にことわりが無い限り、C++／VC++／Win32です。情報提供者orネタ提供者がいる場合は、表題の右横に《　》で書いています。

'01/10/08

Tips 51. 　functorを活用する

functorについては、ｒｓｐ（スーパープログラマへの道）の、

＞第C7回　 functorは函数合成の夢を見るか(何のこっちゃ＾＾；) 00/09/27
＞第D5回　 倒れるまでヤキを食え！（いいかげんプログラムってうっとおしいねん） 01/01/17

で、少し書いていますが、インライン展開されるところがミソです。yaneSDK2ndのCDIB32Effect::Blt関数等が、これを使っていたりします。

そのメインの転送部分は、これです。

非常に遅いコードであるのは、Tip.48〜Tip.50を読まれた方には、わかるでしょう。これでは何のために、functorを使用しているのか、わかったもんではありません。functorの最大のメリットは、インライン展開される、という部分です。よって、上のコードは、以下のように修正すべきです。

しかし、このfunctor fがある程度複雑で、lpDst,lpSrcのレジスタ割付が阻害されるようになってくると、このようにインデックスでアクセスするほうが速いのかは微妙になってきます。（ループを展開している部分は確実に早いのですが）

Tips 52. 　\でなく / を使えと言ったのは誰だ

C言語では、'\'は、'\\'のように書かなければなりません。日本では円マークになっていますが、海外ではバックスラッシュになっています。ASCIIコードで言えば、0x5c。どうして、こんな文字をエスケープとして使ったのかは、やねうらおの知るところではありませんが、非常にうっとおしい文字であることには違いないでしょう。

Windowsでは、'/'（スラッシュ）でもフォルダ指定できるので、こちらを使いなさい、という風に言われるのも無理ないところです。（私もそう思っていました）　ところが、DirectShowでwmvファイルが再生できないということで、カイネさんに調べてもらっていたんですが、わかったことは、

むむむむむ、、。きっと、このCodec、かなり古いAPIを呼び出してファイルを読み込んでいるのか内部で独自に読み込んでいるのか、そのへんが理由であることは容易に推測できますが、DirectShowのCodecって言ったら、作られたの最近でないですか。なんでそんなことするかなー．．とか思うわけであります。

というわけで、yaneSDK2ndでは、ファイル読み込みクラスでフルパス名に変換するときに、'/'は'\'に置換するという処理を入れることにしました。非常に泣かせる結果です。

'01/10/15

Tips 53. 　ド・モルガンの則

２項に対するド・モルガン則は、高校でも習います。あまりにも有名ですね。

ｎｏｔ（Ａ　∪　Ｂ）　＝　notＡ　∩　notＢ
ｎｏｔ（Ａ　∩　Ｂ）　＝　notＡ　∪　notＢ

C言語風の表記で書けば、上の２つは、

!(A || B) == !A && !B
!(A && B) == !A || !B

です。

なぜこんなことを問題とするのかと言うと、whileやforには、ループの終了判定のための条件式を書かなくてはならないのですが、こいつが、人間の思考に反しているというか、ループは繰り返しなのですから、「ループを終了するための条件」を書かせて欲しいのです。

どうして、誰もこのことを問題としないのか、私には不思議でなりません。あまりにも初歩的な事項すぎて、忘れられていたり、あまり議論にのぼったりしないので、この場を借りていくつか書きたいと思います。

つまり、終了するための条件を頭のなかで考えてしまう普通の（？）思考法である私は、こいつの否定条件形を書かなければならないのです。たとえば、A || Bのときに抜けるならば、その否定 !(A || B) == !A && !Bをwhileの条件式に書かなければなりません。!(A || B)と書いてもいいんですけど、あまり格好良くないので、!A && !Bの形で書くのが普通です。

だから、否定形を作り出すための法則、すなわち、ド・モルガン則が必要になってくるのです。

例：
ｘが１００以上か、ｙが１００以上になればループを終了
⇒　「ｘ＞＝１００」か「ｙ＞＝１００」でループ終了
⇒　ループを抜けない条件は、『「ｘ＞＝１００」か「ｙ＞＝１００」』で無いこと
⇒　!((x>=100)||(y>=100))
⇒《ド・モルガン則の適用》　!(x>=100) && !(y>=100)
⇒ (x<100) && (y<100)

というようになります。

Tips 54. 　多項ド・モルガン則

では、３項の場合について考えてみます。結論から言えば、

ｎｏｔ（Ａ　∪　Ｂ　∪　Ｂ）　＝　notＡ　∩　notＢ　∩　notＣ
ｎｏｔ（Ａ　∩　Ｂ　∩　Ｃ）　＝　notＡ　∪　notＢ　∪　notＣ

です。多項になっても、ド・モルガン則は成立します。

これを証明するのは面倒なので、duality（双対性）という概念を持ち出します。

つまり、論理集合の定義

Ｕ＝｛Ｔ，Ｆ｝　　　　　　　// 全集合はＴ(true) or Ｆ(false)から成る
not Ｔ = Ｆ，not Ｆ＝Ｔ 　//　trueの否定はfalse,falseの否定はtrue

また、∪(or)と∩（and）の定義は、

ですから、∪と∩，ＦとＴが対称（双対）になっています。（Ｕ⇔∩とＦ⇔Ｔを同時に入れ替えても成り立ちます）

定義において、このような双対性があるので、ド・モルガン則が成立するのは、これより明らかです。（ＦとＴを入れ替えるというのは、ｎｏｔを付けると解釈してください）

※　大学院で使うような論理数学の教科書には、この双対性というのがちらっと出てきますが、こんなものは、高校で教えるべきだと思います。ド・モルガン則を証明するより、よっぽど簡単です。

Tips 55. 　論理の分配則

また、分配則も成り立ちます。

（Ａ　∪　Ｂ）　∩　Ｃ　＝　（Ａ　∩　Ｃ）　∪　（Ｂ　∩　Ｃ）
（Ａ　∩　Ｂ）　∪　Ｃ　＝　（Ａ　∪　Ｃ）　∩　（Ｂ　∪　Ｃ）

上のと下のとは、∪と∩が入れ替わっただけ（双対）というのに着目すれば、覚えるのは、どちらか一つで良いです。私は上式を覚えています。上式は、∪を＋，∩を×と考えれば、

（Ａ　＋　Ｂ）　×　Ｃ　＝　（Ａ　×　Ｃ）　＋　（Ｂ　×　Ｃ）

という、普通の分配則と同じですから、直感的に理解できるでしょう。

Tips 56. 　elseだけ書いてはいけないのか？

Tips.53〜Tips.55で、論理数学の簡単なおさらい（？）をしました。プログラミングしていて、時々使うので覚えておいて損は無いです。

ただ、私が言いたいのは、そんなことでは無いのです。これを書くきっかけとなったのは、以下のプログラムです。

省略しているのではありません。正真正銘、if成立時の式はありません。とんだド素人のプログラムだと、お笑いになるかも知れませんが、これ、私が最近書いたプログラムの一部です。どうして、こう

書かないのか、と問われるかも知れません。そう書かない理由は、他の場所から、コピペしてきたからです。そのコピペする元では、ifの成立時の処理が書かれていました。しかし、コピーしてきた、こちらには、その処理は必要なかったので、ブランクにしました。

しかし、これを保守していた、プログラマにとって、この部分がとても気持ち悪かったらしく、勝手に後者の形式に書き換えてしまいました。ですが、これは明らかな改悪なのです。これを書き換えたプログラマは、単に自分の感覚になじまないという理由だけで書き換えてしまいました。なぜ、これがいけないか、彼は理解できていませんし、おそらく、これを読んでおられる方のほとんどの方も、同様でしょう。

もう少し詳しく説明します。前者と後者は、ｉｆ式のなかが、否定形になっています。それが最大の問題なのです。コピペしてきているわけで、何かの要請によって、コピペ元に条件を追加しなくてはならなくなるかも知れません。たとえば、条件式がこのように

修正されたときのことを考えてみましょう。先の部分は、ここからコピペしているわけで、当然、この修正を反映しなくてはなりません。前者の形式ならば、このままコピペすれば、それで作業は完了です。ところが、後者のように書き換えていたとしたら、どうすれば良いでしょうか？

ここまで読んで来られた方ならば、Tips.53のド・モルガン則を適用して、

と書き換えなくてはならないことはおわかりでしょう。ある程度の熟練されたプログラマならば、これは無意識に出来ます。この程度が無意識に出来ないのならば、プログラマ失格と言っても過言では無いです。しかしですね！コピペで済むものを、わざわざこんな書き換えはしたく無いのですよ！！

さらにコピペ元に条件が追加されたときのことを考えてみましょう。

これ、さきほどの後者の形式だと、コピペ先は、Tips.54の多項ド・モルガン則を適用して、

と書き換えなくてはなりません。理屈ではそうですが、こんな保守、やらされるほうにすればたまったものではありません。そもそも、これだけ形が違うと、コピペしてきてあることも気付きにくいですし、この部分が前者の論理の否定形であることすら気付かないです。よしんば気付いたとしても、誰でもこの書き換えをさらっと出来るわけでも無いでしょう。

もう、私の言いたいことが、わかっていただけたでしょうか。後者の形式は、何もすっきりなどしていないのです。「前者の形式が気持ち悪いから後者の形式に書き換えました」なんて言うのは、そのプログラマの自己満足に過ぎません。

これの応用で、私は条件式を否定形で書きたく無いがゆえに、わざと if 成立時の処理はブランクにして、elseで書くことがあります。これを、とんだド素人のプログラムだと考るのか、熟練されたプログラマのプログラムと考えるのかは、読者のご判断にお任せしますが．．。

Tips 57. 　安全性チェックは境界条件でやる

ある文字列を表示するプログラム（関数）を書いたとしましょう。

少なくとも、テストしなければいけないのは境界値です。すなわち、最小値である０（ゼロ）バイトのとき、どうなるのか。そして、３ではどうか。３で動けば任意の数ｎでも動くと考えられます。あと忘れてはいけないのが、∞（ある程度大きい値）で、バッファオーバーに対する安全性について調べるのです。

このように、極端な部分で必ずテストする習慣が必要です。特に、ゼロと∞は忘れがちなので、必ずやりましょう。

たとえば、wsprintfでは、1,024バイトまでのバッファしか扱えません。それ以上の場合は、_snwprintf 関数を使います。∞でテストしないと、いつまでたっても、こういう制限があることに気付かないのです。

'01/10/28

Tips 58. 　成立時脱出ループ　《れむ》

Tips.53で、whileの条件式として、ループを抜ける条件を書かせて欲しいという話をしました。もちろん、書けます。

実際のところ、こうやって書いたほうが、楽な部分も結構あります。永久ループのための構文が一つあって、continueとbreakとgotoさえ実装されていれば、それで良いという人も結構います。私も、そうだと思います。while (true)の部分は、人によって好みがあって、while ( 1 )やfor( ; ; ) （←泣いてる？＾＾；）等も考えられるところです。

たいてい、こういうプログラムは、リファクタリング（改良）の対象となるかも知れません。要するに、もっと洗練された、美しいコードにせえ！と誰かに突っ込まれることでしょう。しかし、果たして本当にそんな必要があるでしょうか？　上記コードを、仮に

と書き直したところで、実際のところ、そこからは何も生まれません。そればかりか、前者は、if式の寸前に、何か処理を書ける余地があるのに、後者にはその柔軟性がありません。つまり、後者の形は、前者の縮退した、特殊な例であり、ループとして、柔軟性、一般性があるのは前者なのです。（だから、前者のスタイルが優れているという結論にもなりませんが）

私は良く思うのですが、使っていないものを削除したりすることが改善では無いのです。（見かけはスッキリしますが）　また、プログラムは、同じ内容のものを少ないコード量で書く競技でも無いのです。それさえ理解していれば、前者のスタイルが生理的に許せない、ということも無いと思うのですが．．。

Tips 59. 　条件式はbooleanでは無いのか？

やねうらおのように、Cをやる前にPASCAL系の言語をやってましたというお行儀のいい坊ちゃん育ちなプログラマ（んなわけないか．．）は、if 式の中に、ぽんとint型変数が書いてあるのが許せません。

if ( !x ) {

みたいな奴ね。これ、なんやねん？とちょっと思ったりもします。

if ( x==0 ) {

でええやん？と思います。C++は強く型付けされて（strongly typed）いるわけですから、ifのなかは、論理値すなわち、boolean（ブール代数型）でなくては！と思います。（C#ではそうなっています）　まあ、Cにはbool型自体存在しなかったので、このへんは仕方ないのかも知れません。

同様に、Tips 57の、while ( 1 )も、それはどうなんや？と思ったりもします。まあ、そのへんは好みなので、どうでもいいと言えばそうなんですが、何か、int型もbool型も違いがわかっていなさそうで、いかにも頭悪そうです。＾＾；

ところで、次のプログラムは合法(legal)なのでしょうか？

bはbool型の変数です。ですから、わざわざb==trueとしている意図が見えません。よく、こう書いている人が居るんですが、こんなものは削除すべきだと思うのです。

しかし、これが合法かどうかというと、少しややこしいです。The Annotated C++ Reference Manualによると、

私、この日本語、とてもまずい表現だと思うのですが、「２つ有る」と言う場合、それ以外には有るのか無いのかわかりません。常識的に考えれば他には無いのでしょうけれど、有ったところで論理的には矛盾しません。まあ、b == trueと書いてもプログラムは正しく動くんですけど(VC++で確認)、この本には、次のような記述もあります。

それで、結局、true/falseの定義は見つから無いのです。まあ、bool型の（のみの）リテラルとして考えて良いのでしょうが。これ↑を見る限りは、仮にtrueが1,falseが0だとしても、暗黙に変換されるわけで、b == trueの部分は、うまく動くことは保証されそうではあります。

私はC++ではなくCだったころ、コンパイラによってはboolはintをtypedefしてあるかも知れない、とよく言われたことがあります。しかし、いまはbool型がpremitiveな型としてサポートされているので、C++の開発では、そんな心配は無いようにも思います。しかし、Win32の開発でときどき出てくるBOOL型とは何なのでしょうか？実際、MapInles.hで大文字のBOOLはintとtypedefされています。ということは、BOOLは、０か１以外の値も取り得るわけで、BOOLを使っているときに、

とか書いていると、このBOOL値が0か1しか取っていないとは限りませんから、そのうち痛い目に遭いそうな気もします。

Tips 60. 　エラー処理の記述の仕方　《Toru》

普通、エラー処理は、Ａという処理をやって、失敗しているかをｉｆで判定して、失敗していればエラーリターン、Ｂという処理をやって、失敗していればエラーリターン、、という方式で行なうものと思います。ところが、こうやると、Ｂという処理をやって失敗した場合、Ａという処理の終了処理を呼び出す必要が往々にして有ったりします。

たとえば、ファイルを２つオープンして、コピーするようなプログラムでもそうです。二つ目のファイルオープンに失敗すれば、一つ目のファイルを閉じなければなりません。ファイルのオープン〜クローズが、何らかのクラス化されていれば、スコープアウトされるときに、デストラクタが自動的に解決してくれるかも知れませんが、そんなケースばかりとも限りません。

このときに、次のようなスタイルで書けばどうか、というのがToruさんの提案です。

なるほど。これは、正しいフローですし、美しいし、いいことずくめのように思えます。ところが、私は「このスタイルだと、if文が１０個あると、１０個インデントされて、現実的なプログラミングスタイルにならないのでは？」とToruさんに尋ねたところ、「やっぱり例外を使うべきですかねぇ．．」と言われました。

うーむ。私の尋ね方が少し意地悪だったかも知れません。１０個インデントされて困るならば、ｉｆでインデントするのをやめれば良いだとか、エラーリターンすべきところをｇｏｔｏで書いてしまえば良いだとか、そういうレベルでも良いと思うんです。

前者が見やすいか、後者が見やすいか、それとも、gotoで飛ばさず、直接CloseHandle(..); return 1;　というように終了処理を埋め込むほうが良いのか、ファイルのオープン〜クローズをinner class化するのが良いのか、それは、終了処理の量、全体としてのコード長さ、最大インデントの数によりけりです。いつでもこのスタイルで良い、ということは無いと思うのです。

Tips 61. 　&&の評価順

ビット演算& の評価は、右からか左からか定義されていません。同様に、

このように書いた場合、どちらのfuncが先に呼び出されるかも定義されていません。VC++では、これについて面白い現象があるので、さ〜さんのページを参考として挙げておきます。

http://www.aya.or.jp/%7Esanami/peace/memorial/code31-40.html#CODE36

しかし、&&は違います。必ず左から右です。

Perlでは&&や || は、ショートカットオペレータと呼ばれていて、&&の左の式が偽ならば、&&の右の式は評価（実行）されないのです。そこで、ファイルのオープンに失敗したときにエラー処理をするプログラムは、

と書けます。同様に、C/C++でも、これは書けます。よくあるのが、

というものです。pが非NULL(C++ではNULL==0が保証されているので、こう書けます)であるときだけ、ある関数を呼び出すというものです。第一のオペランドが真のときだけ、第二オペランドを評価することは保証されています。（同様に、 || は、第一オペランドが偽のときのみ第二オペランドを評価することが保証されています）

これを使わないと、

のように書いてあるものは、

とBを２回書くか、

とするか、何にせよ、面倒くさそうです。

Tips 62. 　&と>>の組み合わせ

&でマスクをとったあと、シフトしたい、ということが往々にしてあります。たとえば、

です。しかし、これは、

と、シフトを先に行なえば、ビットマスクは１バイトで済みますんで、x86系のCPUでは、後者のほうが短いコードになります。案外盲点になっているので、気をつけてみてはどうでしょうか。どちらが見やすいコードかというと、また話は別ですが。

バリエーションとして、 (r << 8) & 0xff00　は、 (r & 0xff) << 8; と、先にマスクをとります。

'01/10/29

Tips 63. 　２進数で小数を表現する

２進数の浮動小数点表記としてＩＥＥＥの、、なんて話はしません（笑）

スケーリングの話です。仮にいま、２５６倍にスケーリングして、１．０を２５６として表現するときのことを考えてみましょう。

このとき、０．５は１２８として表現されます。０．２５は、６４として表現されます。０．７５ならば、６４＋１２８＝１９２というようになります。
このように、小数部は、８ビット（のみ）で表されます。同様に６５５３６倍（２＾１６）にスケーリングすれば、小数部は１６ビット（のみ）で表されます。

小数部を８ビットとして、割り算をする例：

このように、整数のみを使っていながら、それを仮想的に小数とみなすことが出来ます。これが、スケーリングの大きな特徴です。

Tips 64. 　sinをテーブル化する

Tips.63で、小数を整数で表現する枠組みが出来ましたので、さっそくsinのテーブルを考えてみましょう。sinは最大で１.0です。よって、1.0を256と考えれば、1.0以外は１バイトで表現できます。まあ、テーブルサイズをBYTEにする必要も無いので、WORDで良いんですが。角度も、１周360゜(degrees)や、１周が２π（radian）というのも、うっとおしいので、これもスケーリングして、一周を256だとか65536のほうが話が早いです。

sinをテーブル化してしまえば、cosもそのテーブルを利用できます。仮に１周を256でスケーリングしてあるsinテーブルを利用するならば、

です。

Tips 65. 　atanをテーブル化する

tanの逆関数、atanというのがあります。角度を求めるものです。高校の数学では普通、y/xの形で与えますが、これだとx == 0のときに、この割り算結果が∞になってしまうので、Cの関数としてはatanではなくatan2という、(x,y)の形を与えて、その角度を返す関数を用います。

この関数、何に使うかと言いますと、シューティングゲーム等で、自機をめがけて発射される弾の方向を算出するのに必須なのです。

atan自体の（まともな）計算方法は、奥村晴彦氏の「Ｃ言語によるアルゴリズム事典」等に、テーラー展開あるいは連分数展開で求める方法が紹介されていたと思いますが、そんなものでは役に立たないのです。

また、単純に考えると、y/xのテーブルというのは、非常に大きそうにも思えます。目的の値を探すのが、非常に時間がかかりそうに思われます。一見すると、atanは単調増加だから、２分サーチが使えるだとか、そういう話にもなりそうです。

まったく違うのです。atanは、そんなことをしなくてもテーブルの一発参照で済む方法があります。

それは場合分けです。x ≦ y と x > yの場合を分けてしまうことです。こうすれば、たとえば前者、x ≦ yの場合ならば、(x / y) ≦ 1が保証されます。

演算結果が１以下であることが保証されるということは、（１を無視すれば）小数部しか無いということです。Tips.63の方法を用いれば、その結果は（どんな値であれ）８ビットやら１６ビットやらで表現できるということです。ということは、テーブル参照できるということです。

簡単ですね。以下、x > yの場合も、atanの特性から、このテーブルを利用できます。

実装としては、このxとyの大小関係による場合分け（ x ≦ y と x > y）と、象限ごとの場合分け（第１象限x >= 0 , y >= 0　，　第２象限x < 0 , y >= 0　，第３象限x < 0 , y < 0　，第４象限x >=  0 , y < 0）の２×４で８つの場合分けをして、それぞれ上記のatan_tableを使って求めればｏｋです。

'02/05/12

Tips 66. 　ディフォルト引数

どうでも良いことですが、引数は、「ひきすう」と読みます。「いんすう」と読むと相手は「因数」だと勘違いします。＾＾；

よく初心者にありがちなのが、こういうチューンです。

この関数に、第３パラメータを用意して．．

こうしておけば、いままでとは関数インターフェースが変化しないので、従来のプログラムも正しく動くと考えますね。ところが、世の中、そう甘くなかったり、甘かったりするのです。（どないやねん！）

上のように変えたとき、コンパイルが通らなくなるケースは、ずばり、この関数ポインタを用いて何かをやっていたときです。関数プロトタイプが変化するので、この関数を関数ポインタ経由で呼び出していたりするプログラムはコンパイルが通らなくなるのです。

ちゅーことで、気をつけてください（誰にゆうてんの．．＞私）

Tips 67. 　続コメント算法　《ちょぴ》

/* 〜　*/のコメント文について、こんな意見をいただいたので紹介させていただきます。

Tips 68. 　vector<bool>

vectorのなかで、vector<bool>だけは特殊な存在です。メイヤーさん(Scotte Meyers)は、その著書『EffectiveSTL』のなかで、「vector<bool>は使わないようにしよう」という項タイトルで、

１．STLのコンテナでないこと
２．bool型の値が格納されないこと

をその欠点としてあげておられます。すなわち、

このコードはコンパイルされないのです。．．って、そうなのかよ！いま知ったよ（笑）

これは、vector<bool>は、擬似コンテナで、実際のbool型の値を格納しているわけではないからです。１バイトには8個のbool型の値が格納されているのです。これは、プロキシオブジェクトを作成して、operator [ ]によって読み出しを書き込みから区別する(⇒『More Effective C++』第30項 proxy class）技法で実装されています。

別にこの実装で困ることはそんなに無いのですが、上のコードがコンパイルできないと困ることもあるかも知れません。そこで、もし、上のコードがコンパイルしたいのなら、vector<BOOL>を用いて、使うときにbool*にキャストするというのはどうでしょうか。

と、ここまで書いたのちにVC++6.0のSTLで、

をコンパイルすると、正しく動くんですよ。ん？？動くの？＾＾； 気になったので、vectorのヘッダを見る。

確かに、その定義っぽいんですけど、ディフォルトallocatorの指定が無いです。ということは、VC++6では、vector<bool>と書くだけでは、このクラスが実体化されるわけではないようです。

Tips 69. 　多次元配列

固定長配列を使うのはやめて、vectorにしなさいというのは、もはや常識（？）だと思うのですが、vectorによる多次元配列というのはどのようになるのでしょうか？

配列の配列を作れば良いので、以下のようになります。

vectorのコンストラクタの第１パラメータは、配列サイズ、第２パラメータは初期化のためのパラメータを指定できます。

たとえば、

これならば、200という数字で初期化された、100個の要素を持つint配列が出来ます。上の２つの技法を組み合わせれば、

x×yなる２次元配列を用意できます。trueで初期化された、２次元配列が欲しければ、

で良いですね。このあと、

というように、２次元配列らしくアクセスできます。

Tips 70. 　オートコンプリート

Visual Studioのオートコンプリートは、「.」や「->」を打ち込んだときにだけ働くと思っている人が多いですが、入力中にCTRL + SPACEで強制的にオートコンプリートをさせることができます。

※　メンバのオートコンプリートについてはTips.41にあるように、this->をダミーでタイプするのですが、これはVSのマクロを用います。

※　しかし、CompleteWordは、マクロ中の記述は無効のようなので、実際はこれではオートコンプリートされないようです。仕方ないので、このマクロをshift+ctrl+spaceに割り当てて、shift+ctrl+space　⇒　ctrl + spaceと連続して押すことによって、メンバのオートコンプリートを実現するといいと思います。

戻る