C++ではなくあえてC言語を使用するメリット

[02giri]

いつもお世話になっています。

私は現在独学でC++の勉強を進めているものです。
件名の通り、(Cの上位互換言語である)C++ではなくあえてC言語を使うメリットについて疑問に思い、
トピックを立てさせていただきました。

私はC++を使用して三目並べやバブルソートなどの簡単な並べ替えのプログラムを作成してきましたが、
今の所、C言語を使用する必要が出てきたことはありません。
(もちろんもっとも効率の良い書き方を目指しているわけではなく、最低限狙い通りの動作をさせる上では必要なかった、
という意味です)

しかし、こちらの掲示板を拝見していると、
質問される方の内、かなりの方のソースコードがCを使用して書かれているように思います。
(学生の方も多いようなので、先生や教授から使う言語を指定されているだけかもしれませんが)

CとC++の違いを自分で調べたところ、
Cが好まれる場面はプログラムの動作環境(OSやメモリ数など)に制限がある場合が多いように思われたのですが、
それ以外にあえてCを使用するメリットはどういったことが考えられるでしょうか。

ご意見をいただけると嬉しいです。

[softya（ソフト屋)]

それは、C++の文法がC言語に比べて遥かに複雑であると言う事が原因だと思います。
ちゃんとＣ++を使うことは難しいですから。クラスの継承とかクラクラきませんでしたか？

[02giri]

>> softya様
ご意見ありがとうございます！

それは、C++の文法がC言語に比べて遥かに複雑であると言う事が原因だと思います。
ちゃんとＣ++を使うことは難しいですから。クラスの継承とかクラクラきませんでしたか？

なるほど。確かに私自身まだ継承がうまく使いこなせていないと思います。
三目並べの際もファイルを分ける際に多重継承を使用しなければならず、かなり混乱しました…。

ということはC++の文法を学ぶ前の段階で、Cを使われている(学ばれている)方が多いということなんでしょうか。

[softya（ソフト屋)]

場合によってはC++さえ必要ないと思います。
複雑な文法を覚えることは、果たしてゲーム開発に必要な事でしょうか？
言語は道具なので、必要な時必要な道具を覚えれば良いだけです。

C++はゲームに必須と言う考えが既に道具である言語の役割をよく考えていないと言う状況を表しているのかもしれません。
と言うことで仕事で必要な人、環境上Ｃ++を必要としている人、便利な道具を苦労してでも覚えて後で楽したい人が覚えるのがＣ++です。

【補足】
>三目並べの際もファイルを分ける際に多重継承

この多重継承の必要な状況はとんと想像出来ません。良かったらコードを見せてもらえると嬉しいです。

[usao]

車で行けばいいのになんで自転車なの？
→自転車で行ける距離だったので
→現在自転車には乗れるけど車の運転はできないので
→車なら早いだろうけど自転車でも頑張れば物理的に行けないわけではないし

現在自転車に乗っているひとが将来自動車免許を取得して乗り回すつもりがあるのかないのかは個人次第．

…という感じじゃないでしょうか．

[softya（ソフト屋)]

その例えで行くと、東京だと車を持つ事は必要ないって状況ですよね。電車が縦横無尽に走ってますので。
電車(C言語)で事足りるのになぜ車(C++)が必要なの？
って感じでしょうか。どうです。答えれれそうですか？

【補足】
意地悪じゃなくて、意味を考えて欲しいんです。
なぜ、Ｃ++を学ぶのか。自分は何がしたかったのか。
よく手段と目的を間違える人がいるので気になりました。
ゲームを作りたかったはずなのに、いつの間にかＣ++を覚えることが目標になっている人がいるもので。

[02giri]

>>softya様

場合によってはC++さえ必要ないと思います。
複雑な文法を覚えることは、果たしてゲーム開発に必要な事でしょうか？
言語は道具なので、必要な時必要な道具を覚えれば良いだけです。

C++はゲームに必須と言う考えが既に道具である言語の役割をよく考えていないと言う状況を表しているのかもしれません。
と言うことで仕事で必要な人、環境上Ｃ++を必要としている人、便利な道具を苦労してでも覚えて後で楽したい人が覚えるのがＣ++です。

