SSブログ
ソフトウェア/PC関係 ブログトップ
前の10件 | -

Macでバックスラッシュでハマった話 [ソフトウェア/PC関係]

会社で支給されていたThinkPadが,昨年原因不明の不調で起動しなくなり,代替として使えるPCが手元にMacBook Airしかなかったために,仕方なく業務でMacを使うようになった。最近古いPC入れ替えのお知らせが来て,本来ThinkPadでもMacでも選べるはずなのだが,何故かThinkPadの在庫がないと言われて,MacBook Airが業務に使うには非力だったのも事実なので,背に腹は変えられずM1のMacBook Proに入れ替えた。これでもう当分Windows環境には戻れそうにない。

私物としても古いMacBookを持って入るので,まるきり初心者ではないものの,いろいろMacでやり方がわからないことがあると,追求して調べずにWindowsマシンでやってしまったりしていたために,わからないことはわからないままになってしまっていた。しかし業務に私物のPCを使うわけには行かないので,MacBook Proでやっていく上は,なんでもMacでできないと都合が悪い。というわけで現在も試行錯誤しながらやっている訳である。

まず最初に驚いたのは知らないうちに,MacOSのターミナルのデフォルトのシェルがzshになっていたことである。Linuxでもbashしか馴染みがなかったのでzshは全く知らないが,基本的なところは互換性があるだろうから余り気にしない。ただ流石に新しいだけあっていろいろ便利な機能があるらしい(あまり良く把握していない)が,追加の便利モジュールがあるのでいくつか入れてみた。oh-my-zshが便利だとあちこちに書いてあったので入れてみたが,何がどう変わったのかはよく分かっていない。認識しているのは,デフォルトでaliasが色々設定されていたり,各種コマンドライン補完のためのファイルがパッケージされているらしいこと,gitを使うのに便利なプロンプトになるというところだろうか。ただoh-my-zshと一緒に入れたpecoというツールがとても便利である。pecoは別にzsh専用ではないのだが,zshを活用しようと思わなければ存在に気が付かなかった可能性があるのでzshのお蔭といったところになるだろう。Pecoはフィルタコマンドで,標準入力で文字列のリストを渡してやると,CUIでリストの中からいずれかを選択することを可能にする。例えば,カレント・ディレクトリのファイルのリストを渡すとpecoがファイルを一覧表示してくれてカーソルキーを使って目当てのファイルを選択してリターンキーを押すと,選ばれたファイル名がpecoの出力として得られるのである。長いファイル名をすべてキー入力するのに比べると圧倒的に楽になる。私の場合は右手しか使えない状態なので尚更便利である。フィルター機能が秀逸なのだが,その辺,気になった人は色々紹介しているサイトがあるのでググってみていただきたい。

.zshrcでpecoを起動するキーを設定しておくと,コマンドで入力中にファイル名が必要なところでpecoにファイル名のリストを食わせて起動することで操作を楽にすることができる。しかしこれを使って気づいたのだが,lsコマンドやfdコマンドなどでファイルリストを作ってpecoに食わせた場合コマンドラインに戻ってくるのはファイル名に含まれる空白や特殊文字もそのままになってしまうということである。いちばん簡単な解決法はファイル名をそれぞれダブルクォートで囲んでしまうということ。そこで.zshrcを編集して,ダブルクォートを追加するようにしてみた。ここで注意が必要なのは,ダブルクォートがシェルスクリプト中では特別扱いが必要な文字ということである。そのため普通の文字として扱うためにはバックスラッシュでエスケープする必要がある。そんなことはプログラマとしては至極当たり前のことなのでやっているのだが,実際実行してみるとなんかおかしい。ダブルクォートが表示されるべきところに円記号が表示されており,ダブルクォートそのものは表示されていない。なぜだろう。ここでひとしきり悩むわけである。これはしかし後から考えると永年Windowsの世界で生きてきた人間には気づかなくても仕方ないことだったと言えるだろう。私は暫くウンウン唸っていてふと閃いたわけである。それは,MacOSでは「バックスラッシュ」と「円記号」が別物なのではないかということ。

