読者です 読者をやめる 読者になる 読者になる

KOSEIのブログ

自分の可能性をどこまでも

神秘学を日常に

2016/08/21

僕の一日は単調な一日です。朝は3時半起きして「八段錦法」という中国の導引術に由来する健康体操をみっちりやります。やることも単調で毎日内容を変えたりしません。午前4時前後までには洗顔をすませて、その後おおよそ50分間、読書の時間に当てています。この時間帯が僕にとって「黄金」の時間帯です。起きたばかりで頭が冴えているので、理解力や記憶力も抜群です。

その後5時には家を出ます。どこに行くかというと「散歩」です。ウォーキングですね。別に正式にウォーキングとして誰かから習ったわけではないのですが、もう10ヶ月ぐらいは続けています。以前はランニングをしていたのですが若いころの怪我が原因で右膝が痛くなったため、ランニングからウォーキングに変更したのです。

最近散歩に出る前の1時間に勉強した内容を散歩中に瞑想しながら歩くようになりました。散歩中はその他にも「ヘブライ文字」の暗記をしています。それもヘブライ文字(形状)と、その文字が持っている意味、対応するタロットカードの意味、そしてヘブライ文字カバラ神秘主義生命の樹とは繋がりがあるために、それも関連付けて暗記していく(カバラとしての意味と生命の樹のどこに当たるか)、同時にゲマトリアで用いるような数値が各文字には決められていますが、その数値の暗記、占星術で用いる10大惑星の関連付け、4大要素(火・地・風・水)の対応付け、対応する現代のアルファベット。ひとつのヘブル文字からそれだけのものを想起させていくのです。僕にとっては娯楽であり楽しい作業です。またこれは「ボケ防止」にもなりますし、今後僕が極めたいと思っているヘルメス哲学の基礎にもなりますので、たゆまぬ努力を続けているわけです(この作業は毎日続けています)。

現在紙に書くレベルであればそのすべてを記憶しましたが、歩きながら行うことにより、つまり日常的な行為とジョイントさせることにより、記憶の奥深くまで入っていくのです。空で暗じることも記憶を定着させます。もっとも結構の年数勉強していますから、「そのすべてを暗記した」といっても、あまり自慢にはなりませんけど。

ところで、今日は朝の学習時間にひとつの啓示をもらいました。今日の学習内容の中に「普遍的な愛」という事が書かれていたのです。人は自分の周りの人に対して、ある人には「愛」を感じ、ある人には感じません。愛を感じる相手というのは「気が合う相手」「仲良し仲間」あるいは恋愛や結婚の世界ならば「一生を伴にしたい相手」であったり、また「家族」といった精神的な繋がりがある場合が多く、逆に愛を感じないという場合、その原因はというと、先ほどとは真逆で「気が合わない相手」、酷いものになると「敵愾心」といったものです。この違いはどこから来るんだろうと考えると、自分が所属したり気が合うグループといったような団体とは相容れないような人に対しては「排他主義」になるのだということです。

これでは戦争・争いが起きるのも無理からぬこと。国家が「これは我々の正義を守るための聖戦である!」というようなことを正々堂々と言ってのけるわけです。「戦争」とは政治の道具であり、人間の生命を奪う悲惨なものです。一方、「聖」とは俗を超越したものです。なので「聖」と「戦」がひとつの熟語になっている事自体が理解不能です。

ところが今朝勉強した「普遍的な愛」というのは、すべての人を自分の仲間として受け止めるという愛情です。この愛は男女間の愛情とはまったく違うもので、もっともっと大きな愛情なのですね。これを自分で意識することが精神的な発達の第一歩なのだそうです。

自分が、とにかくオレが、わたしが、あなたは仲間、あいつは敵、と言って、仲間にはやさしく、敵には破滅を・・・では、入り口にも立っていないということです。

この「普遍的な愛」のパワーはとてつもなく強烈なものということです。この愛のチカラを知っていて活用している人は事業に成功しており、知らない人は人生でさほどの大きな業績を残せない人たちです。

僕は今までいろいろな仕事をやって来ましたが、今になって振り返ると、最後の最後で失敗したときは、どこかで「我」を出しすぎていたようです。相手も自分なのです、相手を傷つければ自分も傷つきます。

毎朝のウオーキングでの気付きはとても有効です。そしてとても気持ちがいいです。

KOSEI

 

OSのハナシ<元SE独白記>

<元SE独白記>  2016/06/16