ありがとうございます。とてもわかりやすくイメージできました。
私はC++を勉強する際に、C++がCの上位互換ならC++をやればいいだろうとの安易な考えからCを飛ばして勉強を始めてしまったのですが、
その選択も今思えば適切ではなかったのかもしれませんね。


>この多重継承の必要な状況はとんと想像出来ません。良かったらコードを見せてもらえると嬉しいです。

ちょっと長くなってしまうので、一部抜粋してみました。
構成としては、ゲーム全体を対人戦(vs)モードとcpuモードに分けたのですが、
それぞれ重複する部分が多かったので、control.h→stage.h→vs_mode.h(cpu_mode.h)という形で
以下のようにファイル分けを行なったのです。

コード:

//control.h
#ifndef DEF_CONTROL_H
#define DEF_CONTROL_H
#include <ctime>


class mgr{
	double rule;			//ルールを確認するかどうかの選択時に使用。
	double mode;			//モード選択時に使用
	double lv;				//cpuの強さ選択時に使用

public:
	mgr();
	
	void show_rule();		//ゲームのルール(値のルールではない)を表示する

	void set_rule(double);
	double get_rule();

	void set_mode(double);
	double get_mode();

	void set_lv(double);
	double get_lv();

};

#endif

コード:

//stage.h
#ifndef DEF_STAGE_H
#define DEF_STAGE_H
#include "control.h"

class stage : virtual public mgr {
public:
	stage();

	char place[10];			//石を置く場所
	int stone[10];			//石を格納

	int stone_temp;			//入力された石の場所を一時的に格納
	
	void check_place();		//そこに石が置けるかどうかを判定し、間違っていたら修正させる(返り値なし)
	void show_place();		//現在のステージの状況を表示する
	void show_result();		//最終結果を表示する
	int check_end1();		//プレイヤー1の勝利フラグを判定
	int check_end2();		//プレイヤー2の勝利フラグを判定
	
};

#endif

コード:

//vs_mode.h
#ifndef DEF_VS_MODE_H
#define DEF_VS_MODE_H
#include "stage.h"

class vs_mode : virtual public stage{

	int turn;				//現在のターン数

public:

	void set_turn();	
	int get_turn();			

	int vs_mode_main();		//vs_modeのメイン関数。三目並べそのものの部分。
};

#endif

コード:

//cpu_mode.h
#ifndef DEF_CPU_MODE_H
#define DEF_CPU_MODE_H
#include "stage.h"

class cpu_mode : virtual public stage{
	int turn;				//現在のターン数
	
public:

	int cpu_mode_main();

	int message;			//time(NULL)によって得た乱数を格納し、EXモードのメッセ―ジ表示に使用

	void set_turn();		//turnを入力
	int get_turn();			//turnを出力

	int stop_reach();		//プレイヤーのリーチに反応してビンゴを阻止
	int make_bingo();		//CPUにリーチができていたら優先してビンゴにする

	int easy_cpu();			//弱いCPUのAI
	int normal_cpu();		//普通のCPUのAI
	int hard_cpu();			//強いCPUのAI
	int ex_cpu();			//EXモードのCPUのAI

};

#endif

実はもともと一つのmain.cppにすべてを詰め込んで書いていたので継承は全く使っていなかったのですが、
ファイル分割の勉強のためにあえてオブジェクトごとに分割して継承させてみたのです。
長くなってしまうのでとりあえず.hファイルだけ載せてみたのですが、イマイチ継承の必要性がわかりづらいですね。。。
関数の定義部分で基底クラスのメンバを使用したかったので継承させたのですが。

改めてみるといろいろ残念で申し訳ないです。
(我ながら関数の型とかバラバラですね...)

[usao]

>電車(C言語)で事足りるのになぜ車(C++)が必要なの？
（えーと，私への突っ込みなんですよね？これ．）
このたとえで頑張ろうとしたのですが，
電車がまともに走ってない地方に住んでいることもあり，うまく書けませんでした（泣）

質問者様の質問が　何でわざわざCを使うのか？　なのに対して
何でわざわざC++を使うのか？　と逆のことを問われている気がしますが…　何を言えばいいんでしょうかね．

私はゲームを作ってはいないのですが，C++を使う理由は，個人的には
「機能面で　C++ ⊃　C (記号これで合ってるかな？)　だから」でしょう．
C++をまがりなりにも日常的に使っている身としては，環境的な理由もないのに「Ｃだけで」とか言われたら正直かなりきついです．
簡単に言えば，C++で書く方が圧倒的にコーディングが楽．
（あとは　個人的に　C++という言語が好きかも）

