Twitterでもちょっとつぶやいたけど。

最近引っ越したのだけど、この引越し先、共用のインターネット接続サービスが導入済な親切仕様。
で、基本はプライベートIPアドレスが割り当てられるのだけど、入居前に確認したら、有料でグローバルIPアドレスをもらえるオプションもあるとのことだったので申込書を取り寄せた。

今日届いたので中身を確認したら、単にグローバルIPアドレスなだけではなく、基本的に固定アドレスになるらしい。
これはいいものだ、と嬉しくなりながら読み進めていくと、次の文面が。

サーバの立ち上げは、禁止とさせていただきます。
独自ドメインでの立ち上げは、禁止とさせていただきます。

……えーと、正に独自ドメインでサーバを立ち上げたいがためにグローバルアドレスが欲しかったわけですが。

共用回線だから、サーバなんぞ立てられた日には帯域を食い潰されて他の人の迷惑になる、との考えからの制限だと考えるとそれほど理不尽な制限ではないけど、自分が使いたい用途に使えないことには変わりはない。
サーバを立てたい主な理由に、自宅LAN内のファイルやPCに出先からアクセスしたいというものがあるので、外部のホスティングサービスを使うという選択肢はない。
ということで、サーバ用途には別回線を用意する必要があるけど、さてどうしたものか。

・案1: 手持ちのモバイル回線を使う。サーバ以外の用途には共用回線を使う。
長所: 追加投資が不要。ついでに言うと、既に環境は組んであるので追加設定もほとんどいらない (サーバのトラフィックが共用回線に出ないように制限する程度)。
短所: サーバ回線が遅い。特に上りが遅いので出先の下りに影響してしまう。

・案2: 新規に光回線でも引いてみる。
長所: サーバ回線が速くなる。
短所: 追加投資が必要。また、せっかくの共用回線がもったいない(貧乏性)
そもそも別回線引けるんかいな？

しばらくは案1の構成でいくけど、案2への移行も考えとこうかなぁ。

DvorakJP配列を使えるように、ja-rk-ruleにルールを追加してuim-skkを使っているけど、読み入力中に、DvorakJPで"onn"に当たる"q"を押すと、ひらがな/カタカナのトグルキーとしての機能が優先されてしまう。
例えば、「▽みほん」と入力しようとして、ひらがな入力モードで「Mihq」と入力すると、「▽みh」 + トグルと解釈されて、「ミ」になる。
そのため、"onn"を封印して使っていたけど、回避できそうな方法を見付けたのでメモ。
なお、確認したuimのバージョンは1.5.7。ちょっと古いかな。
新しいバージョンだと違ってる可能性がある。

方法:
skk.scmからskk-proc-state-kanjiの定義をまるっと~/.uimにもってきて、skk-kana-toggle-keyの判定を行っている部分を変更する。
skk.scmを直接変更してもいいけど、この辺はポリシーとか好みとかの問題。

変更前:

