2022年5月の日記

今はSpacemacsでC++をやっている。
コードの編集に関しては申し分がない。
IDEとしてみたとき、不満が残る部分がある。
IDEというと、矢印キーでカーソルを移動したりしないといけない、とういう先入観がある。
実際ほとんどのIDEがそうなのではないかと思う。
Qt Creatorは、Qtアプリケーションを作るときには、他のIDEよりもずっと手軽で使いやすい。
基本的な機能は揃っているし、グラフィカルなGUIの編集がサポートされている。
Qt CreatorなしでQtアプリケーションを作るとなると、かなり面倒なことになる。
KDevelopは、あまり使い込んでいない。
「K」はもちろんKDEの「K」を指しているのだろう。
しかし、KDEに特化した機能というのはそれほどなく、汎用的なCとC++のIDEとして使える。
CLionというCとC++のIDEが気になっている。
これはフリーソフトウェアではないし、無料でもない。
年間約￥23,000と、そこそこの価格になっている。
月額払いもできる。
マルチプラットフォームという点を除いて、フリーで使えるQt CreaterやKDevelopよりも突出して優れている部分はあるのだろうか。

SFML Blueprintsという本を読んでいる。
タイトルからはSFMLの解説が中心のような印象を受けるが、SFML自体の解説はそこそこで、実際にゲームを作っていくことが中心となっている。
SFMLがシンプルなため、あまり解説することもないだろうから、そうなるだろう。
クラシックなAsteroidというゲームを作るところまで読んだ。
ここで、衝突処理のところに注目したい。
例えば、隕石と自機の衝突を考える。
隕石も自機もEntityというクラスから派生している。
そして、Entityには次のような純粋仮想関数がある。

virtual bool isCollide(Entity const &entity) const = 0;

隕石も自機もこの関数をオーバーライドして、衝突の判定をしないといけない。
そして、衝突したのが隕石同士の場合は無視したい、つまりfalseを返すようにしたいとする。
そうすると、ぶつかった相手である引数のentityが隕石なのか自機なのか判定できないといけない。
これが問題となる。
本では、とりあえずの対応として、dynamic_castでentityが隕石なのかをテストしている。
dynamic_castは遅くて、ゲーム内のEntityの数が多くなると問題になるという注意もされている。
別の解決策として、double dispatchを利用することが挙げられている。
ただ、ちょっと書かれているだけで、具体的なコードは示されていない。
真先に思い浮かぶのは、クラシックなデザインパターンのVisitorだが、それではまたちょっとした問題が残る。
もうちょっと模索してみる。

瓦が外れていると報告があったので、修理しないといけなくなった。
かなり険しい高さと位置なので、登るのがためらわれた。
自分が登ったわけではないけど、落ちないかとひやひやものだった。

この章からいよいよ本格的になってきた。
かなり手強い。
アセンブラを知らなければ手も足もでない、というくらいの手強さ。
例外の解説は、かなり難解で、ふんふんと読み流した。
要約は次のようなものだ。

• Reversing the stack is a slow process.
  
• Using C++ exception takes up a lot of space. This is because each function defined in the code not only has to contain the code for that function, it must also contain an FDE that tells the code how to unwind the stack in the event that an exception is fired.
  

これだけみれば、C++ユーザーの常識として知っていたことだけど、バイナリレベルの詳細まで踏み入ったことはなかった。
後の方の章でもう一度詳しくやるらしいので、完全に理解できなくても大丈夫だろう。

価格を調べたりしていた。
少し前までは、Ryzenが優位で話題になっていて、次はRyzenを買うことに決めていた。
Intelの12世代のCoreが出てから、Ryzen優位という状況でもなくなったようだ。
マザーボードはASRockのにすると決めている。
Intelの場合、Z690というチップセットのが良い。
HやBのものもあって幾分か安い。
Z690にする場合、3万くらいはみておかないといけない。
AMDの場合はB550で良さそうだ。
グラフィックスカードはまだめっぽう高い。
エントリークラスのものでも1、2万程度といったところか。
ミドルレンジのもので6〜8万、ハイエンドのものだと20万近くするのがざらにある。
ゲームしないのでこんなのは全く必要ない。
できればCPUのものを使うようにしたい。
今日買いにいければと思っていたけど、まだ決心がつかなかった。

しばらく途中で放置していたのを読み終えた。
面白い。
続けて読んでいこう。

古いPCの整理をしていた。
ゴミデータを削除して、一応残しておきたいものを外付けのHDDの一箇所にまとめた。
今使用しているPCは2016年末に組んだものだけど、まだすこぶる快適に動作している。
その一つ前のが、Windows Vistaの入っているもので、Core 2 QuadというCPUで動作している。
これもまだ、メインで使うのでもなければ、ぎりぎり許容範囲の使用感だ。
しかし、Vistaを操作していると、いきなり電源が落ちる現象が発生していた。
ハードウェアの問題かと思っていたけど、そうではなかったようだ。
Linuxをインストールしてみると、問題なく動作する。
Vistaにはもうお休みしてもらうことにする。
これでもう使用できるWindowsが残りノートPC1台になった。
そのノートPCはあまりに動作が遅すぎるので、プログラミングにはとても使えるものではない。
断舎利というの言葉を最近たまに聞く。
ものへの執着を捨てるということらしい。
この考えはPCのデータにも適用できる。
なんとなく削除できずに残っているデータが溜っていくと、PCを使っているときに何かに取り付かれているような感覚になる。
思い切って削除してしまうことは大事だ。

