C/C++ゲーム製作総合スレッド Part7 [転載禁止]©2ch.net

**名前は開発中のものです。** · 2015/01/11(日) 10:19:31.85

ゲーム製作におけるC/C++全般に関するスレです。

元スレ
DXライブラリ総合スレッドその18
http://peace.2ch.net/test/read.cgi/gamedev/1399459468/

前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.net/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.net/test/read.cgi/gamedev/1357899040/
C/C++ゲーム製作総合スレッド Part4
http://toro.2ch.net/test/read.cgi/gamedev/1376262450/
C/C++ゲーム製作総合スレッド Part5
http://peace.2ch.net/test/read.cgi/gamedev/1389798031/
C/C++ゲーム製作総合スレッド Part6
http://peace.2ch.net/test/read.cgi/gamedev/1404815419/

**名前は開発中のものです。** · 2015/01/14(水) 18:32:13.33

>>22
舞台装置と役者は似て非なる別物だからよ

>>14みたいなことをやる場合、
当たり判定まではキャラクターと同じでも
HPは持っていない壊せない壁をどう定義するかがな

**名前は開発中のものです。** · 2015/01/14(水) 20:11:23.18

>>23
同じオブジェクトで行けるってことは、似て非なる別物じゃないと思うが

**名前は開発中のものです。** · 2015/01/14(水) 20:25:50.33

好きなようにすりゃええがな
あんさんの方法を否定してる奴なんて誰もおらん
あんさんは他人を否定したくて仕方ないかも知れないがな！

**名前は開発中のものです。** · 2015/01/14(水) 21:38:06.89

例えどんな方法でも実現可能だったとしても
複数の手法の中からベストな物を追求するのは良いことである

**名前は開発中のものです。** · 2015/01/14(水) 22:19:18.87

>>25
まぁ、お前にゃ聞いてないがｗ
似て非なる別物の根拠を訪ねただけで、否定したように感じるってのは相当病んでるぞ

**名前は開発中のものです。** · 2015/01/14(水) 23:02:57.92

当たり判定の範囲をなしを含む特有の定義にして、
一番最初に横たわるキャラクターオブジェクトそれがマップ

他のキャラクターとは一部の要素が大きく違う分管理に差が出るし
無駄を承知で分けた方が分かりやすくはなる…かも

**名前は開発中のものです。** · 2015/01/15(木) 21:04:25.90

マップと言えば、マップチップタイプみたいな並びを記憶しておく必要があるマップは、
当然二次元配列を使うとして
たとえば現在の装備一覧のような、
同じ要素を指す数値の並びをしている物の塊も二次元配列にすべきなんだろうか

**名前は開発中のものです。** · 2015/01/15(木) 23:17:08.52

>当然二次元配列を使うとして
？

**名前は開発中のものです。** · 2015/01/16(金) 08:47:44.30

>>29
別にどう作っても良いけどマップも1次元の配列で持っていた方が楽
座標x、yも持たせておけばいい

**名前は開発中のものです。** · 2015/01/16(金) 12:23:34.85

二次元のビットマップ画像も普通一次元配列で確保するよな。

**名前は開発中のものです。** · 2015/01/16(金) 23:19:42.96

>>29
＞たとえば現在の装備一覧のような(…中略…)二次元配列にすべきなんだろうか

一覧表示にも色々あるけど
要求(される操作)に応じて適切なデータ構造(コンテナ)選ぶものなので
二次元配列でおｋ(な要求)ならそれで作るのが一番いいんじゃねーの

要素数がたかが知れてる場合、配列(std::vector)使ってるからって
何か問題が生じるような事はまずないわけだし

**名前は開発中のものです。** · 2015/01/17(土) 08:27:09.12

2次元配列でOKなものは1次元配列でOK
わざわざ2次元配列を使うメリットは何も無い

**名前は開発中のものです。** · 2015/01/17(土) 11:40:55.67

シンタックスシュガーでしかないもんねぇ
初心者に教えるなら積極的に使うけど

**名前は開発中のものです。** · 2015/01/17(土) 11:55:03.58

一次元配列で確保した上で行(or列)先頭にアクセスするための
インデックス(LUT)を用意するような内部実装でも二次元配列
なんであってだな(>>32)

ターゲットも実装も不明ならメリットねぇとは断言できんよ

