[雑談?]c++の分かりやすいプログラム
[雑談?]c++の分かりやすいプログラム
人によって様々なソースコードの書き方があるようなのですが
実際どのような書き方をしているのか知りたいです。
・・・っといっても、細かく言い始めるとキリがなさそうなので
これだけは絶対にしてる!とか
こうしたほうが処理が速い!といったことを教えていただけると嬉しいです。
また、書き方だけでなく
ファイル分割等も、何かわかりやすくするコツがあれば教えて欲しいです。
実際どのような書き方をしているのか知りたいです。
・・・っといっても、細かく言い始めるとキリがなさそうなので
これだけは絶対にしてる!とか
こうしたほうが処理が速い!といったことを教えていただけると嬉しいです。
また、書き方だけでなく
ファイル分割等も、何かわかりやすくするコツがあれば教えて欲しいです。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
かなーりアバウトな質問なので、的確に答えられそうにないですが、
自分は速度なんてあまり気にしないようにしています。
そもそも、最近のPCなら多少無理しても動きますし、遅いから~って言ってる人は実際計測したのか疑問に思います。
(あ、もちろんそういうことが必要な現場もあるのは知っていますよ)
あとは、いろいろありますが、継承をしないってことですかね。
自分は速度なんてあまり気にしないようにしています。
そもそも、最近のPCなら多少無理しても動きますし、遅いから~って言ってる人は実際計測したのか疑問に思います。
(あ、もちろんそういうことが必要な現場もあるのは知っていますよ)
あとは、いろいろありますが、継承をしないってことですかね。
Re: [雑談?]c++の分かりやすいプログラム
理由が気になりますね。Suikaba さんが書きました:あとは、いろいろありますが、継承をしないってことですかね。
Re: [雑談?]c++の分かりやすいプログラム
自分の知識不足のせいです。Suikaba さんが書きました:かなーりアバウトな質問なので、的確に答えられそうにないですが、
自分のソースコードの書き方がむちゃくちゃなのは分かるのですが
どうすればよいのかがわかりません。
なにかキーワードがひとつでも見つかれば
そこから色々見つかるのではと思い
とりあえず質問をさせていただきました。
確かに最近のは十分速いですもんね。Suikaba さんが書きました: 自分は速度なんてあまり気にしないようにしています。
そもそも、最近のPCなら多少無理しても動きますし、遅いから~って言ってる人は実際計測したのか疑問に思います。
綺麗でわかりやすいソースを書くことを優先したいと思います。
どのような問題点があるのでしょうか?Suikaba さんが書きました: あとは、いろいろありますが、継承をしないってことですかね。
多重継承の問題は沢山あったのですが
継承自体はしない方がいいというものは見られませんでした。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
継承をするってことは、すなわち派生クラスすべてに共通するもの(不変性)があるってことなんですが、
派生クラスの追加等に伴ってそれが失われてしまうことがあります(大抵そうなる)。
この変数はすべての派生クラスに必要だ→こいつには必要ないな…
ってことが起こるのは容易に想像できます。
それなら、Interfaceを実装して、メンバ変数とかはたとえほとんどのクラスに共通でもそれぞれのクラスに書いたほうがいいと思います。
これなら、不変性が証明できたとき、あとでまとめるといったこともできますしね。
あとは、コンポジションやらで十分だった、ってことがおおいってのもありますね。
継承をするときは、それなりの理由がある&それを人にちゃんと説明できるって時にすればいいかなーと思います。
継承をするなと言い切るよりは、どうしても理由があるとき以外はするな、といったほうが良かったかもしれません。
【追記】
たまに勘違いされている方がいるのですが、インターフェースの実装と単なる継承は、C++では構文はたしかに同じですが、意味するところは結構違いますので、気になったらググってもらえるといろいろ情報が集まると思います。
派生クラスの追加等に伴ってそれが失われてしまうことがあります(大抵そうなる)。
この変数はすべての派生クラスに必要だ→こいつには必要ないな…
ってことが起こるのは容易に想像できます。
それなら、Interfaceを実装して、メンバ変数とかはたとえほとんどのクラスに共通でもそれぞれのクラスに書いたほうがいいと思います。
これなら、不変性が証明できたとき、あとでまとめるといったこともできますしね。
あとは、コンポジションやらで十分だった、ってことがおおいってのもありますね。
継承をするときは、それなりの理由がある&それを人にちゃんと説明できるって時にすればいいかなーと思います。
継承をするなと言い切るよりは、どうしても理由があるとき以外はするな、といったほうが良かったかもしれません。
【追記】
たまに勘違いされている方がいるのですが、インターフェースの実装と単なる継承は、C++では構文はたしかに同じですが、意味するところは結構違いますので、気になったらググってもらえるといろいろ情報が集まると思います。
最後に編集したユーザー Suikaba on 2012年10月31日(水) 19:51 [ 編集 1 回目 ]
Re: [雑談?]c++の分かりやすいプログラム
人のプログラムをまずはパクって使ってみて覚えます。
こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。
自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。
一番わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。
最低限、インデントとコメントくらいは必要かと思います。
自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。
こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。
こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。
自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。
一番わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。
最低限、インデントとコメントくらいは必要かと思います。
自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。
こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。
Re: [雑談?]c++の分かりやすいプログラム
<Suikaba様
無駄に継承すると
かえって扱いづらいということですね。
後の仕様なども考えて
まず変更が無いであろう部分、
かつ継承したほうが効率のいいものだけ
継承を使おうと思います。
無駄に継承すると
かえって扱いづらいということですね。
後の仕様なども考えて
まず変更が無いであろう部分、
かつ継承したほうが効率のいいものだけ
継承を使おうと思います。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
自分で1から作るのではなく、その作ろうとしている処理を他の人がどのように実装しているのかAKIЯA さんが書きました:人のプログラムをまずはパクって使ってみて覚えます。
こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。
調べながら作っていってみます。
処理をひと通り書き終えたら、AKIЯA さんが書きました: 自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。
一番わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。
最低限、インデントとコメントくらいは必要かと思います。
自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。
しばらく見なおしてみるようにしてみます。
そういう心がけが大切なのですね。
これからもプログラミングに励みAKIЯA さんが書きました: こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。
少しずつ進歩していけれるよう、頑張ります!
MLP!MLP!
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: [雑談?]c++の分かりやすいプログラム
どんだけリファクタリングするかも大事でしょうね。
書きっぱなしのコードはたいてい可読性がよくありません。
書きっぱなしのコードはたいてい可読性がよくありません。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: [雑談?]c++の分かりやすいプログラム
わたしはできるだけ継承を使うように設計しますね。
ゲームのフレームワークで、いわゆるタスク管理には継承が便利です。
むしろ継承を使わないと実装できません。
継承を使うときは派生クラスが基底クラスの存在を意識しなくて済むように実装します。
派生クラスに必要かどうかという観点で基底クラスの実装をすることはないですし、派生クラスの実装が基底クラスに影響を与えることもないです。
それ自体が必要十分に機能し、余分なものは載せない。
基底クラスに限らずそうあるべきだと思います。
それから、次に活かせるように完成したあともモジュール化を意識してリファクタリングに時間をかけてます。
ある程度の規模のアプリケーションになると一から全部作ることはもはやないと言っていいくらいにはなってると思います。
C++特有の話としては、一時オブジェクトを意識するくらいですかね。
C++に限ったことではないですが、コンパイルした時点でミスに気付くように修飾子を活用するとか、コメントがなくても困らないくらい自然にコードが読めるように識別子を付けるとか。
ゲームのフレームワークで、いわゆるタスク管理には継承が便利です。
むしろ継承を使わないと実装できません。
継承を使うときは派生クラスが基底クラスの存在を意識しなくて済むように実装します。
派生クラスに必要かどうかという観点で基底クラスの実装をすることはないですし、派生クラスの実装が基底クラスに影響を与えることもないです。
それ自体が必要十分に機能し、余分なものは載せない。
基底クラスに限らずそうあるべきだと思います。
それから、次に活かせるように完成したあともモジュール化を意識してリファクタリングに時間をかけてます。
ある程度の規模のアプリケーションになると一から全部作ることはもはやないと言っていいくらいにはなってると思います。
C++特有の話としては、一時オブジェクトを意識するくらいですかね。
C++に限ったことではないですが、コンパイルした時点でミスに気付くように修飾子を活用するとか、コメントがなくても困らないくらい自然にコードが読めるように識別子を付けるとか。
Re: [雑談?]c++の分かりやすいプログラム
<たいうち様
xUnitというものがあったのですか。
勉強になります!
<ソフト屋さん様
<ISLe様
その機能を使いたい時に呼び出し
その機能以外は持たせない様にすればいいということですね。
無駄な部分で呼び出されないようにすればいいのですね。
コメントがなくてもいいというと
グラフィックハンドルを代入しておく変数に[img_]をつける
といった感じでしょうか?
xUnitというものがあったのですか。
勉強になります!
<ソフト屋さん様
やはり、後で修正することは大切なのですね。softya(ソフト屋) さんが書きました: どんだけリファクタリングするかも大事でしょうね。
書きっぱなしのコードはたいてい可読性がよくありません。
<ISLe様
つまり、基底クラスは1つの機能であり、ISLe さんが書きました: 継承を使うときは派生クラスが基底クラスの存在を意識しなくて済むように実装します。
派生クラスに必要かどうかという観点で基底クラスの実装をすることはないですし、派生クラスの実装が基底クラスに影響を与えることもないです。
それ自体が必要十分に機能し、余分なものは載せない。
基底クラスに限らずそうあるべきだと思います。
その機能を使いたい時に呼び出し
その機能以外は持たせない様にすればいいということですね。
テスト用にまず作って、それからリファクタリングをしっかししていこうとおもいます。ISLe さんが書きました: それから、次に活かせるように完成したあともモジュール化を意識してリファクタリングに時間をかけてます。
ある程度の規模のアプリケーションになると一から全部作ることはもはやないと言っていいくらいにはなってると思います。
つまり、その変数や関数にアクセスできる範囲を前もって考えてISLe さんが書きました: C++特有の話としては、一時オブジェクトを意識するくらいですかね。
C++に限ったことではないですが、コンパイルした時点でミスに気付くように修飾子を活用するとか、コメントがなくても困らないくらい自然にコードが読めるように識別子を付けるとか。
無駄な部分で呼び出されないようにすればいいのですね。
コメントがなくてもいいというと
グラフィックハンドルを代入しておく変数に[img_]をつける
といった感じでしょうか?
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
違います。天紆 狐 さんが書きました:つまり、基底クラスは1つの機能であり、
その機能を使いたい時に呼び出し
その機能以外は持たせない様にすればいいということですね。
基底クラスは、派生クラスにとって自分自身(is-aの関係)でなければいけません。
クラスには、外側に向けた実装と、内側に向けた実装があるわけですが、派生クラスが基底クラスの内側に向けた実装を利用して、外側に向けた実装(いわゆる振る舞い)をオーバーライドするのは自然です。
しかし、派生クラスが基底クラスの機能を使って、基底クラスにない振る舞いを実装するのであれば、その基底クラスはただのユーティリティクラスです。
基底クラスの機能を便利に使うという発想を持つことが、is-aの関係を正しく理解していないと言えると思います。
他のスレでも話題になっていますが、あらかじめ制限をキツくしておいて、必要に応じて緩くしていきます。天紆 狐 さんが書きました:つまり、その変数や関数にアクセスできる範囲を前もって考えて
無駄な部分で呼び出されないようにすればいいのですね。
緩くするときには本当にそれでいいのかいったん検討します。
これもしばしば話題になりますが、コード上の識別子を並べたときに、できるだけ英語として自然に読めるように変数名や関数名あらゆる名前を工夫します。天紆 狐 さんが書きました:コメントがなくてもいいというと
グラフィックハンドルを代入しておく変数に[img_]をつける
といった感じでしょうか?
工夫すると言っても一定のルールに従えばいいので慣れれば自然にできるようになると思います。
Re: [雑談?]c++の分かりやすいプログラム
<ISLe様
クラスというものを知っているというだけで
正しい使い方等は知りませんでした・・・
http://www.textdrop.net/google-stylegui ... able_Names
こちらのサイトにいろいろのっているみたいなので
c++の勉強をしながら
ここに書いてあることを理解していこうと思います。
最初は制限をできるだけキツくするようにします。
クラスというものを知っているというだけで
正しい使い方等は知りませんでした・・・
http://www.textdrop.net/google-stylegui ... able_Names
こちらのサイトにいろいろのっているみたいなので
c++の勉強をしながら
ここに書いてあることを理解していこうと思います。
最初は制限をできるだけキツくするようにします。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
わたしも正しいと胸を張って言えるほどのものではありませんが。天紆 狐 さんが書きました:クラスというものを知っているというだけで
正しい使い方等は知りませんでした・・・
入門書にしばしば継承の説明として、「『動物』クラスを継承して、『犬』クラスや『猫』クラスを作る」というのがあります。
間違いではないのですが、実はここに落とし穴があるのです。
#プログラミング入門書というのはこういった落とし穴があちこちにあるものです。
これは、『動物』という枠組みのルールできちんと成立する世界(フレームワーク)があってはじめて意味があります。
『犬』『猫』の共通点を探して『動物』を作るのは設計の話で、実装の話ではありません。
『犬』『猫』を“実装するとき”に共通点をまとめるのなら、
『動物』クラス→(継承)→『犬猫共通』クラス→(継承)→『犬』or『猫』
という構成にしなければ世界が変わってしまうわけです。
つまりは設計が大切だということですね。
設計と実装は、頭を切り替えてきちんと切り離して考えないと、プログラムはどんどんぐちゃぐちゃになります。
構造化を進めてフレームワークとしてまとめるほどの力が付けば、プログラマとしてはリーダー格になれると思います。
オブジェクト指向も自然と身に付くでしょう。
それは一企業のコーディングルールなので、その企業に関係のないひとが守るべきようなものではないです。天紆 狐 さんが書きました:http://www.textdrop.net/google-stylegui ... able_Names
こちらのサイトにいろいろのっているみたいなので
c++の勉強をしながら
ここに書いてあることを理解していこうと思います。
参考になるところはたくさんありますけどね。
書かれている内容を鵜呑みにしないで吟味してください。
Re: [雑談?]c++の分かりやすいプログラム
<ISLe様
今、自分のゲームにはどういう機能があり、
また、それに関連する情報はどのようなものがあるのか
きちんと理解し、それらを
皆様の意見を参考にしながら
設計していこうと思います。
今のうちに実用的な力を身に着けて
将来に役立つよう頑張ります。
今、自分のゲームにはどういう機能があり、
また、それに関連する情報はどのようなものがあるのか
きちんと理解し、それらを
皆様の意見を参考にしながら
設計していこうと思います。
今のうちに実用的な力を身に着けて
将来に役立つよう頑張ります。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
雑談スレだし私からも質問させて下さい。
リファクタリングという言葉が何度も出てきてますが、
xUnitによる単体テストで保護された状態で行っていますか?
私の経験上では、十分設計を洗練させるためのリファクタリングには
単体テストが不可欠です。十分な単体テストなしでは、
満足できるリファクタリングができなかったり、
デグレを起こしたりでした。
私が初期から参加していたプロジェクトでは、
内部処理に限れば単体テストを書くことが多かったです。
途中参加だったり、特に多いのが、「過去の資産」と称する
碌に仕様書もないようなシステムのバージョンアップ等では、
単体テストを書ける状態にするまでのリファクタリングが膨大で、
極々一部しか書けません。
Web系などでもUI以外の部分は単体テストが作成可能で、
UIと内部処理をできるだけ分離する必要があると思うのですが。
再度質問を書くと、、、
1.単体テストは書ける?書いたことがある?
2.有益だと思う?有益だった?
3.どういう時に役に立った?どういう時に役に立ちそう?
4.単体テストを書くことのディメリットは?
5.単体テストなしのリファクタリングはうまくいく?いかない?
こんな感じでしょうか。
業種や言語によっても傾向は違うでしょうが、
回答を分析して、とか何も考えていませんので、
プロアマ問わず気が向いた人はてきとーに書いてくれるとうれしいです。
リファクタリングという言葉が何度も出てきてますが、
xUnitによる単体テストで保護された状態で行っていますか?
私の経験上では、十分設計を洗練させるためのリファクタリングには
単体テストが不可欠です。十分な単体テストなしでは、
満足できるリファクタリングができなかったり、
デグレを起こしたりでした。
私が初期から参加していたプロジェクトでは、
内部処理に限れば単体テストを書くことが多かったです。
途中参加だったり、特に多いのが、「過去の資産」と称する
碌に仕様書もないようなシステムのバージョンアップ等では、
単体テストを書ける状態にするまでのリファクタリングが膨大で、
極々一部しか書けません。
Web系などでもUI以外の部分は単体テストが作成可能で、
UIと内部処理をできるだけ分離する必要があると思うのですが。
再度質問を書くと、、、
1.単体テストは書ける?書いたことがある?
2.有益だと思う?有益だった?
3.どういう時に役に立った?どういう時に役に立ちそう?
4.単体テストを書くことのディメリットは?
5.単体テストなしのリファクタリングはうまくいく?いかない?
こんな感じでしょうか。
業種や言語によっても傾向は違うでしょうが、
回答を分析して、とか何も考えていませんので、
プロアマ問わず気が向いた人はてきとーに書いてくれるとうれしいです。
Re: [雑談?]c++の分かりやすいプログラム
1.単体テストは書いたことがある。
2.とても有益だと思う。単体と結合の区別が結構あやふやになることが多いので、テストというくくりで以降は話を進めてみる。
3.簡単なバグつぶしには結構役に立った。コード量はテストを書く分、確かに増えるけどもその後のデバッグに占める時間も考えるとなかなか良い感じ。あとは、テストがしやすい設計にしようと日頃から考えることになるので、今まで適当に組んでいたところで考えたり出来る。ただ、テストが目的にはなってはいけない。
4.やっぱり最初はサボリ気味。テストを書くのが億劫になってしまうことがある。
5.わからない。ちなみに、TDDの考え方では、テストを失敗させる→動くようにする→リファクタリングってサイクルを早く回すような考え方が黄金パターン。ここでのリファクタリングはとても重要。
って感じでしょうか。
適当なこと言ってるかもしれないので、鵜呑みにはしないでくださいね。
あと、テストを書くと、謎の自信がつくことがあります。
2.とても有益だと思う。単体と結合の区別が結構あやふやになることが多いので、テストというくくりで以降は話を進めてみる。
3.簡単なバグつぶしには結構役に立った。コード量はテストを書く分、確かに増えるけどもその後のデバッグに占める時間も考えるとなかなか良い感じ。あとは、テストがしやすい設計にしようと日頃から考えることになるので、今まで適当に組んでいたところで考えたり出来る。ただ、テストが目的にはなってはいけない。
4.やっぱり最初はサボリ気味。テストを書くのが億劫になってしまうことがある。
5.わからない。ちなみに、TDDの考え方では、テストを失敗させる→動くようにする→リファクタリングってサイクルを早く回すような考え方が黄金パターン。ここでのリファクタリングはとても重要。
って感じでしょうか。
適当なこと言ってるかもしれないので、鵜呑みにはしないでくださいね。
あと、テストを書くと、謎の自信がつくことがあります。
Re: [雑談?]c++の分かりやすいプログラム
わたしは、ゲームプログラムという特殊な形態(?)のせいかもしれませんが、フレームワークを使った単体テストは行ったことがありません。
プロジェクトごとの独自性が大きいので、リファクタリングも、フレームワークとして使い回せるコードの抽出が中心で、単体テストには向きません。
各種ペリフェラルにアクセスするモジュールを作成しますが、基礎研究としてハードに造詣のある担当者が最初からモジュールとして設計したものを作ります。
少なくともわたしが関わったプロジェクトに関しては単体テストが用意されたことはなかったですね。
一年も掛からない中小規模のプロジェクトにしか関わったことがありませんが。
フレームワークを使った単体テストというのは、幾つもの工程を経て出力が得られるようなシステムでは役に立つと思いますが、即応性の高いモジュールが互いに影響しながら並行動作するゲームプログラムだと使えるところがないと思うのです。
プロジェクトごとの独自性が大きいので、リファクタリングも、フレームワークとして使い回せるコードの抽出が中心で、単体テストには向きません。
各種ペリフェラルにアクセスするモジュールを作成しますが、基礎研究としてハードに造詣のある担当者が最初からモジュールとして設計したものを作ります。
少なくともわたしが関わったプロジェクトに関しては単体テストが用意されたことはなかったですね。
一年も掛からない中小規模のプロジェクトにしか関わったことがありませんが。
フレームワークを使った単体テストというのは、幾つもの工程を経て出力が得られるようなシステムでは役に立つと思いますが、即応性の高いモジュールが互いに影響しながら並行動作するゲームプログラムだと使えるところがないと思うのです。
- softya(ソフト屋)
- 副管理人
- 記事: 11677
- 登録日時: 13年前
- 住所: 東海地方
- 連絡を取る:
Re: [雑談?]c++の分かりやすいプログラム
私もゲーム業界では単体テストユニットを使って書いたことが無いです。
昔はメモリがカツカツだったので、そんなものを入れる余地さえ残っていないことが多々ありましたね。
ライブラリのテストで単体テストはテスト・ドライバを書いたりして実施してましたが単体テストユニットは使ったがなかったです。
ISLe さんの言われる通り、ゲームにおいてはシーケンシャルな単体テストに通ったところで論理的整合がゲーム中で取れなくなるバグのほうが多いので余り顧みられなかったと言ったところでしょう。
ゲームでxUnitを使った人がいたら私も聞いてみたいですね。
昔はメモリがカツカツだったので、そんなものを入れる余地さえ残っていないことが多々ありましたね。
ライブラリのテストで単体テストはテスト・ドライバを書いたりして実施してましたが単体テストユニットは使ったがなかったです。
ISLe さんの言われる通り、ゲームにおいてはシーケンシャルな単体テストに通ったところで論理的整合がゲーム中で取れなくなるバグのほうが多いので余り顧みられなかったと言ったところでしょう。
ゲームでxUnitを使った人がいたら私も聞いてみたいですね。
by softya(ソフト屋) 方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。
Re: [雑談?]c++の分かりやすいプログラム
自分に限って言えば、C++を使うのは最近数値計算をする時に限られてきましたが、(ゲーム等は作っていないので)
気を付けていることは、式が直観的に書けるかどうかということですかね?
A = B × Cと手計算で書くならば、プログラムもA = B * C と書けるようにするべきだと思っています。
これは演算子のオーバーロードレベルの話ですが、たとえば"関数の内積"だとか、"合成関数"とか"変換"だとか
その他独特な書き方をどうやって(自分にとって)直観的に書くことができるかということを最近考えてます。
(でないとあとから読めたものじゃない)
まぁ人に見せるものじゃないので、別に自分が分かればいいのですが。
たとえばdiv という記号を割り算(division)と解釈する人はいるでしょうけれど、僕はそれを直観的でないと感じるのでそうしません。
(いつも手計算の時にはdivergenceの意味で使っているから)
気を付けていることは、式が直観的に書けるかどうかということですかね?
A = B × Cと手計算で書くならば、プログラムもA = B * C と書けるようにするべきだと思っています。
これは演算子のオーバーロードレベルの話ですが、たとえば"関数の内積"だとか、"合成関数"とか"変換"だとか
その他独特な書き方をどうやって(自分にとって)直観的に書くことができるかということを最近考えてます。
(でないとあとから読めたものじゃない)
まぁ人に見せるものじゃないので、別に自分が分かればいいのですが。
たとえばdiv という記号を割り算(division)と解釈する人はいるでしょうけれど、僕はそれを直観的でないと感じるのでそうしません。
(いつも手計算の時にはdivergenceの意味で使っているから)
Re: [雑談?]c++の分かりやすいプログラム
ゲームだと確かにバグが発生する部分までの処理が長い(?)
ので単体テストは使いづらいのですかね。
<GRAM様
式を直感的に書くことは
やはり大切なのですね。
こまめに変数にわけたり
関数化したりして
どういう計算をどのように組み合わせているのか
分かりやすいようにしてみようと思います。
ので単体テストは使いづらいのですかね。
<GRAM様
式を直感的に書くことは
やはり大切なのですね。
こまめに変数にわけたり
関数化したりして
どういう計算をどのように組み合わせているのか
分かりやすいようにしてみようと思います。
MLP!MLP!
Re: [雑談?]c++の分かりやすいプログラム
最近は、分かりにくくするために、あえてC++で実装するということをやったりと、かなり邪道に走っています。
楽な実装方法を選択すると、安易に業者変更されたりするので、自衛策としてやっています。
MinGW(C++11) + Boost C++ Libraries、かつPHPで前処理とかやっていると、まず他社でメンテナンスできなくなりますから(できても安価にはならない)。
世知辛い世の中になったものです。
ほとんどのお客さんは、こんなことをする必要はないんですけどね。
楽な実装方法を選択すると、安易に業者変更されたりするので、自衛策としてやっています。
MinGW(C++11) + Boost C++ Libraries、かつPHPで前処理とかやっていると、まず他社でメンテナンスできなくなりますから(できても安価にはならない)。
世知辛い世の中になったものです。
ほとんどのお客さんは、こんなことをする必要はないんですけどね。
Re: [雑談?]c++の分かりやすいプログラム
ずっとゲーム移植の仕事をしてて、きっちりモジュール化してるので最初の一回しか仕事が回ってこず収入が無い、というのは世知辛いと言うんでしょうかね。たかぎ さんが書きました:世知辛い世の中になったものです。
Javaですが、MOVA(i505)時代に移植したソースがずっと使い回されているということをひょんなことから5年後に知りました。
おそらくAndroidにも使い回されているんじゃないかなあ。
Re: [雑談?]c++の分かりやすいプログラム
Suikabaさん、ISLeさん、softyaさん、回答ありがとうございました。
良い設計にはリファクタリングが不可欠で、
リファクタリングにはxUnitが不可欠という思いなのですが、
かくいう私も、仕事では書けないことの方が遥かに多いです。
良い設計にはリファクタリングが不可欠で、
リファクタリングにはxUnitが不可欠という思いなのですが、
かくいう私も、仕事では書けないことの方が遥かに多いです。