電装工芸日記
- 舞台照明機器の製作とか -
2022年12月の投稿［22件］
2022年12月31日 この範囲を時系列順で読む この範囲をファイルに出力する
2022年の大晦日です。
コロナの感染拡大は完全に収まりはしなかったものの、仕事ではその影響も和らぎ忙しくさせて頂いた一年でした。
ご協力を頂いた各方面の方々に改めて感謝申し上げます。
ただ、体力的には過負荷が続いたもので、年末休暇に入ってからの２日間は完全にシャットダウン。大晦日の今日になってようやく普通に戻ってきた感じです。
年末にやるべきことの大半が出来ませんが、少しはこなして実家にも顔を出しましょう。
Ｃ言語の書き方は妄想だけなので合間に少し進めます。
#雑談
コロナの感染拡大は完全に収まりはしなかったものの、仕事ではその影響も和らぎ忙しくさせて頂いた一年でした。
ご協力を頂いた各方面の方々に改めて感謝申し上げます。
ただ、体力的には過負荷が続いたもので、年末休暇に入ってからの２日間は完全にシャットダウン。大晦日の今日になってようやく普通に戻ってきた感じです。
年末にやるべきことの大半が出来ませんが、少しはこなして実家にも顔を出しましょう。
Ｃ言語の書き方は妄想だけなので合間に少し進めます。
#雑談
2022年12月28日 この範囲を時系列順で読む この範囲をファイルに出力する
書き方を考えています。
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
マルチプロセスについて調べていました。
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
2022年12月27日 この範囲を時系列順で読む この範囲をファイルに出力する
Ｃ言語を習得する壁として代表的な機能は、
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
ライトアップのご依頼が多くなっています。
自家製の制御システムがあるので安く提供出来るのが強みですが、このところはリレーやタイマーが手に入らず難儀してました。
今月に入ってダメもとでモノタロウさんを見直したところ在庫あり。メーカーのサイトを見ると「供給量が少ないのでご注意ください」とはあれど供給は復活している。
速攻でオーダー。
リレーはOMRONさんのG7L-2A-BUBですが、フランジ形状なので取り付けが楽で、小型で動作電流も少なく、20A流せるので使い勝手が良いリレーです。AC100vで駆動する物を主に使いますが、制御用のDC電源が不要だし、横繋ぎで動かせるし、既設のタイマーで動いているAC100v負荷があれば制御信号として電源を盗み出して使うことも出来ます。
タイマーも数量限定ながら手に入りました。近い将来IoT化するつもりですが、電源の制御はシンプルなタイマーリレーに限ります。
#本業 #ガチ工作
自家製の制御システムがあるので安く提供出来るのが強みですが、このところはリレーやタイマーが手に入らず難儀してました。
今月に入ってダメもとでモノタロウさんを見直したところ在庫あり。メーカーのサイトを見ると「供給量が少ないのでご注意ください」とはあれど供給は復活している。
速攻でオーダー。
リレーはOMRONさんのG7L-2A-BUBですが、フランジ形状なので取り付けが楽で、小型で動作電流も少なく、20A流せるので使い勝手が良いリレーです。AC100vで駆動する物を主に使いますが、制御用のDC電源が不要だし、横繋ぎで動かせるし、既設のタイマーで動いているAC100v負荷があれば制御信号として電源を盗み出して使うことも出来ます。
タイマーも数量限定ながら手に入りました。近い将来IoT化するつもりですが、電源の制御はシンプルなタイマーリレーに限ります。
#本業 #ガチ工作
「行燈」を作らねばなりません。
灯台の様な円筒の建物のライトアップを依頼されているのですが、歴史のある代物なので落ち着いた雰囲気にしたいと。
建築デザイン的に窓の存在感が強いのでライトアップでも窓を主張したいと。
カーテンを付けて光を透かせばいいのですが、ライトアップをしない面の窓からは出来るだけ光を漏らしたくないと。
と、なりますと、内側から窓に向けた面だけが光る「箱」をこさえねばなりません。「行燈」なワケです。
お金も手間も時間もかけられないし、どうしたものかと思案しておりますが、看板屋さんの知恵と資材を使わせてもらうことにしました。
全体を木枠で作り、光を漏らしたくない面には肉厚のターポリンを張り、光らせる面にはノボリ看板で使う生地を張ります。相手物が相手物ですから防炎素材を使わないといけませんが、看板で使う素材は余程の安物でなければ防炎素材。
ちょいと年末年始休暇を減らして製作ですねぇ。
#本業 #ガチ工作
灯台の様な円筒の建物のライトアップを依頼されているのですが、歴史のある代物なので落ち着いた雰囲気にしたいと。
建築デザイン的に窓の存在感が強いのでライトアップでも窓を主張したいと。
カーテンを付けて光を透かせばいいのですが、ライトアップをしない面の窓からは出来るだけ光を漏らしたくないと。
と、なりますと、内側から窓に向けた面だけが光る「箱」をこさえねばなりません。「行燈」なワケです。
お金も手間も時間もかけられないし、どうしたものかと思案しておりますが、看板屋さんの知恵と資材を使わせてもらうことにしました。
全体を木枠で作り、光を漏らしたくない面には肉厚のターポリンを張り、光らせる面にはノボリ看板で使う生地を張ります。相手物が相手物ですから防炎素材を使わないといけませんが、看板で使う素材は余程の安物でなければ防炎素材。
ちょいと年末年始休暇を減らして製作ですねぇ。
#本業 #ガチ工作
2022年12月23日 この範囲を時系列順で読む この範囲をファイルに出力する
もう数日頑張れば本業が落ち着きます。夏休み前の小学生みたいにワクワクした気持ちですが何をしましょう。
手つかずの課題は特盛です。自由に何でも出来そうな解放感はあっても時間も気力も体力も資金も有限です。
物理装置を作るのもいいのですが、暖かい部屋に籠ってヌクヌクと出来る課題がいい。
まずはArt-Netエンジンですかね。これが出来れば幾つかの課題をクリアするキーになります。
調光制御の底辺で必要になる計算ライブラリも重要でしょうか。レベル値にマスタ値を与えて出力値を得るとか、幾つかのレベル値をマージするライブラリです。調光卓的なシステムでは必須です。
さらにはANSIエスケープシーケンスを用いた画面表示ライブラリです。これはpythonが苦手なfor文を多用せずには書けないのでＣ言語で書くのが必須だからです。
明日は数か月ぶりの完全オフなのでゆっくり考えましょう。
追記
ゆっくり考えようと思ったのですが、アホみたいに疲れが出て何も出来ませんでした。
アドレナリンに頼って誤魔化すと反動が酷いお年頃。
#雑談
手つかずの課題は特盛です。自由に何でも出来そうな解放感はあっても時間も気力も体力も資金も有限です。
物理装置を作るのもいいのですが、暖かい部屋に籠ってヌクヌクと出来る課題がいい。
まずはArt-Netエンジンですかね。これが出来れば幾つかの課題をクリアするキーになります。
調光制御の底辺で必要になる計算ライブラリも重要でしょうか。レベル値にマスタ値を与えて出力値を得るとか、幾つかのレベル値をマージするライブラリです。調光卓的なシステムでは必須です。
さらにはANSIエスケープシーケンスを用いた画面表示ライブラリです。これはpythonが苦手なfor文を多用せずには書けないのでＣ言語で書くのが必須だからです。
明日は数か月ぶりの完全オフなのでゆっくり考えましょう。
追記
ゆっくり考えようと思ったのですが、アホみたいに疲れが出て何も出来ませんでした。
アドレナリンに頼って誤魔化すと反動が酷いお年頃。
#雑談
今扱っている課題ではハードウェアの処理能力を出来るだけ主題の処理に振り向けたいのです。
C/C++の使用やポインタの活用は大いに貢献しそうですが、プロセス間通信をポインタを介して行うことは今時のOSでは無理っぽい。プロセスの独立性をOSがガッチリ固めるからです。
プロセス間で通信するにはOSがマネージするpipeや共有メモリを用いないといけません。幸い、pythonで同様のことをするよりも処理速度が速いようなので現実的ではありますが、このレベルの情報になりますとその筋の上級者が書いているので前提が高度で完全理解には程遠いところです。もっと基礎を固めないといけません。
現時点では同プロセス内でのスレッド処理で構成するのが現実的かなと。
同プロセス内ならポインタを介してスレッド間で変数を共有できるそうです。
ただ、Art-Netエンジン(受信/パッチ/送信の一連処理)を独立したプロセスにしたいので、いずれはプロセス間通信を多用出来る技術も習得しないといけません。
理解には及んでいませんが、芸は無いけど速度が出せる共有メモリが一番良さそうです。
追記
プロセス間でのメモリ共有
説明は少ないですが、サンプルコードに余計な装飾がありませんし、ほぼANSI-Cで書かれているので理解しやすい。
共有メモリを宣言し、そのメモリのアドレスを数値としてポインタ変数に渡しているだけです。別プロセスへのアドレスの渡し方が地味ですが、動作を理解するにはこれでいいのです。単に値が渡ればいいのか、特別な手段で渡すのか、明確にわかります。
これを習得出来たら楽になりますね。
#Ｃ言語
C/C++の使用やポインタの活用は大いに貢献しそうですが、プロセス間通信をポインタを介して行うことは今時のOSでは無理っぽい。プロセスの独立性をOSがガッチリ固めるからです。
プロセス間で通信するにはOSがマネージするpipeや共有メモリを用いないといけません。幸い、pythonで同様のことをするよりも処理速度が速いようなので現実的ではありますが、このレベルの情報になりますとその筋の上級者が書いているので前提が高度で完全理解には程遠いところです。もっと基礎を固めないといけません。
現時点では同プロセス内でのスレッド処理で構成するのが現実的かなと。
同プロセス内ならポインタを介してスレッド間で変数を共有できるそうです。
ただ、Art-Netエンジン(受信/パッチ/送信の一連処理)を独立したプロセスにしたいので、いずれはプロセス間通信を多用出来る技術も習得しないといけません。
理解には及んでいませんが、芸は無いけど速度が出せる共有メモリが一番良さそうです。
追記
プロセス間でのメモリ共有
説明は少ないですが、サンプルコードに余計な装飾がありませんし、ほぼANSI-Cで書かれているので理解しやすい。
共有メモリを宣言し、そのメモリのアドレスを数値としてポインタ変数に渡しているだけです。別プロセスへのアドレスの渡し方が地味ですが、動作を理解するにはこれでいいのです。単に値が渡ればいいのか、特別な手段で渡すのか、明確にわかります。
これを習得出来たら楽になりますね。
#Ｃ言語
オレメモです。
● Ｃ言語のポインタ
私の理解ですが、ポインタとは変数の扱い方の一つで、定義した名称ではなくメモリ上のアドレスを指定して変数にアクセスする方法です。変数のアドレス得る方法と、アドレス指定で変数を読み書きする方法の二つを総称したものとなります。
ＯＳやプログラム言語はハードウェアを直視せずに済ませるためにあるのですが、ポインタはその意図に反して原始的なアプローチでメモリに直接アクセスする方法だと言ってもよいようです。
様々な解説では変数のアドレス得る方法とアドレス指定で変数を読み書きする方法、さらにポインタの効能を混在させて説明するので分かりにくいのです。
先達の意図には反しますが、少しアプローチを変えて書いてみようと思います。
ただし、変数とは保存先を表す＜アドレス＞と保存されている＜数値＞で構成されているので、この辺りが頭にイメージ出来ないと以下は理解不能だと思います。
任意のアドレスをユーザが設定することも可能ですが、ＯＳや言語が割り当てるアドレスを使うのが普通。いや、勝手に決めて正常に動くことはまず無いでしょう。
変数のアドレスを得る方法
変数を定義するなら、
int data;
などと書けばいい。この段階で保存先のアドレスは決定されています。というか、変数が持つ情報の実体は保存先を表すアドレスです。
この変数のアドレス値を得るなら、
&data
とすればいい。変数名の前に＜&＞(アンパサンドと読むらしい。アンドではないそうな)を付けて装飾すると変数のアドレスを表します。
単に変数名とすれば中身を読み書き出来、変数名の頭にアンパサンドを付ければ保存先アドレスを読み書き出来るのです。
例えば、変数の中身を表示するなら、
printf("変数の中身：%d\n", data);
アドレスを表示するなら、
printf("変数の格納先アドレス：%d\n", &data);
となります。
アドレス指定で変数を読み書きする方法
変数のアドレスを保存するための変数はポインタ変数と呼ばれる特殊なものです。
通常変数と違って
int *addr;
とか
char *str_addr;
などと定義します。変数の前に＜*＞(アスタリスク)を付けて装飾することでポインタ変数だと宣言します。
アドレスを格納するには＜*＞を付けず、
addr = &data;
とします。
アドレス指定(ポインタ)で変数を読み出すには、
num = *addr;
とします。上記に続くなら変数dataの内容が変数numに入ります。
書き込むなら、
*addr = 10;
となり、変数dataの内容も10になります。何故なら、dataも*addrも同じアドレス(実体)にアクセスするからです。
ポインタの活用方法、動的変数、静的変数なども理解しなければなりませんが、先達の情報以上のことは書けそうありません。
自分ナリの整理は付きましたし、数か月後の自分が再理解できると思うのでここまで。
#Ｃ言語
● Ｃ言語のポインタ
私の理解ですが、ポインタとは変数の扱い方の一つで、定義した名称ではなくメモリ上のアドレスを指定して変数にアクセスする方法です。変数のアドレス得る方法と、アドレス指定で変数を読み書きする方法の二つを総称したものとなります。
ＯＳやプログラム言語はハードウェアを直視せずに済ませるためにあるのですが、ポインタはその意図に反して原始的なアプローチでメモリに直接アクセスする方法だと言ってもよいようです。
様々な解説では変数のアドレス得る方法とアドレス指定で変数を読み書きする方法、さらにポインタの効能を混在させて説明するので分かりにくいのです。
先達の意図には反しますが、少しアプローチを変えて書いてみようと思います。
ただし、変数とは保存先を表す＜アドレス＞と保存されている＜数値＞で構成されているので、この辺りが頭にイメージ出来ないと以下は理解不能だと思います。
任意のアドレスをユーザが設定することも可能ですが、ＯＳや言語が割り当てるアドレスを使うのが普通。いや、勝手に決めて正常に動くことはまず無いでしょう。
変数のアドレスを得る方法
変数を定義するなら、
int data;
などと書けばいい。この段階で保存先のアドレスは決定されています。というか、変数が持つ情報の実体は保存先を表すアドレスです。
この変数のアドレス値を得るなら、
&data
とすればいい。変数名の前に＜&＞(アンパサンドと読むらしい。アンドではないそうな)を付けて装飾すると変数のアドレスを表します。
単に変数名とすれば中身を読み書き出来、変数名の頭にアンパサンドを付ければ保存先アドレスを読み書き出来るのです。
例えば、変数の中身を表示するなら、
printf("変数の中身：%d\n", data);
アドレスを表示するなら、
printf("変数の格納先アドレス：%d\n", &data);
となります。
アドレス指定で変数を読み書きする方法
変数のアドレスを保存するための変数はポインタ変数と呼ばれる特殊なものです。
通常変数と違って
int *addr;
とか
char *str_addr;
などと定義します。変数の前に＜*＞(アスタリスク)を付けて装飾することでポインタ変数だと宣言します。
アドレスを格納するには＜*＞を付けず、
addr = &data;
とします。
アドレス指定(ポインタ)で変数を読み出すには、
num = *addr;
とします。上記に続くなら変数dataの内容が変数numに入ります。
書き込むなら、
*addr = 10;
となり、変数dataの内容も10になります。何故なら、dataも*addrも同じアドレス(実体)にアクセスするからです。
ポインタの活用方法、動的変数、静的変数なども理解しなければなりませんが、先達の情報以上のことは書けそうありません。
自分ナリの整理は付きましたし、数か月後の自分が再理解できると思うのでここまで。
#Ｃ言語
2022年12月22日 この範囲を時系列順で読む この範囲をファイルに出力する
Pythonで難儀したオカゲ・・・ですが、Ｃ言語の基本が頭に入っていくと書きやすいなぁ～って気分になります。
私が一番好きなのはPICのアセンブラです。アセンブラをガツガツ書いていると変人扱いされますが、機械を直接触っている感じがイイんです。
Ｃ言語はこの感覚に近い気がします。優しさがないので取っ掛かりは大変ですが、見えてくると機械に直接触れている感じが強いのです。変数の型が厳密だと言っても、歯車だってタイミングベルトだってモジュールが合わなきゃ動かないのと同じことです。違いは物を理解するためのキーワードに過ぎず。むしろ共通点を見つけて利用した方が機械イジリは絶対に楽しい。
コマンドの向こうにあるコンピュータの機械としての動作をイメージしないと出来ないことですが、コンピュータも歯車機械もバイナリコードか鉄板かの違いだけで部品が協調して動いていると思えば垣根なく感じられます。
・・・冒頭の書きやすいって言葉には語弊があるかも。
変人が新しいオモチャを手に入れて嬉しくなってるだけです。すみません(笑
分類は必要ですが、それが目的になって全体が見えなくなるのはつまらないと思うのです。
分けることで理解を深め、よりよい組み合わせを見つけたいですね。
#妄想
私が一番好きなのはPICのアセンブラです。アセンブラをガツガツ書いていると変人扱いされますが、機械を直接触っている感じがイイんです。
Ｃ言語はこの感覚に近い気がします。優しさがないので取っ掛かりは大変ですが、見えてくると機械に直接触れている感じが強いのです。変数の型が厳密だと言っても、歯車だってタイミングベルトだってモジュールが合わなきゃ動かないのと同じことです。違いは物を理解するためのキーワードに過ぎず。むしろ共通点を見つけて利用した方が機械イジリは絶対に楽しい。
コマンドの向こうにあるコンピュータの機械としての動作をイメージしないと出来ないことですが、コンピュータも歯車機械もバイナリコードか鉄板かの違いだけで部品が協調して動いていると思えば垣根なく感じられます。
・・・冒頭の書きやすいって言葉には語弊があるかも。
変人が新しいオモチャを手に入れて嬉しくなってるだけです。すみません(笑
分類は必要ですが、それが目的になって全体が見えなくなるのはつまらないと思うのです。
分けることで理解を深め、よりよい組み合わせを見つけたいですね。
#妄想