先のWindows Vistaが入っていたPCの調子が悪いので、ハードウェアの故障なのか、原因を特定するためにLinuxをインストールしてみた。
古いBIOSのもので、USBスティックメモリからブートすることができず、一々DVDに焼かないといけず、資源を無駄遣いにする。
インストーラーが起動せず、いくつか試す必要があった。

• Pop!_OS 22
  インストールはできたが、ブートローダーのインストール先を指定することができない。
  BIOSでは一番最初のドライブからしかブートできない。
  Pop!_OSは4つめのHDDにインストールしたため、起動できないことになった。
  Super Grub2のようなメディアを使ってブートすることもできるが、やらなかった。
  
• Fedora 36
  インストーラーの途中で画面が表示されなくなって、インストールできなかった。
  
• openSUSE Tumbleweed
  これも、インストーラーの途中で画面が表示されなくなって、インストールできなかった。
  Tubleweedとはローリングリリースのエディションを指している。
  
• Manjaro
  うまくいった。
  インストール途中で、Grubをインストールするドライブを選択できる。
  Manjaro自体をインストールするドライブとは別の、一つ目のドライブのMBRにインストールできる。
  

こういう経緯で、Manjaroがインストールされた。
動作も中々軽快な感じだ。
HDDなので、少しもたつくのは仕方ない。
SSDにはまだWindows Vistaが入っているけど、そろそろお休み頂いてもよいだろう。

疣の治療。
治療はせずに、薬の処方箋だけもらった。
次回は4週間後。
もう5ヶ月になるのだが、まだ終わらないのだろうか。

ブックオブによってみた。
OpenGLプログラミングガイド 第2版というのが220円で置いてあったので確保しておいた。
バージョンはOpenGL 1.1とあまりに古過ぎる。
実用的価値はほぼない。
歴史資料として所有しておく。
日本語で書かれたOpenGLの解説書というのも新鮮だ。
あと、コンピュータグラフィックスという本が1700円で置いてあった。
これもまた古く、1993年刊行となっている。
いったんスルーしたのだけど、後で欲しくなってきたので購入しておいた。
これは利用価値があるのかどうか分からない。
あと、桜庭一樹の読書日記というのを100円で入手した。

もう、SFML2.5からは、SFML_LIBRARIESやSFML_INCLUDE_DIRは使われていない。
というか使えない。
SFML Blueprintsのサンプルコードでは、これらの変数を利用しているので書き換えないといけない。
${SFML_INCLUDE_DIR}は、find_packageした時点で自動的に設定されるので削除すればよい。
(最も、Linuxでパッケージマネージャーを使ってSFMLをインストールしたなら、/usr/include以下にヘッダが配置されるのでインクルードパスの指定は不要ではある。)
${SFML_LIBRARIES}は、コンポーネントを個別に設定する。
その際、例えばsfml-graphicsをリンクしたいなら、SFML::graphicsではなく、sfml-graphicsを指定する。
やるべきことは単純なった。

find_package(SFML 2.5 REQUIRED COMPONENTS system window graphics audio network)
...
# 
target_link_libraries(${executable_name} sfml-system sfml-window sfml-graphics sfml-audio) 

例としてnetworkは今は使わないケースにしてみた。
必要なものだけをリンクすればよい。
一括で指定できる${SFML_LIBRARIES}は便利だが、明示的に指定する方が融通が利く。

波括弧による初期化のスタイルを指定する方法のメモ。
次のようなコードがあったとする：

auto x{42};

WebKitのスタイルは、これを次のようにフォーマットする：

auto x { 42 };

この余分なスペースはあまり好きではない。
Googleやその他のスタイルと同じように、最初のまま、余分なスペースを入れて欲しくない。
設定項目は2つある。

• Cpp11BracedListStyle: true
  
• SpaceBeforeCpp11BracedList: false
  

これで余分なスペースは追加されないようになる。

帰ってからやりたいことが色々とあるのに、眠くなる。
集中できず、あまり捗らなかった。
一応、少くとも1日1章のノルマを課した、物理の本の3章はこなした。
あとは目立った成果はない。

「スーパーユーザーなら知っておくべきLinuxシステムの仕組み」が届いた。
かなり濃い内容で、思ってた以上に良さそう。
どのタイミングで読み始めるか、すぐに始めるか、決めかねている。

連休中にLearning Boostを終えたので、ちょっとクールダウンも兼ねて色々やってみた。

• 物理の勉強の再開
  
• 「プログラミングのための数学」という本
  
• PacktのSFMLの本
  

