2017-12-11

来年出版予定の「江添亮の詳説C++17」の組版に使うTEXを公開

来年出版する予定のC++17の新機能を解説した参考書、書名は現在、「江添亮の詳説C++17」を予定している本の組版に使うTEXを公開した。

https://github.com/EzoeRyou/cpp17book

この参考書は今年2017年に9ヶ月ほどかけて書いていた本で、C++17に追加された新機能のほぼすべてを解説している。

この参考書は、アスキードワンゴから出版される予定だ。アスキードワンゴでは本の組版にTEXを使っている。

私は自由なライセンスの価値を信じるものであり、本も自由になるべきだと信じている。私の書いた本は自由なライセンスにできるとして、組版に使ったTEXも公開したい。TEXは明らかにソースコードに当たるものであり、ソースコードが公開できなければGPLv3ではライセンスできないのでCC-BY-SAなどを使わなければならない。私が執筆したC++11/14コア言語は、こういった理由でCC-BY-SAだった。

さて、今回の本では、TEXも公開できることになった。すでにmarkdownで書かれた本のソースコードは公開しているので、まだ出版前だがTEXも公開してしまうことになった。これで、今回の本「江添亮の詳説C++17」は自由なライセンスであるGPLv3でライセンスすることができる。

商業出版で使われる本のTEXを公開してどういう効果があるのか、私には予測できない。いい効果があると今後にもつながるのでうれしい。

アスキードワンゴの編集者が作成したTEXを眺めた感想としては、自動化が難しそうだと感じる。今回公開したTEXは私がmarkdownで書いて、pandocでTEXに変換し、それを編集者が手で編集することで作成されている。著者としては編集者の労力を減らすために自動化できるところは自動化したいのだが、編集済みのTEXをみると、結局、編集者が人力ですべてをチェックしなければならないことに変わりはない。

そして、PandocはHaskellで書かれているので、PandocをハックするためにはHaskellを学ばねばならない。Haskellを学ぶのは大変だ。

そういう話をしていたら、同僚のHaskell大好き人間からアスキードワンゴはHaskell本を出しているではないかとツッコミが入った。

Haskellによる関数プログラミングの思考法 - アスキードワンゴ

学ばねばならぬのか。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-12-06

C++標準化委員会の文書: P0790R0-P0799R0

P0790R0: library-operator-spaceship

operator <=>が標準ライブラリに与える影響について。

operator <=>によって生成される比較演算子は、ソースコードの書き換えと同等の効果を及ぼすのであって、実際の比較演算子ではないため、アドレスを取ることができない。これにより、opeartor <=>アドレスを取るユーザーコードは動かなくなる。これは互換性の問題となるが、そもそも比較演算子のアドレスを取るユーザーコードはまれだ。というのも、比較演算子はメンバー関数とフリー関数のいずれかで実装されるので、ユーザーコードでアドレスを取るにはどちらで実装されているか知らなければならない。また、一部の標準ライブラリは、a @ bのような式が妥当だとのみ規定されていて、operator @がどのように実装されているかを規定していない。その場合、ユーザーコードでアドレスを取った場合、そもそも未定義となる。なので、互換性の問題はまれにしか起こらないはずだ。

文書は、標準ライブラリで比較可能な型のうち、operator <=>に対応すべきではない型、変換関数を捨ててopeartor <=>に切り替えるべき型、既存の比較演算子に加えてoperator <=>を追加したほうがよい型、operator <=>を追加したほうがよい他の型をラップしている型、現在比較を提供していないがoperator <=>に対応したほうがよい型、operatgor <=>を追加したほうがよいCの型を列挙している。

valarrayというだいぶ忘れ去られた型も考慮している。

よく調べたものだ。

[PDF] P0791R0: Concepts are Adjectives, not Nouns

コンセプトCを使うtemplate < C X >を、template < C typename X >に変える提案。

template < C X >の意味はわからない。Xは型なのだろうか。値なのだろうか。CがコンセプトならばXは型だが、Cがintへのtypedef名ならば、Xは値だ。この問題は、内側のスコープの宣言で名前が隠れるともっとややこしくなる。


template < typename T > concept C = true ;

// Xは型
template < C X > struct S ;