**名前は開発中のものです。** · 2015/01/17(土) 11:57:15.65

>>35被ったスマン

**名前は開発中のものです。** · 2015/01/17(土) 17:31:33.18

たとえば縦スクロールSTGのマップとかで、
メモリ節約のためにマップを行ごとに細切れにして
表示範囲の上に一行足して下から一行引くような処理をしていたりする場合、
一行ずつ読み込んでるんだという事を示すためにわざとやるとか
試作段階で仕様が固まらなかった時の苦肉の策がそのままになっちゃったとか？
二次配列ってなんかあんまり使い道が浮かばない

**名前は開発中のものです。** · 2015/01/17(土) 18:57:09.16

3Dでキャラクターが技によって自由に地面の凹凸を操作できるようにしたいんですが
予め頂点を作っておかないとダメでしょうか？

キャラクターがここじゃーって指してる座標に一番近い面の上に
頂点をいい感じに窪ませるように配置して、
もともとあった面と入れ替わるような感じにしたいのですが、
当たり判定やハードウェアレンダリングしたいならやっぱり面倒ですか？

まぁハードウェアレンダリングなんてどうやればいいのかわからないですが

**名前は開発中のものです。** · 2015/01/17(土) 20:24:50.48

確かにあんまり、というか殆ど多次元配列使わないな
配列へのアクセス部分は、隠蔽する傾向にあるから、アクセス用インデックスが多次元でも、アクセスの内部仕様は１次元配列でやってることが多いな

また配列の次元数を増やすと、後から解読するのが難しくなって、可読性が下がる
だから次元が増える場合は、次元別にクラス定義して、一次元配列のメンバに下位次元を持たせるようにしてるな

そういやD3DMATRIXに2次元配列のメンバあるけど、自分で定義したものじゃないし、そもそもそのメンバって殆どアクセスしないなぁ

**名前は開発中のものです。** · 2015/01/17(土) 20:40:58.36

std::vector<std::vector<int>>とかやるじゃん？

**名前は開発中のものです。** · 2015/01/17(土) 20:55:17.63

Dictionary<Point, Tile> Mapしか使わん

**名前は開発中のものです。** · 2015/01/17(土) 21:10:19.92

>>41
enum定数でアクセスするのかな？
それにどんな情報を入れるんだろ

**名前は開発中のものです。** · 2015/01/17(土) 21:23:58.77

ベジェとか普通に書いたら多次元配列になるんじゃ…

**名前は開発中のものです。** · 2015/01/17(土) 21:56:16.62

>>41
やりません
コンテナ2つ重ねても無駄に複雑になるだけでしょ

**名前は開発中のものです。** · 2015/01/17(土) 22:50:59.20

>>41
リソースに余裕がある場面では使ってるな
規模が大きくなってくると細かいことまで気にしてられんからこれ使うとラク

**名前は開発中のものです。** · 2015/01/17(土) 22:59:23.12

>>39
テッセレータを使ったらいいのでは？
凹ませたい領域を4頂点の単純なタイルで表現し、それをフィールドに敷き詰めておく。
凹ませるときは、該当するタイルに対しテッセレーション（最大64分割）して、
高さマップを与えてディスプレースメントさせる。

**名前は開発中のものです。** · 2015/01/18(日) 00:08:51.85

>>45
やるぜ？
可変長CSVの読み込みとか

**名前は開発中のものです。** · 2015/01/18(日) 07:49:00.66

長さ不定のに多重vectorはしないかな

**名前は開発中のものです。** · 2015/01/18(日) 12:34:52.67

vector<vector<T>>は便利なときもあるけど、
コピーやトラバースのパフォーマンスがvector<T>に比べて著しく遅いんで、
そちらが重要なときは多少冗長でもvector<T>で扱うようにしてる。

**名前は開発中のものです。** · 2015/01/18(日) 12:40:46.60

vector<vector<T>*>

**名前は開発中のものです。** · 2015/01/18(日) 12:44:37.58

生ポインタ使うならdequeで良いだろ
とは言えないパフォーマンス差があるんだよな…

**名前は開発中のものです。** · 2015/01/18(日) 13:35:03.38

vector<unique_ptr<T>>

**名前は開発中のものです。** · 2015/01/18(日) 14:23:19.06