今日はOSの話をしたいと思います。しかし僕が携わってきた大型汎用機のOSは専門的過ぎてしまうので、ブログの読み物としては重いと思います。そこで、僕が大型汎用機の事務処理計算の仕事に入る前のゲームのプログラミングをやっていた時代までタイムスリップしてみます。パソコンのOS上で開発をしていたのですが、そのころのパソコンのOSは、Windows OSがまだありませんでした。昔の人なら誰でも知っている「MS-DOS」です。もっとも昔はOSといえば「MS-DOS」しかなかったのですが。これは「 Micro Soft Disk Operating System 」のことで、マイクロソフト社開発による、パーソナルコンピュータ向けの16ビットOSです。いまのWindowsのようにきれいなアイコン等はなくて、真っ黒な画面があるだけです。コマンドラインにすべてコマンドを入力してプログラムを動かすのです。

じつは今のWindows OSからエミュレートできるのです。エミュレートというか、Windows OSはそもそもMS-DOSの上に建てられた家のようなものなので、これはWindowsが内部のMS-DOSの機能を使って表示しているということでしょうね。下の画面を見てください。これは僕がいま使っている、どこにでもある「Windows7」で立ち上げたMS-DOSの画面です。

 

最初はこういう画面が出てきます。ここにディレクトリーを表示するコマンド「 dir 」と入力してリターンキィを押します。すると、

 

これは僕の現在のパソコンの中のCディレクトリーの中味を表示しているのです。

このMS-DOSの機能は低いものでした。簡単にファイル管理とメモリー管理を見てみましょう。

ファイル管理:FAT(File Allocation Table 俗称ファット)でファイルを管理。

モリー管理:一時的にアクセス可能なメモリー空間は、最大640KB~768KB程度だったというのですから、いかに低機能だったかですね。そのためバンク切り替え(バーチャルメモリーのようなもの)などで解決していたのですね。

現代のパソコンOSのメモリーはギガ単位です。隔世の感がありますね。

KOSEI

 

プログラム開発工程(続きの続き)<元SE独白記>

<元SE独白記>プログラム開発工程(続きの続き)  2016/06/14

ところで昨日のブログでは端末が並んでいる部屋があると言いましたが、端末の数は20~30でしょうか・・・。大規模システム開発になるとそれぐらいの規模になります。端末ですが一見するといまどこの家庭でも使っている「デスクトップ型パソコン」に似ていますが、実はまったく違います。これはコンピュータではなく端末に過ぎないのです。大型汎用機にたくさんの端末が繋がれているところをイメージしてもらうと一番わかりやすいです。単なる端末なのでこの中には「CPU」はありません。「ダム端」とかいう言い方をします。操作するだけであって、計算しているのはメインフレーム本体なのです。

ところでそんなに何十台の「ダム端」がぶらさがって仕事をしていて、処理スピードは落ちないのだろうか?と誰しも不思議に思うでしょう。でもそこにはメインフレームにはマルチタスク可能な機械で、「タイムシェリングシステム」という仕組みが働いています。下の手書きの絵を見てください。

 