「バックスラッシュ」という記号はそもそもASCIIのエンコーディングでは,0x5cというコードポイントに割り当てられている。一方日本で使われる「円記号」はASCIIでは定義されていない。そりゃそうだ。で,日本のJIS(X201)では1バイトの文字エンコーディングが規定されているのだが,ここではコードポイント0x5cに「円記号」が割り当てられている。そして逆に「バックスラッシュ」は定義されていない。つまりASCIIとJISとでは「バックスラッシュ」と「円記号」が完全に交換されている事になっているのである。その結果として一般的なコンピュータの世界では,コードポイント0x5cの文字は,環境にインストールされているフォントによって「バックスラッシュ」と表示されたり「円記号」と表示されたりするが,文字データとしては同一のものとして扱われてきたのである。ところがいつのMacOSからそうなのかは知らないが,MacOSでは「バックスラッシュ」と「円記号」が同時に存在しうる状況なのである。それこそMacOSらしいと言えるのかもしれないが目に見えているものがまさにそのものなのである。確かに今やUnicodeがOSの標準のエンコーディングとして採用される時代にあって,過去の遺物のようなASCIIコードの事情を引きずり続ける必要はないのかもしれない。しかしプログラミング言語としては,Unicode(UTF-8)のソース・コードをサポートする処理系が一般的になっているとはいえいまだにASCIIエンコーディングのソース・コードも有効な場合がほとんどである。(普通の文字だけを使っていればUTF-8エンコーディングで書かれたファイルはASCIIエンコーディングとしても読めるという事情はあるが)

話を戻すと,Windowsの世界で生きてきたプログラマにとっては「バックスラッシュ」=「円記号」であり,脳内で自動的に相互変換されてしまうのである。ところが今のMacOSではそれが通用しない。エディタに「円記号」が表示されていればそれは純然たる円記号であって,決してバックスラッシュではないのである。それで私が編集した.zshrcでは,私が円記号を入力したので円記号が表示されているだけで,結果としてエスケープされなかったダブルクォートは文字列リテラルを囲む特殊記号として機能していたので表示されなかったというわけである。MacOSでバックスラッシュを入力する方法は[option]+「円記号」だそうだ。プログラミングのときにこれではあまりに面倒だろうから,「円記号」単独でバックスラッシュを入力する設定も可能だそうだ。いずれにしても何か特殊な設定をしていない限り,バックスラッシュが必要なところには目で見て正しくバックスラッシュが表示されていなければならない,ということである。


nice!(0)  コメント(0) 

Windows11でHyper-Vを使う(編集中) [ソフトウェア/PC関係]

なかなかBlog記事を定期的に書くという習慣を取り戻せない...。描きたいことはあるのだがね。先日CrucialのDDR4 32GB DIMMで玉砕したと描いたが,結局あれは諦めて,Teamの16GB DIMMを別に買ってトータル48GBのシステムにした。これだって,一昔前からしたら夢のようなメモリ搭載量である。実際普通に使ったらこんなメモリーは必要ない。使い切れない。というわけで自然と仮想化環境としての利用の話になる。ESXi環境としてしまうと,仮想化ゲストを利用するしかなくなってしまってちょっと残念なのでWindows11の環境のままHyper-VやDockerのホストとして使う方向で行きたい。Hyper-Vを使うにあたってちょっと躓いた点があったのでそんな話を書いていきたい。が,まとめて一気に書き上げる気力も時間もないので少しずつ追記していく形で完成させていこうと思う。

Hyper-Vを使うにあたって考えたのは,以前MicrosoftがVirtualPCを買収して,Windows XPにVirtualPCが標準搭載された時のこと。あの時XP上でXPの仮想環境を構築する場合1ライセンスに限りホストPCのライセンスのもとに仮想環境を利用することができた。果たして今はどうなのだろうか。Windowsの仮想環境を用意しようと思っても,そのためにライセンスを購入しないといけないのではハードルが高い。それはLinuxの仮想環境を作るのであれば問題にならないのだが,Windowsの仮想環境があれば何かと便利である。しかし現在はVirtualPCの時のような太っ腹な措置は用意されていないようだ。まぁ,そうだろうなぁ。しかし,Windows11の開発環境という名目でWindows11が起動可能な仮想ディスクが配布されているのでこれをダウンロードしてくれば,取り敢えず使える環境は手に入ることが分かった。問題はこのOSに有効期限が設定されていることだ。現時点で手に入るものの有効期限は2023年1月10日となっている。長期的に利用できるものではないのだ。期限が過ぎたらまた新しい仮想ディスクが配布されるのかもしれないが,自分でしたカスタマイズなどはまたやり直しである。それを割り切って使うか,おとなしくライセンスを購入するかは悩ましいところだ。Power Auotomateを使って初期設定プロセスを自動化するなどの手は使えるかもしれない。

そんな訳で長期利用の問題はさておき,取り敢えず無償で開発環境を使うにあたってちょっと躓いたことがあったので,次の更新でその辺りを追記して行きたい。


nice!(0)  コメント(0) 

DDR4メモリの互換性にハマる [ソフトウェア/PC関係]

少し前にネット・オークションで購入したマザーボードで組み立てたPC用にDDR4の32GBメモリーを購入して挿してみたが見事に動かなかった。Z170チップセットとZ390チップセットのマザボ。メモリに相性があるとかそういう感覚を全く忘れていた。Crucialだから大丈夫だろうとか勝手に考えてたけど,マザーボードのサポート・リストにはCrucialはあまり載ってないみたいなので,認識を改めよう。高い授業料だった。ネット・オークションで売っぱらうかな。売れるかな。動作確認できないからジャンク扱いだと安そうだが。