null_ptr

**名前は開発中のものです。** · 2015/01/18(日) 15:20:17.44

nullptrでは･･･

**名前は開発中のものです。** · 2015/01/18(日) 15:53:55.88

相当昔にC++触って、今と環境がかなり違いそうなのですが、
タスクシステムを実装する時、昔は固定長のメモリを予め確保したうえで、そのメモリを
newすることによって使っていたのですが、今のゲームもこのやり方が主流ですか？
それともスマートポインタ＋std::listでも速度出るのでしょうか？

スマートポインタとやらは、これはやってる事はガベージコレクションですよね？
速度に問題無しということですが、ヒープ領域から自由にnewdeleteして大丈夫なのかと不安になるのですが・・・

**名前は開発中のものです。** · 2015/01/18(日) 16:23:04.34

誰も使ってない

**名前は開発中のものです。** · 2015/01/18(日) 17:19:29.87

>>56
スマートポインタはリソース管理の安全性を高めるだけで、
new、deleteのパフォーマンスを高めるわけではない。
むしろクラス被せる分、オーバーヘッドが嵩む。
現代のハードウェア環境においては、多くの場合そのオーバーヘッドは問題にならないというだけ。

**名前は開発中のものです。** · 2015/01/18(日) 18:04:36.15

手動解放は、車で例えると
タイム短縮のためにわずかなエンジンパワーのロスも許されないプロレーサーや、
オートマはエンジンパワーが完全には伝わらないのでクソ
俺は完璧なギアチェンジ操作ができる（自称含む）のでマニュアルで通すんだって人向け

解放忘れてメモリリーク他の面倒な問題を起こしても泣かないなら全部手動で
それが嫌なら我々が作った処理班にぜひおまかせ下さい！
スマートポインタってそういうもの
shared_ptrやweak_ptr自体の書き忘れや循環参照などは防げないけど

>>54
ga

**名前は開発中のものです。** · 2015/01/18(日) 19:56:46.03

>>56
ここではWindowsならメモリ確保の負荷はそんなに問題にならないとしている

http://marupeke296.com/ALG_No2_TLSFMemoryAllocator.html

スマートポインタはGCってそれどういう意味だよ。
スマートポインタに使っている参照カウントはGCの方式の一つとは言えるが。

http://ja.wikipedia.org/wiki/参照カウント

**名前は開発中のものです。** · 2015/01/18(日) 20:33:19.91

おじさんは2万円前後の安もんの8インチタブ(CPU:Z3735G，RAM:1GB)を
即売会場でデモ機として使う都合で、バッテリー駆動でできるだけ長時間
ヌルヌル動かすために貧乏根性丸出しな組み方しちゃったけど、そういう
変な目的が無ければ自分の好きなようにやればいいと思うんだがな

○○のやり方が大丈夫なのか不安とか意味わかんねぇな。周りキョロって
ねぇで自分で決めた基準動作環境で自分でテストすればいいじゃんと

**名前は開発中のものです。** · 2015/01/19(月) 05:04:21.05

最近は底の方でも1GB
これなら多少雑に使ってもリークさえさせなければ問題ないな

なお512MB以下は爆死する模様
そんな化石がまだあるのかどうかは知らないが

**名前は開発中のものです。** · 2015/01/19(月) 08:44:27.43

全部起動時に読み込みとかやめて！

**名前は開発中のものです。** · 2015/01/19(月) 19:59:00.97

ふははは、貴様のセルを使うかどうかもわからない画像や音楽データで埋めてくれる！

読み込み時間といい、占有領域といい、ロースペにはある種のテロだな…

**名前は開発中のものです。** · 2015/01/19(月) 23:27:21.97

音楽やムービーのストリーム再生以外で、オンメモリでないゲームが作れるって凄いな。
そこまでリソースが用意できないよ。

**名前は開発中のものです。** · 2015/01/20(火) 00:33:47.17

メモリ次第ではあるけど
常駐とブラウザ合わせたら警告食らうくらいのゲームならあるんじゃないの

**名前は開発中のものです。** · 2015/01/20(火) 01:29:50.61

>>65
数年前、(旧)Android Marketに個人でゲーム出した時は機種依存の
バッドノウハウの量に本気で吐き気がしたけど、あれに比べたら
PCゲーは作りやすい思たよ。メモリフットプリント小さくするだけで
おｋなら大したこたないと思える程にAndroidスマホはカオス

