キー入力クラスの設計

フォーラム(掲示板)ルール
フォーラム(掲示板)ルールはこちら  ※コードを貼り付ける場合は [code][/code] で囲って下さい。詳しくはこちら
ISLe()

Re: キー入力クラスの設計

#31

投稿記事 by ISLe() » 4年前

入力装置を総括したいなら、入力装置の範疇でするべきでしょう。
コントローラーを巻き込んではいけません。

インプットクラスがコントローラークラスに通知するのは、仮想であっても物理的なキーやボタンが押されたという情報です。
コントローラークラスがアプリケーションに通知するのは、アプリケーションで定義されるイベントやシグナルです。
右へ移動するためのキーやボタンが押された、というのと、プレイヤーを右へ動かす要求がされた、というのは異なるものです。

コントローラーは、あくまでもアプリケーション(内のオブジェクト)をコントロールするのが主目的です。
例えばAIが制御するコントローラーであれば外部装置の入力を必要としません。


コントローラークラスもインプットクラスもCVirtualControllerを継承するようにしてしまいました。
継承というのはis aですから、コントローラーもインプットもCVirtualControllerだということです。
これは設計として分かれていないですよね。

現在のコントローラークラスの実装が入力情報をスルーしているだけのものだから同じものとしてしまっているのではないでしょうか。
そして将来的にも実装で仕様の違いを何とかしよう・何とかできると思っているのではないでしょうか。
それが実装でモノを考えているということなのです。



理想コントローラークラスと書いたとき、コントローラーとはゲームコントローラー、入力装置のことを想定してました。
ゲームパッドではなくゲームコントローラーという呼称のほうが自分の中ではメジャーなもので、気を付けてはいるつもりなのですが、用語の意味が場所によって異なっていることがあるのは申し訳ないです。

ISLe()

Re: キー入力クラスの設計

#32

投稿記事 by ISLe() » 4年前

過去のトピックから読み直してみたのですが、わたしがコントローラークラスに対して総括とか理想とかいう単語を出していますね。
ですが、その単語だけに集約されて、さらに過去のトピックと混ざって、別のモノに置き換わってしまっている印象です。

わたしの投稿には、上記の単語だけでなく、具体的な説明もあるのですが、そちらはまったく意識に残っていないようです。

3D_3Dさんに限らず、日本語で説明したことがまったく見向きもされないというのを、以前からしばしば感じていましたが、わたしの文章はわたしが思っている以上にヒドいのかもしれません。

アバター
Tatu
記事: 440
登録日時: 8年前
住所: 北海道

Re: キー入力クラスの設計

#33

投稿記事 by Tatu » 4年前

前のトピック「C++でのリプレイの実装」に書かれている
http://dixq.net/forum/viewtopic.php?f=3&t=15513
インプット、コントローラー、リプレイについて書いてみました。

インプット(キー入力クラス・ゲームパッドクラス)
使用されるかどうかを問わず、全てのキー、ボタンの情報(No:16の「ネイティブな入力」)を管理(No:18)
ネイティブな入力からステータスへの変換を行う(No:16)
キーコンフィグの影響を受ける(No:16)
変換されたステータスを渡す機能を持つ(No:16)
ステータスの定義はコントローラーで行われている(No:18)

コントローラー
ユーザー操作のステータスを渡す機能を持つ(No:4)
インプットから受け取ったステータスの変換・合成を行う(No:16、No:30)

リプレイ(No:4)
コントローラーを継承
ユーザー操作のステータスを渡す機能については
記録時は元のコントローラーのステータスを取得・記録し、元のステータスをそのまま要求元に返す
再生時は記録を読み出し要求元に返す
というようにする

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#34

投稿記事 by Rittai_3D » 4年前

ISLe()さん、Tatuさん。返信ありがとうございます。

>ISLe()さん
入力装置を総括したいなら、入力装置の範疇でするべきでしょう。
コントローラーを巻き込んではいけません。

インプットクラスがコントローラークラスに通知するのは、仮想であっても物理的なキーやボタンが押されたという情報です。
コントローラークラスがアプリケーションに通知するのは、アプリケーションで定義されるイベントやシグナルです。
右へ移動するためのキーやボタンが押された、というのと、プレイヤーを右へ動かす要求がされた、というのは異なるものです。