nice!(0)  コメント(0) 

git-cryptをcygwin環境でビルドしてみる [ソフトウェア/PC関係]

特に脈絡もない話題だが,cygwin環境でgit-cryptを使用する必要に迫られたので調べてみた。

git-cryptはパスワードなどの情報を暗号化してgitレポジトリに格納するための透過的な仕組みであるが,gitの標準的なパッケージには含まれていないため,別途用意する必要がある。ところが残念ながら,cygwinにはパッケージが用意されていない。Linuxのubuntuにもないようなので,それはまぁ仕方ないところだろう。それじゃ自分でビルドしてやろう,ということになるわけだ。

git-cryptはgithub上のレポジトリ,https://github.com/AGWA/git-crypt で公開されている。レポジトリのファイルの中に,ビルドの仕方についてのドキュメントも含まれている。それによると,ビルドにはGNU makeとg++,libssl-devの3つのパッケージが必須のようだ。cygwinにも相当のものはあるので,cygwinのインストーラー(setup.exe)で事前にインストールしておこう。もちろんgit-cryptを動作させるためにも,git-cryptのレポジトリをクローンするためにもgitのパッケージが必要である。

で,まず手始めに,適当なディレクトリで「git clone」を実行して git-cryptのレポジトリをクローンする。次に,git-cryptのディレクトリに移って,makeを実行する。

cd git-crypt
make

これであっさりうまくいくかと思いきや,util.cppのコンパイル中にあえなくコンパイルエラーが発生する。

g++ -Wall -pedantic -Wno-long-long -O2 -std=c++11   -c -o util.o util.cpp
In file included from util.cpp:156:
util-unix.cpp: In member function ‘void temp_fstream::open(std::ios_base::openmode)’:
util-unix.cpp:79:38: error: ‘mkstemp’ was not declared in this scope; did you mean ‘mkdtemp’?
   79 |         int                     fd = mkstemp(path);
      |                                      ^~~~~~~
      |                                      mkdtemp
util-unix.cpp: In function ‘std::string our_exe_path()’:
util-unix.cpp:135:51: error: ‘realpath’ was not declared in this scope
  135 |                 char*           resolved_path_p = realpath(argv0, nullptr);
      |                                                   ^~~~~~~~
make: *** [<builtin>: util.o] Error 1
  
mkstemp関数が宣言されていないとはどういうこと? stdlib.hもインクルードしてるのに。狐につままれたような気分でmkstemp関数だけを呼び出すテストコードを書いてみたら,問題なくコンパイル出来た。違いはなにかというと,コンパイル・オプションだろうか。上記の出力を見ると一目瞭然だが,git-cryptの方は「-std=c++11」が指定されている。C++11仕様でコンパイルするという指定だ。C++11でmkstemp周りが変更されたという認識はなかったが,試しにこのオプションを外してみることにした。C++11じゃないとコンパイルできないコードがあればエラーになるだろう。と思っていたが結果的に何のエラーもなくビルドが完了した。それならわざわざ「-std=c++11」を指定してる理由は何なのだろう。このまま使っているとなにか不具合が起きるのだろうか。取り敢えず手元の暗号化/復号化は動作しているようなのであまり深く追求する気はない。しばらく様子見としよう。
nice!(0)  コメント(0) 

Node.jsでグローバルにインストールしたモジュールをrequireする方法 [ソフトウェア/PC関係]

最近,仕事でJavaScriptでコーディングする必要が出来て,あれこれ調べながらやってみている。JavaScriptは私のように昔から様々なプログラム言語を学んできた人間にとっては少々厄介な言語に見え,これまでにも何度か習得を試みたのだがその都度撃沈してきたのである。まぁ仕事で必要とか,真に迫った動機がなかったこともあるのだろうが。言語の指定さえなければ他にいくらでも選択肢はある。

という訳で,いろいろ調べて分かったことをこのblogにその都度記録しておこうと思う。twitterとかだと後で確認するのが面倒なので。

で早速JavaScript,というよりむしろnode.jsの話なのだが,npmを使ってsqlite3のようなモジュールをグローバルにインストールした場合,jsスクリプト内で下のように,

let sqlite3 = require("sqlite3");

とやってもモジュールが見つからないというエラーになってしまう件について。

要はアプリケーションのワークスペースを作ってローカルにインストールしてそこからスクリプトを実行するという手順を踏むのが面倒くさいというわけである。結論から言うと,NODE_PATHという環境変数に

> npm root -g