メインフレームに左上の図のようにいまA、B、C、Dの4台の端末が繋がっているとします。するとメインフレームのCPUは、まずA端末が要求している仕事をします。次にB端末の仕事・・・、というようにすべての端末(ここではA、B、C、Dの4台)をし終わったら(D端末まで終わったら再びA端末に戻り同じことを繰り返します。A→B→C→D・・・・・という具合に。「でもA端末の仕事をしている間、B、C、Dは待ってなければいけないのでは?」と考えますね?上の図では例として時間が経過しているということを表すためにA端末の処理が6:30から始まって、その後1分ずつ増やしていますが、汎用機のCPUの処理速度は、僕が使っていたメインフレームマシンは第4世代のマシンだったので1秒間に1億回の演算ができたマシンです(100 MIPSいまは更に性能が向上しているはず)から、一つの端末の簡単な演算に必要な時間はナノセカンド秒単位でしょう。それこそ目にも留まらぬスピードなので、人間はまるで自分がメインフレームを独占して使っているような錯覚を起こしているのです。これを実現させているのが「タイムシェアリング・システム」です。現代のパーソナル・コンピュータという言葉は「パーソナル=個人の自分だけの」コンピュータです本当に個人が占有しているのですが、汎用機の時代は単なる端末にすぎなかくて、このような仕組みでパーソナルのふりをしていただけなのです。

なので、それぞれの端末で実行をかけたりすると、その数が増えれば増えただけ一台の端末での動きが遅くなります。開発が佳境に入ってくると皆テストを始めたりで、処理速度はグッと遅くなり、ひどいときは停まってしまいます。決してハングアップしているわけではなく、CPUが他の端末からの要求(デマンド)を処理するのに忙しいのです。そういう時は夜間に仕事をするしかありません。まったく身体に悪いワーストテンに入る仕事です。また夜間は「バッチ処理」というのを定期的に流すのでそれがもの凄く時間がかかりその間はまったく一般の処理はできませんでした。端末が使える時間をいかに確保するか?が成功の鍵でしたね(笑)。

バッチ処理」というのは、対話型で動くプログラムではなくて、順次に一定の処理を繰りかえりていく一括処理プログラムのようなものです。いまのパソコンでも電源を入れて立ち上がった後に走るのは「バッチ処理プログラム」です。バッチ処理で何をするかというのが「ブートストラップ」エリアにあらかじめ格納されていて、電源が入るとこのプログラムをキックする(最初から始める)のです。そこにはキレイなWindowsの初期画面を出力し、仕事の準備をして待ち体勢になるのです。バッチ処理に関しては次のサイト(Wikipedia)をご覧ください。

https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%83%81%E5%87%A6%E7%90%86

KOSEI

 

 

プログラム開発工程(続き)<元SE独白記>

<元SE独白記>プログラム開発工程(続き)  2016/06/14

プログラム開発工程の続きです。昨日は自分がコーディングしたソース・コード(人間がプログラミング言語で記述した大元のコード-プログラム本文-)に論理的な間違いが無いかどうかを念入りに机上でチェックします。もっとも念入りにといっても、特に大規模なプログラムになるとチェックし切れませんからその後の「コンピュータによるチェック」でやればいい、というようになってきますが、仕方の無いことでしょう。眼や神経が最初から余り疲れてしまっても後の作業に影響します。チェック箇所は2つのポイントです。まずは文法チェック、次に論理チェック。このうち文法チェックも確かに大切ですが、論理チェックに重点を置いたほうがいいと思います。論理的にまちがったコードを書くと実行時に動きが止まってしまいキーボードの入力ができなくなってしまったり(大体が無限ループが原因です)、abort(アボート=流産とか、流れが止まるとか言う意味)したりします。アドートとは、俗に「落ちた」というやつです。

コンパイル作業:これはプログラマーがコーディングしたソース・コードを機械語に落とし込むための中間ファイルを作る作業です。ここでの主目的は「文法エラー」を取り去ることです。最初は100行ぐらいの文法エラーは出るものです。しかしエラー箇所を修正すればどんどん減っていきます。大体はニァミス、ポカミスの類です。スペル間違い、入れ子が対応していない(入れ子またはネスティング)、ピリオドがついていない・・・・・等々。エラーコードを見ながら修正していきますが、慣れてくればエラーコードの番号を見ただけで原因がつかめます。問題は見たこともないエラーコードが出てきた場合です。原因を追究していったら深刻なエラーだったという場合もありますが、ある程度考えてみてそれでもわからない場合もあります。そのような時は無視します。なぜかというと、「コンパイラー」も4またプログラムであり、これを造ったのも人間ですから、なかには造った人が間違っていることも充分あり得るのです。ちなみにプログラム上の動作上の間違いを「バグ(虫)」と呼んでいます。バグをなくして正常に動くようにすることを「バグフィックスする」とかいいます。

このコンパイルエラーのうち「定義エラー」は無視します。たとえば外部のファイルを参照したり、外部のプログラム(このプログラムをサブルーチンともいいます。今コールしているプログラム本体はメイン・ルーチンです)をコールしたりしていても、記述はしてあっても実態はまだ繋げていないからコンパイルエラーが出ても当たり前なのです。

ついでに説明しておきますと、外部プログラム(サブルーチン)で外部に出さなくても、内部ですべて終結させることも、もちろんできます。サブルーチンでやっていることを全部メインルーチンに記述すればいいだけの話です。しかしプログラムを設計するときはサイズの問題、メンテナンス性の問題、といった部分を考慮しなければいけないので、特に他のプログラムでもよく使う処理であれば、外部に出してサブルーチン化すべきでしょう。その方が生産性も上がります。

リンケージ作業:上記のようなコンパイル時に定義エラーになった、まだメインプログラムに繋がっていないファイルをすべてこのリンカーが繋げてくれます。この段階でエラーがゼロならあとは実行あるのみです。

実行:僕が使っていた開発環境ではプログラムの実行はすべてコマンドラインからコマンドを打ち込みました。このときの注意点ですが、最初の一回の実行で一回目から正しい動きをすることは100%ありませんから、本番とまったく同じテスト用の環境を作っておき、その環境下でテストを何回も繰り返します。こういう段階を踏まずにもしも間違えて本番環境で実行してしまい、本番環境に深刻なダメージを与えてしまったら、それこそ損害賠償問題です。僕のやっていたのは金融システムや航空システムだったので、、コンピュータが停まってしまうということは、社会に混乱を引き起こし、かつ企業にとっては大損害なのです。

じつはこの「実行」の段階が最終段階だと思ったら大間違いです。いちばん時間がかかる段階なのです。ロジックどおりに動いているのに何故画面上の正しい位置に表示されない?とか、表示はされるが数字が増えている、文字が化けている、こんなことはザラです。何回見直しても原因がわからない、こんなことはしょっちゅうです。自分が趣味でパソコンでプログラムの勉強をしているのなら、判らないのはそのままにしておいても誰も何も言いませんが、プロフェッショナルとして仕事をしている場合はそうも行きません。プログラマーがいちばん胃を悪くするときでしょう。

このような時は「トレーサー」というプログラムを使います。問題の半分近くは解決します。トレーサーとは、順を追って流れを追いかけてくれる(トレースしてくれる)プログラムです。プログラマーが書いたメインプログラムの動きに合わせて、必要な記憶領域の内容等を1命令(演算)ごとに表示してくれるプログラムです。例えばどこかの記憶領域に何かしらのデータを格納したとします。するとここでその記憶領域の内容をみれば間違っているかどうかは一目瞭然です。たとえば本来格納する数字が「1」だったとします。ところがトレーサーの内容を見たらまったく違う値が入っていた!ここが原因だったということになりますね。

ですが、面倒な場合は記憶領域にデータの出し入れが発生するところで自分でディスプレイ命令を挿入しコンパイル、リンク作業を再びおこない、ディスプレイの結果を見て判断します。また「ウォークスルー」という手法がありますが、これには僕もずいぶん助けられました。情報システム用語辞典によると、

ソフトウェア開発において、ソフトウェア成果物の品質向上を目的に、その作成者が主体となって開催するレビューのこと。インスペクションに準じる公式なソフトウェアレビューに位置付けられることが多い。ウォークスルーは、レビューを希望する作成者が数人のレビューアを招集、成果物の内容を順に説明する形式をとる。それに対してレビューアは、説明を通じて対象を追跡・検証し、その誤りや矛盾、抜け漏れなどを指摘するというのが大まかな流れである。カジュアルなグループディスカッションから公式レビューまで、幅広いバリエーションが存在する。いずれにしても、一つの製品を完成させるには色んな方の苦労の結晶だということですね。

KOSEI

 

 

 

プログラム開発工程<元SE独白記>

<元SE独白記>プログラム開発工程  2016/06/13

僕が現役SEだったころはパソコンやワークステーション上での開発という現場はありませんでした。すべて「大型汎用機」と呼ばれるものでした( 「メインフレーム」とも )。メインフレームとパソコンの違いをみてみましょう。

コンピュータにはCPUというものがあります。これはCentral Processing Unit 中央演算処理装置ですが、現在パソコンのCPUはマイクロチップ化されていますが、メインフレームのCPUは、どデカイ箱であってその箱が中心だったわけで、なので「メインの」「フレーム(枠・箱)」と呼ばれていたわけですね。メインフレームのCPUは「TTL」「ECL」と呼ばれるものですが、マイクロプロセッサのCPUは「MOS」と呼ばれるものです。マイクロといわれるだけあって「集積度」はすごいのですが、いっぽうメインフレームのCPUは集積度が上げられないため、複数のチップから構成されていたのです。しかし処理速度はメインフレームのCPUのほうが速いです。

僕は若い頃から趣味でマイクロコンピュータをいじっていたため、メインフレームの部屋に入って「これがCPUだよ」といわれたときは「???」でした。ピンと来なかったですね。(初期のころのメインフレームは特にですが)人間考えすぎると頭が熱くなってきますが、CPUも同じで発熱が大きかったのです。コンピュータルームに入ると、24時間体制でクーラーがガンガンきいていて、理由をあとで聞いて納得しました。最初は「オペレータ(操作員)は皆暑がりなのかな?」と真面目に考えていました。

 IBM_704_mainframe

しかし1990年代に各社ともCMOSマイクロプロセッサに移行したそうですが、発熱量も同時に下がったとのこと。じゃあ処理スピードも下がったの?と思いきや、マルチプロセッサ化で性能をキープしたそうです。僕が現場にいたころはちょうどそのハザマのころだったようです。「現在は独自仕様のマイクロプロセッサを複数(最大64個など)搭載するものが多い」とWikipediaにはありました。

メインフレームの定義を見ると、「企業の基幹業務である組織内部の処理と、大量または機密性の高い処理に利用する大型コンピュータを指す。」とありました。構造化や分散処理の波がメインフレームを「滅び行く恐竜」扱いしていますが、じつはいまだにまだ製造し販売しているのです。もちろん全盛期よりははるかに台数は少ないですが。理由は組織内の機密処理をオフラインで行えば機密性は上がるためでしょうね。

ところで、僕がメインフレームの世界に入って仕事を始めたころの開発環境は、いま考えても或る部分は笑えるものがあります。その当時の僕のプログラム開発の流れを再現してみましょう。

昨日のブログでも書きましたが、プログラム仕様書が手元に渡ってきたらまずプログラム・フローチャートを作成します。

1)コーディング・シートと呼ばれる紙に手書きでコーディングします。間違えたら消しゴムで消して書き直します。