細切れにそれぞれ一時間程度ずつ時間を割り振ってみた。
物理は以前やっていた教科書を使うことにする。
久々に開いたが、前の内容を全く思い出せないので、最初から始めることにした。
練習問題がたくさん用意されている。
一度やっているやつはスキップしていった。
読むだけなら数日で終わりそうだ。
しかし、テキストにも書いてあったけど、物理の本は読物のように読んでも何も身に付かない、とのこと。
それには完全に同意。
ただ、練習問題を全部やっていると、かなり時間がかかることになって、そのうち息切れして放置状態になってしまう可能性が高い。
一度読物のように通して読んでから、再度最初から練習問題を解いていくという進めかたにすることにする。
「プログラミングのための数学」という本は、いつどこで買ったのかよく思い出せないくらい放置してあった。
ずっと本棚に置いてあったので、存在は認識していた。
ちゃんと目を通したのは、今日が初めてだと思われる。
1章だけ読んでみたが、すごくいい感じだ。
十分に時間を書けて読む価値がある。
PacktのSFMLの本は、3冊チョイスした。

• SFML Game Development By Example
  
• Mastering SFML
  
• SFML Blueprints
  

SFMLはシンプルなライブラリなので、がっちりとした本を読まずとも、使い初めることはできる。
これらの本もざっと目を通した感じ、SFMLそのものに対する解説というより、ゲームプログラミングをすることが主目的といった感じだ。
別のライブラリを使うようになっても応用できるだろう。
なぜSFMLの本に手を付けたかというと、いい加減マリオの記事を完成させるか、放棄するかしてしまいたいからだ。
何も参考にせずに、試行錯誤しながら進めることも可能だけど、時間がかかる。
一度完成された手順を参考にしてから、それに沿った形で進めるようにしたい。
あと今日はやらなかったけど「Hands-On System Programming with C++」という本の優先度が高い。
一度時間が空いてしまって、前の内容を思い出せず最初から読み直している。
4章まで読んだ。
時間を空けると忘れてしまうので、少しずつでもいいので、毎日進めていくようにしたい。

Asioの章。
Asioは「ay-see-oh」と発音するらしい。
カタカナだと「エイ シー オー」といった感じだろうか。
今まで「アズ アイ オ」と読んでいた。
Asioは、それだけで一冊の本が出てしまうほど(実際にPacktから出ている)、適用範囲が広いライブラリだ。
この章で触れたのは、おそらく最も基礎的な部分であっただろうと思われる。
それでもなかなか、いや、かなり手強かった。
肝となるのは非同期処理。
サーバー側は async_* というコルーチンの関数を使うことで、接続の待ち受けや、データの送信と受信の完了を待たずに、他の処理を行うことを可能とする。
Asioはそのための基盤を提供している。
この章のサンプルはUDPとTCPのエコーサーバーのようなシンプルなものだが、それでも結構扱いが難しいコードとなっている。
現実のプログラムでAsioを採用するためには、まだまだ鍛錬が必要となるだろう。
この本で扱ったのは、使い始める前の段階の、開始地点までの道のりを示したといったところ。

前日買い損ねた「スーパーユーザーなら知っておくべきLinuxシステムの仕組み」という本。
中身はちらっと覗いていて、良さそうだということは確認してある。
Linuxを長いこと使っているが、こういう本で体系的に学んだことがない。
入手できる経験値はそこそこ高そうだ。

最後のAppendixを読み終えた。
タイトルは「C++11 Language Features Emulation」というもの。
よくある、C++の新機能をさらっとおさらいするだけのおまけだと思ってたけど、そんなことはなかった。
趣旨は、C++11より前のC++03や98でも、Boostを利用してC++11の新機能の代替するというもの。
もうC++11より古いバージョンを使うことはないので、それほど重要とも思っていなかった。
しかし、知らないことも書かれていた。
例えば、std::exception_ptrによる例外の強化。
他も、Boostのことを知らないのは当然としても、C++11を復習して基礎を固めるのに役に立つ内容だった。
とりあえず、これでこの本はコンプリートだ。
まだまだBoostを使いこなせるようになったというところまではいかないが、スタート地点には立てたような気がする。
完全を期するなら、もう一周したいところだ。
しかし、まだ後にPacktの紙の本が3冊控えているので、そうはいかないかもしれない。

• Hands-On System Programming with C++
  
• CMake Cookbook
  
• Learn Three.js 3rd edition
  

とりあえず、この3冊は完了させておきたい。

昨日アマゾンで注文した、トラックボールのマウスが届いた。
LogicoolのM575というやつ。
さっそく使ってみた。
手を置いたときのフィット感とても良い。
ボールを回すときの感触も気持ちが良い。
デザインも良い。
マウス自体には満足だ。
ただ、やはり、しばらく慣れるまで時間が掛かりそうだ。
長年普通のマウスを使ってきたので、握ってぐりぐり動かす動作が染み付いているのを矯正しなければいけない。
手を置くと、無意識にトラックボールでなく、マウス本体を動かそうとしてしまう。
あと、スクロールバーを下にドラッグする動作が、ちょっとやりづらい。
たぶん、アイコンをドラッグするときなども同様だろう。
右ボタンを維持したままボールを回すのが、ちょっとやりづらい。
これもたぶん慣れれば普通にできるようになると思う。