(だった。今はどうなってるのか知りません)

**名前は開発中のものです。** · 2015/01/20(火) 10:35:24.77

1080pの画像を一度に100枚読み込めばロード地獄間違いなし
1920*1080*4 /1024/1024 *100 = 791MBぐらい
スマホだとアプリが強制終了するかも

グラフィックの豪華なアプリのModern Combat 5でもメモリは512MBぐらいまでしか使わない

**名前は開発中のものです。** · 2015/01/20(火) 22:05:53.74

圧縮テクスチャ使えば1/5くらいにはなるんじゃね？

**名前は開発中のものです。** · 2015/01/21(水) 16:36:27.53

そういや、Appmethodってどうよ？ちょっと気になってるんだが使ってる奴居る？

**名前は開発中のものです。** · 2015/01/21(水) 22:17:40.75

タスクシステムで組む時、
・タスクリスト２つ用意して移動と描画分ける
・タスクリスト１つに移動も描画も入れる

どっちがいいのでしょうか？個人的には前者にしたいけど・・・

**名前は開発中のものです。** · 2015/01/21(水) 22:19:47.80

前者にしたいのにできない要因を考えるのがよい
「みんながどうやってるか気になる」ってだけなら気にする必要はない

**名前は開発中のものです。** · 2015/01/22(木) 00:52:45.85

タスクシステムはバグった時に大変そうな印象
そりゃあ、バグれば大抵それなりに大変な目に遭うんだけどさ

**名前は開発中のものです。** · 2015/01/22(木) 02:20:52.62

>>68
一般的なアプリは、数MB

**名前は開発中のものです。** · 2015/01/22(木) 07:47:04.58

昔タスクシステムスレあったけど相手の主張への罵詈雑言だらけでいつの間にか消えたなｗ

**名前は開発中のものです。** · 2015/01/22(木) 16:27:46.03

移動と描画両方持ってたほうがスマートだべ

**名前は開発中のものです。** · 2015/01/22(木) 16:50:32.20

>>75
「タスクシステム」っていう名前が何を指すのかがすごく曖昧なのに
それを無視して自分の中の定義を押しつけ合う奴らの隔離スレだったし
消えて当然とも言える

**名前は開発中のものです。** · 2015/01/22(木) 17:35:35.81

まあ個人でゲーム作る分にはどう作ろうが60FPS出てちゃんと動けば勝ちだからなｗ
会社とかで厳密にタスク管理されてるなら覚えなきゃならんのだろうけど。

**名前は開発中のものです。** · 2015/01/22(木) 18:57:21.14

タスクシステムw
馬鹿しか使わん

**名前は開発中のものです。** · 2015/01/22(木) 21:08:37.90

>>79
なんで？

**名前は開発中のものです。** · 2015/01/22(木) 21:13:16.12

>>79
OS上で動くアプリならそうかもな
OS込みとしてならタスクは最適解だろうし、組み込み系で使われてるOSは名前が違うだけて同じ系統のものだよ
現在マイノリティなのは認めるけどな

**名前は開発中のものです。** · 2015/01/22(木) 22:06:24.79

ほーら始まったｗ
スレ立ててそっちでやれｗ

**名前は開発中のものです。** · 2015/01/22(木) 23:18:22.87

たすくしすてむってなあに？
おいしいの？

**名前は開発中のものです。** · 2015/01/22(木) 23:53:50.36

ごめんなさい
反射してしもた

**名前は開発中のものです。** · 2015/01/22(木) 23:56:43.23

だーかーらー、ただのリストに大げさな名前付けんなや

**名前は開発中のものです。** · 2015/01/23(金) 00:49:17.98

http://ja.m.wikipedia.org/wiki/TRONプロジェクト
多少は勉強になるから、読んでみたらどうだろう
これの亜流だよ

**名前は開発中のものです。** · 2015/01/23(金) 01:07:05.72

はじめからほとんど完成しているシステムに、
そのシステムの中枢部に触れないように要素を追加できるような実装を目指すなら有効
つまり、OSやエンジン作るならこれがいいかもしれない
が、そうでなければバグが修正困難だったり無駄な手続きが多いクソ
なんだ実行順って必要になった時にやらせろオラァァ