を実行して返ってきたパス文字列を設定してからnodeコマンドを実行すれば良い。それならnode.jsのインストール時に自動的に設定してくれれば良さそうなものだ。グローバルにモジュールをインストールするという仕組みがせっかくありながら,デフォルトでは利用できないというのはなんとも不可解だ。もっと調べればこの辺の事情もわかるかも知れないが,私的には使えれば良いのでここでやめておく。


nice!(0)  コメント(0) 

Open Live Writer で投稿してみるテスト [ソフトウェア/PC関係]

マニュアルでHTML書くのは流石に面倒になってきたので。

上手くいくかな?


nice!(0)  コメント(1) 

C++20の新機能Rangesを使ってみたい!(2) [ソフトウェア/PC関係]

C++ Rangesの話の続き。であるが,Rangesの機能の話を続ける前に,試してみる環境の話をしたい。記事のタイトルも「Rangesを使ってみたい」だったわけで。プログラミング言語の機能なのだから,実際にプログラムを動かしながらやっていきたいところだ。

C++ Builderの記事でも書いたが昔は無料で試せるC++コンパイラなどまずなかったが,今や最先端の処理系を基本的に無料で試すことができる。ありがたい時代になったものだ。今世界的に代表的なC++コンパイラといえばMicrosoftのVisual C++,GNUのg++,そして様々な会社が関わって開発されているClangの3つといってよいだろう。各陣営(という言い方が適当かはわからないが)標準化に対するスタンスは微妙に違うようだが,新しい標準への対応や提案段階の機能の試験的実装などが早いのは確かである。なので,新しい機能を実際に試してみようと思ったら,まずこれら3つの処理系をチェックしてみると良い。しかもWindows環境では3つのどれも無料で使用可能である。VC++の場合は,個人利用や小規模な企業などライセンス条項の使用権に該当すればVisual StudioのCommunity Editionを無料で利用できる。無料バージョンとは言え,製品版のProffessional Editionと機能的にほぼ同等なので,C++を試してみる分には何ら不足はないはずだ。 g++とClangについては,基本的にはLinux環境向けに開発されているオープンソースのソフトウェアである。が現行のWindowsではどちらも利用可能になっている。その方法は2通りある。1つはcygwinというLinux互換ツール環境を使う方法で,もう一つはWSLというWindows上でLinuxを動作させる仕組みを使うことである(詳しい人にはDockerを使ったり,Hyper-Vのような仮想化環境を使うなどの選択肢もあるがここでは触れない)。どちらも標準インストールのWindowsには含まれていないので,自力でインストールする必要がある。インストール方法についてはInternet上にいくらでも解説しているサイトを見つけることができるのでここでは割愛する。

cygwinもWSLもインストールしただけではg++もClangもインストールされていない可能性があるので必要に応じて追加パッケージのインストールが必要となる。例えばcygwinでは標準ではg++がインストールされないので,cygwinのインストール時に使用したセットアップ・プログラムを再度起動して,パッケージ選択画面で,「View」を「Full」に変更してから「Search」欄に「g++」と入力して検索する。検索結果の中に「gcc-g++」というパッケージが見つかると思うので,マウスでダブル・クリックすると「New」列の表示が「skip」からバージョン番号に変わる。現時点では選択できるg++のバージョンはいくつかあるのだが特に理由がない限り最新バージョンを選んでおけばよいだろう。私の環境では11.2がインストールされている。Clangの場合はcygwinではあまり新しいバージョンのパッケージは用意されていなくて。私の環境では8.0.1となっている。これで良ければg++と同様のやり方でパッケージをインストールできる。

WSLの場合,Linuxのディストリビューションと同じものが動作すると考えて良いので,Linux用に開発されているソフトウェアは最新版が利用できると考えて良い。私の環境では好みでubuntuを使用しているので,ubuntuを例にとって説明する。WSL2で配布されているubuntuにはいくつかのバージョンが有り,少し前までは20.0.4が最新であった。このバージョンならwslコマンドでインストールできる。ただ,こいつは少し古いので,配布されているソフトウェア・パッケージのバージョンが最新ではない場合がある。もちろん,自分でソース・コードからビルドすれば最新バージョンを使うことは可能だが色々と面倒くさい場合がある。私の調べたところubuntu20.0.4でふつうにaptコマンドでインストールできるのはg++が9.3.0であった。しかしテスト版のパッケージを配布しているサイトを登録するとg++11をインストールできた。手順についてはこちらのサイトを参照されたい(英語だが,特に難しいことは書いてない。テスト版パッケージの利用は自己責任なので悪しからず。) Clangに至ってはubuntu 20.0.4のインストール直後にはパッケージすら見つからなかった。だが,以下のコマンドで,リストをアップデートしてから再度試したらたらインストールできた。バージョンは10.0であった。

