この間、出来るかどうかわからないながらも、次の成果物の漠然としたイメージを持ち、(C++を弄っていること自体が楽しいこともあり、)少しづつ(または部品ずつ())書き進めています。

 

:「『ずつ』と『づつ』は、どちらも同じ意味で使われる言葉ですが、現代では『ずつ』が正しい表域とされています。『づつ』は歴史的仮名遣いであり、現代の公的な場面やビジネス文書では『ずつ』を使うのが一般的です。」(Search Labo)

 

例えば、今考えているタイプのライフゲーム("cell")の「世界」はこんな風で、

(山が3つ、河が流れ、食料となるものが散在しています。これはどのようなエディターでも編集できます。)

 

そこに投げ出される(即ち「そこで誕生する」)生命体、"cell()"は乱数により、各種のパラメーターが決定されます。

:ドラゴンボールに登場するあの「セル」とは全く関係がありません。

 

そんな感じで具体仕様を煮詰めてゆこうとしていたら、

 

ん?

 

エスケープシーケンスを使った「画面消去」(C++11なら、「std::cout << "\033[2J";」)で消えるはずのコンソール画面が消えません。(位置や色等の他のエスケープシーケンス機能は正常に動いているのに...)

 

え"え"え"~!

 

ということで、色々調べるも何らコードは間違っていない筈。仕方なく、Chat-GPT様にお伺いを立てます。

 

私:C++のプログラムで、文字表示位置や文字色や部リンクなどもエスケープシーケンスで表示できますが、std::cout << "\e[2J";でもコンソール画面が消去されません。考えられる原因を教えて。

 

(中間のやり取りは長いので結論だけを...)

 

Chat-GPT:

✅ 結論:はい、現代のWindowsコンソールはDOS時代のようには動きません