コントローラーは、あくまでもアプリケーション(内のオブジェクト)をコントロールするのが主目的です。
例えばAIが制御するコントローラーであれば外部装置の入力を必要としません。
ひょっとして、わたしは今まで勘違いをしていたかもしれませんし、これも勘違いかもしれませんが、コントローラークラス(ゲームパッドではない方)はインターフェースクラスでしょうか?
だとすると、わたしは「コントローラークラスは2つの入力装置からの入力をひとつの入力装置からの入力とみなして、お互いの入力を統合したステータスを返す」ようなものだと思っていました。違うのならば考えなおしてみます。
過去のトピックから読み直してみたのですが、わたしがコントローラークラスに対して総括とか理想とかいう単語を出していますね。
ですが、その単語だけに集約されて、さらに過去のトピックと混ざって、別のモノに置き換わってしまっている印象です。

わたしの投稿には、上記の単語だけでなく、具体的な説明もあるのですが、そちらはまったく意識に残っていないようです。
このトピック内でコントローラーがどのコントローラーを指すのか分からなくなる時があります。
複数の意味を持つコントローラーのせいなのでしょうね。

>Tatuさん
インプット(キー入力クラス・ゲームパッドクラス)
使用されるかどうかを問わず、全てのキー、ボタンの情報(No:16の「ネイティブな入力」)を管理(No:18)
ネイティブな入力からステータスへの変換を行う(No:16)
キーコンフィグの影響を受ける(No:16)
変換されたステータスを渡す機能を持つ(No:16)
ステータスの定義はコントローラーで行われている(No:18)

コントローラー
ユーザー操作のステータスを渡す機能を持つ(No:4)
インプットから受け取ったステータスの変換・合成を行う(No:16、No:30)

リプレイ(No:4)
コントローラーを継承
ユーザー操作のステータスを渡す機能については
記録時は元のコントローラーのステータスを取得・記録し、元のステータスをそのまま要求元に返す
再生時は記録を読み出し要求元に返す
というようにする
前トピックの入力周りの要点をまとめてくださりありがとうございます。
今後このトピックを参考にするであろう方々が、いちいち前トピックに飛ばなくても大まかな流れがつかめると思います。
オフトピック
これで、わたしも混乱せずに流れの把握ができることでしょうw
初心者です

ISLe()

Re: キー入力クラスの設計

#35

投稿記事 by ISLe() » 4年前

このトピックは、良い設計をしたい、という主旨ではなかったのでしょうか。
Tatuさんの書いたように、3D_3Dさん自身がまとめることをずっと期待していたのですが。

インターフェースかどうかは重要なのでしょうか。
まとめも大事ですが、前のスレの話の流れもよく見てください。
入力とコントローラーを分離する、という話題の提供から始まっているのです。
入力とコントローラーを分離する、というのは大前提なのです。

いまは入力装置のコントローラーのことは、ゲームコントローラーと書くようにしています。

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#36

投稿記事 by Rittai_3D » 4年前

ISLe()さん、返信ありがとうございます。
このトピックは、良い設計をしたい、という主旨ではなかったのでしょうか。
Tatuさんの書いたように、3D_3Dさん自身がまとめることをずっと期待していたのですが。
あせりすぎていて、すべきことをしていませんでした。
あせり、更に混乱すると何をすべきなのか分からなくなる悪い癖です。もう少し落ち着いてするべきことを見てみます。
インターフェースかどうかは重要なのでしょうか。
まとめも大事ですが、前のスレの話の流れもよく見てください。
入力とコントローラーを分離する、という話題の提供から始まっているのです。
入力とコントローラーを分離する、というのは大前提なのです。
インターフェースというのは抽象化するという意味で言ったので深い意味はありません。
またコードを書いてみました。以前は、キー入力クラスとゲームパッドクラスが仮想のコントローラークラスを継承していましたが、 CKeyboardInput / CGamepadInput では入力装置基底クラスを継承し、入力をまとめてみました。 CInputDevice は仮想コントローラークラスを継承し、複数の入力装置からの入力をひとつの入力装置からの入力とみなすようにしました。
そして、キー入力で動くプレイヤーのサンプルと適当に動くAIのようなものを作ってみました。
考え方はこれであっているでしょうか。
► スポイラーを表示
初心者です