**名前は開発中のものです。** · 2015/01/23(金) 10:32:52.67

最近はどんな言語でもクロージャやジェネレータ (yield) をサポートするようになってきた。
タスクシステムとは呼ばれないけど、同じ目的には使えるんじゃないの？

描画に関しては、オブジェクトが自前で描画命令を発行するのか、
オブジェクトとは別にスプライトのような構造を用意して、描画はそちらに任せるかの差が大きい気がする。
巷のゲーム向けのフレームワークを見るに、後者のほうが可搬性は優れているんじゃないか？

**名前は開発中のものです。** · 2015/01/23(金) 10:52:38.49

オブジェクトが自前で描画って構造はゲームではあり得なくない？
ポーズ作るだけで一苦労じゃん

**名前は開発中のものです。** · 2015/01/23(金) 16:09:48.65

ネットに転がってるC++のゲームソースしっかりしたのはほとんどタスクシステムっぽいのばっかだから
そういうソースじゃないと読む気がしなくなったっていう(´・ω・｀)

**名前は開発中のものです。** · 2015/01/23(金) 16:29:50.12

単一のタスクだけで動かすと実によく機能するのに、
タスク同士を連動させようとすると途端にギクシャクする辺りが
実にぼっちらしくてよいが、
プログラムにそんなのやらせてどうするんだ

**名前は開発中のものです。** · 2015/01/24(土) 11:10:33.23

>>89
cocos2dとかそんな感じじゃね

**名前は開発中のものです。** · 2015/01/24(土) 13:26:12.19

C++11のstd::asyncってのが便利そうだから使ってみた。
確かに簡単に別スレッドに非同期に仕事をさせられる。
だが、どうも処理結果を受け取ってスレッドを終了するのに膨大なコスト（500msくらい）がかかるようだ。

代わりに、std::threadで常時スレッドを走らせておいて、std::mutexで同期を取りながら
データのやり取りをするようにしたらとてもスムーズに動くようになった。
しかし、std::asyncを使った場合と比べて、煩雑な記述が避けられない。

スレッド終了のコスト高杉。

**名前は開発中のものです。** · 2015/01/24(土) 13:34:42.36

TBBやPPL使っとけ

**名前は開発中のものです。** · 2015/01/24(土) 16:36:58.01

>>93
Windowsの話だよな？

**名前は開発中のものです。** · 2015/01/24(土) 20:09:43.23

C11使っとけ

93 · 2015/01/24(土) 21:51:42.90

>>94
サンクス。
調べてみる。

>>95
そうだよ。

**名前は開発中のものです。** · 2015/01/24(土) 22:06:18.60

1タスクごとにスレッドそのものを開始終了するとコストが高いので
想定するCPUのコア数だけワーカースレッドを用意して
それらにタスクを投げるのが定石じゃないかな。

・キューにタスクがない時はスレッド待機。
・タスクをキューに投げたら全ての待機スレッドを励起。
・いずれかのスレッドがキュー上のタスクを取得して実行、他は再び待機。
・タスクが完了してもスレッド完了せず、次のタスクを確認する。

デザインパターンにあったはず。

**名前は開発中のものです。** · 2015/01/24(土) 22:12:29.49

>>70
居ないのか……ま、いいや

**名前は開発中のものです。** · 2015/01/24(土) 22:16:34.35

スレッドの使い分けは適切に使わないと工数が意味もなく増殖するからな……

**名前は開発中のものです。** · 2015/01/24(土) 22:31:57.37

>>98
勉強になった。
やっぱそういうやり方が常套なのね。
そういや、マルチスレッドのデザインパターンってのがあるって聞いたことがあるな。
調べてみるわ。

**名前は開発中のものです。** · 2015/01/25(日) 21:12:51.89

タスクシステムよりシーン管理の方がよっぽど複雑だと思うの

**名前は開発中のものです。** · 2015/01/25(日) 21:27:30.87

シーンって「タイトル画面とキャラ選択画面とゲームのメインループその他」の意？
それとも「メインループ中の各シーン」のことかな。

>>101
標準テンプレートとか使える程度に技術のある人なら余裕で実装できるよ。

**名前は開発中のものです。** · 2015/01/25(日) 23:16:44.80