ちょっと時間かかってしまった。
FilesystemとIOStreamsの章。
FilesystemはC++17で標準ライブラリに追加されたものとよく似ている、というか、ほぼ一緒なので見慣れた感じがした。
目的や用途も明確で、特に迷うところはなかったはず。
IOStremasはそうではない。
拡張性を提供するために、きめ細やかな指定ができるようになっているため、ちょっとしたことをするためにも、何段かステップを踏まないといけない。
言い換えると、手続きが冗長で、複雑だということだ。
独自のフィルターを書くというところまでは、この本では扱っていない。
そのためか、まだ真価を見せていない、といったところで、現実ではどの程度の助けが得られるのかイメージできなかった。
次は大の苦手の並行処理の章だ。

並行処理の章。
並行処理は経験が乏しいため、本を読んでもいまいちな感じで、苦手意識を持っていた。
しかし、この章は不気味なくらいすんなりと飲み込めた。
十分な量のサンプルコードとそれに対する解説があるの。
コードのパターンを視覚的にインプットしてからそれに肉付けするという感じで理解を深めてくれるといったところだろうか。
Boostの話なのだが、多くは、一部重要な違いがあるものの、C++11以降の標準ライブラリに含まれるものと共通となっている。
Boostだけに止まらず、C++の並行処理の初歩を学ぶのにも良い章となっている。
あと、PromiseとFutureというのが登場するのだが、最近JavaScriptのサイ本の第7版を読んでいる。
そこでJavaScriptのPromise、Futureを学んでいて、利用形態は異なるが、概念としては共通するものを感じられて理解の助けになったように思う。
次は、Asioというネットワークのフレームワークだ。
これだけで本が一冊出るほど大きなトピックで、完全にカバーするものではないだろう。
その次は、ほぼおまけの章なので、実質次が最後の章となる。

大きい本屋に行ってきた。
あまり買いたいものはなかった。
一冊だけ目に付いたのがあった。
「スーパーユーザーなら知っておくべきLinuxシステムの仕組み」という本。
買おうと思ったのだけど、よく見るとカバーの折目がずれていて、状態が良くなかったので止めておいた。
中身はかなり良さそうな内容だったので、アマゾンででも買うかもしれない。
あとはコンピューターの数学という有名も本も少し迷った。
1万円近くするのだけど、ポイントが5000円分程たまっているので、これを機に買っても良いかなと思ったのだけど、たぶん読まないだろうから止めておいた。
マンガも欲しいのが2冊あって、働かない2人の25巻と、ロトの紋章の34巻がないか探したけどなかった。
今アマゾンをチェックしたら、ロトの紋章の新品は在庫がなかった。
最終巻だけ手に入らないという事態になってしまった。

2店舗あって、割と近くにならんでいるのだけど、贔屓している方のお店は定休日だった。
まだ新調するかどうか決めかねていたので、今日買わなくてもすんだので、結果的に良かったかもしれない。
もう一方の方を見ていった。
IO-DATAのGigaCrystaという今使っているディスプレイの4Kのが置いてあった。
Ryzen 5と7のCPUは、kakaku.comの最安値より、大体消費税の10%くらい、3000〜4000円程度高くなるようだ。
たぶん、もう一方でも似たような値段ではないかなと思う。
買うならネットで買ってしまった方がいいかもしれない。
ASRockのAM4ソケットのMBでちょうど良さそうなのがあった。
MBはASRockと決めている。
せっかく来たので、マウスをそろそろ買い替えておこうかとおもって、見ていった。
トラックボールにトライしてみたくなって触ってみた。
エレコムのでちょうどよさげなのがあったので買おうかと思ったけど、ネットより1000円程度高いのでやめておいた。
結局何も買わずに出ていった。
こうやってネット価格と比較していると何も買えなくなってしまいそうだ。
もう割り切ってしまった方がいい気もする。

半年くらい放置している。
もうエンディング間近と思っていたがまだ少しあるようだ。
これから一日一時間以上、何かのゲームをプレイして、毎日ブログに記録を付けるということを計画している。
久々のゲームで、一時間くらいプレイしてみて、ほんとあっという間だった。
一時間じゃマップをうろうろしているだけで終わってしまう。
これじゃブログを書こうにも書けない。

今使っているやつは普通の優先のだけど、そろそろ限界に近いように思える。
お店でトラックボールのを買いそびれてしまったのが引掛って、無性に新調したくなった。
アマゾンで検索して最初に出てきたやつを購入した。
Logicoolのだ。
Logicoolのマウスは何回か使ったこがある。
どちらも割りとすぐ不調になったこともあって、あまり選択肢になかった。
アマゾンレビュー評価の高さに釣られて買ってしまった。
また、タイムクーポンで500円オフだったのもあった。
明日届くようで少し楽しみ。