2)コーディング・シート上にすべてのコーディングが完成したら、これをあるところに届けます。これは届ける係りの人がいるので申請をして待ちます。

3)自分でコーディングしたプログラム文を、いったいどこに届けるのかというと、「キーパンチャー」という人のところに届けるのです。早くて数時間、遅くても数日のうちにはキーパンチャーがパンチしたカードがプログラマーである僕のデスクに届けられます。このキーパンチャーという職業は若い女性がやります。一度見ていたことがありましたが、イヤ、その速いこと速いこと!指なのかキーボードなのか見分けがつかないほど・・・・。僕がキーパンチャーに「きみはサイボーグ?」と聞いても誰も同意すると思います。

4)次はその穴の空いたカードを持ってコンピュータルームへ行きます。ここでは入室の時に自分のID、所属部署、氏名、処理内容を記入して入室。オペレーターがカード読み取り機にパンチ済みカードをかけて、フロッピーディスクに読み込みます。それをもらって自分のデスクに返ります。コーヒーでも飲んで一服してから、端末が並んでいる部屋があるのですが、そこへ行っていまもらってきたフロッピーの中身を端末に表示して内容をチェックします。間違いがあれば修正します。

言っておきますが、メインフレームがあるビルは自分のデスクがある部屋や端末が並んでいる部屋があるビルとはかなり離れたところに在るので、いったんビルを出て他のビルまで徒歩でトボトボと移動するのですから、面倒なことこの上ないです。書いているだけで疲れてきましたので続きは明日にします。

