結論から言うと、NBAD 現 FAB 銀行は一般利用者向けに口座残高を取得できる公式 API を公開していません。そのため、ログインを伴わずにスクリプトや C 言語のプログラムから直接残高を取得する方法は基本的にありません。 Web 自動化でログイン画面を操作する方法も技術的には可能ですが、CAPTCHA や多要素認証、利用規約違反のリスクが高く、口座凍結などの実害が出る可能性があるためおすすめできません。 実運用としては、公式アプリや公式サイトでの確認を前提にするか、どうしても自動化の参考情報が欲しい場合は、ログインを伴わない範囲で公開情報の挙動を調べる程度に留めるのが現実的です。例えば F...

御報告ありがとうございます。
うぐぐ・・致命的な不具合ですね・・。

ノーマルクリアラーさん

ご意見ありがとうございます。
仰る通りの仕様が本来の仕様です。
現在ver0.9で全実装完了しておりませんで、特にプラクティスはまだ未完成状態です。
ver1.0公開までには対応したいと思っております。

ノーマルでやりましたが、難しいですね。

このコードではダイアログ表示と処理がすでに完結しているので、私は gtk_main() を呼ぶ必要はないと考えます。gtk_main() はイベント待ちループに入るため、終了条件がないとプロセスは戻りません。ウィンドウを常駐させない用途なら gtk_main() を削除するか、ウィジェットの destroy シグナルで gtk_main_quit() を呼ぶのが正しい使い方です。

私の理解では、shared object に quadmath を static リンクすること自体が前提として非対応です。libquadmath は PIC 前提の完全 static 利用を想定しておらず、-static と -shared を同時に使うとそのエラーになります。実運用では実行ファイル側を static 化するか、対象環境に quadmath を同梱して rpath で解決するのが現実的だと思います。

私なら DirectXTex は DLL ランタイム前提で使うものだと割り切りますし、RuntimeLibrary の不一致はその設計差によるものだと思っています。d3dx11 は旧 DirectX SDK 依存で今後の利用は勧められないので、現在は DirectXTex と自前ローダを使うのが無難です。DX11 では補助ライブラリに頼らず、API設計に慣れる方向が正解だと感じます。

私ならボス戦と会話は状態管理で分けます。ボス登場時に「会話フラグ」を立てて会話処理を呼び、会話終了後に戦闘開始、HPが0になったら戦闘終了フラグを立てて戦闘後会話に移ります。ステートマシン的に処理を整理すると、コードがばらばらでも順序通りに進めやすくなります。

Dx11では画面そのものを直接ロックすることはできないので、私は描画先をSwapChainではなくRenderTargetTextureにします。そのテクスチャをCopyResourceでStagingリソースへコピーすれば、CPU側で読み出せてUIやカーソルも含めずに制御できます。探すなら「DX11 Render Target to Texture」「Staging Texture CopyResource」で調べると情報が出てきます。

原因は、ヘッダ同士が相互に include されている状態で、さらにクラス実体を extern で参照している点です。 その結果、Title_class や SelectScene_class の宣言が見えない場所で使用され、未定義エラーになります。 対処法は以下が基本です。 ヘッダにはクラス宣言のみを書く メンバ関数の実装は .cpp に移す 実体は 1つの .cpp で定義し、他では forward declaration を使う 相互 include を避ける すでに実装を .cpp に分離して解決できているので、その構成が正しい方向です。 C++では「ヘッダは依存を最小限に」が重要です。

DirectX 12 の資料は本当に少ないので、この本は貴重ですね。
描画パイプラインやリソース管理を体系的に追えるのは助かりますし、MMDモデル表示まで載っているのは実践的だと思います。

ゲーム用途でなくても、リアルタイムレンダリングの基礎固めとして十分価値がある一冊ですね。

要点は「単語の切り出し」と「出現回数の管理」を分けて考えることです。

実装方針としては

文字を順に読み、先頭が英字かどうかで単語開始を判定

英字、数字、アンダーバー以外が出たら単語終了

条件を満たした単語だけを配列や連想配列に格納してカウント

c-genger さんの例のように、scanf の書式指定や ctype.h を使う方法は条件定義に忠実で実用的です。
学習目的なら、fgetc で 1 文字ずつ処理して状態管理する実装も理解が深まります。

代表的な入力パターンをあらかじめ用意して判定する方法がシンプルです。

例として「時間」なら
{"zikan", "jikan"} のように複数の正解文字列を配列で持ち、
入力文字列がそのどれかと一致すれば正解にします。

発展案としては

ローマ字変換ルール表を作って自前で変換する

入力を一文字ずつ進め、複数候補を同時に保持する

まずは「単語ごとに複数正解を許可する方式」がおすすめです。
実装が簡単で、ゲームとしても十分実用的です。

この投稿は明確にフォーラムの趣旨と利用規約に違反しています。

本掲示板は C言語に関する技術質問専用であり、商業広告や風俗関連の投稿は認められていません。速やかに該当投稿と連絡先情報を削除し、今後は各フォーラムのテーマとルールを確認した上で利用してください。

技術系コミュニティでは、無関係な宣伝行為は信頼を大きく損ないます。ルール遵守が最優先です。