ISLe()

Re: キー入力クラスの設計

#37

投稿記事 by ISLe() » 4年前

CInputDeviceMgrは複数の入力装置からの入力をひとつにまとめてもなお入力装置だと思いますが。

もはや3D_3Dさんが何をしたいのか分かりません。
あっているかと尋ねられても答えようがありません。


ここでDeviceという単語を使うのは個人的にはお勧めしません。
「入力装置」としたのが良くなかったでしたかね。単に「入力」としたほうが良かったか。
キーボードに複数の十字キーを割り当てるような場合、それぞれの入力装置クラスでいちいちハードウェアのキーの状態を取得してチェックするのは効率が悪いので、現実においての物理的なハードウェアは一箇所で管理したほうが良い。
デバイスドライバの仕様で排他的にしかアクセスできないような場合もありますし。
Deviceという単語はそういうハードウェアリソースにアクセスする部分で使うのが良いと思いますが。

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#38

投稿記事 by Rittai_3D » 4年前

分からない点は、

・キーボード入力クラスやゲームパッド入力クラスで自分で定義した仮想キーコードとDxLib.hで定義されているキーコードの対応表を作ることは良いのか悪いのか。(ゲームパッドで使用している数字は、龍神録プログラミングの館の「キーコンフィグに対応させてみよう」で使用しているような数字です。)
・コントローラークラスで、以前貼ったコードで言う CInputDeviceMgr のインスタンスを作成して良いのか。(以前、コントローラークラスでキー入力クラスのインスタンス化はよくないと言っていた気がしましたので。)
よくないならどこでインスタンス化すれば良いのか。
・キーボード入力クラス、ゲームパッド入力クラスの InputProc() で入力状態の更新をしつつ、自分で定義した仮想キーコードに変換してよいのか。

現在のわたしが疑問に思っている点です。
わたし自身何がしたいかよくわからなくなっています。すこし落ち着いて何がしたいのかよく考えてみます。
ここでDeviceという単語を使うのは個人的にはお勧めしません。
「入力装置」としたのが良くなかったでしたかね。単に「入力」としたほうが良かったか。
キーボードに複数の十字キーを割り当てるような場合、それぞれの入力装置クラスでいちいちハードウェアのキーの状態を取得してチェックするのは効率が悪いので、現実においての物理的なハードウェアは一箇所で管理したほうが良い。
デバイスドライバの仕様で排他的にしかアクセスできないような場合もありますし。
Deviceという単語はそういうハードウェアリソースにアクセスする部分で使うのが良いと思いますが。
なるほど。入力よりは入力装置としたほうが分かりやすいだろう、と考えたことがあだになってしまいました。気をつけます。
初心者です

アバター
usao
記事: 1550
登録日時: 6年前

Re: キー入力クラスの設計

#39

投稿記事 by usao » 4年前

なんというか コード提示が長い ですよね.
皆まで書く必要も無いのではないでしょうか?
例えば,CKeyboardInput で言えば,コードっぽく書くにしても

コード:

class CKeyboardInput : public IBaseInputDevice
{
public:
  virtual void InputProc()
  {
    //キーボードの押下状態を調べて,現在のキーコンフィグ状態に基づき
    //仮想キー押下状態情報を生成して メンバ変数 m_InputState に設定する
    //※ここの実装詳細まではいらないのでは?※
  }

  virtual int GetInputState() const {  return InputState;  }
private:
  int m_InputState;
};
くらいの表記さえあれば,話は可能なように思うのですが,どうなのでしょう?
オフトピック
「設計」ではなく「実装」側の話かと思いますが,
IBaseInputDeviceクラスが
int m_InputState; というメンバ変数を抱えているのは違うかな,という気がします.

ISLe()

Re: キー入力クラスの設計

#40

投稿記事 by ISLe() » 4年前

