にゃははー

はへらー

謎の用語niebloid

cppreference.comは随所に様々アノテーションがついていて大変便利だ。例えば(since C++17)といった感じでこれはC++17以降に登場した定義とかそういうのがひと目でわかる。さっき20での変更に何があるのか適当に眺めていたところ、<algorithms>の変更でConstraind algorithmsというのを見つけた。これはいわゆるRange TSと呼ばれていたもので、Boost.Rangeの標準化みたいなもの(のはず)だ。

よくよく見てみると、これには(niebloid)という見慣れないアノテーションがついている。全くわからない。他の(concept)とかは意味がわかる。これはそのままだ。

適当にぐぐってみるとものすごくヒットが少ない。とはいえ検索結果で目につくのはなんと言ってもEric Nieblerだ。この人はBoost.Rangeのメンテナで、Range TSの担当(?)だ。なるほどなんとなく察しがつく。

どうもniebloidというのは彼が作った造語で、これらはADLを徹底的に排除した関数呼び出し形式で扱えるなにかを指すらしい。 言いたいことはわかるがしかしあまりに唐突すぎる言葉なのでcppreference.comにも何かしらの説明がほしい... cppreference.com内で検索してもヒットしないのはいただけない

ちなみにNieblerは ニーブラー と発音するっぽいので、おそらくniebloidは ニーブロイド と発音するのだろう。

msgpackのデバッグをするための何か

msgpackのデータはあるんだけどなんかズレてたりしてデシリアライズ出来なくて困った困ったみたいなとき、目デシリアライズするのも(でかいと)ツライし、そうでなくてもデバッグしてる間に中身を見ようとしてもVSのデフォルトのビジュアライザだと中途半端でつらいものがあった

一応ブラウザで動くビジュアライザもあるらしいがbase64にしないといけないっぽいし、でかいデータでも大丈夫なのかな、、とか、(多分)オフラインだけどちょっと機密データのデバッグには抵抗感がある http://sugendran.github.io/msgpack-visualizer/

Visual Studioのデバッガは優秀(真顔)だけどvisualizerもmsgpack的にはちょっと足りない

つくったもの

msgviwer

https://github.com/Flast/msgviewer

とりあえずバイナリデータをツリー状にして可視化する

単にツリーで見えても修正とかだるかったからオフセットも見えるようにしてる

Qtで作ってるから大体の環境で動くはず

ビルド方法とかドキュメントとか無いのはなんとかしないといけない(使命感)

msgpack-vs-visualizer

https://github.com/Flast/msgpack-vs-visualizer

Visual Studioのデバッガで配列とか中身全部みれるようにするやつ

こっちもドキュメントとか全然ないけど雰囲気でがんばって(適当)

とりあえず配列のようなやつらは全部ちゃんと見えるようになった

余計な via とか見えてるのは気が向いたらそのうちなんとかしたい

allocaをinline関数で使うと危険である?

“allocaをinline関数で使うと危険である"という要旨のメールがoss-securityに流れてて、これは一体どういうことだ…と思った。

長い文章でも無いしそんなに難しくもないが、どうやらGCCオプティマイザの展開順に問題があるようだ。

http://www.openwall.com/lists/oss-security/2017/04/10/18

曰く、alloca(本文ではC(99)のVLAを指していた)を見つけるとGCCはそれを__builtin_allocaに展開した後、そのinline関数をインライン展開するので、ループ中で使うとスタックをガンガン持ってかれるということだった。 allocaは任意のスコープではなく、関数スコープからの離脱でのみスタックの巻き戻しを行うので、ループ本体を一巡したあとに本来巻き戻って欲しいスタックが巻き戻らず、次のallocaが行われてスタックが枯渇する脆弱性になると指摘している。

試しにMLに張られたコードに足りない部分を補完してバイナリを見てみたが、どうにも普通に巻き戻しはしているように見える。 -Oから既にインライン展開は行われるが、いくつかの最適化レベルを眺めてもやはり巻き戻しているように見える。

https://godbolt.org/g/fiofnf

なにか別の要因があるのだろうか…

スレッドアンセーフなshared_ptr

多分みなさんはstd::shared_ptrを使ってるとシングルスレッドで使うんだからスレッドアンセーフでいいのにとか思うことが良くありすぎて再実装したくなると思います。ならない方はなって下さい。設計が悪いと言う人はrecursive mutexを今後使わないで下さい。

はい。

で、libstdc++にはそういう拡張があるらしいです。 ドキュメントにはないけど。

基本的に使い方はstd::shared_ptr(と関連するもの)と同じだけど、第二テンプレート引数を受け取る点が違ってて、このテンプレート引数でMT-safe-nessを指定する感じになっている。

bits/shared_ptr_base.h melpon.org

執筆時点で定義されているのは3通り

  • 完全にunsafe
  • ミューテックスを使ってアトミックにカウント
  • アトミックカウンタを使ってアトミックにカウント

ext/concurrence.h

デフォルトのポリシーはスレッドサポートがあるかどうかとCPUのアトミック命令のサポートがあるかどうかで変わるぽいです。

なので、明示的にstd::_S_singleを渡せばMT-unsafeなshared_ptrが手に入ります。 ヤッター!

演算子における引数の評価順と副作用

年も瀬だというのにTwitterで規格書たちが騒いでいたのは記憶に新しい(?)と思うけど、自分もC++11(とちょっとあと)までしか読んでなかったせいで、いろいろ時代の潮流に取り残されている感じがあったのでちゃんと自分で調べましたっていう話。

事の発端と反応はおおよそこちらにまとまっているので参照されたい。

paiza.hatenablog.com

現時点でC++17として正式に規格が発行されたわけじゃないので本文中ではC++1zとし、最終的にISとなった場合にさらに追加で変更されている可能性もありますので、注意してください。

続きを読む

Boost.Fusion, Boost.Phoenixのメンテナになりました

今朝見慣れないメールがいくつか飛んできていて、その中でJoel de Guzman(FusionとかPhoenixとかSpiritとかのAuthor)が、「君をメインメンテナとしてコミット権追加しといたから、ヨロシク」ってなてました。

Boostの開発はgithubに移行してからpull-requestすれば誰でも参加できるものだったので、特にコミット権は不要で(ただしコミット権持った人が反応しないとめっちゃ滞る)、まぁいいかなってFusionとか100個ぐらいpull-requestガシガシ投げてたんですが、最近Phoenixもいじるようになって流石に面倒になってきたんでしょうか... 当のJoelはSpirit.X3の開発に専念したいみたいですし。

コミット権あっても何でもやっていいわけではないので、明らかなtypoとかテスト追加とかは直接やるとして、結局はpull-request出してセルフマージしていく感じになると思います。明らかな破壊的変更は他の人のレビューも待って誰かにマージしてもらう感じで。

インクルードガードとpragma once

C++ Advent Calendar 2015の5日目です。

C++時代から近代C++に至るまで、ヘッダファイルの重複インクルード排除のために通称インクルードガードというものが使われてきました。

#ifndef YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H
#define YOUR_VERY_VERY_AWESOME_LlBRARY_HEADER_H

#endif // YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H

しかしこれはファイルの前後に書かないといけないという制約や、他のヘッダとトークン列が一致してしまうと意図せずヘッダがインクルードされないという問題がありました。

これに対してたった1行で書いて終わりの#pragma onceは、標準化を求める声も多く、目的が明確で、実装もあるにも関わらず、標準に入る気配すらありません。 twitterとかでもそういう声をたまに見るのですが、ちょっと考えれば難しそうだというのがわかってもらえるかと思うので、ここでまとめておこうと思います。

続きを読む