だから，なぜC++を学ぶのか？といったら
　学習の苦労　<< その後の(ゲーム開発なりなんなりでの)コーディングをCだけでやり続ける苦労
と見積もるから，でしょう．（より便利な手段を手に入れるため，ですかね．）
この不等号を逆向きに感じるならば，C++に手を付けなければよいだけです．

以上で回答になりますでしょうか？

[softya（ソフト屋)]

usaoさん、勘違いさせてすいません。 02giriさん宛のつもりでした。

[02giri]

>>usao様
ご意見ありがとうございます！

車で行けばいいのになんで自転車なの？
→自転車で行ける距離だったので
→現在自転車には乗れるけど車の運転はできないので
→車なら早いだろうけど自転車でも頑張れば物理的に行けないわけではないし

現在自転車に乗っているひとが将来自動車免許を取得して乗り回すつもりがあるのかないのかは個人次第．

…という感じじゃないでしょうか．

こちらもとてもイメージしやすいです。
Cで事足りるのならば、あえてC++を使う必要はないだろう、ということですよね。
一般的にはCよりC++の方が複雑ですし。

>>softya様

その例えで行くと、東京だと車を持つ事は必要ないって状況ですよね。電車が縦横無尽に走ってますので。
電車(C言語)で事足りるのになぜ車(C++)が必要なの？
って感じでしょうか。どうです。答えれれそうですか？

むむ、それもそうですね。
確かに電車(C言語)が行きたいところに通じていれば、わざわざ車(C++)に乗る必要はない。

ですが、実際問題C++ではかけてもC言語で書けない(書けてもC++より煩わしい)という場面は存在しますよね。
んー。そういうことなんでしょうかね。

例えに直すと、
電車だと最寄駅には行けても目的地までは歩かなければならない。(それも場合によっては数十分)
車に乗れれば、最寄駅ではなく目的地に直接行ける。ただ、駐車場があるかはわからない。

という感じでしょうか。こうして考えてみるとなかなか奥深いですね。

[02giri]

[補足]
>>softya様
すみません。
例え話の方に頭が行き過ぎて、本質的な問いに答えられていませんでした。

【補足】
意地悪じゃなくて、意味を考えて欲しいんです。
なぜ、Ｃ++を学ぶのか。自分は何がしたかったのか。
よく手段と目的を間違える人がいるので気になりました。
ゲームを作りたかったはずなのに、いつの間にかＣ++を覚えることが目標になっている人がいるもので。

私にとっての「目的」は「モノを作ること」です。
現在は勉強の途中ということもあり、とっつきやすく完成形のイメージがしやすいゲームを目標として
プログラムを組んでいますが、将来的には開発職に就きたいと考えていますので、
その意味ではゲームのみならずさまざまな「モノ」を作れるようになる必要があると思います。

softya様のおっしゃる通り、C++を学ぶ(身につける)ことは手段であって目標ではないですよね。
確かに、何かを作るときに見知らぬ関数が出てきて、それを調べているうちに
「あれ？これで何がしたかったんだっけ？」となってしまうことがたまにあるので、
手段と目的を取り違えることの無いように、気を付けたいと思います。

[softya（ソフト屋)]

ソースコードは後で見るので、すいません時間下さい。

[usao]

>usaoさん、勘違いさせてすいません。 02giriさん宛のつもりでした。
なんということでしょう．


>将来的には開発職に就きたいと考えていますので、
であれば，「言語の習得」というのも目的のひとつと言えますね．

オフトピック

電車と車の比較で言えば，ルート形状の複雑さというのもありますね．
鉄道網<<道路網　だと思うので，素直なルート（地図上でのルート形状が直感に近い）を辿れるのは車．

[02giri]

>>softya様

ソースコードは後で見るので、すいません時間下さい。

いえいえ、こちらこそ手間をおかけしてすみません。
なお、本質的な動作は以前日記の方でsoftya様にご覧いただいたものと変わりませんので、
ご了承ください。

>>usao様

ありがとうございました。softya様は私への質問を意図されていたようですが、
usao様の意見を知ることができて参考になりました！

オフトピック