user@hostname ~/cpp
$ sudo apt update

....(出力は省略)...

もっと新しいバージョンを使いたい場合は,Clangの公式サイトからpre-built版をダウンロードできる。ダウンロードしたアーカイブ・ファイルを展開しまるごと/usr/localにコピーすれば使えるようになる。現時点の最新版はバージョン14である。

user@hostname ~/cpp
$ tar xf clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz

user@hostname ~/cpp
$ cd clang*

user@hostname ~/cpp/clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04
$ sudo cp -R * /usr/local/

ubuntu 20.0.4のところで「少し前までは最新」と含みをもたせた書き方をしたが,実は今週になって22.0.4が利用可能になり,WSL2版も用意されたのだ。まだwslコマンドではインストールできないようだが,「ストア」アプリからはインストール可能になっている。最新版だけあって,g++も11.2,Clangも14.0をインストールできる。現状これを使うのが一番お手軽である。

とこれで有力な3大処理系が揃ったことになる。これはなんとも贅沢な環境だ。問題はRangesのサポート状況だが,こちらのページにC++の各改訂版の新機能の処理系別のサポート状況がまとめられている。Ranges は「c++ 20 library features」の表の中段くらいに「The One Ranges Proposal」として載っている。これによるとg++はバージョン10で一部サポート,Clangはバージョン13で一部サポート,VC++はバージョン19.29でサポート(*が付いてるが)となっており,どの処理系でもまだ完全サポートには至っていないことを窺わせる。最新の機能なので仕方ないとも言えるし,C++20に取り込まれたRangesがまだ不完全と言われていることも関係しているかも知れない。そんな訳で実際どのくらいまで使えるものかは,実験してみるしかない。次回はその辺りを書きたい。


nice!(0)  コメント(0) 

C++20の新機能Rangesを使ってみたい! [ソフトウェア/PC関係]

先日,数十年ぶりに本業のプログラム開発でC++言語を使う機会を得た。この間はJavaやらPythonやらを使った開発仕事しかなかったのだ。今回は単発仕事とは言え,使用する言語仕様も自由にしてよいという制限の少ないものだったので,心置きなく新しい標準仕様(世間ではModern C++と呼ばれることが多いようだ)を使わせてもらった。とは言え新しい機能は私自身よく理解できていなかったものも多く,そういう意味では限定的ではあったが。しかも使用するライブラリがVC++の/stdc:c++17オプション(ISO C++17規格)でコンパイルできないものがあったせいで最新のものは使えなかったのだが。

C++の標準化に関わっている身としては最新規格の機能を全てちゃんと理解しておくべきなのだが,仕事でガッツリ使う機会がないとなかなか理解は深まらないものなのである。実際今回の仕事を通して理解が深まったものも多いし,ついでにちょっと学習意欲が高まったこともあり,以来いろいろ文献を読んだりしている。そんな中,今ちょっと興味が高まっているのはRangesである。これは文字通りC++で範囲を扱うための仕様で,2020年発行の規格改訂版C++20で新規に取り込まれたものだ。C++の標準化の進め方として,ある程度規模の大きい機能は,まずTechnical Specification(TS)という独立した仕様(といっても現行のC++の拡張仕様という形)にまとめて,単体で議論し,実際に使ってみてから,それを元にブラッシュアップしてC++本体仕様に取り込むという手順になっている。そんな訳でRangesが最初に提案されたのはだいぶ前でTSの時点で目にはしていたのだったがちゃんと読んでなかったということか,どうも内容を間違って認識していた事がわかった。お恥ずかしい限りだが,この際ちゃんと理解して使えるようにしておきたい。で,範囲を扱うというのは間違いではないのだが,単に範囲を扱うクラスを導入すると言うだけでなく,C++の標準ライブラリを巻き込んだ影響度の大きい仕様だったのだ。