KOSEI

 

 

プログラミング設計<元SE独白記>

プログラム・フローチャート  2016/06/12

フローチャートというのは、別にプログラムを設計するときでなくても、頭の中でやる作業ですし、人生は選択の連続です。例えば朝ランニングに行くときのことを考えて見ましょう。朝起床してランニングに行くかどうかを決定するまでのフローチャートはこうなります↓↓(手書きなので見苦しいです)

 

*このフローチャートによるとランニングした朝は朝食抜きですネ。

プログラムをつくる時もいきなりコーディングから始めることはまずありません。頭の中をまとめる意味でもまず「フローチャート」を作成します。その後にそれぞれの判断文や決定した処理をプログラミング処理言語に置き換えていくのです。

その際に覚えておかなければならない約束事があります。それは次のサイトをご覧ください。

http://www9.plala.or.jp/sgwr-t/c_sub/jis_fl.html

このサイトには「流れ図」とありますが、「フローチャートflowchart」の直訳です。資料によっては「流れ図」といっているものもあります。

最初のころよく使うフローチャート記号は、次の6個ぐらいなものでしょう。

「処理」を表わす長方形

「判断」を表わすひし形

「直接アクセス記憶」を表わす円筒形

「書類」を表わす紙の下端が切れたような図、

端子(流れ図の入口と出口)を表わす横長の円

流れ図が複数にわたる時に「結合子」としてつかう小さな円

