C++/Tclの感想
高木です。こんばんは。
先日、C++/Tclについてブログを書きました。
そのときにも書きましたが、私としてはC++/Tclほど凝った機能は必要ありません。
それ以外にもいろいろいいたいことがあります。
今回はそのあたりについて、もう少し深掘りしてみることにします。
最初にお断りしておかなければならないのは、C++/Tclは非常によくできたライブラリであることは確かなので、決してダメ出しをしようということではないのです。
あくまでも私が使う上で、「こうだったらいいのに」という願望レベルの話です。
願望レベルの話であっても、それを踏まえて独自のライブラリを作ることができればそれはそれで価値があることだと思います。
まず挙げるべきなのは、前回も書いたようにCMakeを使うようになってしまった点です。
というか、この規模であればヘッダオンリーライブラリのほうがいいと思うのです。
それであれば、インクルードするだけですのでビルド方法なんか関係なくなります。
残念なことにDebian系のLinuxでは、tcl.hは/usr/include/tclディレクトリに、tk.hは/usr/include/tkディレクトリにインストールされます。
せっかくCMakeを使うのであれば、そのあたりも吸収できればいいのですが、間接的にインクルードするヘッダファイルもそれらのディレクトリの下にあるので、結局はコンパイルオプションや環境変数で#include指令での探索先を指定しなければなりません。
そういうこともあって、ますまずCMakeを使いたくなくなります。
次に、オリジナルのC++/TclはC++98またはC++03しかなかった時代に作られたものなので、Boost C++ Librariesのshared_ptrやbindに依存していました。
いまや、それらのライブラリは標準規格に取り込まれ、Boost C++ Librariesに依存する必要がなくなっています。
そのこと自体はいいのですが、最新のC++/TclはC++17を要求するようになってしまった割には、レガシーなC++の記法を前提とした設計のままです。
それならいっそTR1を使うなどして、C++98/03でも使えるようにしておいたほうが応用価値が高まった気がします。
最新のC++を使うのであれば、ラムダ式を使ってコマンドを作成するなど、モダンな書き方ができてもいいと思います（もしかして、私が気付いていないだけ？）。
Tcl C APIには、何でも文字列で扱っていたレガシーな形式と、Tcl_Objを使った新しい形式の両方が混在しています。
せっかくラッパーライブラリを作るのであれば、レガシーなAPIは相手にせず、Tcl_Objを使った新しいものだけに対応すれば十分だと思います。
Tcl_Objをラッピングしたクラスに変換コンストラクタを用意すれば、レガシーなAPIのように直接文字列を指定することもできるはずです。
いろいろ好き勝手を書きました。
最初に書いたように、C++/Tclは非常によくできたライブラリです。
それは疑う余地がありません。
結局のところ、好みや趣味の問題なんでしょうね。