ざっくり説明するとコンテナ・クラスとそれを扱うためのアルゴリズム・ライブラリの改訂ということになる。コンテナクラスというのはvector,list,map,setなど,複数の同じタイプのデータをまとめて管理・処理するためのクラスである。C++でアルゴリズムというとコンテナのインスタンスに含まれるデータを対象に何らかの処理を行うライブラリである。代表的なものにはソートがある。アルゴリズムがコンテナを処理するためには普通コンテナに含まれるデータに順次アクセスできる必要がある。しかしながらコンテナと呼ばれる各クラスはそれぞれ目的もデータの管理の仕方も別々であるし,必ずしも継承関係にないので,そのままでは全部別々のアクセスの仕方をする必要がある。つまりソート一つとっても,コンテナ・クラス別に用意しなければならなくなってしまう。これはあまりに非効率だ。ソートのアルゴリズムは共通なのにデータのアクセスの仕方が違うというだけで,アルゴリズムを実装したコードがコンテナ・クラスの数だけ重複して存在することになる。それでは,メンテナンスの観点でもよろしくない。これをどのように解決したかと言うとIterator(反復子)である。Iteratorは各コンテナ・クラスとは別のクラスであって,大雑把に言うとポインタである。典型的にはコンテナの中の1つのデータを指すポインタであって,*演算子を適用することでデータの値を読める。そして++演算子を適用することで次のデータを指すように変化する。そしてコンテナ内のデータの末端を表すもう一つのIteratorの値と同値になるまで++演算子の適用を繰り返すことでコンテナ内のすべてのデータを読めるようになっている。Iteratorは各コンテナクラス毎に,演算子オーバーロードを駆使して定義されるが全て同じインターフェースを継承しているのでIteratorに対応したアルゴリズムは,異なる種類のコンテナ・クラスを共通して扱えるというわけだ。このようにIteratorは先頭のデータを指すものと,末端を指すもの(通常は最後のデータの次を指す)の2つを組にして利用するようになっている。先頭と末端で囲まれたデータ,ということはこれは範囲にほかならない。Rangesが組み込まれる以前はIteratorのペアとして範囲を扱っていたのだ。例えば整数のvectorをソートすることを考えてみる。Ranges以前は次のようになっていた。

#include <algorithm>
#include <iostream>
#include <vector>

using namespace std;

int main()
{
	vector vec {10, 5, 3, 7, 1, 4};
	
	sort(vec.begin(),  vec.end());
	
	for(auto x : vec){
		cout << x << endl;
	}
	return 0;
}

begin関数はvectorクラスの先頭の要素を指すIteratorを返す関数,end関数は末尾を指すIteratorを返す関数である。そしてsort関数がIteratorのペアを引数にソートを実行するアルゴリズム関数である。これをコンパイルして実行すると次のように出力される。

user@hostname ~/cpp
$ g++ sort_ex.cpp -std=c++20 -o sort_ex

user@hostname ~/cpp
$ ./sort_ex
1
3
4
5
7
10

これはこれで,そういうものだと思えば納得なのだが,いちいちbeginとendを自分で呼び出してやるのは煩雑である。こんな決まりきったコードをプログラマに書かせないで済ませるのがオブジェクト指向の良いところだろう。シンプルにコンテナのインスタンスをポンと渡してやって済ませられないだろうか。Rangesはこの問題を解決してくれる。仕組みとしてはbeginとendの2つのIteratorを1つにまとめて扱うためのデータ型のようなものを導入しているのだが,endの部分が少し変更になっている。Ranges以前はbeginとendが必ず同じクラスのメンバーでないといけないという制限があったがそれがなくなり,単に番兵(sentinel)と呼ばれる,末端を判断するためにbeginと等値比較ができれば良いようになった。なんだかよくわからないかも知れないが,これはとりあえず自分でコンテナ・クラスを定義したりしない限り余り用がない。普通に使うならbeginとsentinelは表に出てくることはないからだ。先程のsortの例は,Rangesバージョンだと次のように書ける。

#include <algorithm>
#include <iostream>
#include <vector>

using namespace std;

int main()
{
	vector vec {10, 5, 3, 7, 1, 4};
	
	ranges::sort(vec);
	
	for(auto x : vec){
		cout << x << endl;
	}
	return 0;
}

違いはstd名前空間のsort関数ではなくstd::ranges名前空間のsort関数を使うことと,2つのIteratorの代わりにコンテナ・インスタンスそのものを引数に渡すところでだけある。これだけでもだいぶシンプルになったのが分かるだろう。このようにRangesではもともと存在していたアルゴリズム・ライブラリをRanges対応に置き換えたライブラリが提供されるのである。RangesがSTL(Standard Template Library) v2とも呼ばれているのはそうした理由からであろう。C++の最初のISO標準であるC++98から存在しているSTLがより近代的に改訂されたのである。とは言え,sort関数の引数が1つになったくらいではそれほど大した話ではないと思うだろう。実際Rangesの恩恵はそんなものではないのだ。そうしたことについてはまた次回。


nice!(0)  コメント(0) 

まだまだ現役だったC++ Builderの無料版を試してみる [ソフトウェア/PC関係]