シーンったら状態遷移のことではつまり両方

**名前は開発中のものです。** · 2015/01/25(日) 23:53:06.16

>>98
ワーカースレッドが、キューに何もないことを確認して、
眠ろうとしているところに、
キューにタスクが入って、ワーカーに起きるよう指示を出す。
ワーカースレッドはその後寝てしまう。悪いことに全ワーカーが同じ状態。
次のキュー挿入で起きるけど。

なんかこんなこと考えると、こんがらがってきます。

**名前は開発中のものです。** · 2015/01/26(月) 15:41:45.19

>>105
キュー操作そのものにミューテックスで排他かけるから
「寝る」一連の動作と「起こす」一連の動作は複数のスレッドで並行に起こらない。

「寝て大丈夫かキューを確認したらタスクがあるから寝ずに実行」か
「完全に寝る→即座に次のタスクがキューにある状況で起こされる」のどちらか。

.NETだとWait()とPulseAll()、Javaならwait()とnotifyAll()で
簡単に実装できるけど、Win32APIだと少し面倒だった。

まずは上記2つのどちらかを調べて流れを掴んで、
それをC/C++用のAPIで書き表すことを考えてはどうかな。

**名前は開発中のものです。** · 2015/01/26(月) 16:22:24.05

>>106
condition_variable

**名前は開発中のものです。** · 2015/01/26(月) 17:05:42.55

*0.5の乗算と/2の除算
表す物はまったく同じだけど、前者の方が早いんだろうか？

**名前は開発中のものです。** · 2015/01/26(月) 17:06:44.50

/2の除算

**名前は開発中のものです。** · 2015/01/26(月) 17:08:38.36

シフト演算

**名前は開発中のものです。** · 2015/01/26(月) 17:36:32.42

整数ならそもそも結果が違うな
浮動小数ならコンパイラが最適化してくれるだろ

**名前は開発中のものです。** · 2015/01/26(月) 17:48:01.99

2のｎ乗倍しかできないじゃないですかー！やだー！
書き方が悪かったのは認める

**名前は開発中のものです。** · 2015/01/26(月) 18:30:30.51

>>112
浮動少数なら変わらないんじゃ？

**名前は開発中のものです。** · 2015/01/26(月) 21:04:49.69

>>106
Javaや.NETはスレッド簡単に書けるんか。
C++11や今後の新しいC++規格で同じようなライブラリ入れてくんないかな？

**名前は開発中のものです。** · 2015/01/26(月) 21:13:32.54

>>114
すでに >>107 が答えてくれてる。
std::thread, mutex, shared_mutex(=RWLock), condition_variable, async/future
C++11, 14 にて、この手の処理のための部品は揃ったと思われる。
あくまで部品なので、タスクキューなんかは自分で多少は書くことになるとは思うが。

**名前は開発中のものです。** · 2015/01/26(月) 21:19:26.58

#ifndef～#endifの組み合わせと#pragma onceの違いがよく分からない
前者は明確なインクルードガードだけど、後者は？

**名前は開発中のものです。** · 2015/01/26(月) 21:45:22.75

前者はガード以外にも使える
後者はガード専門

**名前は開発中のものです。** · 2015/01/26(月) 21:45:26.06

>>116
一回だけincludeしてねとコンパイラに言う

**名前は開発中のものです。** · 2015/01/26(月) 21:57:36.77

ついでに言うと#pragma onceは非標準

だけど主要コンパイラで実装してないものがないほぼデファクトスタンダード状態

**名前は開発中のものです。** · 2015/01/26(月) 22:06:02.39

>>115
ありがとう！
C++的にはちょうど良い落としどころっぽいね。
使い易くてハイパフォーマンスなスレッド記述をマスターしてやるぜ！

**名前は開発中のものです。** · 2015/01/26(月) 23:14:24.34

なるほど、むしろ#pragma onceがインクルードガード専用なんだな

>>119
マジで！？
VSで最初から書き込まれているプリプロセッサが非標準なのかよ

**名前は開発中のものです。** · 2015/01/27(火) 02:06:38.39

そもそも#pragma自体が、コンパイラ独自実装な機能で使うタグみたいなのじゃなかったっけ
まあ今となっては大抵のコンパイラで使えるみたいよ
http://en.wikipedia.org/wiki/Pragma_once