まあ短いプログラムであれば、フローチャートを書かずにコーディングを始めてもいいと思うのですが、ある程度以上の長さのプログラムになる場合はフローチャートは必須です。でも論理的な思考を身につけるという意味でもフローチャートを書くことをクセづけたほうがいいでしょう。

KOSEI

 

 

論理演算<元SE独白記>

<元SE独白記>  2016/06/11

今日は「論理演算」について書きます。といっても何をどう書いていいのやら。「使ったことがある」というのと「説明できる」というのは話が違いますからね。そこでインターネット検索の力を借りましょう。「論理演算」で検索すると、以下のような説明がでてきます。

論理演算とは、2つ以上の1または0入力値に対して、1つの演算結果(1または0)を出力する演算のことである。 論理演算は、初級シスアドの試験では重要でSQL文における抽出条件の作成などにおいて必要不可欠な考え方だからだ。 論理演算の演算の種類として、論理積(AND)、論理和(OR)と否定(NOT)の3種類がある。

またまた意味不明な言葉が出てきたと思います。「シスアド」とは、システム・アドミニストレーター、つまりシステム管理者とでもいう役割を受け持つ人です。初級とあるのでシスアドになるためには基礎的で重要な知識ということですね。SQLとはデータベースを使いこなすときに必要な言語です。さて、この論理演算ですが、別名「ブール代数」ともいいます。上の説明にもあるように「0」と「1」だけの演算です。2進数演算といってもいいですね。具体的に説明します。演算をする二つの要素を「A」と「B」とします。

論理積(AND条件) AもBも、すべて「1」の時に「1」を出力する(答は「1」になる)、それ以外の場合の答えは「0」。つまり次のようになります。

0x0=0、0x1=0、1x0=0、1x1=1

これだけだと、一体何のことやら・・?ですよね。でもちゃんと使い道があるのであります。それどころか論理演算はかなり重要なものなのです。では引き続き

論理和(OR条件) AかBのいずれかが「1」の時に「1」を出力する。それ以外のときは「0」を出力する。

0x0=0、0x1=1、1x0=1、1x1=1

否定(NOT条件) A、Bどちらかの値が「1」なら「0」に、「0」なら「1」に反転する。

以上3つを基本にして幾つか組み合わせパターンがあります。

否定的論理和(NAND条件) すべての値が「0」のときに「1」を出力

ここら辺は説明が煩雑ですので、「こういうのがあるな」ぐらいに考えて置いてください。

排他的論理和(EOR、XOR条件) 入力値が違うとき1を出力する。それ以外(入力値が同じとき)は、0を出力する。

これらは高校の数学で習った「集合」を想い出すといいと思います。以上の記事はインターネット上のサイトを参考にさせていただきました。

http://www.pursue.ne.jp/jouhousyo/sysad/sysad011.htm

もうちょっと詳しく知りたい人は上記サイトで勉強してください。他にもたくさんあります。

では「実際にどう使うの?」という話ですが、たとえば「あるビットにフラグが立っていたら(「1」だったら)処理するようにしたい」というときには二つのコーディングの仕方があります。ABCと名前をつけた8ビットの記憶エリアの一番右端の(0ビットめ)が「1」だったら、ある処理をしたい、としましょう。

方法1:if ABC = 1 then ある処理  これは最もベタなコーディングです。

方法2:ABCDという記憶エリアにあらかじめ「00000001」を格納しておきます。そのうえで、

「ABC XOR ABCD = 真 ならば ある処理」とします。

論理演算の一番簡単なつかい方はこのようなビット検査の時に使いますが、そのほかにも論理演算子を使うことで「a と bが等しい」かつ「c は dよりも大きい」といった条件式を組み合わせたより複雑な条件式を記述することができるのです。

上の例で0ビットめのチェックの場合、もちろん方法1でも方法2でも、どちらでも結果は同じで同じ動作をします。しかしプログラムが走っている(動作している)環境はしょっちゅう変わるものです。「0ビットめじゃなくて3ビットめのみが「1」だったら「ある処理」を実行しよう、というように変わったとします。すると方法1でコーディングしていた場合は、変更が発生します。コードの修正です。「if ABC = 1」のコードを「if ABC = 4」に修正する必要が発生します。使用している箇所が多いとそれだけ修正時のミスも増えます。ところが、論理演算をつかうことによって、大元の「ABCD]の内容のみを修正すればいいので、ラクですし間違いも少ないのです。

KOSEI