namespace ns {

using C = int ;

// Xは値
template < C X > struct S ;
}

字面は同じtemplate < C X >なのに意味が変わってしまう。

この問題は、本来形容詞であるコンセプトを名詞として使っているから生じるのであって、形容詞的な文法にすればいい。すなわち、文法を以下のように変更する。

template < CopyConstructible typename T > struct S ;

この変更により、複数のコンセプトを簡単な文法で指定することも可能になる。

template < CopyConstructible LessThanCompareble tyepname T > struct S ;

なるほど、趣旨はわかるが文法が冗長になる。

P0792R0: function_ref: a non-owning reference to a Callable

Callableを所有しないラッパーfunction_refの追加。std::functionと違いメモリ確保をせず例外も投げない。

[PDF] P0793R0: SG5: Transactional Memory (TM) Meeting Minutes 2017/06/19-2017/10/09

Transactional Memoryの会議の議事録。

[PDF] P0794R0: SG14: Low Latency Meeting Minutes 2017/08/09-2017/10/11/

Low Latency会議の議事録。

[PDF] P0795R0: From Vulkan with love: a plea to reconsider the Module Keyword to be contextual

Vulkanより愛をこめて。

モジュールTSではmoduleというキーワードの追加を提案しているが、moduleという識別子はすでに多くの既存のソースコードで使われている。特にKhronos Groupの低級グラフィックAPIのVulkanでもmoduleを識別子として使っている。moduleは文脈依存キーワードにすべき。

[PDF] P0796R0: Supporting Heterogeneous & Distributed Computing Through Affinity

NUMAが当然となった現代では、メモリーアフィニティの重要性はいよいよ増すばかりだ。複数のスレッドによる並列処理を行ったとしても、そのメモリーが特定のひとつのスレッドだけで効率的にアクセスできるようになっている場合、並列処理はスケールしない。このようなメモリーとスレッドの関係をアフィニティと呼ぶ。

そこで、C++は標準でシステムのリソーストポロジーをクエリーし、メモリー領域の相対的なアフィニティをクエリー子、実行とメモリ領域を制限するようなアフィニティの設定機能を持つべきだ。

そんなの標準化できるのだろうか。

[PDF] P0797R0: Exception Handling in Parallel STL Algorithms

並列アルゴリズムを中断する方法の提案。

シーケンシャルアルゴリズムは例外を投げることによって中断できた。並列アルゴリズムも提案段階ではexception_ptrを複数もつexception_listを例外として投げることで中断できる予定だったが、この設計には色々と問題があったので廃止された。

この提案では、例外を格納するdisappointment_buffer<disappointment_type>を追加し、これを実行ポリシーオブジェクトで並列アルゴリズムに渡すことで例外リストを受け取る設計を提案している。

P0798R0: p0798r0: Monadic operations for std::optional

optionalにモナド操作として、and_then, or_else, mapを追加する提案。

画像から猫を抽出してより可愛くするコードを考える。

