Ubuntu 16.04にアップグレードした
Ubuntu 16.04にアップグレードした。今回はかなり問題だらけだった。 まず、アップグレードが正常に終わらなかった。古いパッケージを削除する途中で、hicolor-icon-themeのインストールスクリプトが正常に終了しなかったとのメッセージが表示された。同じ問題が報告されているようだ。 Bug #1571139 “package hicolor-icon-theme 0.15-0ubuntu1 failed to...” : Bugs : hicolor-icon-theme package : Ubuntu 他にも、Localesのインストールスクリプトが正常に終了しなかったというメッセージも表示された。 そして、"E: mkinitramfs failure cpio 141 gzip 1"と表示されたまま画面が完全に固まってしまった。入力を一切受け付けず、端末に切り替えるこ
2014-05-pre-Rapperswil mailingのレビュー: N4000-N4009
さて、さくさくC++WG論文を解説していく。 [記念すべきキリ番がPDF] N4000: Towards a Transaction-safe C++ Standard Library: std::list STLコンテナーをトランザクションセーフにするための研究の一環として、std::listをトランザクションセーフに書き直してみた実験の報告。STLコンテナー自体をトランザクションセーフにすることで、ユーザーが明示的にトランザクショナルメモリーのコードを書かなくてもすむ。 実験は、現在提案されているTransactinal Memoryを実験的に実装したGCC 4.9とそのstd::listの実装に対して行われた。 論文によると、十分に実装可能であり、変更は最小限ですんだという。変更の大半は、メモリ確保と解法、swap関数にtransaction_safeキーワードを使うだけだという。
iteratorや拡張forよりStreamのforEachが速い？ - きしだのHatena
ちょっと気になったので、簡単にベンチマークしてみました。 最初は、ラムダ呼び出しが入る分forEachは遅いんじゃないかと思っていたら、倍の速さに。 もちろん、いろんな条件で変わるんだろうけど、ここまで差が出ることがあるのは驚き。 あと、Collectors.summingIntのような基本型に対するCollectorを使うよりは、intStreamに変換してからsumなど専用メソッドを使うほうが圧倒的に速いことも確認できた。 とりあえず、0から10万件のListを用意。 array = IntStream.range(0, 100_000).boxed().collect(Collectors.toList()); それからベンチマーク用のメソッドを用意。 public static void bench(String name, Supplier<Integer> proc){ ben
std::threadをMinGWで使えるようにした - kikairoya’s diary
implement condition-variable to gthr-win32 needed for std::thread family. modify from gcc-4.7.0. · GitHub libgcc の GThreads wrapper が pthreads 以外の環境では Condition-Variable に対応していないため std::thread が使えなかったが、必要になったので Condition-Variable を Windows (Mingw32, Mingw64 両方) で動くようにした。 GCC's std::thread didn't work on Windows due to unsupported Condition-Variable functions of libgcc's GThread wrapper on non-pthr
C++ Labyrinth - boost::spirit を使う(CSVパーサーの作成)
parse_info<> を使ったパージング ループは、およそ次のようになるだろう。 IteratorT first, last; rule<> r; while ( first != last ) { // パージング実行 parse_info<IteratorT> info = parse( first, last, r ); // パージングに失敗したらループを終了 if (!info.hit) break; // 次のパージング位置を設定 first = info.stop; } grammar<> 文法を定義するには、grammar<> という基底クラスから派生させたクラスを用いるのが便利である。 grammar<> は、派生させるクラスを引数とするクラステンプレートで、 そのスケルトンは次のようになる。 (The Grammar より引用) struct my_grammar
宿題: boost::regex: 国民宿舎はらぺこ 大浴場
boost::regex 関連の調査の宿題。ていうか、Boost ライブラリを用いた文字列処理全般、かな。 boost::regex_match() でマッチするケースと、boost::regex_search() じゃないとマッチしないケースとを切り分ける。 Perl では /^$pattern$/ でマッチするようなケースが boost::reg_match() ではマッチしないことがある模様 ... つい先日リリースされた 1.34.0 ではどうか? Perl で言うところの /$pattern/g に相当する記述方法はないか? boost::regex_grep() というのはあったらしいが、すでに deprecated 。Predicate とかいうコールバックらしきものの設定が必須な模様で、そういう意味でも使いにくい (Perl の grep 関数を意識してるのかな?)。 bo
茶々入れ: 国民宿舎はらぺこ 大浴場
C/C++は永久に不滅です！ (IT Pro) 突っ込みどころ満載なのでちょっと茶々入れしてみようと思う。 Part1 C/C++は永久に不滅です！ その一つに，C言語は非常に自由度の高いコーディングができることが挙げられます。例えば，if-elseの処理を1行で記述できるC/C++の三項演算子は便利な機能ですが，よく見ないと処理内容がよくわかりません（リスト1）。 三項演算子って、C ではよく悪者にされるよね。おいらは値を代入するシーンや値を return で返すシーンではそれなりに有用だと思っているし、演算順序が左→右であることから複合的な条件分岐も割と整理して記述できるという利点もあったりするんだけれども。 でも、確かに示されているコード例は、酷いね。せめて、 (msg[i] >= 'a' && msg[i] <= 'z') ? msg[i] += 'A' - 'a' : msg[i
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tupleのネスト
http://atnd.org/events/7148