スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

現役プログラマーの方からの アドバイスを書く!(プログラミングに関して)

まず、どうでもいいこと。

「アラサー」とか「アラフォー」とかいう言葉があるじゃないですか。
あれ、最初インド的な挨拶か何かと思ってたんですが、

Around30(アラウンド・サーティー)とかの略語
だったんですね。
-------------------------------------------------------------
-------------------------------------------------------------


今日は、現役のプログラマーの方から教えてもらった、
プログラミング方法をまとめてみます!(`・ω・´)

※「教えて貰った」と言っても、
口頭ではなく掲示板だったり質問サイトだったり
します。
また、絶対にそうしないといけないという訳ではありませんので、参考程度に。


【1】生のポインタは使わない。
自分は、今まで、生のポインタを使っている所があったんですよ。

#define SAFE_DELETE(p)   { if (p) { delete (p);     (p)=NULL; } }

class Test{
public:
Test():m_a(0){};
~Test(){ SAFE_DELETE(m_a)};
private:
A* m_a;
};




これで、
----------------------------------------------------
ポインタは、クラスが初期化してくれるし、
最後はデストラクタでdelete、NULLを代入するからOK!

----------------------------------------------------
とか思ってたんですよ。

でも、よく考えたら、最初の初期化の記述を忘れたらSAFE_DELETEの所で
意味の分からない場所をdeleteしようとしてバグり
ますし、

デストラクタのSAFE_DELETE(m_a)を記述し忘れたらメモリリークが発生するんですよね。
※実際、そうなった事が何度もある。

なので、「クラスが自動的に開放するからOK!」とかではなく、
初めからポインタ自体をスマートポインタか何かにすべきかな
と思いました。


【2】変数の命名規則を決める。
命名規則というのは、要するに変数などの名前の付け方です。

で、名前の付け方ですが、
------------------------------------------
【1】何に使う変数なのか分かるようにする
【2】どんな属性の変数なのか分かるようにする

------------------------------------------
主にこの2つに留意して付けると良いとか。

【1】は、例えば下記の様な変数だと意味が分からないので、
-------
int a; //aって何?
-------
int TextureHandle; みたいにして、「テクスチャへのハンドルを受け取ってるんだな」
と言う風に、分かりやすくします。

【2】は、有効範囲だとかポインタなのかとか、
そういった変数が持つ情報を名前に含めてしまいます。

--------------------------------------
int m_handle; //メンバの変数( 先頭にm_ )
int g_handle; //グローバル変数( 先頭にg_ )
CTexture //クラス (先頭に大文字のCを付ける)
g_pDevice //グローバルなポインタ( g_の後にポインタを表すp )
m_pDevice //メンバのポインタ( m_の後にポインタを表すp )
ObjectVec //vector配列 (最後にVec)
--------------------------------------
こんな感じです。

ここら辺は、人によって色々と変わると思いますので、
どれが正しいというのはありません。
ただ、「こうする!」と決めたら、全て統一したやり方にするのは重要ではないかと。


【3】ビルド時間を短縮せよ。


<追記予定!>
スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

1 スマートポインタ

 そのTestクラスだと(記事で触れている様な初期化やSAFE_DELETEがあっても)元々問題のあるコードになっていますので、やはりスマートポインタにしておいた方がいいですね。

No title

以前、バグって分かったんですが、
この上記のコードって、 vectorとかに突っ込んだら壊れるんですよねv-292
(std::vector<Test>みたいな。)

ステップインでコードを追って行ったら、通常のデストラクタとvector側のデストラクタで
2回呼び出されて、 2回目の呼び出し時にバグってました。e-260

ともかく、もう全てスマートポインタ等に切り替えた方が良さそうですねv-388

No title

私は、普通にTestのようなクラスを使ってました・・・
安全性を考えればスマートポインタにした方がいいかもしれませんね。
(スマポの処理がないぶん、速度は速いのかもしれませんがw)

No title

「クラスは、コンストラクタで初期化、デストラクタで~」みたいな説明をしてる参考書って多いと思いますから、
※但し、STLと一緒に使う事は想定してない

その勢いで、上記のTestクラスのようなものを作る事って多いような気がしますねv-292
(普通に、参考書で見た事をそのまま実際に使ってる状態

まぁ、自分もその一人でしたv-393


安全性を考えたらスマートポインタにした方が良さそうですよねv-290

生のポインタの場合、 処理速度や使用メモリの面では
スマートポインタ使用時よりは良くなるかも
しれませんね(笑

ただ、その場合はデストラクタで開放とかやるのではなく、
プログラムが終了する前に、UnInit()みたいな関数を呼び出して、
明示的に開放処理を行う関数を呼び出すようにした方がいいのかなー、とか思いましたv-293
(「関数呼び出し忘れ」の可能性は残りますが)

No title

>vectorとかに突っ込んだら壊れる
 そういう参考書は STLというよりはコピーが発生する可能性を考慮していないんですよね。
 おかげでコピーしたら破綻するクラスを作る人はプロでもかなり多くいるので困ったものです。


>処理速度や使用
 ずっとスマートポインタのままで使うのではなく、時には生ポインタを取りだして使うなど運用でカバーすればほとんど変わらないかと。

 私の場合はよく生存期間が長い上位のクラスでスマートポインタでポインタを保持し、下位のクラスでは取りだした生のポインタをそのまま渡して使うことが多いです。
 この方式だとスマートポインタには参照カウンタ等が要らなくなるので軽量なスマートポインタで済みます。


>有効範囲
 型の命名方法を統一するのは非常に重要なことです。
 ただまぁ、役割は同じだけど型が少し変わってしまっただけで全コードに修正が入る様な名前の付け方にするのだけは、ちょっと避けたほうがいいかもしれませんね。

No title

>>コピーしたら破綻するクラスを作る人はプロでもかなり多くいる
そうなのですかv-292
参考書で基本的な文法などを覚えて、その後は使うだけという感じになる人が多いのかもしれないですねv-290

クラスであれば、コンストラクタ・デストラクタ辺りのやり方だけを覚えて、
「複数の場所から参照されてた場合」とか、
「コンストラクタで例外が発生した場合」とか、
そういう色んな条件に応じてどのような問題が発生するか?発生しうるのか?まで
色々と考えてみてる人は少ないのかもしれませんね。

・・・そういえば、
「ネット上で公開されているソースをそのままコピーして使ってる人が多い!」というような嘆きのコメントを見た記憶があります。
※明らかに説明やソースコードが間違ってる(場合によってバグるようなコード)のに、
問題が発生するか?などを 何も考えずに、とりあえずコピーペーストして使っていると見受けられるような人が多かったとの事。

ともかく、色んな使い方やエラーなどを想定して、問題が発生しないかを考える習慣は付けておいた方が良さそうですね。

>上位のクラスでスマートポインタでポインタを保持し
なるほど、この方法は良さそうですねv-290
いつ、どこでポインタが不要になるか、後処理をするか等を決めていれば
全部 参照計測ポインタにする必要は無いですね。
その代わり、勝手な事をしないように(変な所でdeleteしたり)決めておく必要がありますねv-293

>型の命名方法
確かに、開発途中で何らかの変更があるかもしれませんし、
その度に修正してたら手間がかかって良くないですねv-404
ちょっとした変更でも、修正しなければならない名前は付けないように気をつけようと思います。
とりあえず、自分はPascal記法で分かりやすい名前を付けようと思いますv-411

No title

>色々と考えてみてる人は少ないのかも
 世の中には書いているコードだけが動けばいい、という人は多いようです。
 最近は静的チェックツールもかなり精度が高くなってきていますので、そういうツールの利用が広まっていけばいいとは思うのですが、なかなか……。
 
 自分の周囲には普段からそこまで考え無しなのはそういませんが、スケジュールが破綻しているなど質を落としてでも効率を上げる必要があったりする場合、往々にして細かいところまで気が回らないことはありますね。


>ネット上で公開されているソースをそのままコピーして使ってる人が多い
 山のようにいますよね。サンプル・テストレベルならまだいいのですが、そのまま仕事で使ってしまうケースも往々にしてあったりするのが実情のようで。
 バグなどリスクはまだテスト・レビューで回避出来る可能性がありますが、ライセンス・著作権のリスクの方は流用コードでは避けにくいので、参考にし自分で咀嚼して書き直さないといろいろと問題になるかもしれません。


>その代わり、勝手な事をしないように
 そうなりますね。
 まぁスマートポインタを使うこともあって、ユーザー自身が deleteすることはほぼ皆無になりますので、自分でdeleteなどしているとすぐに判りますw

No title

>>世の中には書いているコードだけが動けばいい、という人は多い
なるほど、そうなのですかv-292
多分、自分の行わせたい処理だけやって、それが出来ればOK(エラーが出ずに)
みたいな感じになっているのかもしれませんね。
(想定した状況以外の事は、あまり考えない)

まぁ、他にも時間が無いからプログラムの質として良くない状態で終わる場合もあるっぽいですね。
(納品期間の関係で提出して、その後に来るであろうバグ報告に対する準備を始める~ みたいな話を聞いた事があります。)

>>仕事で使ってしまうケースも往々にしてあったり
確かに多いですね。
ゲーム企業なんかでも、 
他人のソースをコピーして、一部をちょっといじったものなどは自作作品として認めません」、
みたいな、注意書きをしている所があったりしますし。
(それだけ、コピーして使ってる人が多いのでしょう)

それならまだしも、 ライセンス関係で問題が発生してしまう
かなり面倒な事になるでしょうねv-404

(「ICO」というゲームでは、ライセンス有りのライブラリを使っていたことにより問題が発生し、
ゲームの生産終了、廃盤 になったりしました。)

>スマートポインタを使うこともあって
予め可能性を潰してたらバグの発生箇所も分かりやすいですねv-411
たまに、自分でも変なコードを書いてプログラムが壊れてしまう事があるんですが(笑
そういう場合でも、原因を発見しやすそうですv-293
コメントの投稿
管理者にだけ表示を許可する



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。