失礼ながら既に過去のものと思いこんでいた,C++Builderがまだしっかり現役であることを今日たまたま知った。現行バージョンは11で,リリースは昨年の9月である。前身のBorlandのTurboC++のバージョン1.0からしばらくかなりお世話になっていたので,なんだか嬉しい気分になる。何しろ当時は,C++コンパイラが無料で簡単に手に入るという状況ではなく(機能的に制限のあるものが限定的に無料で配布されていたことはあったが),学生が個人で手軽に購入できるようなC++コンパイラはTurbo C++しかなかった。しかもちょうどANSI C++の規格が発行されたばかりの頃で最新の標準規格のC++コンパイラが使用できるということでかなり興奮したものである。その後,バージョンが上がるごとにきっちりアップデートして最終的にはBorlandブランドのC++Builderの初期バージョンまで使っていた記憶がある。そんな訳でBorlandのプログラミング言語製品がEmbarcadero に売却されたときは言いようのない寂しさを感じていたものだ。他にもTurbo AssemblerやらTurbo Debuggerやら果てはDelphiまで購入して使っていたので一つ一つは安価でもBorlandにはトータルでかなりの額を投資していたのである。

その後Embarcaderoからは古い言語製品が無料で配布されたりしてはいたものの,所詮古い製品であり,無料で各種の高品質なC++コンパイラが利用できる現在では懐古趣味的な興味しか持てないものだった。以来すっかりC++Builderのことは忘れていたが,そんな期間もしっかり進化を続けていたようだ。去年のリリースではあるがC++20には未対応とは言え,C++17には対応している。専用のパッケージ・マネージャでインストールするだけで利用可能なBoostライブラリも用意されている。で一番重要なのは無料のCommunity Editionが利用可能なことだ。これは製品版のProfessional Editionと機能的にほぼ同等な上に,制限付きとは言え,個人であれば営利利用もOKという太っ腹なものだ。利益が大きなソフトウェアを開発する場合には有料版を買ってくれということのようだ。有料版の価格はそこそこいいお値段がするのだが(しかも最低一年はサポートも込みにしないといけないらしい)儲かりそうな場合に金を払えば良いというのなら,十分リーズナブルと言える。但し,Community Editionは最新バージョンではなく1つ前のリリースのようだ。つまり現在利用できるCommunity Editionは10.4.2である。10.4.2の製品版のリリースは去年の2月なので,実質半年くらい遅れているだけである。どうしてもバージョン11の新機能が使いたいというのでなければ10.4.2で充分であろう。そうでなくても少し待てば11も利用可能になるようである。

大いに興味をそそられたので,試してみることにした。ダウンロードするにはEmbarcaderoへの無料ユーザー登録が必要だ。私の場合は元々IDを持っていたのでそれを使った。ダウンロード・サイズが140Mバイト程度だったので随分コンパクトだと思ったら所謂ダウンローダーだった。実際にインストールしてみたら1Gバイト以上はダウンロードしていた。動作環境ののWindowsは8.1以降とのことだが,8.1でインストーラを起動したらサポート対象外だというメッセージが表示されたのはご愛嬌だろう。対象外と言われても,インストールを続行したら,そのまま問題なくインストールは完了した。途中でシリアル・ナンバーの入力を求められるが,ダウンロード時に使用したIDのメール・アドレスにシリアル・ナンバーが送付されてくるのでそれを入力すれば良い。このシリアル・ナンバーのライセンスは1年のようで,期限が来たら再発行が可能らしい。その頃には新しいバージョンがリリースされているだろうから,インストールし直すのも良いだろう。

インストール後,手始めに「コンソールアプリケーション」の新規プロジェクトを作ってみた。空っぽのmain関数を含むソース・ファイルが自動生成されるので,そこに自分のやりたいことを追加していけば良い。ここで早速一つ謎が...。今時当たり前ではあるが,C++Builderのコンパイラは64ビット対応なはずである。しかし,新規生成されたプロジェクトのターゲット・プラットフォーム欄には「Windows 32ビット」という表示。ドロップダウン・リストになっているが拡げても64ビットという選択肢はない。今時32ビットがデフォルトというのも不思議だが,問題は64ビットに変更する手段がわからないこと。あちこちのメニュー項目を試してみたがそれらしい設定はない。そこでようやくヘルプを検索してみることに。そうしたらすぐ見つかった。新規生成されたプロジェクトのウィンドウのの右上に表示されている「Project1.cbproj -プロジェクト」とタイトル・バーに表示されているペイン(プロジェクト・マネージャというらしい)にツリー表示されている中の「ターゲット・プラットフォーム」を右クリックしてコンテキスト・メニューの「プラットフォームの追加」を選択。「プラットフォームの選択」という小さなダイアログが表示されるので,そこで「Windows 64ビット」を選択してOKボタンを押せば良い。まぁ最初からヘルプを見ればよいだろうと言われるだろうが,操作が今ひとつ直感的でないことは否めない