木、金と有給をとったので4連休になった。
予定

• Learning Boost残り150ページ程度を読み終える
  
• マリオの続きを再開すること
  
• ゲームを1日1時間以上プレイしてブログを書き始めること
  

こんなところ。
あともう一つ重要なのがあって、PCを買うかどうかと迷っている。
もうしばらくは連休がないので、買うならタイミングは今がベストだ。
でも、今のPCでも使用に際しては、あまり不満はない。
あえていうと、C++のプログラムのコンパイルで若干もたつくことがある。
例えば、std::regexなんかを使ったとき。
これが改善されるなら買い替えてみる価値はある。
あと4Kディスプレイにしたいという願望もある。

デフォルトではxhtml-strictとなっている。
別にそれでもいいけど、html5にすることもできる。
デフォルトをhtml5にするには、.spacemacsのuser-configでorg-html-doctypeをセットする。

(with-eval-after-load 'org
  (setq org-html-doctype "html5")
  )

ファイル個別にhtml5にするには、ファイル冒頭付近に、次のようにしてプロパティをセットする。

#+HTML_DOCTYPE: html5

こちらの方が良いように思える。

まだC++の準備で、本題のシステムプログラミングには入らない。
大体次の3つのパートに分けられている。

• C++17の新機能
  
• RAIIについて
  
• Guideline Support Library (GSL)の導入
  

C++17については、さらっと触れた程度で、あまり深入りはしていない。
すべてを網羅しているわけでもない。
これから使っていくものを紹介しておいた、といったところだろう。
inline variableは初めて知った。
RAIIについては、その重要性がしつこいくらいに強調されていた。
C++ユーザーなら馴染みのある内容ではないかと思う。
GSLはここで初めて触れた。
一部機能が削除されていたりする。
特に、contract(契約)に違反したとき、std::terminateさせるのではなく、例外を投げるように指定するオプション GSL_THROW_ON_CONTRACT_VIOLATION がなくなっているのは大きい。
他には、gsl::cstring_span<>がなくなったりしている。
この章まではまだ前準備といったところで、次の章からが本編だ。
結構楽しみにしている。

ラズパイOSには64ビット版がある。
ここからダウンロードできる。
推奨されているのは32ビット版の方で、自分のラズパイにインストールしてあるのも32ビット版だ。
ラズパイ4Bに搭載されているチップ(SoC)は BCM2711 というもの。
このチップに Coretex-A72 別名 ARM v8 というCPUが含まれている。
詳しくはこちらに書かれている。
このARM v8というのは64ビットのCPUらしいが、32ビット版のラズパイOSだと、32ビットのCPUとして認識される。

$ arch
armv7l

armv7l というのは ARM v7 Little endian を意味しているものと思われる。
そして、ARV v7は32ビットアーキテクチャのようだ。
なぜこんなことを書いているかとういと、昨日読んだHands-On System Programmingに、ちょっと興味深いことがかかれていたためだ。
CやC++のint型のサイズには、x86_64のLinuxでは32ビット幅、つまり4バイトとないっている。
これは言語の仕様で32ビットでなければいけないと決まっている訳ではない。
言語の仕様はもうちょっと緩くて、16ビットや64ビットだったりすることも可能性としてはある。
しかし、現在のPCのデスクトップでプログラミングをしているうちは、だいたい32ビットだろう。
それに慣れすぎているせいで、あたかもintがどこでも32ビットだと思い込んでしまうこともある。
しかし、CやC++の基礎を割りとしっかり学んでいれば、おそらく、この事実は十分に認識されている。
興味を引かれたのは、もう一歩踏み込んだところだ。
int型はデフォルトで利用される整数型で、CPUにとって一番効率の良いサイズが想定されている。
一番効率の良いサイズとは、レジスタのサイズと同じものだ。
つまり、64ビットCPUなら64ビット、32ビットCPUなら32ビットということになる。
でも、x86_64の64ビット版のLinux上ではintは32ビットとなっている。
これは、ただ後方互換性のためにそうなっているらしい。
だいぶ昔、64ビットCPUが普及し始めたころ、64ビットになるとintが64ビットになるものだ、と思い込んでいたことがあって、人にそう言い触らしていたことがある。
結果、CとC++ではintは32ビットのままで、気まずい思いをした。
しかし、今回、あながち間違いでなかったことが分かった。
さらにもう一歩踏み込んで、CISCとRISCでの違いについて書かれていた。
IntelなどのCISCプロセッサでは、64ビットアーキテクチャであっても8ビット、16ビット、32ビットのレジスタが存在している。
そのため、64ビットが最適なサイズではあるものの、例えば、16ビットの整数の演算でもパフォーマンスはほとんど落ちない。
RISCプロセッサでは、そのようなレジスタは用意されていない。
そのため、例えば、16ビットの整数の演算を行うためには、単に演算するだけではなく、いくつか追加の処理を行わなければならず、パフォーマンスが落ちる。
ここで話がラズパイに戻る。
ラズパイのARMv8はRISCプロセッサだ。
だから、ラズパイでintのサイズを確認したら、もしかしたら64ビットになっているのかも、と思って試してみたのだが、ラズパイOSが32ビット版だった。
この環境では、sizeof(int)は4を返してきた。
64ビット版ならどうなるのだろう、ということで、ラズパイOSの64ビット版の存在を確認した。
ここまで書いていて、一つ分かったことがある。
ARMv8のレジスタは64ビットだが、32ビットとしても使用できるようだ。
こういうことなら、おそらく64ビット版でもsizeof(int)は4になっても不思議ではない。

