Sublime Text 3からghqで管理されたリポジトリを開くプラグインを書いた
Sublime Text 3 から x-motemen/ghq で管理されたリポジトリを開くプラグインを書きました。
なぜいま Sublime Text 3
高機能テキストエディタ Sublime Text が Atom と覇権を競い合ったのも今は昔、 ご存知の通りいまやGUIテキストエディタ界は Visual Studio Code の一強状態です。
その勢いたるや凄まじく、[VisualStudio なんとかかんとか][検索] してもVSではなくVSCodeの情報がヒットする始末。
かたや、
- 有料で
- クローズドソースで
- 日本語入力があやしく
- デフォルトの機能がVSCodeに劣っている
Sublime Text 3の人気はもはや風前の灯火、Sublimerは地下深くに隠れ潜み、諦観とともにその再起を祈っている昨今です。
実際私も2年ほど前に、長らく使っていたSublime Text 3 から VSCode に宗旨変えをしました。
しかしながら、ネイティブアプリ特有の素早い起動や、サクサクとした軽快な動作はElectron製エディタにはない魅力です。 というわけでメインのエディタには VSCode を使いつつ、軽い用途や大きいファイルの取り扱いには Sublime Text 3 といった風に使い分けていくことにしました。
ghqとは
ghq はGoで書かれたリポジトリ管理のためのCLIツールです。
プラグイン
VSCode の場合には vscode-ghq 拡張機能によって、簡単にワークスペース間の移動が行えるのですが、 Sublime Text 3 にはそのようなプラグインが存在していません。
今回はプラグインを自作することで、vscode-ghqライクなワークスペース間の移動を可能にしました。
インストール方法
ghqのインストール方法
プラグインの動作にはghqが必要になります。(ghqのインストール方法)
プラグインのインストール方法
- Package Control をインストールする
- コマンドパレットから
Package Control: Add Repositoryを選択し、https://github.com/Ryooooooga/SublimeGHQと入力する - コマンドパレットから
Package Control: Install Packageを選択し、SublimeGHQをインストールする
操作方法
コマンドパレットから GHQ: Open Repository... を選択するとすべての ghq root からリポジトリの一覧が表示されます。
キーバインドを登録しておけばより便利です。
// Default (<OS>).sublime-keymap [ ... // キーバインドの設定例 // Ctrl + Alt + P { "keys": ["ctrl+alt+p"], "command": "ghq_open_repository" } ]
x64セルフホスティングCコンパイラを書いた
前回:
はじめに
セルフホスト(自分自身をビルド)できるCコンパイラmoccを書きました。
前回はバックエンドをLLVMに頼っていたため、今回はx86_64向けのアセンブリを吐くようにしました。 基本的な設計はほぼ前回と同じですが、コードは全て新しく書き直しました。
例によって@rui314さんの低レイヤを知りたい人のためのCコンパイラ作成入門を参考にしています。
工夫した点
基本的な点は、前回とほぼ同じなので上記の記事を参照してください。
前回に比べ、拡張性や規格準拠性を意識して構文木の構造を一部変更しましたが、 結局セルフホストに必要な最小限の機能のみを実装したため、使える言語機能は下記を除けば前回のものと大差ありません。
新しく使えるようにした機能:
- 列挙体
- 変数の宣言時初期化
- 複数の変数の同時宣言
GitHub Actionsを用いたテストの自動化
前回は面倒がっていたテストの自動化を行いました。
GitHub Actionsはお手軽でいいですね。
まとめ
前回のCコンパイラはバックエンドをLLVMに頼っていたため、 x86_64向けのアセンブリを吐くCコンパイラを作成しました。
出力コードの効率などは度外視していたためひどく非効率的なコードが出力されますが、 バックエンドを含め実装することができました。
出力コードの最適化は今後の課題です。
Almel v1.1.3 をリリースした
自作shellテーマ、Almel を更新しました。
v1.0.xとの変更点は以下の通りです。
- コードを全部書き直した
- コンフィグファイルの構造を変えた
- fish, bashに対応した
- 現在時刻を表示する
timeセグメントを追加 - 直前に実行されたコマンドの実行時間を表示する
durationセグメントの追加 - シェルごとに異なる内容を表示できる
shellセグメントを追加
コンフィグファイル (~/.config/almel/almel.yaml) に互換性がないため、エラーが発生する場合には一度コンフィグファイルを削除してください。
コードの全リライトの副作用として若干実行速度がはやくなりました。
また、GitHub Actionsを使って x86_64 環境向けのバイナリ (Windows, mac, Linux) を自動的に用意するようにしました。
v1.1.3 のデフォルトの見た目は次のようになります。
全部盛りのため結構うるさいです。
コンフィグファイルの segments 項目で表示するセグメントとその表示順を変更できます。
以下に自分用の設定を晒します。
os: linux: background: 33 mac: background: 33 windows: background: 33 git_user: background: 75 time: format: "\uf017 %H:%M:%S" duration: background: 242 segments: - - os - user - directory - git_repo - git_user - - duration - status
zshのプロンプトテーマを自作した
自分用にzshのプロンプトテーマをRustで自作しました。 自分が常用しても問題ない程度の完成度になったので公開しました。
セグメントの表示内容は左上から
- OS
- ユーザ名@ホスト名
- (中間省略された) カレントディレクトリ
- Gitブランチ
- Gitユーザ
- 直前の終了ステータス
となっています。(順番、色、表示/非表示などに関してはカスタマイズ可能)
まだREADMEが空っぽなので後で中身を書きます。
以前使用していたプロンプト
bobthefish
ログインシェルにfishを使用していた頃 (~ 2018年9月) はプロンプトテーマに bobthefish を使用していました。
高機能で、更に環境変数によってある程度のカスタマイズができる非常によいテーマでした。 特に、それまではデフォルトプロンプトのbashやfishしか使ってこなかったこともあり、Powerline系のセグメントやGit statusの表示などは一種のカルチャーショックでした。 なにより見た目がかっこいい。テンションがあがるものはよいものにきまっている。
中間pathの省略については好みが分かれるところだとは思いますが、自分はonにしていました。
agnoster.zsh-theme
zshに乗り換えてからは agnoster.zsh-theme をカスタマイズして使用していました。 agnoster.zsh-themeはbobthefish以前に開発されたテーマです。
変更の内容は
- 中間path省略の実装
- 入力位置を次行に
- 直前の終了ステータスの値を表示
- 環境変数でセグメントの色や表示/非表示を切り替えられるように
RPROMPTに直前のコマンドの実行時間を表示- 現在のGitユーザ名を表示
などです。
この1年ほどはこれを使用していましたが、以下のような不満がありました。
- bobthefishに比べGit statusの情報が荒い (dirty/clean程度の情報しかわからない)
- zshスクリプトで書かれているのでコードが読みにくい、書きにくい
- 若干動作がもっさりしているような気がする
今回はzshスクリプトではなくRust、つまりネイティブな言語で実装することでもっさり感と書きやすさを解消したわけです。 ついでにGit statusの解像度をbobthefish程度にまで引き上げました。
他の候補
今回した自作したテーマ以外にも、ネイティブ言語で実装されたテーマは存在しています。
それぞれの特徴と、なぜそれらを使用しなかったかの理由を簡単に述べます。
silver
silver は、同じくRustで書かれたテーマです。bash, zsh, fishに対応しています。
gitコマンドをプロセスとして呼び出してその出力を利用するのではなく、libgit2を使用することで高速な表示を実現しています。 libgit2関係のコードはこのsilverを参考にさせてもらいました。
このテーマの不満点を以下に挙げます。
- 入力位置を2行目にすることができない
- Git statusの解像度がagnoster.zsh-themeと同程度
- エラーが発生するとすぐにpanicする
- mac向けのバイナリがGitHub Releaseに用意されていないので
cargo installする必要があるが、自分用dotfilesではRustのインストールをしないようにしているので扱いが難しい
powerline-go
powerline-go はその名の通りGoで実装されたテーマです。同じくbash, zsh, fishに対応しています。 これは珍しく2行表示に対応したテーマです。
このテーマの不満点です。
ちなみにこのテーマはlibgit2を使用せず、gitコマンドの出力を利用してブランチなどの情報を表示しています。
自作テーマ
そういうわけでなんとなくテーマを自作することにしました。 開発はRustで行い、silverに倣ってlibgit2を利用しています。
デザインは基本的に (カスタマイズ後の)agnoster.zsh-theme をトレースしています。
また、$XDG_CONFIG_HOME/almel/ 以下 (もしくは $HOME/.config/almel/以下)にあるYAMLファイルを読み込むことでセグメントの表示順や表示の有無、色、アイコンなどを自由にカスタマイズできるようになっています。
表示速度に関しては、ざっくり1.5倍程度速くなりました。(zshのプリコンパイル機能は思ったよりつよい)
流石にネイティブ実装は速い (エンター押しっぱなしにしたときのzshテーマの反応) pic.twitter.com/e3D4S5Akka
— りょがまや (@Ryooooooga) 2019年10月16日
これから機能の拡張や高速化をしたりドキュメントを整えたりする予定です。 それから、現在はzshにしか対応していないのでbashにも対応させたいです。
インストール
適当にcrates.ioで公開したのでcargoからインストールできます。
cargoを利用したインストール
$ cargo install almel $ eval "$(almel init zsh)"
zpluginを利用したインストール (現在はmac用のバイナリしか用意していない)
$ zplugin ice from"gh-r" as"program" mv"almel* -> almel" $ zplugin load Ryooooooga/almel $ eval "$(almel init zsh)"
セルフホスティングCコンパイラを書いた
セルフホスト(自分自身をビルド)できるCコンパイラnoccを書きました。
はじめに
去年の夏あたりからCコンパイラを書くのが流行っていたのでやってみました。
例によって@rui314さんの8cc、9ccと低レイヤを知りたい人のためのCコンパイラ作成入門を参考にしていますが、バックエンドにはLLVMを使用しています。
工夫した点
以下、作る上で工夫した点です。
言語仕様に制限をつける
C言語の全仕様を網羅しようとすると到底完成は不可能なのでサポートする言語仕様に制限をつけまくりました。 制限には例えば以下のようなものがあります。
- 変数宣言が初期値を取れない。
- 複数の変数をコンマ区切りで宣言できない。
- typedef宣言や型のconst修飾などはその語順を固定している。
- 型解析時は型のconst修飾を無視する。
- 関数のプロトタイプ宣言はトップレベルでのみ行える。
- 関数ポインタが使えない。(関数ポインタ自体は実装してあるが関数ポインタ型の変数を宣言できない)
- 列挙体が使えない。
- etc
セルフコンパイルに不要そうな機能はあらかた切り捨て、また、そのような機能はできる限り使用せずにコードを書くことで比較的短期間でセルフコンパイルに漕ぎつけることができました。(最初のコミットが2019年4月4日 12:02でセルフコンパイルに成功したのが2019年4月14日 14:30 前後なのでだいたい10日間くらい)
テスト駆動的に開発する
noccの開発はテスト駆動的に行いました。
テストの記述にはLLVMのJITコンパイルが非常に役に立ちました。
参考: nocc/test_engine.c at master · Ryooooooga/nocc · GitHub
意味解析器を構文解析器から分離
構文解析器の中に型検査やシンボルの解決などのコードを書くと、コードが肥大化したり見通しが悪くなったりしがちです。
文脈自由言語であれば、構文解析フェーズで(型情報なしの)抽象構文木を生成し、そのあとで木訪問器(Visitor)を使ってその抽象構文木に型情報やシンボルの情報を追加する手法が取られることがあります。
しかし、C言語は文脈依存言語であるため、(typedef宣言をサポートする場合) シンボルの登録や解決を構文解析と同時に行う必要があります。
例えば、a * b;というC言語のコードがあったとして、このコードがどのような意味を持つのかはそれ以前の文脈に依存します。
{
int a;
int b;
a * b; /* ここでは乗算 */
}
{
typedef int a;
a * b; /* ここではint*型の変数bの宣言 */
}
そこでnoccではswiftcなどを参考に意味解析器をモジュール化し、構文解析器から呼び出されるコールバック関数として実装することで構文解析と意味解析のコードを分割することにしました。
実際のコードを示しながらどのように分割を行ったか述べます。
識別子式の解析
以下の関数、parse_identifier_expr()は単一の識別子からなる式(a, ctx, printfのような)の構文解析を行う関数です。
ExprNode *parse_identifier_expr(ParserContext *ctx) {
const Token *t;
/* トークンを読む */
t = consume_token(ctx);
/* トークンが識別子であることをチェックする */
if (t->kind != token_identifier) {
fprintf(stderr, "expected identifier, but got %s\n", t->text);
exit(1);
}
/* 意味解析モジュールの呼び出し */
return sema_identifier_expr(ctx, t);
}
見ての通り、実装としてはトークンを1つ読んで識別子かどうかを確かめているだけの単純なものです。
このparse_identifier_expr()から呼び出されている関数、sema_identifier_expr()が意味解析モジュールのコールバック関数です。
これは1つの識別子トークンを受け取り、シンボルの解決や型情報の解決を行ったあとその式を表す抽象構文木のノードを返す関数です。
ExprNode *sema_identifier_expr(ParserContext *ctx, const Token *t) { /* 抽象構文木のノードを表す構造体 */ IdentifierNode *p; /* ノードの構築 (省略) */ /* 現在のスコープからシンボルの宣言を探す */ p->declaration = scope_stack_find(ctx->env, t->text, true); if (p->declaration == NULL) { /* シンボルが見つからなかった */ fprintf(stderr, "undeclared symbol %s\n", t->text); exit(1); } /* (省略) */ /* 式の型は宣言された変数の型と同じ */ p->type = p->declaration->type; /* 構築したノードを構文解析器に返す */ return (ExprNode *)p; }
[2019/04/15 追記]
次はより複雑な文の解析を行う場合を見てみます。
複合文の解析
{ ... } によって表現される複合文 (Compound Statement)はレキシカルスコープを形成します。
この文の構文解析は以下の関数、parse_compound_stmt()によって行われます。
StmtNode *parse_compound_stmt(ParserContext *ctx) {
const Token *open;
const Token *close;
Vec *stmts;
/* 複合文の形成するレキシカルスコープに入る */
sema_compound_stmt_enter(ctx);
/* トークンを読む */
open = consume_token(ctx);
/* トークンが 「{」 であることを確認する */
if (open->kind != '{') {
fprintf(stderr, "expected {, but got %s\n", open->text);
exit(1);
}
/* 内部の文の抽象構文木ノードを格納するvectorを生成する */
stmts = vec_new();
/* 「}」 トークンが出現するまで繰り返し文を解析する */
while (current_token(ctx)->kind != '}') {
vec_push(stmts, parse_stmt(ctx));
}
/* トークンを読む */
close = consume_token(ctx);
/* トークンが 「}」 であることを確認する */
if (close->kind != '}') {
fprintf(stderr, "expected }, but got %s\n", close->text);
exit(1);
}
/* 抽象構文木ノードを生成し、レキシカルスコープから抜ける */
return sema_compound_stmt_leave(ctx, open, (StmtNode **)stmts->data,
stmts->size, close);
}
上のコードでは、識別子式の例とは異なり意味解析モジュールが2回呼び出されています。
sema_compound_stmt_enter()関数sema_compound_stmt_leave()関数
これらはそれぞれ「{」の出現時、「}」の出現時に呼び出されるコールバック関数であり、複合文が形成するレキシカルスコープの生成と破棄を担当します。
/* 複合文の開始時に呼び出されるコールバック関数 */ void sema_compound_stmt_enter(ParserContext *ctx) { /* 新しいスコープをスタックにプッシュする */ sema_push_scope(ctx); } /* 複合文の終了時に呼び出されるコールバック関数 */ StmtNode *sema_compound_stmt_leave(ParserContext *ctx, const Token *open, StmtNode **stmts, int num_stmts, const Token *close) { /* 抽象構文木のノードを表す構造体 */ CompoundNode *p; /* (省略) */ /* スタックからスコープを取り除く */ sema_pop_scope(ctx); /* ノードの構築 (省略) */ /* 構築したノードを構文解析器に返す */ return (StmtNode *)p; }
[2019/04/15 追記ここまで]
このように構文解析と意味解析を分離する試みは結果的に成功し、構文解析器 (parser.c) と 意味解析器 (sema.c) 双方の見通しの良さを保つことができました。
まとめ
コード生成はLLVMにおんぶにだっこであんまりちゃんと書けた気がしません。
気が向いたらx86_64のコードを吐けるようにしてみようと思います。
現状です pic.twitter.com/9lWaWAS8w1
— あやか (@Ryooooooga) 2019年4月14日
これでコンパイラ書けます言える
— あやか (@Ryooooooga) 2019年4月14日
他人に堂々とコンパイラハラスメントできる
— あやか (@Ryooooooga) 2019年4月14日
JITコンパイル時の関数呼び出しの扱い方
x86_64での関数呼び出し
x86_64(以下x64)ではcall命令の呼び出し関数の指定を相対アドレスで行うため、JITコンパイルをする際はそのアドレスの取り扱いに苦労します。
#include <stdio.h> #include <string.h> #include <sys/mman.h> int main(void) { const char code[] = { /* * int f(void) { * return add(2, 3); * } */ 0xbe, 0x03, 0x00, 0x00, 0x00, // mov esi, 3 0xbf, 0x02, 0x00, 0x00, 0x00, // mov edi, 2 0xe8, 0x01, 0x00, 0x00, 0x00, // call +1 # (相対アドレスでaddを指す) 0xc3, // ret /* * int add(int x, int y) { * return x + y; * } */ 0x89, 0xf8, // mov eax, edi 0x01, 0xf0, // add eax, esi 0xc3, // ret }; const size_t size = sizeof(code); // 実行可能なメモリ領域を確保する void* ptr = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (ptr == MAP_FAILED) { return 1; } memcpy(ptr, code, size); // 機械語を呼び出す int (*f)(void) = ptr; printf("%d\n", f()); // 5 // 確保した領域を解放する munmap(ptr, size); return 0; }
上の例では、相対アドレス+0x00000001を指定して、その直後に定義される関数addを呼び出しています。
0xe8, 0x01, 0x00, 0x00, 0x00, // call +1 # (相対アドレスでaddを指す)
呼び出す関数がこのように同一のコードセグメントに含まれる場合はこのように指定すればいいのですが、 標準ライブラリの関数やコンパイラ側で定義した関数の呼び出しを行う場合は呼び出しアドレス指定の取り扱いに困ります。
// C言語側で定義された関数 int sub(int a, int b) { return a - b; } //------------------------ 0xe8, 0x??, 0x??, 0x??, 0x??, // call sub (subの相対オフセットがわからない)
レジスタを経由して絶対アドレス指定で関数を呼び出す
このような場合は、レジスタ経由で呼び出すと絶対アドレス指定ができるため、取り扱いが簡単になります。
mov rax, <subの絶対アドレス> call rax
これをコードにすると次のようになります。
int sub(int a, int b) { return a - b; } //----------------------- char code[] = { /* * int f(void) { * return sub(2, 3); * } */ 0xbe, 0x03, 0x00, 0x00, 0x00, // mov esi, 3 0xbf, 0x02, 0x00, 0x00, 0x00, // mov edi, 2 0x48, 0xb8, 0x00, 0x00, 0x00, 0x00, // mov rax, sub 0x00, 0x00, 0x00, 0x00, // 0xff, 0xd0, // call rax 0xc3, // ret }; // subの絶対アドレスを指定する code[0x0c] = (uintptr_t)sub >> 0; code[0x0d] = (uintptr_t)sub >> 8; code[0x0e] = (uintptr_t)sub >> 16; code[0x0f] = (uintptr_t)sub >> 24; code[0x10] = (uintptr_t)sub >> 32; code[0x11] = (uintptr_t)sub >> 40; code[0x12] = (uintptr_t)sub >> 48; code[0x13] = (uintptr_t)sub >> 56;
全コード
#include <stdio.h> #include <stdint.h> #include <string.h> #include <sys/mman.h> int sub(int a, int b) { return a - b; } int main(void) { char code[] = { /* * int f(void) { * return sub(2, 3); * } */ 0xbe, 0x03, 0x00, 0x00, 0x00, // mov esi, 3 0xbf, 0x02, 0x00, 0x00, 0x00, // mov edi, 2 0x48, 0xb8, 0x00, 0x00, 0x00, 0x00, // mov rax, sub 0x00, 0x00, 0x00, 0x00, // 0xff, 0xd0, // call rax 0xc3, // ret }; code[0x0c] = (uintptr_t)sub >> 0; code[0x0d] = (uintptr_t)sub >> 8; code[0x0e] = (uintptr_t)sub >> 16; code[0x0f] = (uintptr_t)sub >> 24; code[0x10] = (uintptr_t)sub >> 32; code[0x11] = (uintptr_t)sub >> 40; code[0x12] = (uintptr_t)sub >> 48; code[0x13] = (uintptr_t)sub >> 56; const size_t size = sizeof(code); // 実行可能なメモリ領域を確保する void* ptr = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (ptr == MAP_FAILED) { return 1; } memcpy(ptr, code, size); // 機械語を呼び出す int (*f)(void) = ptr; printf("%d\n", f()); // -1 // 確保した領域を解放する munmap(ptr, size); return 0; }
structured bindings(構造化束縛)を自作クラスで行えるようにする
はじめに
structured bindings (構造化束縛) をstd::pair<>やstd::tuple<>以外の自作のクラスに対して適用するための方法をコード例込みで解説している日本語の記事が見つからなかったのでメモを兼ねて残しておきます。
結論
std::tuple_size<T>を特殊化するstd::tuple_element<N, T>を特殊化するget<N>(T)/T::get<N>()を定義する
structured bindings (構造化束縛)
Structured binding declaration (since C++17) - cppreference.com
structured bindings は C++17 に追加された有用な機能で、関数の返り値からの多値の受け取りなどを簡便に行える言語機能です。
* 関数から複数の値を受け取る例
// 複数の値を返す関数 std::tuple<int, std::string, double> f() { return std::make_tuple(42, "foo", 3.14); } int main() { // 関数からの返り値を受ける auto [n, s, d] = f(); assert(n == 42); assert(s == "foo"); assert(d == 3.14); }
上の例を structured bindings を使わずに書くと例えば次のようになります。
* structured bindings を使わずに関数から複数の値を受け取る例
int main() { int n; std::string s; double d; std::tie(n, s, d) = f(); assert(n == 42); assert(s == "foo"); assert(d == 3.14); }
structured bindings は、std::tuple<>以外にもいくつかの型についてその恩恵を受けることが出来ます。
* std::tuple<>以外の多値型を受け取る例
{
// std::pair<>
auto [a, b] = std::make_pair("bar", 100);
}
{
// 生配列
int raw_array[3] = {1, 2, 3};
auto [a, b, c] = raw_array;
}
{
// std::array<>
std::array<int, 3> array = {1, 2, 3};
auto [a, b, c] = array;
}
{
// 構造体
// 非staticなメンバ変数はすべてpublicである必要がある
struct S {
std::string a;
int b;
};
auto [a, b] = S { "bar", 10 };
}
自作クラスに structured bindings を適用する
上記に当てはまらないようなクラスについても structured bindings を適用することが出来ます。
例えば次のような privateな 非staticメンバ変数を持つクラスColorを考えます。
* 自作クラス
class Color { std::uint32_t c; public: Color(std::uint32_t c) : c(c) {} std::uint8_t red() const { return c >> 16; } std::uint8_t green() const { return c >> 8; } std::uint8_t blue() const { return c >> 0; } };
(Colorは内部に色の16進表現を保存し、メンバ関数red(), green(), blue() でRGBそれぞれの色要素を取り出せるようなクラスを想定しています)
これをauto [r, g, b] = ...のように受け取りたいのですが、そのままでは当然エラーになってしまいます。
int main() { Color orange = 0xff8000; auto [r, g, b] = orange; // エラー: cannot decompose non-public member 'Color::c' of 'Color' }
一度std::tuple<>に変換する関数を用意してauto [r, g, b] = orange.as_tuple();のように書いてもいいのですが直截的でないので別の方法をとります。
1. std::tuple_size<>を特殊化する
まずはじめに、structured bindings で受け取る変数の個数をコンパイラに示します。
コンパイラはstd::tuple_size<>::valueの値でこれを確認するため、std::tuple_size<Color>を特殊化します。
* std::tuple_size<>の特殊化
namespace std { template <> struct tuple_size<Color> : integral_constant<size_t, 3> {}; // Color は 3要素である }
2. std::tuple_element<>を特殊化する
次に要素の型をコンパイラに示します。
これにはstd::tuple_element<>::typeが使われるため、std::tuple_element<N, Color>を特殊化します。
* std::tuple_element<>の特殊化
namespace std { template <size_t N> struct tuple_element<N, Color> { using type = uint8_t; // 要素の型はすべて std::uint8_t }; }
3-a. フリー関数get<>()を定義する
最後に実際に要素の値を取り出します。
これには関数get<N>(Color)が用いられるのでそれを定義します。
使用される関数はADLによって探索されるので目的のクラスと同じ名前空間に定義すれば良いでしょう。
* get<>()の定義
template <std::size_t N> uint8_t get(const Color& c) { if constexpr (N == 0) return c.red(); else if constexpr (N == 1) return c.green(); else return c.blue(); }
以上で自作クラスColorに structured bindings を適用することが可能になります。
* Colorに対する structured bindings
int main() { Color orange = 0xff8000; auto [r, g, b] = orange; assert(r == 255); assert(g == 128); assert(b == 0); }
3-b. メンバ関数get<>()を定義する
フリー関数get<>()の代わりにメンバ関数get<>()を使用することも可能です。
* メンバ関数Color::get<>()の定義
class Color { ... template <std::size_t N> std::uint8_t get() const { if constexpr (N == 0) return red(); else if constexpr (N == 1) return green(); else return blue(); } };
フリー関数get<N>(Color)と、メンバ関数Color::get<N>()が同時に定義されていた場合、メンバ関数Color::get<N>()が優先的に使用されます。
まとめ
structured bindings はGCC/ClangのみでなくMSVCでも利用することの出来る優れた機能です。
「C++は複数の値を関数から返すことのできない言語だ」などと揶揄されることもしばしばありましたが今やその限りではありません。
* 全コード
#include <cassert> #include <tuple> #include <iostream> class Color { std::uint32_t c; public: Color(std::uint32_t c) : c(c) {} std::uint8_t red() const { return c >> 16; } std::uint8_t green() const { return c >> 8; } std::uint8_t blue() const { return c >> 0; } template <std::size_t N> std::uint8_t get() const { std::cout << "Color::get<" << N << ">()" << std::endl; if constexpr (N == 0) return red(); else if constexpr (N == 1) return green(); else return blue(); } }; template <std::size_t N> uint8_t get(const Color& c) { std::cout << "get<" << N << ">(Color)" << std::endl; if constexpr (N == 0) return c.red(); else if constexpr (N == 1) return c.green(); else return c.blue(); } namespace std { template <> struct tuple_size<Color> : integral_constant<size_t, 3> {}; // Color は 3要素である template <size_t N> struct tuple_element<N, Color> { using type = uint8_t; // 要素の型はすべて std::uint8_t }; } int main() { Color orange = 0xff8000; // こう受け取りたい auto [r, g, b] = orange; assert(r == 255); assert(g == 128); assert(b == 0); }