3D_3D さんが書きました:・キーボード入力クラスやゲームパッド入力クラスで自分で定義した仮想キーコードとDxLib.hで定義されているキーコードの対応表を作ることは良いのか悪いのか。(ゲームパッドで使用している数字は、龍神録プログラミングの館の「キーコンフィグに対応させてみよう」で使用しているような数字です。)
入力クラスで完結することなので、好きなように実装すれば良いと思います。
ただし入力モジュール間の共通化等考慮してください。
3D_3D さんが書きました:・コントローラークラスで、以前貼ったコードで言う CInputDeviceMgr のインスタンスを作成して良いのか。(以前、コントローラークラスでキー入力クラスのインスタンス化はよくないと言っていた気がしましたので。)
よくないならどこでインスタンス化すれば良いのか。
それをすると、コントローラーが入力の実装に依存するので、コントローラーと入力の分離という大前提が崩れます。
既に説明したことですが、将来的に、現実に接続される装置と複数プレイヤーへの対応などのマネージメントが必要になります。
それはコントローラーの役割ではないので、外部からコントローラーモジュールと入力モジュールのアタッチやデタッチができるように考慮しておくべきです。
きちんと分離できていれば新たに考慮することはないとも言えます。
3D_3D さんが書きました:・キーボード入力クラス、ゲームパッド入力クラスの InputProc() で入力状態の更新をしつつ、自分で定義した仮想キーコードに変換してよいのか。
コントローラーに対して必要な出力ができれば、実装はどうでも良いです。
動作に癖が出る可能性は否定できませんが。


わたしには、どうでもいいことで悩んでいるようにしか見えません。
きちんと設計して仕様を決めれば、自ずと決まることばかりではないでしょうか。

前のトピックから、良い設計ということで、たくさんの要件を出してきました。
直前に提示されたコードの問題点を指摘しているだけではないのです。
すべてを満たす方法を考えてください。

ソースコードのコメントに、そのコードを書く意図を書きましょう。
そうすれば堂々巡りになることは少なくなるのではないでしょうか。

アバター
usao
記事: 1550
登録日時: 6年前

Re: キー入力クラスの設計

#41

投稿記事 by usao » 4年前

読み間違えているのかもしれませんが, BUTTON_UP とかは「仮想キー」というやつですよね?
CPlayer::Proc() 内でこの BUTTON_UP とかを調べている,というのが,なんか話が分からない感じです.

簡単な(動作種類が少ない)例として左右移動とジャンプだけができるゲームを考えると,
ゲームシーンにおいてプレイヤキャラクタに要求されるのは
{左に行け,右に行け,ジャンプしろ}の3種(の組み合わせ).
であれば,例えば,

コード:

enum PLAYER_ACTION_REQUEST_FLAGS
{
  GO_LEFT=0x01, GO_RIGHT=0x02, JUMP=0x04
};

void CPlayer::Proc( unsigned int ActionRequestFlags )  //引数は↑のenumのフラグの組み合わせ.(上位がControllerから得て渡す)
{
  ...
}
みたいな形になるのではないでしょうか.
↑は動作要求を引数で受けてますが,提示されているコードの形に合わせれば

コード:

void CPlayer::Proc()
{
  //あたかじめ指定されているControllerから,動作要求情報を取得する
  const unsigned int ActionRequestFlags = m_pAttachedController->GetRequestFlags();  //うまい名前が思いつかないな…
  ...
}
みたいな形でしょうか.

つまり,Controllerが教えてくれるのは, 3種の動作要求が今現在なされているかどうか という情報であって,
仮想的なキーの状態を返すものではない,と.
(仮想キー群の押下状態を出力するのは Input の役目)

ISLe()

Re: キー入力クラスの設計

#42

投稿記事 by ISLe() » 4年前

usaoさんは読み違えてませんよ。

コマンド技とかの複合操作になれば違いははっきりします。
前のトピックに出てたダッシュ操作とか。

連続押しの場合、入力モジュールからコントローラーモジュールに対しては、歩くボタンが連続で押されたという通知です。
コントローラーモジュールからアプリケーションに対しては、『歩け』『走れ』という命令(イベント)が発せられるわけです。
『走れ』はアプリケーションに対して必要なイベントであって、イベントコードは必要ですが、ボタンの仮想コードはなくても良いのです。
もちろん、『走るボタン』というものを入力モジュール側とのやり取り用に用意しても構いませんが。