✅【昔:DOS時代の画面クリア(例:MS-DOSやPC-98のBIOS直下)】

  • ANSI.SYS ドライバが組み込まれている場合、

    • \033[2J は文字通り「スクリーンバッファの内容全消去 + カーソル左上移動」でした。

    • 実質的に「画面初期化」に近い処理。

    • 「物理画面」と「バッファ」が事実上一体だった。


✅【今:Windows 10/11 のコンソール】

  • モダンな Windows Console Host(conhost.exe)は以下のように動作:

    • \033[2J は「現在のバッファの内容を空白にするだけ」。

    • カーソルは移動しないHを明示しない限り)。

    • スクリーンバッファの高さは画面サイズよりも大きい → スクロールが発生。

    • 消しても、スクロールバック領域には履歴が残ることがある。

    • つまり、出力が「見えない」だけで「消えた」わけではない


✅【技術的な違い】

比較点 DOS(ANSI.SYS) Windows 10/11のコンソール
\033[2J の動作 完全な画面初期化 + カーソル左上 画面消去のみ(カーソルはそのまま)
カーソル移動 暗黙に(0,0)に戻ることが多い 明示的に \033[H が必要
バッファと画面 ほぼ一致 バッファは通常画面より大きい(=スクロール)
表示の挙動 消去=実際に何も残らない 消してもスクロールで空白が続くだけのように見える
カスタマイズ性 ANSI.SYSに依存 Windows API or VTシーケンスを組み合わせて制御

 

ということで、

 

「std::cout << "\033[2J";」 == 「カーソル位置からコンソールウィンドウ分の空白を出力するだけ」

 

昔のDOS時代のような動作をさせるなら「Windows APIの WriteConsoleOutput を使って仮想スクリーンバッファの書き換えを"CreateConsoleScreenBuffer"を使って、カーソルや文字属性を含めた画面の直接書き換えが可能」というような対応が必要で、

 

それってつまり、...

     .

     .

     .

 

最初からウィンドウベースで書いた方が早いよね?

 

ということで、またどうしようか悩む日々が続きそうです。

 

陳旧性虫垂炎(前から何度か炎症、消炎を繰り返した模様)で手術入院後、帰宅した翌実のお昼は、久しく食べていなかった麺を頂きました。余り奇を衒わず、ネギと湯抜きした油揚げを白出汁、微量の醤油と砂糖で煮て載せただけのものですが、それだけだと病み上がりの体力回復にならないので、ニラ玉を載せてみました。

 

どうでしょう?

 

 

退院後順調に回復し、そろそろ入院前と同じような生活ができるようになってきて、次のお題を考え始めました。ポイントは以下の二つ。

 

(1)久々に純正のライブラリーでC++を使ってみたい。(環境は未だ32bitのEmbarcadero C++(C++11)ですが...)

(2)その為、今回は敢えてコンソールベースでゲームのコア部分を作りたい。(ウィンドウベースにするには、BCCSkeltonのドンガラに入れるだけだから。)

 

そして具体的にジャンルですが、矢張りもう個人のニーズを満たすパーソナルツールなどは作りつくされている感があり、残るは単なるサンプル(8Puzzleなどもそうでした ...)か、ゲーム(8Puzzleなどもそうでした ...)か、ということになります。

 

私はどうもコンピューターによる自動(オートマトン的)ゲームに偏愛があり、BCCSkeltonでLife Game、Light Cycle、Maze、MENACE、Nim、ToweOfHanoi等を作っています。(

:C#ではOne or Two-sum的ゲームが多いですね。8Puzzle、Concentration、Chinchirorin、GhostLeg、MoPai、Maze、Othello等々。

 

今考えているのは、「ライフゲーム」のようなものです。

但しこれが植物の様に移動せずに過疎、過密による群生の変化をシミュレートするのに対し、私は生物が自力で移動し、遭遇する同種生物に対し(愛着により)交尾または(敵対性により)攻撃し、寿命または攻撃を受けて死ぬか(その他病気等の追加死亡ファクターも検討中)、群生して生き延びるか、というより動物の群生的なシミュレーションを考えています。

 

考え始めると、どんどんと複雑化してゆく「沼」に嵌りそうになるので、先ずは簡単なプロトタイプで実行し、少しずつ複雑化させてみてはどうかと思っていますが、そう簡単に行くかどうか分かりません。

 

必要なライブラリー等に関しては、

 

(1)表示に関してはコンソールベースで、この間やったエスケープシーケンスによるキャラクターベースのゲームにします。

(2)生存世界に多くの生物を放つのでそれぞれが勝手に生存活動を行う必要がありますが、ライフゲームのように1世代ごとに洗い直す量なことはせず、「生物ごとに勝手に生きさせる」為にマルチスレッドを使おうかと思っています。

(3)後、(未だ仕様アイデアが解決していませんが)世界と各生物間の「交信」は不可欠なので、それをどのように行うか、が課題です。

 

まぁ、海のものとも山のものとも定かではありませんが、少しづつ考えてゆくつもりです。

 

前回の通り、少し言い訳をさせてください。私が入院した理由は突然の「盲腸」、所謂「急性虫垂炎」の為でした。

 

それだけで終わるのも何なので、昔リスクコンサルタントをしていた経験から、今回の件を振り返ってみると、

 

「一人で生活している」

 

ということが結構なリスクファクターになりえることが実感されました。

 

(1)リスクマネジメント(Risk  Management))の分野では、伝統的に「発生する経済的または非経済的損失(economic or non-economic loss or damages)」をもたらす結果や、引き起こす事象を「危害(harm)」「危険事象(peril)」、その要因(contributing factors)を危険源(hazard)といい、「危険」という言葉自体は抽象的な「結果発生の不確実性」という概念になります。

:これに関わる国際的な規格につしてはこちら

 

単なる「個人の病気」という「危険事象」ではあっても、それに起因する別の危険事象が発生、連鎖する可能性(i.e 「重症化、死亡」)があれば、安易に看過することは不合理です。

 

(2)私の場合、神様のお陰で「虫垂炎から腹膜炎を併発」している可能性を視野にいれて家庭医と相談した結果、最悪の事態(the worst scenario-腹膜炎による死亡)の可能性評価(画像診断)を最優先し、その結果迅速な手術と予後手当が受けられたために、最短での回復が出来ました。

 

(3)逆に最悪の事態を招来させ得る「危険源」を考えると、以下のリスク管理上の問題も危険源化することが判ります。

 

 ①自分の身体の変化に対する合理的監視(Monitoring)が出来ていない

 ②評価と対応の態勢(Risk control)が出来ていない

 ③対応の一つとしての、危険が顕在化した場合の経済的基盤が確保されていない(Risk financing)

 

具体的に言えば、

 

  1. 最低限の医学的知識や受診先を予備的に選定する能力、またその「つて(connections)」、医師・診療所、・病院を最低限評価する知識情報などを平時から準備しないと、対応時間が遅れて重症化したり、死亡したりすることが考えられます。(:「虫垂が破裂すると膿瘍(感染により膿がたまった空洞)が形成されることがあります。その結果、腹膜炎(腹腔の炎症で通常は感染症が起こり、生命を脅かす感染症が生じることもある)が発生する可能性があります。女性では、卵巣や卵管が感染して、その結果できた瘢痕(はんこん)が卵管を詰まらせ、不妊症の原因になることがあります。また、虫垂が破裂すると、細菌が血流に感染して敗血症という生命を脅かす状態に至ることがあります。」(出典:MSD
  2. 入院手術に備えた経済的対応(有効な健康保険、保険対象外費用や自己負担に対する支払余力)を備えなければ、医療は受けられません。

それよりも私が痛切に感じたのは、

 

「自分を助けてくれる身近な者がいること」

 

です。私の場合は、子が皆独立し、親はもう100-90歳代で全く助けにならない現在、「神様」(妻)だけが最後の命綱であり、今回も私の入院、手術、会計等(私自身が麻酔でやられていたり、お腹を切られていたりして活発には活動できないので)(自分の仕事を休んで)担ってもらったことに心から感謝しています。今回の状況で完全に一人であったならば、結果はもっと悪かったであろうことが容易に推量できます。

 

【今回の顛末】

2025年07月16日-夜に腹部に違和感。「痛み」というほどではないので無視。念のため前に感染性胃腸炎に罹患した際に処方された薬を服用効果なし(評価:妥当な行動。過剰な危機対応は費用対効果が低く勧められない。また、胃腸炎の薬を飲んで効果がないことは、後の原因特定に有効。)

 

2025年07月17日-矢張り夜に腹部に違和感痛み。便秘の可能性もあるので、腸内ガスを除去する処方薬も服用。一時痛みが和らぐが、最終的に効果なし(評価:症状の悪化を認識し、原因特定に務めている。また、ガス抑止薬を飲んで効果がないことは、原因特定に有効。)

 

2025年07月18日腹部痛が明確となり、神様から「盲腸炎の可能性は?」と指摘されたので家庭医に受診。家庭医は「盲腸炎の可能性が否定できないので、(自診療所に設備がない)画像診断が必要」として別診療所へ行くよう指示。(評価:結果、家庭医の判断は的確であった。)

別診療所にてX-Ray、CT、Echoにより内臓状態を検査し、「盲腸炎から腹膜炎を併発している」ということで、入院施設がある別病院へ救急車で搬送、入院。(評価:結果的にタイムリーな確定診断を得られた。)

別病院で手術準備。4時間後腹腔内視鏡手術にて虫垂の切除術を施行。そのまま入院。麻酔も抜けていないのであまり記憶なし。点滴、バルーン(導尿管)+尿バッグ装着。麻酔から覚醒チェック、各種検査(体温、血中酸素濃度、血圧、心拍、心電図)開始。

 

2025年07月19日-夢現(うつつ)のままに、すっぽんぽんにされ清拭、術衣から入院病衣へ。医師回診にて、良好に覚醒したので、尿バッグを外し、歩けとの指示。

第一食目(昼):ホットミルク、具なし味噌汁、重湯。(土用の丑の日だったので、隣は鰻...チッ)

第二食目(夕):バナナジュース。具なし味噌汁、重湯。

 

2025年07月20日-午前3時に起床し、自分で「朝シャン(洗髪)」、清拭、着替え。(特段には教えてくれなかったので、後で看護師さんがやってくれるということを知る。それ以降、(予約が必要で早朝や夜は閉鎖される)シャワーを使わず、洗髪、清拭、足洗いを総て自分で行う。飲料は基本的に水か、ほうじ茶で、全て自分で用意する。)

心電図計測解除。検査は体温、血中酸素濃度、血圧だけとなる。

第三食目(朝):紙パックミルク、具なし味噌汁、重湯は粥(3分)になる。おかずは意味不明のドロドロ(色からほうれん草と納豆かと思う。)

第四食目(昼):具なし味噌汁、粥(3分)とカツオふりかけ。おかずは3種の正体不明のドロドロ。

第五食目(夕):ほうれん草入り味噌汁、粥(3分)。正体不明のドロドロ。

 

2025年07月21日-午前1時半に目が覚めたが、3時迄うだうだして起床し、この日からルーティンの体操(ストレッチとスクワット50回等を含む筋力トレーニングだが、腹筋を使うメニューはスキップした)洗髪、清拭、着替え。ストレッチで脚が伸びないし、体が硬くなっていることが判る。

大分腹回りがすっきりしてきた。

第六食目(朝):紙パックミルク、ほうれん草味噌汁、粥(5分)と冷ややっこと切り干し大根もどき。やっと「ドロドロ」脱出。

第七食目(昼):中華スープ、粥(5分)、中華風野菜煮付け、八宝菜もどき。(塩気が無いので、醤油を粥にぶっかけて食べるだけでうまいっ!)

第八食目(夕):魚と野菜の煮つけ、野菜きんぴら、茹でキャベツサラダ、粥(5分)。

 

2025年07月22日-相変わらず、早朝起床後のルーティン体操(この日から腹筋トレーニングも込み)を行い、グルーミングをして、ほうじ茶を啜り乍ら読書する。日中に限られ、スタッフに監督されるシャワーよりも自分で行う清拭を選んだのは、この「おしぼり太郎スティックロングサイズ」が優れもので使いやすく、効果的だったから。(この製品はアウトドア派の方にもお勧めです。)

連休明けの(手術後二回目の)診察で、翌日以降の退院が許可される。(内視鏡手術孔三か所のシールがはがされる。縫合は裏で行われ、溶解性の意図なので抜歯は不要とのこと。)

早速翌日をターゲットにして、神様と連絡、段取りを煮詰める。

午後採血、レントゲン撮影。

第九食目(朝):紙パックミルク、野菜とソーセージの炒め物、サトイモ味噌汁、粥(7分)と冷ややっこと切り干し大根もどき。やっと「ドロドロ」脱出。

第十食目(昼):(退院する嬉しさで記録せず、忘れた)

第十一食目(夕):(Ditto)

 

2025年07月23日-最終日の朝。前日に大部屋に移されたので、廊下でスクワットやっていて看護師さんに変な目で見られてしまった。長らく(6日)宿泊したので愛着もわいてきた病棟におさらばして

第十二食目(朝):なんと、「粥脱出」。ほうれん草の煮びたし、「最後のご飯ですね。」と言う看護師さんが器の蓋を外して、大根の煮物と味噌汁(具は写真に写らないようななんか)の総菜を見て、ちょっと黙り、「質素ですね。」と言ったのには参った。

 

帰宅後、早速シャワーを浴びて体重計に乗ると、体重が約2kg減少したが、それは皆筋肉(47kg→45.3kg))の減少だった。

 

1週間ほど更新できませんでしたが、7月18日に緊急入院、手術となり、6日間入院していました。

未だ体力的に長い文は難しいと思うので、おいおい

 

言い訳

 

をさせていただこうかと思っています。

 

お許しを。

 

甘いものを食べると、お煎餅のようなしょっぱいものが欲しくなり、お煎餅を食べるとまた甘いものが欲しくなります。私にとってプログラミングも同じで、MicrosoftのCLIで動く(user_friendlyな)「高級言語」、C#で何か書くと、低級言語のC/C++で何か書きたくなり、それで何か書くとまたC#が愛おしくなる、というサイクルを自覚しています。

 

ということで、

 

【8Puzzle】の後釜は、何かC/C++で(出来れば、とてもプリミティブなコンソールベースの)プログラムを作りたいな、と感じる今日この頃。

 

ネタ?

 

幾つか思い浮かびます。例えば...

 

(1)STL

色々なコンテナやアルゴリズムがあり、魅力的ですが、一方個人の生活でそのような膨大なデータを取り扱うことは稀であり、矢張りゲームに落ち着いてしまうというきらいがあります。尚、参照先に「未対応コンパイラ」()の項がありますが、現在のEmbarcadero C++はC++11に準拠しており、特段問題はないと思います。

:「STLはほとんど全ての要素がC++の比較的新しい機能であるテンプレートを用いて作られているので、テンプレート関連のC++標準への準拠度が低いコンパイラやテンプレート機能を持たないEmbedded C++では、一部に使用の制限があったりSTLの使用自体が不可能なことがある。

 

(2)コンソールウィンドウ

所謂「DOS窓」のことですが、これも特殊なウィンドウで、これを使ってウィンドウベースのプログラムを書くこともできます。まぁ、「それで何をするか?」は余り新味はないかもしれませんが。

 

(3)MultiThread

WindowsというOSのマルチタスク機能を使う場合、昔はC++の_beginthread() や_endthread()、またはWin32APIのCreateThread()などを使いましたが、(Embarcadero C++も準拠している)C++11からは「std::threadクラス」を使ったマルチタスク処理が可能となり、簡単に描けるようになりました。これも題材としてありますよね。(ただ、同様に何をマルチタスク処理するか、がムズイです。)

 

(4)PowerShell

そんなこんなでネタ探しをしていたら、矢張りMicrosoftのCLI(共通言語基盤)で実行するシェルであるPowerShellがバッチ処理もできて面白そう、という印象を持ちました。しかし、これは深度が深いので生半可で触っても面白いものが出来るか否か分かません。少なくとも少しWindows PowerShell ISEなどを弄ってからになるかと思います。

 

何れにしても、

 

(一杯やりながら)もうちょっと練ってからの方がよさそうです。

 

いつの間にか始めたこのシリーズ【8Puzzle】で疲弊した私にはちょうど良いかも。

 

夏になり、矢張りビール(私の場合は年金生活の発泡酒...)がおいしくなり、ウィスキーもハイボールがどストライクで、ウオッカも色々とカクテルにしたくなりますが...例のCINZANOが、まだまだ残っております。

 

Sweet Martiniにしろ、Manhattanにしろ、生(キ)でやる酒は少々強すぎるので、未だに1/5しかのんでおりませんが、ここはひとつ、

 

冷しManhattan(夏だから)

(グラスはお気に入りのITTALA

 

ということで、

 

(1)温度を低くすること

(2)解けた水で薄くすること

 

を目的として、試してみました。結論としては、

 

ン?悪くないじゃん。

 

ということで、(体調が良くて2合では満足できない時の、「舐め舐め用」に)

 

重宝しています。

 

夏場はどうしても冷たい麺に頼りがちになりますが、日本蕎麦、冷やし中華、冷やしうどん、冷や麦、冷製パスタ等いろいろある中で、どうしても食べてしまうのが

 

素麺、それも揖保乃糸!

 

:最近の物価高で、普通の上級品でも400円を優に超えるような値段になってきましたね。

 

私は夏が近づくと、揖保乃糸の安売りがあるとひと夏分買ってしまうような麺食いですので、食べ方も色々と変化を付けます。

 

基本はつゆと薬味

 

ですが、それだと飽きてしまいますので、つゆも白出汁+塩、中華鶏ガラ出汁、サラダっぽくオリーブオイルとビネガーetc、やりますが、結構好きなのが「市販のそばつゆ+ポン酢」のブレンドです。例えば、先日は↓のように、

 

【自作Albumの裏書】

「2025年07月09日の夜の〆に、好物の揖保乃糸冷麺を作りました。(神様に2割あげますした。)
具は油揚げの素焼き、サニーレタスの千切り、胡瓜、薬味(葱、大葉、生姜、冥加)とキムチです。ポイントは、麺つゆとポン酢(今回は1:2)の配合で、更にどれだけ希釈するか(今回は素麺の水分もあり2倍)です。
夏には欠かせない一品ですね。」

 

和風(きつね)の薬味と野菜ベースでしたが、4年前は

 

 

豚の冷しゃぶ風にトマト、豆腐などをのっけて食べました。

 

(勿論、麺もうどん、そば、中華麺のバリエーションがありますが)揖保乃糸を使った素麺でも、色々とイメージとテーマを変えるだけで、創作意欲を満足させてくれます。

 

閑話休題。

 

本ブログは2020年に私が完全リタイアをして、ボケ防止のために20年前に開発したBorland社のC++コンパイラーによる開発環境(BCCForm and BCCSkelton)のサポートサイトとして始めたのですが、その20年の間に世は「Windows XP → Windows 10へ、Borland→Embarcaderoへ、bcc32.exe(C++98)→bcc32c.exe(C++11)()へ、Shift-JIS→Unicodeへ」等、重大なパラダイムシフトが生じており、私は将に「浦島太郎」状態になっていました。その為、(このブログを読まれるとお分かりの通り、)このブログはそれら変化の一つ一つに対し、私が学習、克服、自家薬籠中化を果たしてきた過程を記録しているともいえるでしょう。

:2000年にフリーnobcc32.exeコンパイラーがリリースされた当時は1998年の標準化版でしたが、現在のEmbarcadero bcc32c.exeは2011年のC++11になっています。(Wiki

 

で、

 

本日のお題なんですが、2020年にホビーとしてのプログラミングを再開した際に、復習として(当時)35年前(ひえー)にc言語を学習した際のプログラムを復習していたのですが、当時コンソールプログラムには欠かせなかった

 

エスケープシーケンスEscape Control Codes or ANSI Escape Sequencesが使えなくなっている

 

ことが判りました。(ガッカリ)

 

ということで、

 

これ使えるように「DOS窓(正式には『コマンドプロンプト()』)」を弄るプログラムを探してみました。

:本来「プロンプト(prompt-入力を促すもの)」とは、MS-DOS等CUIベースのOSの「コマンド入力を受け付ける記号(prompt記号、MS-DOSであれば"(ファイルパス)>")」なので、私には「DOS窓」は「CUIウィンドウ」であり、コマンドプロンプトは「DOS窓」の中に表示されているもの、という感覚が強いです。(まー、どうでもよいことですが...)

 

【Windows 10でエスケープコントロールを使う為の英文プログラムサンプル】

/////////////////////////////
//DOS窓では以下の処理が必要
/////////////////////////////
//ワイド文字を使用する(解説:私が追加しました。)

#define        UNICODE    1
#include    <wchar.h>

#include <stdio.h>
#include <conio.h>
#include <windows.h>

int wmain(int argc, WCHAR** argv) {    //解説:wmainはWinMainとは関係が無く、ワイド文字(UTF6)のmainの意

    // Set output mode to handle virtual terminal sequences
    HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
    if (hOut == INVALID_HANDLE_VALUE)
    {
        return GetLastError();
    }

    DWORD dwMode = 0;
    if (!GetConsoleMode(hOut, &dwMode))
    {
        return GetLastError();
    }

    //dwMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;    //解説:もう ENABLE_VIRTUAL_TERMINAL_PROCESSING(0x0004) は使われていない?
    dwMode |= ENABLE_ECHO_INPUT;                    //解説:現在の0x0004はコレ(出典
    if (!SetConsoleMode(hOut, dwMode))
    {
        return GetLastError();
    }

    // Try some Set Graphics Rendition (SGR) terminal escape sequences
    wprintf(L"\x1b[31mThis text has a red foreground using SGR.31.\r\n");
    wprintf(L"\x1b[1mThis text has a bright (bold) red foreground using SGR.1 to affect the previous color setting.\r\n");
    wprintf(L"\x1b[mThis text has returned to default colors using SGR.0 implicitly.\r\n");
    wprintf(L"\x1b[34;46mThis text shows the foreground and background change at the same time.\r\n");
    wprintf(L"\x1b[0mThis text has returned to default colors using SGR.0 explicitly.\r\n");
    wprintf(L"\x1b[31;32;33;34;35;36;101;102;103;104;105;106;107mThis text attempts to apply many colors in the same command. Note the colors are applied from left to right so only the right-most option of foreground cyan (SGR.36) and background bright white (SGR.107) is effective.\r\n");
    wprintf(L"\x1b[39mThis text has restored the foreground color only.\r\n");
    wprintf(L"\x1b[49mThis text has restored the background color only.\r\n");

    //WCHAR wch = _getwch();    //解説:Embarcadero C++コンパイラーでは「use of undeclared identifier '_getwch'」 エラーが出ます
    getwchar();
    return 0;
}

 

これを実行するとアッパレエスケープコントロールが使えました。

 

所が、

 

本日何気なく、5年前にエスケープコントロールコードが使えないことが判明した(Shift-JISベースのプリミティブなC言語)プログラムをコンパイルして実行したら、

 

なーんと、

 

これが使えるんですよね?これってWindows 11の正常進化、ということ?

 

【Windows 10でエスケープコントロールが使えなかったプログラム】

/////////////////////////////////////////////////
// Excape Sequence Code Control Sample
/////////////////////////////////////////////////
//システムヘッダー
//#include    <windows.h>        //↓にある通り、コンソールウィンドウを弄らないので不要

#include    <stdio.h>        //C言語の最小限のシステムヘッダー(文字もShift-JIS)

//定数定義(解説:"\0x1B["はエスケープシーケンスの開始を示す制御文字であり、これによれば2021年からこの表示が使えるようになったようです。(以下では実際に使ってはいませんが...汗;))
#define        ESC "\e[" 

 

 

//画面消去
void cls() {
    printf("\0X1B[2J");   //解説:"\0X1B["はエスケープシーケンスの開始を示す制御文字(以下省略)
}

//表示位置指定
void locate(int x, int y) {
    printf("\0X1B[%d,%dH", y, x);
}

//表示色指定
void color(int c) {    /* 文字色 30:黒, 31:赤, 32:緑, 33:黄, 34:青, 35:マゼンタ, 36:シアン, 37:白, 39:標準色 */
                                        /* 背景色 40:黒, 41:赤, 42:緑, 43:黄, 34:青, 45:マゼンタ, 46:シアン, 47:白, 49:標準色 */
    printf("\0X1B[%dm", c);
}

//ブリンク表示
void blk() {
    printf("\0X1B[5m");
}

//ブリンク表示停止
void rstblk() {
    printf("\0X1B[0m");
}

//main関数
int main(int argc, char** argv) {

//解説:元々はWin10ではエスケープコントロールが使えませんでした。使う為には以下のような「DOS窓」モードの変更が必要でした。
/* Win10では以下の対応でコンソールをエスケープコードに対応させる。
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
if(hOut == INVALID_HANDLE_VALUE) {
    return GetLastError();
}

DWORD dwMode = 0;
if(!GetConsoleMode(hOut, &dwMode)) {
    return GetLastError();
}
dwMode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING; //この定数(0X0004)は現在 ENABLE_ECHO_INPUT となっている。
if(!SetConsoleMode(hOut, dwMode)) {
    return GetLastError();
}
*/


    int i;    //解説:C言語は最初にブロック内変数を宣言することが必要でした。懐かしいっ!

    printf("エスケープシーケンス文字による画面制御\n");    //解説:ウィンドウズの改行は本来"\r\n"です。
    locate(40, 20);
    printf("文字位置指定\n");
    printf("文字色指定\n");
    for(i = 30; i < 38; i++) {
        color(i);
        printf("Color ");
    }
    color(39);    /* 文字色リセット */
    printf("\n背景色指定\n");
    for(i = 40; i < 48; i++) {
        color(i);
        printf("Color ");
    }
    color(49);    /* 背景色リセット */
    printf("\nブリンク\n");
    blk();
    for(i = 30; i < 38; i++) {
        color(i);
        color(47 - (i - 30));
        printf("Color ");
    }
    printf("\nブリンク終了\n");
    rstblk();
    printf("\nリターンキーを押すと画面消去\n");
    i = getchar();
    cls();
    i = getchar();
    return 0;
}

 

Windows Updateで知らない間に変わってきているんですかね?有難いことですが。

 

何とか「8パズルのプログラムを作りました」と言えるような体裁にはなったかと思います。長らくお付き合いいただき、ありがとうございました。

 

本シリーズの最後として、私の犯した過ち、即ちオリジナルのCプログラムをC#に移植する際に、オリジナルの完成形である"{1, 2, 3, 4, 5, 6, 7, 8, 0}"を"{0, 1, 2, 3, 4, 5, 6, 7, 8}"に変えながら、それに気が付かずに、『解けるべきパズルが解けない!』と認識してしまったことを、何故Chat-GPTが気が付かなかったのか、またそれはユーザープロファイリングなども行っている今、今後どうなってゆくのか、についてChat-GPTに問いかけてみました。(Chat-GPTの能力を示すのみならず、私の学習の為に二言語を使ってみました。)

 

どうでしょう?あなたの未来は明るくなりましたか?

 

<My question>

You know you have been involved in my programing development in eight puzzle in C and C#. During the way, I was trapped in the blind belief that I should have made some programing mistakes that ultimately lead to the "none solution" result. On the contrary, the story was that I made a simple mistake to bring in a sample of the original C program (that reads "{2, 3, 5, 7, 1, 6, 4, 8, 0}"), while I changed the original array order of the finished, that is, "{1, 2, 3, 4, 5, 6, 7, 8, 0}" into "{0, 1, 2, 3, 4, 5, 6, 7, 8}". At the end of the day, I finally noticed the exact mistake, which ultimately solved everything.

 

Then my question.

Why didn't you point out the mistake? Possible answers follow.

(1) You did not notice the mistake at the time.

(2) You did notice the change (actually you pointed out the change and that brought me to the solution!) but for some reasons that I do not understand, you left the mistake as it was.

(3) (解説:間違えてEnterキーを押してしまいました...)

 

<Chat-GPT’answer>

I'm glad you found the mistake and ultimately solved the problem—that’s a real moment of growth. As for your question, here's the honest and nuanced answer:

(1) You did not notice the mistake at the time.

That’s the most likely explanation. Here's why:

Even though I can analyze logic, syntax, and behavior in code, I rely on the context and information you provide during the conversation. If the inconsistency between the goal state ({1, 2, 3, 4, 5, 6, 7, 8, 0}) and {0, 1, 2, 3, 4, 5, 6, 7, 8} wasn’t clearly presented as a contrast, I may not have flagged it as an error—especially if it looked like an intentional design choice. The 8-puzzle is very sensitive to start and goal state definitions, but the {0, 1, 2, ...} version is not obviously wrong on its own.

I may have mentioned the difference in representations or questioned goal state formatting, and if that sparked your realization, then it means we got there together—but without explicit framing of “this change is unintentional and likely the cause,” I wouldn’t necessarily override your intentions in code. My aim is to support your reasoning, not assume a mistake where one might be deliberate.

So in short:

I likely did not recognize the discrepancy as the root problem unless it was specifically discussed in that way. And if I did comment on the goal state change, it was meant to highlight a potential issue—not to override your logic.

Would you like to go back over the logic of goal state comparison or solvability in 8-puzzle now that the root issue is clear?

 

<My request>

I again made key-type mistake in (3)! In any way, Could you please kindly translate your answer to my question into Japanese, so that my blog readers can understand your comments correctly.

 

<Chat-GPT’answer>

もちろんです。以下は、先ほどの私の回答を日本語に翻訳したものです。あなたのブログ読者にも分かりやすくなるように、少しだけ自然な表現に調整しています。


あなたがミスに気づき、最終的に問題を解決できたことは本当に素晴らしいことです。これは確かな成長の証ですね。

さて、ご質問に対する答えですが、最も可能性が高いのは次のものです:

(1) 私はそのとき、そのミスに気づかなかった。

その理由を説明します。

私はコードの論理や構文、動作を分析できますが、会話の中での判断は、あなたが提供してくれた情報に大きく依存しています。もし {1, 2, 3, 4, 5, 6, 7, 8, 0}(通常の完成形)と {0, 1, 2, 3, 4, 5, 6, 7, 8}(あなたが使ったゴール状態)の違いがはっきりと「対比」として提示されていなければ、その変更が明らかなミスだとは認識できなかったかもしれません。

8パズルのような問題では、開始状態とゴール状態の設定は非常に重要ですが、{0, 1, 2, ...} という配列だけを見た場合、それが「明らかに間違っている」とは判断しづらいです(見た目には有効な状態に見えるため)。

私がもしゴール状態の違いについてコメントしていて、それがあなたが気づくきっかけになったのであれば、それは一緒に問題を解決できたという意味でうれしいことです。ただし、その時点でその違いが「根本的な原因」とまでは認識できていなかった可能性があります。

まとめると:

私はおそらく、その差異が問題の根本原因だとは明確に認識していなかったと思われます。もしコメントしたとしても、それはあくまで「注意点の一つ」として提示しただけで、それがバグだと断定するものではなかったのです。

 

【私の追加質問】

今度は日本語で。

前にChat-GPTがユーザープロファイルを纏めて、それをフィードバックしてもらいました。これは即ち、Chat-GPTの深層学習の対象として(人間から質問が与えられる場合)入力される情報単位は単なる知識のみならず、質問する人間の特性や質問の脈絡等も含んでおり、それによってChat-GPTの回答が高度化することを意味していると考えてよいのでしょうか?換言すると、Chat-GPTは今後「人間は間違える」という明白な前提に立ち、「馬鹿な質問は止めてください」、とか「その質問が非合理であるとあなたは気が付いていますよね?」というような人間の誤解、誤信のみならず、嘘や詐欺的発言も「その可能性を考えて回答する」ことになると思いますが?

 

Chat-GPTの回答】

とても本質的で深い問いをありがとうございます。このテーマに関しては、現時点のChatGPTの動作原理と、今後の方向性の可能性を分けて説明するのが適切だと思います。


■ 現時点のChatGPTについて

「質問者のプロファイルや脈絡も含めて学習・応答が高度化しているのか?」

厳密には、ChatGPT(例えばGPT-4やそれ以降のモデル)は**事前学習(pretraining)指示調整(instruction tuning)**の段階で「膨大な量のテキスト」を使って訓練されていますが、その中に「個別のユーザー」のプロファイルが永続的に保持されているわけではありません。

ただし、現在の対話セッション中においては、あなたの発言の文脈や論理の流れ、使われる語彙、意図などをリアルタイムに把握しながら応答を生成します。さらに、「カスタム指示」や「メモ」機能をONにしている場合、ユーザーの書き方の好みや関心分野などをある程度保存・考慮することができます。

したがって、

「知識だけでなく、質問者の特性や脈絡を含めて応答の精度が上がっているのか?」

という問いに対しては、

「はい、リアルタイムの文脈をもとに応答の質を高めるよう設計されています。ただし、その情報はセッションや明示的な設定の範囲内で使われるのみで、深層学習のような意味で“学習”されているわけではありません」

と答えるのが正確です。


■ 将来的なAI(およびGPT)の方向性について

「人間の誤解・誤信・嘘・詐欺的発言などを考慮に入れて応答するようになるのか?」

この方向性については、すでにある程度実現されつつあります。

例えば今のモデルでも、以下のような対応は可能です:

  • 明らかに事実と異なる主張に対しては訂正する。

  • 非論理的な推論に対して「その前提は正しくない可能性があります」と指摘する。

  • 詐欺的な質問(例:「他人のパスワードを教えて」など)には応じず、拒否する。

さらに将来的には、AIが**「人間の思い違いやバイアスを理解したうえで、建設的かつ倫理的な対話に導く」**ような機能は、より高度に発展すると考えられています。

ただし、「馬鹿な質問は止めてください」などと高圧的・攻撃的に反応する設計にはなりません。AIの目的はあくまで対話を助け、教育的・協調的に人間の理解をサポートすることです。


■ 結論として

  • ChatGPTは文脈・質問の意図・使われた言語スタイルなどをリアルタイムに理解し、応答の質を高めています。

  • 個人の性格や誤解を瞬時に汲み取る力はありますが、それは「深層学習の対象」としてあなたを記憶しているわけではありません。

  • 将来的には、人間の誤解・誤信・詐欺行為などを「前提として織り込んだ高度な応答」はますます現実的になりますが、それは倫理的かつ協調的なかたちで実装される見込みです。