電車と車の比較で言えば，ルート形状の複雑さというのもありますね．
鉄道網<<道路網　だと思うので，素直なルート（地図上でのルート形状が直感に近い）を辿れるのは車．

なるほど。
ということはCとC++に直すと、目的のプログラムを作るのに最短のソースコードで書ける方を
選択すればよい、というような感じでしょうか。

[softya（ソフト屋)]

ちょっとだけ見て気づいたこと。多重継承していないです。
あとで、ちゃんと見ます。

「多重継承」
http://wisdom.sakura.ne.jp/programming/cpp/cpp25.html
みせてもらったコードの場合は、上記サイトにも有る単一継承の多段階です。

[usao]

>目的のプログラムを作るのに最短のソースコードで書ける
それもありますし，書いたコードを見て何が書いてあるかが直感的にわかるかどうか，という違いもあるかもしれません．

例えば　３次元ベクトル A,B,C,D,E　について

コード:

C = (A*B) * C + ( D - E/5.0 );  //※ベクトル間の*はここでは内積だとする

みたいな計算をしている箇所があったとして，C言語でベクトル用の型とその演算のための関数群を

コード:

typedef struct Vec3D { double v[3]; } Vec3D;

Vec3D AddVec( const Vec3D *lhs, const Vec3D *rhs );  //ベクトル加算
double InnerProduct( const Vec3D *lhs, const Vec3D *rhs );  //内積
...  //必要な関数群がたくさん

みたく用意していた場合，上式の計算を行っている箇所のコードを見て，それが上式の内容だと即座にわかるだろうか？
あとで見返したとき，コーディングされている事柄を把握するのは多分結構大変．
それに対して，C++の機能を用いれば，計算箇所のコードはまさに上式のままで書ける！
計算コードを書くのも楽だし，読むのもやはり楽．
（人から渡されたコードが↑のC言語バージョンみたいなのだったらかなり苦々しい顔をしますねｗ）

[02giri]

>>softya様

ちょっとだけ見て気づいたこと。多重継承していないです。
あとで、ちゃんと見ます。

「多重継承」
http://wisdom.sakura.ne.jp/programming/cpp/cpp25.html
みせてもらったコードの場合は、上記サイトにも有る単一継承の多段階です。

リンク先を拝見しました。私のコードの場合は

control -> stage -> vs_mode
control -> stage -> cpu_mode

という形で継承をしているので、これはリンク先で言うところの「多段階継承」(直列的継承)にあたる、ということのようですね。
その下を見ると、

>上の場合は直列的継承ですが
>一つの派生クラスが複数の基本クラスを持つ並列的継承も可能です
>このような、一つのクラスが複数のクラスを継承することを多重継承と呼びます
(リンク先より引用)

とあるので、直列的継承(一つのクラスに対し直接継承しているクラスが一つ)は多段階継承にあたり、
並列的継承(一つのクラスに対し、直接継承しているクラスが複数)の場合が多重継承と呼ばれる、
という解釈でよろしいでしょうか。

>>usao様

な、なるほど。確かに下のソースはどういう動作をするか全然イメージできないです。
というか可読性も低そうですし、実現したい内容に対してコードが冗長な感じがしますね。
上のコードはコメントが一行あれば動作をイメージできます。

となると、ますますC言語を使うメリットがなくなっていくような…笑
でもきっとこの逆にあたる場面も存在するということなんでしょうね。

[beatle]

となると、ますますC言語を使うメリットがなくなっていくような…笑
でもきっとこの逆にあたる場面も存在するということなんでしょうね。

なんか勘違いしてませんか？
C++はCで書けることすべてを書けますので、Cでは簡単でC++では難しくなる例は有りません。
（一部細かい例外はありますが、本質的なところではないので、C++はCを含むと言いました。）

ただ、C++っぽく書くというのとCっぽく書くというのは区別できますので、
C++っぽく書くよりCっぽく書く方が読みやすい、理解しやすいという場面はあります。

[softya（ソフト屋)]

ちゃんとＣ++を使いこなすとC = (A*B) * C + ( D - E/5.0 ); なんてのが書けますが、最初は書けないと思います。
あとC++はテクニカルに走ると余計わからない事があります。
C = (A*B) * C + ( D - E/5.0 ); などの演算子オーバーロードだけで、通常の手続き部分までコード書くと分けわかんない事になる場面はありえます。