image get_cute_cat (const image& img) {
    return add_rainbow(
             make_smaller(
               make_eyes_sparkle(
                 add_bow_tie(
                   crop_to_cat(img))));
}

しかし、画像に猫が含まれていなかったらどうなるのだ。画像に蝶ネクタイを付加すべき場所が存在しなかったら、 猫が後ろを向いているので目を輝かすことができなかったら。それらの条件では、画像を返すことができない。

例外を使うというのも手だが、プログラムが画像を大量に処理するもので、画像に猫が含まれないことは例外的ではない場合、例外をコントロールフローに使うのはよろしくない。

そこでoptionalだ。

std::optional<image> get_cute_cat (const image& img) {
    auto cropped = crop_to_cat(img);
    if (!cropped) {
      return std::nullopt;
    }

    auto with_tie = add_bow_tie(*cropped);
    if (!with_tie) {
      return std::nullopt;
    }

    auto with_sparkles = make_eyes_sparkle(*with_tie);
    if (!with_sparkles) {
      return std::nullopt;
    }

    return add_rainbow(make_smaller(*with_sparkles));
}

しかし、こんなボイラープレートコードを書きたくない。

そこで、optionalのメンバーにmap, and_then, or_elseを追加すると、以下のように書ける。

std::optional<image> get_cute_cat (const image& img) {
    return crop_to_cat(img)
           .and_then(add_bow_tie)
           .and_then(make_eyes_sparkle)
           .map(make_smaller)
           .map(add_rainbow);
}

趣旨はわかるが現実の問題を解決するC++のコードが、そんなにきれいに引数をひとつ受け取ってひとつ返すような簡単なコードになるわけがなく、したがってこれを使おうとするとラムダ式で囲んだボイラープレートを書かねばならず、机上の空論に見える。

[PDF] P0799R0: Programming vulnerabilities for C++ (part of WG23 N0746)

C++標準規格の文面に脆弱性に対する忠告の文面を入れようという提案

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2017-12-02

仮想通貨と税金についての国税庁の見解についての所感

http://www.nta.go.jp/shiraberu/zeiho-kaishaku/joho-zeikaishaku/shotoku/shinkoku/171127/01.pdf

国税庁が仮想通貨と税金について見解を出しているが、これの一部が私の直感とだいぶ異なる。

1から9までの例について、具体的な暗号通貨であるBitcoin, Ethereum, Bitcoin Cashと日本円を出して考える。その価値は特に実態とは関係がない。

1. 暗号通貨Bitcoinを1万円分買って、後に暗号通貨Bitcoinを2万円で売った。所得=収入-支出=2万円-1万円=1万円となり、1万円の所得が発生する。

わかる。

2. 暗号通貨Bitcoinを1万円分買って、後に暗号通貨Bitcoin全額を支払って2万円の商品を買った。2万円分の収入が発生した扱いになり、所得=収入-支出=2万円-1万円=1万円となり、1万円の所得が発生する。

わかる。

3. 暗号通貨Bitcoinを1万円分買って、後に暗号通貨Bitcoin全額を支払って暗号通貨Etheriumを2万円分買った。2万円の収入が発生した扱いになり、所得=収入-支出=2万円-1万円=1万円となり、1万円の所得が発生する。

理解に苦しむ。暗号通貨から暗号通貨のやり取りには日本円が一切関与していない。

有名画家から絵をもらったとして、その有名画家の絵は市場で1万円の取引実態があるので、1万円の所得が発生したというようなものだ。まだ現金が一切関与していないのに絵を入手しただけで所得になるのはおかしい。

4. これを真面目に計算するのはだるいので具体例を出すのが面倒だが、まあ理解できる

5. 暗号通貨Bitcoinを1万円分買った。後に暗号通貨Bitcoinがforkして、暗号通貨Bitcoin Cashができた。その結果、BitcoinとBitcoin Cashを両方持つことになった。所有するBitcoinの価値は1万円と変わらず、Bitcoin Cashの価値は1千円となった。この場合、1千円の収入が発生した扱いになり、支出は0円で、1千円の所得が発生する。

うーむ・・・結果的に利益が発生したわけではあるが、やはり現金が一切関与していないのに所得となるのはおかしい。

世界に2枚しかない有名画家の絵の1枚を所有しているとして、もう1枚が焼けてなくなったので、自分の持っている絵の価値が1万円分上がった。したがって1万円の所得が発生したというようなものだ。まだ現金が一切関与していないのに所得になるのはおかしい。

6. Bitcoinが雑所得以外に分類される場合について。

わかる。

7. Bitcoinが雑所得とみなされる場合の損失は雑所得のなかだけで通算。

わかる。

8. 暗号通貨にはFXのような投機としての特別措置はない。

実態はもはやFXに近い気がするが、本来の意図した状況ではない気がする。

9. 2万円分の暗号通貨Bitcoinをマイニングするためにコンピューターと電気代で1万円をかけた。収入が2万円、支出が1万円。所得=収入-支出=1万円の所得が発生する。

やはり具体的な現金との関与が一切ないのに所得扱いになるのは解せない。

Bitcoinは実態としては絵に近い。例えば私が有名画家で、私の書いた絵には必ず1万円を支払って購入したい人が列をなして並んでいるとして、私が直ちに売らない絵を描いた場合、私は絵を生み出したのでその場で売らなかったとしても1万円の所得が発生することになるというのと同じ奇妙さがある。