オプションでダッシュの連続押し受付時間を変更できるとしたら、プレイヤーモジュールでボタンの状態を判定するとリプレイ時に設定が異なるとダッシュしなかったり暴発したりすることになります。
だとしたら、オプションの内容もリプレイに記録するのか、ということになります。
イベントを記録すれば、余計なことを考えなくて済みます。
コントローラーモジュールまでで解決するので、プレイヤーモジュールは、そもそもコマンド技や複合操作が存在するということすら知らずに済みます。
知らずに済むというのはコードが汚染されないということです。
ユーザーの操作が正しく反映されるかどうか、という部分と、画面のキャラクターが正しく振る舞うかどうか、という部分を分離独立してコーディング・デバッグできるわけです。

アバター
usao
記事: 1550
登録日時: 6年前

Re: キー入力クラスの設計

#43

投稿記事 by usao » 4年前

Controllerって,こんな感じで操作対象毎に複数あるってことですよね?

コード:

●項目選択時用Controller(例えばタイトル画面とかで使う)

●キャラクタ操作用Controller
 ├ ユーザ入力で操作用Controller
  ├ AI的なController
  └ リプレイ用Controller
  
●なんかまた別の…
オフトピック
とにかく何かがあって,そいつに「何をさせたいのか,どう動かしたいのか」を要求してくるもの という感じか.
それを表すのに "Controller" という単語は(ゲームパッド的なもの(Input)をどうしても思い浮かべてしまう的な意味で)いまいちなのかも…?
なんだろう,「動作要求者」「意思決定器」「命令側」とでもいうか… ??

ISLe()

Re: キー入力クラスの設計

#44

投稿記事 by ISLe() » 4年前

コントローラーはMVCアーキテクチャのCのことです。
プレイヤーコントローラー以外に、メニューコントローラーなど場面(ビュー)ごとに対応するコントローラーは必要になります。
複数切り替えるだけでなく、コントローラーの共通インターフェースで数珠つなぎにして拡張することもできます。

これらの説明は既出です。

設計が主旨であるはずのトピックで、要件定義すらされないのが問題だと思うのです。
それを回答者がやってしまったら丸投げ、というか設計を軽く見ることを助長すると思うのです。


GUIプログラミングを知っていたら『コントローラー』という単語だけで全部理解できるかとも思うのですが
デザインパターン然り実際のところ単語を知っているだけでは何も通じないのかもしれません。

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#45

投稿記事 by Rittai_3D » 4年前

返信ありがとうございます。返信が遅れてしまって申し訳ありません。
設計が主旨であるはずのトピックで、要件定義すらされないのが問題だと思うのです。
それを回答者がやってしまったら丸投げ、というか設計を軽く見ることを助長すると思うのです。
要件定義は、たとえば

コード:

・キーボードとゲームパッドの入力は統合する
のようなものでしょうか。今まで特に考えずにやってきたのでこの程度でよいのか、根本的に違うのか、全く分かりません。
それをすると、コントローラーが入力の実装に依存するので、コントローラーと入力の分離という大前提が崩れます。
既に説明したことですが、将来的に、現実に接続される装置と複数プレイヤーへの対応などのマネージメントが必要になります。
それはコントローラーの役割ではないので、外部からコントローラーモジュールと入力モジュールのアタッチやデタッチができるように考慮しておくべきです。
きちんと分離できていれば新たに考慮することはないとも言えます。
「外部からコントローラーモジュールと入力モジュールのアタッチやデタッチができるように考慮しておくべきです。」
の部分ですが、コントローラークラスでインスタンス化しないとなると、どこで入力装置からの入力を取得すれば良いのでしょうか?
メインでインスタンス化して、引数に渡す、といった感じでしょうか?

コード:

// 「こんな感じ?」というイメージ
int main( void )
{
  // 入力クラスのインスタンスをメインで
    auto input = new CInput;
    // コントローラークラスに渡す
    auto controller = new CController( input );
    return 0;
}
初心者です

ISLe()

Re: キー入力クラスの設計

#46

投稿記事 by ISLe() » 4年前

「キーボードとゲームパッドの入力は統合する」というのは、それをするために必要な事柄を表していません。
「キーボードとゲームパッドの入力は統合したい」というところが本当だと思いますがそれは『要求』です。

要件定義とは、要求に合わせて行うものです。
要件定義を行うためには、要求をまとめなければいけません。
要求をまとめることを、企画と呼ぶ場合もあります。

要求があいまいということは、何がやりたいのか分かっていない、ということです。

要件定義は、要求を実現するために必要そうなことを洗い出してまとめることです。
実装に違い部分もありますが、矛盾がないかどうかといったところを論理的に検討する作業です。