　↓　こういう計算式に関しては、このやり方が分かりやすいと思います。
C = (A*B) * C + ( D - E/5.0 ); //※ベクトル間の*はここでは内積だとする

【補足】
つまり、適材適所って事ですね。
時に酷いクラスの使い方は、Ｃ言語よりコード解読を困難にする事が多々あります。
Ｃ言語でも酷いのは酷いですけどね。

【追記】
忘れてた、ここに書きます。

>とあるので、直列的継承(一つのクラスに対し直接継承しているクラスが一つ)は多段階継承にあたり、
>並列的継承(一つのクラスに対し、直接継承しているクラスが複数)の場合が多重継承と呼ばれる、
>という解釈でよろしいでしょうか。

親が２つ以上あれば多重継承という単純判断で良いかなと。

[softya（ソフト屋)]

ざっと見ましたが、余り良くないです。
継承が、そもそもファイルを分割するという意図にしか使われていませんでの分割前よりも複雑になっているだけです。
傾向として結合度大で、カプセル度小です。
例えば三目並べのルール度外視になりますが4x4にマス目に変更した時は影響は色んな所に及びませんか？
あるいは、vs_modeとcpu_modeの両方を直す事態に・・・。と思われるのです。
変数がグローバル変数として使いまわされているも同然っても良くないです。

オブジェクトが特に目的もなく決められているのも気になります。
ボードはオブジェクトですが、ＯＸもオブジェクト（盤の状態だからいらないかな）で、思考ルーチンもオブジェクトで、プレーヤーもオブジェクトと、あと判定やら制御やらもオブジェクトかと思います。
と言うような基礎的なクラスが幾つか出来上がるはずなのです。

[(´・@・)]

　恐らくここの掲示板の質問でCが多いのは、このサイトの講座がCで書かれているからでは？
無料で情報が入るのがCの最大のメリットかもしれませんね。
　C++のちゃんとしたゲームプログラムのサンプルコードは探しても殆どないと思いますし、
Cの質問に答えられる人に比べて、C++の質問に答えられる人は少ないと思います。

　逆に言えば、ちゃんとしたC++の本を買って勉強出来るならCでゲームプログラムをする必要は特に無いです。

　標準ライブラリを使うだけでも生産性は何倍も変わりますし、ポリモーフィズムを理解してswitch文を置き換えるとか出来るだけでもソースの可読性や拡張性や保守性が格段に上がります。
戻り値をintからboolに変えるだけで、ソースが何を表すかが明確になります。
#ifndefは重複する可能性がありえるから #pragma onceを使う。
　ポインタにしてもスマートポインタを使えばメモリリークの危険性は格段に下げる事が出来ます。
　Cを長く使うと、良くない癖が付いてC++に移る際に障害になったりする事もあるとか。

　ちなみに、個人的にはCよりC++よりC#の方が好きです。
　勉強目的ならC#でフォームアプリケーション作る方が捗ると思うよ。

[softya（ソフト屋)]

>> 02giriさん他、C/C++で悩んでここを読まれる人に

私としては、C++の入門書を理解が出来る人はC++を使うべきだと思います。
どうしてもC++を難しいと感じたり、ゲームを作りたいと言うこと優先するのなら学習時間が長くなるC++で無くてもＣ言語で良いと言う選択肢がある事は覚えておいて欲しいです。　

Ｃ言語：Ｃ++に比べて学習時間が短い。ＤＸライブラリを使えば開発上のデメリットは少ない。C++よりは開発効率は悪いが大規模ゲームが作れないわけではない。
C++：Ｃ言語に比べて覚えることが多く学習時間が長い。使いこなせるレベルが上がればＣ言語よりも開発効率は高い。

[h2so5]

#ifndefは重複する可能性がありえるから #pragma onceを使う。

#pragma once はコンパイラの拡張であってC++の機能ではないですよ。

[ISLe]

C++には便利なライブラリがたくさんありますから、それらを活用できるならC++が便利だと思います。
そういう意味では02giriさんの(日記に書かれてた)三目並べのプログラムはC++をまったく活かせていないと思います。

#ここでのゲームはビデオゲームを指しますが
C++の汎用ライブラリはゲームプログラムにおいて不都合が多いので、内部的にはCっぽく実装したほうが良い場面が多いです。
また、ハードウェアに近い部分は自分でフレームワークを作る必要に迫られることが少なくないです。
C++でゲームプログラミングを学習するとなると、プログラミングより設計の比重がはるかに大きくなってしまい、面白くないと思います。