日付と時間を扱うライブラリの章。
大きく分けて3つから成る。

• Boost.Date_Time
  
• Boost.Chrono
  
• Timer Library
  

Chronoは標準ライブラリにも含まれているので、見慣れている。
さらっと使い方が紹介されているだけのような感じがしないでもないが、良くまとまっていて読みやすく、すぐに使い始めることができるようになっている。
この章は他に比べてやや短かかった。
内容もやさしめだった。

1年半前に2章まで読んでいた。
全く思い出せないので最初から読むことにした。
そもそもシステムプログラミングとは何かというところについては、2章の冒頭に次のような一文がある。

System programming is the act of making system calls to perform various actions in coordination with the underlying operation system.

「システムコールを利用するプログラミング」でも大体合ってるけど、基盤となっているOSと強調して様々なアクションを起こすというところまでいうともっと良くなる。
3章まで読んで、まだCとC++の基礎をやっている段階だ。
基礎といっても、普通のプログラミングの基礎ではない。
システムプログラミングにおける基礎だ。
CとC++はシステムプログラミングに利用されることも考えられて設計されている。
そのため、システムプログラミングで特に要求されるような性質が備わっている。
これらは、例えば、アプリケーションソフトウェアのようなものを対象としたプログラミングではあまり表に出てこない。
一体何の役に立つんだ、というようなものが、システムプログラミングでは光を浴びることになる。
もしシステムプログラミングに興味がなくても、言語についてより深く知るために挑戦してみるのも悪くない。

テストの章。
使用するテストフレームワークは、Catch2、Google Test、Boost.Testと定番のもの。
それらをCMakeのテストツールであるCTestと連携させる。
この中ではBoost.Testが一番扱いやすいような印象を受けた。
連続する整数の合計を求める(1から100までの数を足す)という、非常に簡単なプログラムを対象にテストしただけなので、実際にはどうなるのかまだ不明。
ビルドツールやテストツールとかは、学習に十分時間が割り当てられないことがある。
コードを書くことに比べて退屈な部分があるし、あまりスキルアップした実感が得られないこともある。
ビルドもテストもプログラミングのサイクルの一部分であると考えて、軽視すべきではない。
テストの重要性は十分に認識しているのだが、コードを書くのと同じように自然にテストを行う習慣が身に付いていない。
身に付いていないことも認識していて、最初に目次を見たときに、この章に注目していた。
ここまでは読もうと思っていたので、一応目標達成だ。
残りのページにざっと目を通してみると、より高度な話題になっていくようだ。
あまり詰め込み過ぎずに、一旦ここで切っておくのが無難かもしれない。
これまでのことを実戦して、十分に身に付いてから再開することにする。

外部のライブラリやプログラムを利用する方法について書かれた章。
大体はfind_packageの使い方。
実際に色んなケースを紹介していってみるといった進め方だった。

• Pythonインタープリタ
  
• PythonのC API
  
• Pythonのモジュールとパッケージ
  
• BLASとLAPACK
  
• OpenMP
  
• MPI
  
• Eigen
  
• Boost
  
• cmakeのモジュールが用意されていないケース pkg-config を使う / find-module を自前で用意する
  

サンプルを実行するために、システムに色々とパッケージをインストールした。
CMakeで利用する方法を示すのが目的なので、それぞれのライブラリ自体のことについての解説はほとんどない。
この章を読めば自在に外部ライブラリを利用できるようになるのではないかと期待していた。
しかし、そう簡単な話ではないようだ。
様々なケースがあるし、これさえ押さえておけばOK、というものではない。
状況に応じて対応していかないといけないようだ。
直接関係はないのだけど、PRIVATEとPUBLICの使い分けがいまいちよく分かっていない。
何とも消化不良な感じだ。

去年のうちに4Bと400を買ってあるので、必要はないのだが、まだ流通していないようだ。
Amazonでは買えるようだが、2万5千円程度とやたら高い。
半導体不足はまだ解消していないのだろうか。
それとも転売が横行しているのためなのだろうか。
どちらにせよ悲しい状況だ。

価格.comを見てみた。

• Rayzen 5 5600G ￥25,000
  
• Rayzen 7 5700G ￥38,000
  