設計についての書籍やネットの記事、補助ツールなどたくさんあります。
調べてみてはいかがでしょうか。

3D_3D さんが書きました:「外部からコントローラーモジュールと入力モジュールのアタッチやデタッチができるように考慮しておくべきです。」
の部分ですが、コントローラークラスでインスタンス化しないとなると、どこで入力装置からの入力を取得すれば良いのでしょうか?
メインでインスタンス化して、引数に渡す、といった感じでしょうか?
これまで何回も書いてますが、コントローラークラスのコントローラーというのは入力装置のことではありません。
現実の周辺機器は環境依存のものなので、それを管理するモジュールは当然分離されるべきです。
コントローラーは常に抽象化された対象を扱います。

例えば、新たにゲームパッドが接続されたことを検出するのは、いままで話題になっていない第三のモジュールです。
その装置に対応するインプットモジュールを具体化し、コントローラーモジュールにアタッチします。
コントローラーモジュールは、新たにアタッチされたインプットモジュールを一定のルールでオブジェクトの操作に割り当てます。
どのプレイヤーの操作に割り当てるか指定してアタッチする形態もあるでしょう。それは設計次第です。

これまで話題にならなかったのは必要なかったからですね。
コントローラーの中で具体化するのは適当でないということだけは書きましたけど。

必要ないといっても、やらなくて良いこと、あるいはやってはいけないことをやってしまうのは後に面倒を残すだけです。
予測で手を付けるな、というYAGNIの原則というのがありますが、備えておかなくても良いとは言ってないと思います。

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#47

投稿記事 by Rittai_3D » 4年前

返信ありがとうございます。
要求があいまいということは、何がやりたいのか分かっていない、ということです。
もともと、小さいサンプルで書いていたものなので、やりたいことがあやふやというのもあり、手間取りました。
考えたのですが、
・プレイヤーはキーコンフィグを気にしない -> 直接のキーコードは自分で定義した仮想キーコードに変換する。
・リプレイ、キー入力の入力は区別しない -> キー入力なら上と同様、リプレイなら保存されているキーコードを渡す
・キーボードとゲームパッドの入力は統合する -> 複数の入力装置は、ひとつの入力装置からの入力とみなす。
となりました。もうすこし考えてみます。

また、入力装置からの入力を変換したステータスはどのように渡せばよいのでしょうか。
インターフェイスを介して取得するのでしょうか。
初心者です

ISLe()

Re: キー入力クラスの設計

#48

投稿記事 by ISLe() » 4年前

3D_3D さんが書きました:また、入力装置からの入力を変換したステータスはどのように渡せばよいのでしょうか。
インターフェイスを介して取得するのでしょうか。
入力装置(インプット)側とのやり取り、
アプリケーション側とのやり取り、
コントローラーモジュールはそのどちらも抽象化します。

わたしが以前Javaで書いたサンプルコードは、インプットとコントローラーの境界を示すものであって、それらの形態を決定付けるものではありません。
より良い設計というのなら、要求に対して具体的な提案とともにインプットやコントローラーの仕様を練る必要があります。

コントローラーもインプットも、それ自体がインターフェースとなります。
リプレイのトピックで書いたように、派生させて組み合わせて使うことを考慮してます。
クラスにする、という時点でそれは備えとしてあるべきですし、そして、実際にそれをするのは必要になったときです。

ISLe()

Re: キー入力クラスの設計

#49

投稿記事 by ISLe() » 4年前

ISLe() さんが書きました:入力装置(インプット)側とのやり取り、
アプリケーション側とのやり取り、
コントローラーモジュールはそのどちらも抽象化します。
そして、その2つは区別されなければいけません。

Rittai_3D
記事: 521
登録日時: 6年前

Re: キー入力クラスの設計

#50

投稿記事 by Rittai_3D » 4年前

なんとなくですがわかってきた気がします。

前回のリプレイのトピックからずいぶんと長くなってしまいました。
このトピックがなければ仕様策定や設計の大切さや大変さを分からなかったと思います。

個人的な理由もあり、解決とさせていただきます。回答してくださった皆様、本当にありがとうございました。
初心者です

閉鎖

“C言語何でも質問掲示板” へ戻る