次にBoostライブラリの使用であるが,これは最初に書いたように自分でインストールする必要がある。それにはC++Builderのウィンドウのメニュー・バーから[ツール]-[GetIt パッケージマネージャ]を選択する。表示されたウィンドウの左のペインから「カテゴリ」の下の「C++ Libraries」を選択すると右ペインに利用可能なライブラリが一覧表示されるがリストの最初の方に「Boost 1.70 for the Win64 Toolchain」というようなのが見つかるはずだ。これがwindows 64ビット用のようだ。バージョン番号は時期によって変わるかも知れない。これをクリックすると「インストール」ボタンが現れるのでそれを押せばインストールが開始される。インストールが完了するとソース・ファイルでBoostのヘッダ・ファイルを読み込んで使用可能になっている。

まだ使い込んだわけではないので正確なところはわからないが,MSのVisual Studioに比べると動作は軽いような気がする。おまけに未検証だがiOSやAndroidのプログラムも作成可能なようだ。一瞬,「おおっ!」と思ったが,iOSのプログラム開発ではやはり結局Macが必要らしいので,どれだけ有難味があるものかはよくわからない。私的に少し気になるのはIDEのエディタの使い勝手である。改行が表示されず,実際のファイルの行末に本当にスペース文字があるなしに関わらずカーソルが自由に置けてしかもそこに文字を挿入できるという仕様になっているようでとても気持ちが悪い。意図せず無用なスペースを入れてしまいそうなインターフェースと言える。何らかの設定ができるのかも知れないが。

もう少し使い込んでみないとよくわからないとは言え,C++17とBoostライブラリを手軽に試してみる環境としては面白いのではないだろうか。


nice!(0)  コメント(0) 

kindleのポピュラー・ハイライト表示メニューはどこへ [ソフトウェア/PC関係]

Androidのkindleアプリでのメニュー

主要な電子書籍サービスのひとつAmazonのKindleにはハイライトという機能がある。要はマーカーのようなもので,気になったセリフなどに印や傍線を引いておくことが出来るものだ。デジタルならではの機能としては,マーカーを引いた箇所を検索することが出来る。紙の本と違って本を汚すことにもならないし,これだけなら,とても便利な機能だと思うのだが,ハイライトにはもう一つ極めてお節介で迷惑な機能がある。ハイライトを自分だけで利用できるのではなく,世界中の同じ本を読んでる人の間で共有されるのだ。もっとも,のべつまくなしに共有されるのではなく,同じ箇所をハイライトした人がそこそこ多くいる場合だけのようだが,何処の誰とも分からない人の引いたハイライトなど邪魔でしかない。図書館で借りた本に誰かがマーカーや傍線を引いてしまってるようなものだ。しかも困ったことに,ハイライトには「何人がハイライトしてる」みたいな注釈が小さく表示されるのだがこれまた激しく邪魔なのである。例えば特殊な読みをするような漢字に著者がわざわざルビを振っている場合,表示が重なって読めないことがあるのだから始末に負えない。Amazonはこの機能に余程自信があるのかデフォルトでオンになっており嫌な人は自分で機能をオフに設定する必要がある。しかしこの設定メニューがとんでもなくわかりにくいところにある。更に言うとKindleアプリのバージョンによって設定メニューの場所が変わるようで,以前ここにあったはずと思うところになかったり,Webでググって調べても,そこに書かれている通りに出来ないことがある。私も最近Kindle Paperwhiteではまって,メニューがねーぞ!!とTwitterで呟いたらKindleの中の人が教えてくださった。余談だが,Amazonの中の人はTwitterをかなり力を入れてウォッチしてるみたいで,特にハッシュタグを何も付けずにAmazonの不満をつぶやくと驚くほどの速さでリプライを下さる事がよくある。

で肝心の設定メニューだが,確か以前のAndroidアプリではホーム画面の[その他]の[設定]の中にあったはずが(ググって見つかるサイトのほとんどがこちらを案内している),現時点では別の場所に移動になっている。それはkindleアプリで何か書籍を開きページのどこかページ送り以外の場所をタップしたときに上端に表示されるメニューバーから「Aa」をタップする。すると画面下にフォント関連の設定変更のパネルが表示される。その上部に「その他」というのがあるのでタップすると,ポピュラー・ハイライトの表示のオン・オフの設定が現れるのである。但し,このメニューはポピュラー・ハイライトが設定されていない書籍では表示されないみたいなので注意が必要だ。通常は本を読んでいて邪魔だと感じたときに設定するのだろうから問題はないはずだ。それにしても,わかりにくい場所に移動したものである。以前の方が余程直感的だった。そういう意味では悪いUIの代表例とも言える。Amazonはそこまでしてもこの機能をオフにして欲しくないのかもしれない。大きなお世話であることに変わりはないのだが。

因みに私の確認した限り,iOSでもAndroid(FireOS含む)でもPaperwhiteでも同じ場所にメニューはあった。またどこかへ行ってしまうかもしれないが本記事はそれまでは有効である。


nice!(0)  コメント(0) 
前の10件 | - ソフトウェア/PC関係 ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。