以前、半年前くらい、見たときよりも安くなっているような気がする。
気のせいかもしれない。
「G」が付くやつは、グラフィックス機能を搭載している。
PCでゲームしないのでそれで十分じゃないだろうか。
グラフィックスプログラミングはするけど、10万近くするようなグラフィックスカードの性能を引き出すようなコードを書くとは思えない。
地元のお店で買いたいのだが￥3000程高い。
というか、まだ買うか決めてない。

ビルド時の環境を検出するという章。
CMakeを使う目的は、単に読み易く、保守しやすく、使い易いというだけではない。
クロスプラットフォームなビルドを可能とすることも重要な要素となっている。
だから、ビルド時にOSやCPUの能力などの環境の情報を取得できることは、必要なことだ。
クラスプラットフォームなプログラムでも、OSやCPUの能力に依存しないようなコードを書ければ良いのだが、現実的ではない。
CMakeはビルドを実行する環境の情報を提供することで、いくらかそれを支援する。
そういう内容なのだけど、今はあまり必要ではないかもしれない。
Linuxしか使っていないので、WindowsやmacOSでも動くプログラムを開発するのは、当面考えなくてよい。
一応、こういう風にすれば良いのだよというアドバイス程度に記憶しておこう。
でもFreeBSDはこれからも使う可能性が高い。

ブログをセットアップしたのだけど書くことがないのでそのまま放置していた。
ゲームプレイの記録なんかどうだろうと考えている。
最近まったくゲームをしていない。
これではいけないので、一日一時間くらいを強制するために、ブログにするというのは悪くないように思える。

帰ってからChapter 2を読もうとしていたが異様に眠くて進まなかった。
そのまま寝てしまった。

Cookbookというタイトルの通り、トピックが細かくレシピという形で区切られている。
トピックが細切れ過ぎてやや読みにくい。
各レシピは完全に独立しているわけでもなく、一応順番に読み進めていくようにはなっている。
ちらっとだけ出てきて十分な解説がされないままになっていて、ちょっと難しいところもある。
例えばジェネレータ式なんがそうだ
。
あまり気にしないでおくことにする。

Zen-Codingとは、HTMLの入力で、省略した形をタイプして、それを展開させるやつ。
Emmetの名前でも知られる。
BluefishはZen-Codingをサポートするのだけど、前々からバグがあって使えなかった。
さっきソフトウェアアップデートを走らせたら、Bluefishも含まれていた。
めったとアップデートされないので、もしかしたら、と期待していた。
試してみると、直ってた。
かなり気分がいい。

テキストエディタのカラーテーマなどでお気に入りのDraculaというテーマがある。
このテーマの配色のウィンドウやウィジェットのテーマがあった。
Solusでは ant-gtk-dracula-theme というパッケージ名だ。
最近はZukitreというテーマを使っていていい感じだったのだけど、デスクットップ下のパネル(タスクバー的なもの)のサイズをいじったら、Emacsのウィンドウを最大化したとき、ミニバッファの一部がパネル下に隠れてしまうようになった。
なので使うのをやめることにした。
ソフトウェアセンターからいいのがないか探してみるとDraculaという名前が目に入ったので、これを使うことにした。
配色はまさにDraculaそのものだ。
見慣れた配色で落ち着くし、テキストエディタやIDEとの統一感もばっちり。
これから長い付き合いになるだろう。

/usr/share/info 以下にtexinfoのドキュメントのファイルは入っているのだけど、dirファイルがないため、目次(TOC)が表示されない。
スタンドアロン版のtexinfoを起動するときに $ info emacs などと指定してやれば見れることは見れる。
しかし、目次がないのはさみしいので、何とかしたい。

1年前くらいに買った本。
Packtのだけど、電子版じゃなくて紙の本。
なかなか良い感じだ。

boost::multi_index_containerとboost::bimapの章。
強力過ぎて手に余る感じだ。
適用するケースを判断する難しさに加えて、インターフェイスの複雑さもある。
std::setやstd::mapのように、自然に使えるようなるにはトレーニングが必要になるだろう。
次の章は「Higher Order and Compile-time Programming」というタイトルで、かなり面白そう。

高階(high order)/コンパイル時(compile-time)プログラミングという章。
コンパイル時プログラミングとは要はテンプレートメタプログラミングのことだ。
基礎的なことから始まって、最後にはSpirit Qiのイントロダクションまで。
十分時間をかけて読んだので、Qi以外は概ね理解できたと思う。
使いこなせるかどうかは、いつものようにこれからのトレニーングにかかっている。

先月書いた起動時の警告

Error (use-package): helm/:config: Symbol’s value as variable is void: \213 Disable showing Disable logging

これは、helmレイヤーを dotspacemacs-configuration-layers から外してやると警告が出なくなった。
spacemacsではデフォルトでhelmが有効になっているので、別にhelmレイヤーを明示的に追加する必要はない、らしい。
何かアクションを起すたびに uncompressing foo-bar.el.gz...done とラグが発生するのもなくなった。
と思ったら、やはりラグは発生する。
勘違いだった。
警告が消えただけでも良しとしよう。

参考：Helm Layer