[ただの屍のようだ]

C言語の手続きスタイル、C++のジェネリックスタイル、Lispの関数型スタイル、Javaのオブジェクトスタイル。。。
さらにスクリプト言語の正規表現と検索エンジン、アルゴリズム、ゲームプログラミングにおいての物理エンジンとCG、人工知能などなど
かけだしな私がやろうとしていることをさらっと挙げてみました。もちろん何十年というスケジュールで学習していくつもりです。
ゲーム作りたいだけなら最低限の文法＋環境＋ライブラリで十分です。なんなら人のソースをコピーして少しいじるだけでもできます。
質問者さんのやろうとしていることを、惑わされずによく考えてほしい、それから必要なことだけ、じっくりやればいいです。

[02giri]

>>beatle様
ご意見ありがとうございます。

なんか勘違いしてませんか？
C++はCで書けることすべてを書けますので、Cでは簡単でC++では難しくなる例は有りません。
（一部細かい例外はありますが、本質的なところではないので、C++はCを含むと言いました。）

ただ、C++っぽく書くというのとCっぽく書くというのは区別できますので、
C++っぽく書くよりCっぽく書く方が読みやすい、理解しやすいという場面はあります。

ということは、極端な話C++を十分使いこなせるようであればC言語を使った方が良い場面は、
プログラムの動作環境面で問題がない限りはあまりないということなのでしょうか。
私の当初の認識でもC++はC言語の上位互換言語(Cの機能を内包している)だと思っていたのですが、
こちらの掲示板を拝見していてC言語を使われている方が多いように感じられましたので、
このようなトピックを立てさせていただいた次第です。

[02giri]

>>softya様
ご意見・ご指摘感謝です。

ざっと見ましたが、余り良くないです。
継承が、そもそもファイルを分割するという意図にしか使われていませんでの分割前よりも複雑になっているだけです。
傾向として結合度大で、カプセル度小です。
例えば三目並べのルール度外視になりますが4x4にマス目に変更した時は影響は色んな所に及びませんか？
あるいは、vs_modeとcpu_modeの両方を直す事態に・・・。と思われるのです。
変数がグローバル変数として使いまわされているも同然っても良くないです。

オブジェクトが特に目的もなく決められているのも気になります。
ボードはオブジェクトですが、ＯＸもオブジェクト（盤の状態だからいらないかな）で、思考ルーチンもオブジェクトで、プレーヤーもオブジェクトと、あと判定やら制御やらもオブジェクトかと思います。
と言うような基礎的なクラスが幾つか出来上がるはずなのです。

こちらのソースコードは、一度一つのファイルに詰め込んで作られたものであることはお伝えしましたが、
それを元に(というか半ば強引に)ろくに全体像をイメージせずにファイル分割を断行した結果、
このようなソースコードになってしまいました。
ご指摘の通り、仕様変更が加わった際の修正箇所について全く考慮していませんでしたので、
どこか一か所の修正のために全体を弄る必要が出てきてしまい、C++を使って記述している利点がほとんど失われてしまいました。
ほとんどのprivateメンバ変数にget()とset()を作っているのもカプセル化の意味を無くす要因ですよね。

いただいたアドバイスから、もう一度ファイル分割を設計から見直してみようと思います！

[02giri]

>> (´・@・)様

　C++のちゃんとしたゲームプログラムのサンプルコードは探しても殆どないと思いますし、
Cの質問に答えられる人に比べて、C++の質問に答えられる人は少ないと思います。

　逆に言えば、ちゃんとしたC++の本を買って勉強出来るならCでゲームプログラムをする必要は特に無いです。

端的なご意見をありがとうございます。私は書籍も並行して勉強に活用しておりますので、
じっくり理解を深めながらC++に取り組んでいこうと思います。


>> softya様

私としては、C++の入門書を理解が出来る人はC++を使うべきだと思います。
どうしてもC++を難しいと感じたり、ゲームを作りたいと言うこと優先するのなら学習時間が長くなるC++で無くてもＣ言語で良いと言う選択肢がある事は覚えておいて欲しいです。　