(define skk-proc-state-kanji
       ...
       (if (skk-kana-toggle-key? key key-state)
           (begin
             ...

変更後:

(define skk-proc-state-kanji
       ...
       (if (and (skk-kana-toggle-key? key key-state)
                (null? (rk-context-seq rkc)))
           (begin
             ...

こうすることにより、かなが確定していないローマ字入力がある時にqを押してもトグルキーとして動作しないようになった。
一方、かながすべて確定していれば従来通りトグルキーとなる。
「Mihq」と入力すると、qを押した時点で、hが未確定なのでqがローマ字入力の一部と見做されて「▽みほん」となり、「S;puruq」と入力すると、qを押した時点で未確定のローマ字がないので、qがトグルキーとして動作して「サンプル」になる。

他の機能が割り当てられているキーについても同じことができると思う。自分は必要としていないから変更しなかったけど。

[2012-04-06 00:00追記]
uim-1.7.xにはACTが取り込まれてるっぽい。ACTもqで"onn"扱いなのでどうなってるか気になるな。skk.scmのskk-proc-state-kanjiの定義を見た限りでは1.5.xと同じ動作になると思うけど。
折を見て試してみるか。

[2012-03-09 23:35 str3に関する条件が紛らわしかったので補足しました]

久し振りにシェルスクリプト (bash) を書いていたら、もっと簡単に実現できそうだけどやり方を思い付かないというものが出てきたのでメモ。

やりたいこと：
シェル変数vに"str1:str2:str3"のようにコロン区切りされた3つの文字列が入っている時に、シェル変数aにstr1、シェル変数bにstr2、シェル変数cにstr3を格納したい。
その他条件は以下の通り。

• str1は空文字列の可能性がある。その時はaに空文字列を設定する。
• str3にコロンが含まれている可能性がある。その時はcにコロンも含めた文字列を設定する。(例: v="aaa:bbb:ccc:ddd"の時は、cは"ccc:ddd"となって欲しい(単に"ccc"ではなく))
• できる限り、シェルの機能と一般的なコマンド (目安としてbusyboxに入っているもの) で実現すること。

とりあえず以下のコードで実現できた。同じ文字列に対してcutを3回使っているのが何となく気に入らない。echoと組み合わせるのも何か大仰な感じがするし。

a="$(echo -n "$v" | cut -d: -f1)"
b="$(echo -n "$v" | cut -d: -f2)"
c="$(echo -n "$v" | cut -d: -f3-)"

新機能一覧の概要はこちら→ [C/C++規格: 10] C11の新機能 その1 -- 新機能概要

[2011-04-01変更: char16_t、char32_tのエンコーディングについてコメントを頂いたので修正]

あかん。一ヶ月以上空いてしまった。
次はメモリ順序化のモデルとアトミック型について書こうと思ってたけどまだ読めてない＞＜。
というわけでお茶濁しながら別の話題で。

今回紹介するのはユニコード文字・文字列。
これらはC++11で一歩早く採用されています。wchar_tの場合と同様に微妙な違いもありますが。
C++11の方もまだ見れていないので具体的な違いを全部挙げることはできませんが、例えば新しい型char16_t、char32_tが、C++では独立した型なのに対し、Cでは他の型のtypedefだとか。

■ 新しい文字型
<uchar.h>をインクルードすることで、以下の型が定義される。

• char16_t : 16ビット文字型。のuint_least_16_tと同じ型であると定義される。
• char32_t : 32ビット文字型。のunit_least_32_tと同じ型であると定義される。

[2011-04-01変更: ここから]
処理系によってマクロ__STDC_UTF_16__、__STDC_UTF_32__が1に定義されていれば、それぞれchar16_tがUTF-16エンコーディング、char32_tがUTF-32エンコーディングされた文字を扱う。
これらのマクロが定義されていなければどんなエンコーディングかは処理系定義。
以下、char16_tがUTF-16エンコーディング、char32_tがUTF-32エンコーディングであると仮定して解説しています。違う場合もあり得るので訂正すべきなんだろうけど変な訂正ミスをやらかしそうなので(汗

それぞれUTF-16エンコーディング、UTF-32エンコーディングされた文字列を扱う型。
……という理解をしてたけど、改めて規格書を見直してみると明記されていないような(汗）
とりあえず、この理解が正しいという前提で解説します。間違ってたらゴメン。
# 後述する文字定数、文字列リテラルの接頭子が「u, U」でUTF-*じゃないとかあり得ないでしょ。
# さらに文字列リテラルの接頭子「u8」はUTF-8だということは明記されてるし。
[2011-04-01変更: ここまで]

■ 文字定数
書式 （括弧内に書かれた型は、文字並びの部分が一文字だけの場合):

  '文字並び' (int型)
  L'文字並び' (wchar_t型に対応する型なし整数型……ややこしいな)
  u'文字並び' (char16_t型)
  U'文字並び' (char32_t型)

最初のふたつはl旧Cでもお馴染のもの。残りふたつがC11で新たに定義された文字定数。
それぞれUTF-16エンコーディング、UTF-32エンコーディングの文字となる。整数リテラルの接尾子と違い、uが大文字か小文字かで意味が異なることに注意。

また、シングルクォートの間に複数文字を書くことができるが、そうした場合、どういった値になるかは旧Cと同様に処理系定義。新しい接頭子uやUが付いた文字定数の場合も同様。

■ 文字列リテラル
書式:

  "文字並び" （char配列型)
  L"文字並び" (wchar_t配列型)
  u8"文字並び" (char配列型)
  u"文字並び" (char16_t配列型)
  U"文字並び" (char32_t配列型)

これまた最初のふたつはお馴染のもの。最後のふたつは文字定数と同様に、それぞれUTF-16エンコーディング、UTF-32エンコーディングの文字列を表す。
文字列リテラルには、さらに接頭子 u8 で始まる文字列も追加された。
これは単なる文字列と同様にchar配列型だが、UTF-8エンコーディングされたもの。
通常の文字列がShift_JISだろうがEBCDICだろうが、u8"〜"と書くとその内容はUTF-8エンコーディングされたバイト列になることが保証される。

■ 文字列の連結
C99までは、文字列リテラルを複数並べるとそれをひとつの文字列リテラルに連結するといった機能があった。
C11でもこの機能は健在だが、文字列リテラルの種類が増えたため規則が増えた。
複数の文字列リテラルを並べて書くと、最終的な文字列は以下のようになる。

• すべての文字列が接頭子なし → 通常の(ワイドじゃない)文字列 (今まで通り)
• 接頭子(L, u8, u, U)が付いているものがある。出現する接頭子は一種類 → その接頭子に対応する文字列 (今まで通り + α)
• ワイド文字列の接頭子(L, u, U)が付いているものがある。複数種類の接頭子が混在 → どのワイド文字列になるかは処理系定義 （新ルール)
• ワイド文字列の接頭子(L, u, U)が付いているものとUTF-8文字列の接頭子(u8)が付いているものが混在している。 → コンパイルエラー。 （新ルール)

とりあえずは混ぜるな危険、と覚えておけばトラブルにはならないと思う。

■ 追加関数
<uchar.h>をインクルードすることで使えるようになる関数。

size_t mbrtoc16(char16_t *restrict pc16, const char *restrict s, size_t n, mbstate_t *restrict ps);
size_t mbrtoc32(char32_t *restrict pc32, const char *restrict s, size_t n, mbstate_t *restrict ps);

それぞれ、<wchar.h>をインクルードすることで使えるようになる関数 mbrtowc()のchar16_t、char32_t版。
マルチバイト文字を表す文字列をchar16_t文字1文字またはchar32_t文字1文字に変換する。

size_t c16rtomb(char *restrict s, char16_t c16, mbstate_t restrict ps);
size_t c32rtomb(char *restrict s, char32_t c32, mbstate_t restrict ps);

それぞれ、<wchar.h>をインクルードすることで使えるようになる関数 wcrtomb()のchar16_t、char32_t版。
char16_t文字1文字またはchar32_t文字1文字をマルチバイト文字1文字を表す文字列に変換する。

UTF-8文字とマルチバイト文字の相互変換関数は見当たらないが、UTF-8文字とUTF-16文字またはUTF-32文字との変換は簡単なので、必要ならプログラムを作ればよいということか？

# このペースだと、私が全部規格に目を通す前にもっといいまとめサイトとか
# 書籍とか出てきそうだな。
# や、それはそれで大歓迎なんだけど。楽できるし（笑

「3.5G世代」……やってしもたorz。

ところでこのコメントに付いた「5Gが話題に〜」におもおかあげたい。
現実には逆にこのストーリーに付けたモデレートをキャンセルしてたり。

一月半ばにC11の新機能を紹介すると言って、ちょっと何か書いてから一ヶ月近く経とうとしているが、なかなか次のが書けてません。
サボってたつもりもないんですが、いろいろと身動きが取れない状態でして。

ここしばらくの動向：

• 帰省でなかなか時間が取れず。(1/21〜24)
• さらに風邪でダウン。(1/24〜25)
• 風邪だと思ってたらインフルエンザだった。悪化して身動き取れず。(1/27〜1/31）
• 復帰後、仕事の遅れを取り戻すのにおおわらわ。(2/1〜現在進行形)
• 大きな買い物をすることに。契約やら何やらでやっぱり時間が取れず。(2/5あたりから)
• そろそろ一息つくかなーと思ったら帯状疱疹発症。痛い＞＜(2/8〜なう！)
• でも今週末はアパートの契約更新とかもしなきゃ。追い討ちっ。

インフルエンザの熱が下がって様子見してた1/31は余裕があったので、個人的にメインと思ってるデータレースやら<stdatomc.h>やらについてちょっと読み進めてたんだけど、まだ読み切ってないし。

再来週末も予定入ってるしなぁ。
まだC11の新機能紹介のまとめページとかはないみたいだし、一応来週末は空いてるから何か上げたいなぁ。
# C1X時点のものなら、RiSK氏が翻訳されているようですが、スレッド回りはちょっと変わっているんですよね。

# それにしても体調崩しすぎ。くすん。

先日の日記にて、D言語で不動点コンビネータを書いてみたら分かりにくくなったと述べたが、実はこれだけで実現できることに気付いた。

R delegate(TS) fix(R, TS...)(R delegate(R delegate(TS), TS) f)
{
    return delegate(TS xs){ return f(fix(f), xs); };
}

ラムダ式をサポートしている版ならこう。

R delegate(TS) fix(R, TS...)(R delegate(R delegate(TS), TS) f)
{
    return (TS xs) => f(fix(f), xs);
}

あらやだ分かり易い。
前回の日記のコードはYコンビネータを実装したものだったが、そんなことしなくても、単純に不動点の定義を書き下すだけで済んでしまうわけで。

あ、でも、無名関数の再帰を実現するコードで自らの名前を使ってしまう (fixの定義中でfixを使う) のは反則気味かな？

clang-3.0にて。

// hoge.c
#include <stdio.h>
 
void func(void)
{
        func();
}
 
int main(void)
{
        func();
        puts("The code clang generates is so fast.");
        return 0;
}

ビルド ＆ 実行。

$ clang -O2 hoge.c
$ ./a.out
The code clang generates is so fast.

わー。すごくはやーい。むげんさいきよびだしをいっしゅんでぬけたぞー……？

[2012-02-06 23:20 誤字訂正]
暇潰しネタ。

関数型言語の世界では、計算機論の基礎のひとつ、不動点コンビネータの実装が頭の体操のための題材になることが多い。
一方、手続型言語ではどうかというと、この関数の実装を行うには、関数を動的に生成して返さなければならないため、古い言語では実装することができなかった。(アーキテクチャ固有のハックをすれば別だけど)
しかし、ラムダ式だのデリゲートだのが使える最近の言語なら手続型でも実装できるはず。
手続型言語で不動点コンビネータを実装すれば、慣れている分、分かりやすかったりしないかな？ と思い、D言語で書いてみた。多引数対応。

R delegate(TS) fix(R, TS...)(R delegate(R delegate(TS), TS) f)
{
    class Wrapper(F)
    {
        public F delegate(Wrapper!(F)) func;
        public this(F delegate(Wrapper!(F)) func)
        {
            this.func = func;
        }
    }
 
    return delegate R delegate(TS)(Wrapper!(R delegate(TS)) g)
    {
        return delegate R(TS xs)
        {
            return f(g.func(g), xs);
        };
    }(new Wrapper!(R delegate(TS))(delegate R delegate(TS)(Wrapper!(R delegate(TS)) g)
    {
        return delegate R(TS xs)
        {
            return f(g.func(g), xs);
        };
    }));
}

うん。分かりづらい。これならむしろ関数型言語で素直に書いた方が分かりやすいかもorz

せっかくなので使い方の例をいくつか。

    // 階乗計算
    auto fact = fix(delegate int(int delegate(int) f, int n)
    {
        if(n <= 0)
        {
            return 1;
        }
        else
        {
            return n * f(n - 1);
        }
    });
    writefln("%s", fact(7)); // 5040

    // int配列からdouble配列への写像
    auto map = fix(delegate double[](double[] delegate(double delegate(int), int[]) f, double delegate(int) trans, int[] a)
    {
        if(a.length == 0)
        {
            return [];
        }
        else
        {
            return trans(a[0]) ~ f(trans, a[1 .. $]);
        }
    });
    // 配列の各要素を3で割ったものを得る
    writefln("[%s]", map(delegate double(int x){ return x / 3.0; }, [1, 3, 5, 7, 9, 11])); // [0.333333 1 1.66667 2.33333 3 3.66667]

    // たらい回し関数 （竹内関数)
    auto tak = fix(delegate int(int delegate(int, int, int) f, int x, int y, int z)
    {
        if(x <= y)
        {
            return y;
        }
        else
        {
            return f(f(x - 1, y, z), f(y - 1, z, x), f(z - 1, x, y));
        }
    });
    writefln("%s", tak(10, 5, 0)); // 10

# 実用性？ 知らん。

先日の日記で、C11を使って擬似的な関数オーバーロードを実現しようとしたが、0引数の場合にうまくいかないということを書いた。
その後GCCの拡張機能を使うと実現できることに気付いたのでここに書く。
なお、C11のみで実現する方法はまだ思い付いていない。

さて、ここで使用した拡張機能は何かというと、可変長引数マクロで、コンマの後に空の__VA_ARGS__を続けた時に__VA_ARGS__の直前のコンマを削除できるという機能。

#define MACRO(...)  ほげほげ , ## __VA_ARGS__

のように、コンマと__VA_ARGS__の間に ## を入れると、「MACRO()」と書いた時に__VA_ARGS__直前のコンマが消えて、「ほげほげ」と展開される。
MACRO(a)と書いた場合はコンマが残って「ほげほげ , a」と展開される。
この拡張機能はclang-3.0でも使える。

これを使用して、以前の日記のコードを以下のように変更した。

#include <stdio.h>
 
// 以下の4つの関数をfunc()マクロで呼び分けたい。
void func0(void)
{
    puts("func0()");
}
 
void func1_i(int x)
{
    printf("func1_i(%d)\n", x);
}
 
void func1_d(double x)
{
    printf("func1_d(%f)\n", x);
}
 
void func2_ii(int x, int y)
{
    printf("func2_ii(%d, %d)\n", x, y);
}
 
// 引数が少ない場合の穴埋め用ダミー。
struct dummy; // 前回の日記では中身も定義していたが不要なことに気付いたので削除。
 
// 引数があればその引数、なければ (struct dummy *)0 と評価される式を生成。
#define arg1_or_dummy(...)  ((struct dummy *)0, ## __VA_ARGS__)
 
#define func(...) (func_selector_1st(__VA_ARGS__, (struct dummy *)0)(__VA_ARGS__))
#define func_selector_1st(arg1, ...) \
  func_selector_2nd(arg1_or_dummy(arg1), __VA_ARGS__)
#define func_selector_2nd(arg1, arg2, ...) \
  _Generic((arg1), \
  struct dummy *: func0,                       /* ひとつめがない → 0引数関数 */ \
  int           : _Generic((arg2),             /* ひとつめの型がintで... */ \
                    struct dummy *: func1_i,   /* ふたつめがない → 引数の型が(int) */\
                    int           : func2_ii), /* ふたつめの型がint → 引数の型が(int, int) */ \
  double        : func1_d)                     /* ひとつめの型がdouble → 引数の型が(double)  */
 
int main()
{
    func();
    func(1);
    func(1.0);
    func(1, 2);
 
    return 0;
}

ここのキモとなるのが、新たに定義したマクロarg1_or_dummy。
可変長マクロとなっているが、0個か1個の引数を取ることを想定しており、「arg1_or_dummy()」と0引数にすると「((struct dummy *)0)」と展開される。
一方、「arg1_or_dummy(exp)」と引数が付くと「((struct dummy *)0, exp)」と展開され、コンマ演算子の定義により、((struct dummy *)0が捨てられて)「exp」と等価になる。
最初の引数についてこれを呼び出してやることによって、0引数のfunc呼び出しについてもめでたく正しい展開がなされて疑似オーバーロードが実現できるという寸法。

今回もclang-3.0で確認しました。
ところで、前回書き忘れたけど、clang-3.0はまだC11対応途中 (そもそもC11が正式に決まる前にリリースされたもの。オプションも-std=c1xとなっている) なので、未実装だったり規格と動作が異なったりする可能性はありますのでご注意を。_Generic周りについては規格通りだと思いますが。