開き括弧をや引用符を入力したとき、自動で閉じ括弧や引用符を入力してくれるモード。
Spacemacsでは、同じような機能のデフォルトでsmartparens-modeというのが有効になっている。
C++を書いていると、LSPの候補から選択したタイミングで無効になってしまうのが煩わしくて、smarparens-modeを無効にしておいて、electric-pair-modeを使っていた。
突然おかしくなった。

void foo() {
  if (1) {⛇}  // ⛇のところで改行すると…
}


void foo() {
  if (1) {
    ⛇         // カーソルは正しくここに来るが、
}              // 閉じ括弧のインデントがおかしなことになる
}

もう考えるのも面倒なので、spartparens-modeもelectric-pair-modeも無効にした。
手打ちで入力することにした。
何か前時代に戻った気分だ。

Spacemacsでは最初から使えるようになっている。
C++だと SPC i s と叩くと、coutとかcopyとかのスニペットを入力してくれる。
他にもifとかごく基本的なものもあるのだけど、手で入力した方が早い気がする。
本当に使いものになるのかどうかは分からない。
しばらく意識して使ってみよう。

forループを導入。
問題はとてもシンプルなものにした。
セクションに区切るのが面倒で一続きの文章になってしまった。
前々から思っていたいけど、セクションの分割が下手だ。
先に全体の構造を決めて、ヘッディングだけを先に書いてから本文を書き始めた方が、良い構成になりそうだ。
次はそこを意識してみよう。
あとLua入門よりもマリオの方を先に終わらせたいのだが、なぜか入門の方に手を出してしまった。

ひたすら長かった。
最初は良かったのだが、あまりに長くて全てを吟味するまでには至らなかった。
この章は何度も読み返して確実にものにする必要がある。
そもそも何のためにJavaScriptを覚えようとしているかというと、Webで使いたいからなのであって、言語自体に興味があるわけではない。
そう考えると、この章はこの本の最大の目玉と言ってもいい。
あと残り2章。
Node.jsと最後のはおまけみたいな感じだ。

16章はNode.jsの章。
以前「入門Node.jsプログラミング」という本を読んでいたのだけど、全く基礎を理解していないことが分かった。
とにかく、あらゆるAPIが非同期であるということすら知らなかった。
「入門Node.jsプログラミング」はタイトルが不適切だ。
今読み直せばまた新たな発見があるだろう。
その前にもう1冊Node.jsの本のストックがあるので、それ読んでからやってみてもいい。
17章はご褒美の章。
ツールや拡張言語の紹介。
TypeScriptが有名で人気だけど、Flowというののチュートリアルがあった。
価値は理解できるけど、あまり使いたいとは思わない。
これで終了。
読み進めるのにかなり苦痛を伴っただけに、読み終えたときの達成感は半端なかった。
かなりスキルアップしたんじゃないかという実感がある。
一方で、まだWeb開発のスタート地点にも立っていないだろうということも理解している。
まだまだこれからだ。

「Webブラウザ上のJavaScript」というタイトル。
他の
章と比較して桁違いに長い。
現代では、getElementById()や、getElementsByTagName()などのファミリーは使われないらしい。
代わりに、querySelector()とquerySelectorAll()がすべて受け持つみたいだ。
平気で使っていた。
他にも色々情報をアップデートできた。
一部、Web ComponentsやSVGといったところはかなり難しい。
流しておいた。
もう連休も半分終ってしまったのに、まだ読み終えられていない。
Lerning Boostも読んでしまいたいのだけど、無理かもしれない。

ウィジェットのテーマとアイコンのテーマが必要になる。
デフォルトで利用可能なテーマは、それぞれ3つか4つくらいある。
パッケージマネージャーで検索すると、そこそこの数のテーマが見つかる。
ダークテーマよりもライトテーマが欲しい。
Zukitreというウィジェットのテーマがしっくりきた。
アイコンはSurfnというのにした。
Deepinも良かったけど、Geanyのツールバーアイコンが見易いのでSurfnにした。

WikiはDokuWikiにした。
MoinMoinが好きなので使えたら良かったのだけど用意されていない。
でもDokuWikiもすごく良さそうだ。
難点は非常に重いことだ。
最初にアクセスしたとき、5秒以上待たされることがある。
DokuWikiの問題ではなく、サーバーの問題だろう。
BlogはDotclearにした。
WordPressも使えるのだけど、人と違うのにしたかったので採用しなかった。
設置はしたものの、何に使うか、何を書くか、当てがない。
この日記をBlogに移行してしまうという手もある。
しかし、この日記は今のやり方で6ヶ月続いている。
ペースを崩したくないのでやり方は変えない。
猫の写真をアップロードしていくというのもやってみたい。
うちの猫は大人しくてあまり面白いアクションをしてくれない。
それでもやってみれば面白そうではある。

午前中から午後に掛けて、サイ本を進めていたが、猛烈に眠くなる。
折角の休みなのに寝て過ごしてしまった。
結局数ページ程しか進まなかった。
別に本が退屈な訳ではなく、午前中は調子が出ない。
午前中は別のことをするようにしたほうがよさそうだ 。