アドバイスをいただきました通り、私はまだ継承やクラス、オブジェクトの活用がうまくできていないので、
せっかくC++で記述している利点がほとんど得られていないと思っています。
その意味でまだ入門書を理解できているとは思っていませんが、理屈は理解できているつもりなので、
以前日記の方でアドバイスをいただきました通り、サンプルプログラムを実際に組んでみて、
本当に「理解」できるように頑張ってみようと思います！

>> h2so5様

#pragma once はコンパイラの拡張であってC++の機能ではないですよ。

ご意見ありがとうございます。
#pragma onceも#ifndefも二重インクルード防止…のための機能でしたよね。
正直まだ違いが理解できていませんので、改めてゲームプログラミングの館にて勉強させていただきます！

[02giri]

>> ISLe様

C++には便利なライブラリがたくさんありますから、それらを活用できるならC++が便利だと思います。
そういう意味では02giriさんの(日記に書かれてた)三目並べのプログラムはC++をまったく活かせていないと思います。

#ここでのゲームはビデオゲームを指しますが
C++の汎用ライブラリはゲームプログラムにおいて不都合が多いので、内部的にはCっぽく実装したほうが良い場面が多いです。
また、ハードウェアに近い部分は自分でフレームワークを作る必要に迫られることが少なくないです。
C++でゲームプログラミングを学習するとなると、プログラミングより設計の比重がはるかに大きくなってしまい、面白くないと思います。

ご意見ありがとうございます！
C++の利点としては、継承、カプセル化、ポリモーフィズムなどが考えられますよね。
正直なところ、私はCを飛ばしていきなりC++の勉強に入ったものですから、
勉強の過程でCを使用して記述してあるソースコードを度々参考にしたこともあり、
そのせいもあってC言語よりのソースコードになってしまっているのだと思います。

>プログラミングより設計の比重がはるかに大きくなってしまい、面白くない

なるほど。私はこれまで設計が必要になるほど大きな(C++らしい)プログラムを作った経験がないので、
まだその感覚は味わっていません。
しかし、C++を学ぶ上では設計も避けては通れない道だと思っていますので、
あえてこのままC++で進めて行こうと思います。
その上でCとC++どちらがベターなのか見極められる程度の力が身につくように精進しようと思います！

>> ただの屍のようだ様

ゲーム作りたいだけなら最低限の文法＋環境＋ライブラリで十分です。なんなら人のソースをコピーして少しいじるだけでもできます。
質問者さんのやろうとしていることを、惑わされずによく考えてほしい、それから必要なことだけ、じっくりやればいいです。

ご意見ありがとうございます。
目的をよく考えてから手段を選べばよい、ということですよね。
私の場合は言語の習得自体も目的に含まれている部分がありますので、
C++の特徴、あるいはオブジェクト指向言語自体の特徴を踏まえながら、
じっくり勉強を進めて行こうと思います。

[02giri]

ご意見をいただきました皆様、本当にありがとうございました！
多くの方からご意見をいただきましたおかげで、とても具体的に疑問を解消することができました。
私なりに結論を得ることができましたので、このトピックは解決とさせていただきます。


また、トピックから少し逸れてしまう形にはなってしまいましたが、
三目並べのソースコードにつきましてご意見をくださいましたsoftya様とISle様、
とても勉強になりました。こちらに関しましてもありがとうございます。

現在就職活動と並行してのプログラミング勉強となっておりますので、
少し時間がかかってしまうかもしれませんが、改めてファイル分割や継承を使用した
プログラムを自分なりに設計して作ってみるつもりですので、
その際はまたアドバイスをいただければ幸いです。

[追記]
なお、本トピックが解決に至りました経緯は自明のものと思いますし、
結論も個人個人によって異なってくると思いますので、あえて書く必要はないと判断いたしましたが、
本トピックの場合でも私なりの結論を明記したほうが良いでしょうか・・・？

もし、その必要があれば追記させていただこうと思いますので、ご指摘いただければ嬉しいです。

[h2so5]

なお、本トピックが解決に至りました経緯は自明のものと思いますし、
結論も個人個人によって異なってくると思いますので、あえて書く必要はないと判断いたしましたが、
本トピックの場合でも私なりの結論を明記したほうが良いでしょうか・・・？

もし、その必要があれば追記させていただこうと思いますので、ご指摘いただければ嬉しいです。

解決方法の質問ではないので具体的な結論は不要です。