C++の入門書を書くためにHaskellを学ぶことにした
C++17の参考書、江添亮の詳説C++17はすでに書き上げて、来年の出版を待つばかりになっている。 https://github.com/EzoeRyou/cpp17book 次に書く本はC++の入門書にしようと思っているが、入門書を書く前に、少し時間をかけてHaskellを学ぼうと思っている。 なぜHaskellを学ぶのか。Pandocのためだ。 Pandoc 私の本は、Markdownで書いてPandocで各種フォーマットに変換している。アスキードワンゴでは、Pandocを使ってlatexに変換した上で、手作業で出力されたlatexを編集して組版している。つまり、私の参考書の執筆はPandocに支えられていると言ってよい。 さて、アスキードワンゴ編集部(ドワンゴ)は私が本を出版契約している出版社であり、かつ私が雇用契約している会社でもある。アスキードワンゴの編集者は私の編集者であり同僚
来年出版予定の「江添亮の詳説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コア言語は、こうい
GitHubで他人のプルリクエストに対しコンフリクト解消や追加の修正を行いつつマージする方法
読者がGitHubで何かを公開しているとしよう。そのレポジトリに対して他人がプルリクエストを送ってきた。なかなか良さそうな変更だ。早速マージしたい。 しかし、残念なことにそのプルリクをそのままマージすることができない。なぜならば、 コンフリクトを起こしている 追加の修正が必要だ こういう場合、大規模なプロジェクトや、PR主が職場の同僚や開発仲間であった場合、PR主に修正を依頼するものだ。しかし、個人的な小規模なプロジェクトなのでPR主はPRを出したまま返事がない。 こういう場合に、PRをマージするにはどうすればいいのか。答えは簡単で、プルリクエストが裏でやっているgit操作を自分のローカルでやればいいのだ。 まず、該当のPRのGitHub上のページの、「プルリクエストをマージ」ボタンの横に、コマンドライン操作を表示(view command line instructions)というリンク
VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更
Integrated Terminal Performance Improvements Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。 DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。 テキスト選択：ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。 テキストアライメント：一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。 GC：DOMでターミナ
C++のfilesystemライブラリが膨大すぎる
C++17の参考書はほぼ書き終えて、あとはfilesystemライブラリの解説を残すだけになっている。 EzoeRyou/cpp17book: textbook for C++17 ファイルシステムライブラリは、ext4とかbtrfsのようないわゆるファイルシステムに対するライブラリではなく、ディレクトリとファイルに対する操作を提供するライブラリだ。具体的にはファイルパスの文字列処理や、ファイルのコピーやリネーム、ディレクトリ構造のトラバースといった雑多なファイルシステム操作を提供する。 C++のファイルシステムライブラリは、原則としてPOSIX互換になっている。POSIXの規定するライブラリをモダンなC++風のライブラリとして設計したものだ。例えば、カレントディレクトリにあるファイルをすべて表示するプログラムは以下のように書ける。 #include <filesystem> #inclu
LLVMがWindowsのデバッグ情報フォーマットのPDBをサポート
LLVM Project Blog: LLVM on Windows now supports PDB Debug Info この数年、clangをWindowsでソフトウェア開発するための世界級のツールチェインにするために尽力してきた。このことについては、すでに何度も書いてきたことだ。LLVMは完全なABI互換を実現した（ただしバグ互換ではない）。互換性を実現するのが難しい分野にデバッグ情報があるが、この2年間で、LLVMは飛躍的な発展をとげた。とりあえず結論を先に書くとこうだ。WindowsでClangを使うと、PDBデバッグ情報が出せる。 背景：CodeView VS PDB CodeViewは1980年台の中頃にMicrosoftによって考案されたデバッグ情報フォーマットだ。様々な理由で、他のデバッガーはDWARFという独立したフォーマットを開発し、これは標準化されて、多くのコンパ
Bjarne Stroustrupのプログラミング入門書の査読の感想
C++の設計者ストラウストラップによるプログラミング入門書の最新版日本語訳が、9月に @asciidwango から出版されます。 https://t.co/ssT9ubfXtT — アスキードワンゴ編集部 (@asciidwango) August 5, 2016 アスキードワンゴ編集部からBjarne StroustrupのProgramming -- Principles and Practice Using C++という本の第二版の邦訳が出版される。初版は翔泳社が出していたが、C++14に対応した改訂版の第二版の版権が空いていたので、アスキードワンゴから出すための作業をしていた。私は邦訳の査読をした。 今年になってから半年は、ずっとこの本の査読をしていた。このためにC++標準化委員会の最新の文書を把握する作業が数ヶ月ほど滞った。そして、この仕事は、私がドワンゴに入社して以来、最悪の
作業が早いプログラマーと遅いプログラマーの差の比は4:1
An empirical study of working speed differences between software engineers for various kinds of task プログラマーの作業速度には差がある。作業速度が早いことだけをもって優秀なプログラマーとは限らない。そのソフトウェアの保守性が悪いかもしれないからだ。しかし、やはり作業速度の早いプログラマーは優秀と見られがちだ。特に、転職界隈では、優秀なプログラマーは、その作業速度の速さを形容して、「ニンジャ」とか「10倍プログラマー」などというタイトルで喧伝されている。さて実際には、プログラマーの作業速度は、全体としてどの程度違うのか。 プログラマーの作業速度が早いものと遅いものの比は、従来、28:1であると言われてきた。この数字には根拠となる研究がある。1967年にGrantとSackmanが公開した論文
Chrome 51のV8の興味深いバグ
以下のコードを実行した結果を予想してみてほしい。 function foo() { return typeof null === "undefined" ; } for ( var i = 0 ; i < 1000 ; ++i ) { console.log( foo() ) ; } typeof nullの結果は"object"なので、"undefined"と===で比較するとfalseになる。したがって、関数fooは必ずfalseを返すはずである。1000回実行しようと常にfalseを返す関数は常にfalseを返すはずである。 では実際に実行して確かめてみよう。 実行（何度かクリック） コンソールにコピペするのとは挙動が違うが、何度もクリックすると、なぜかtrueを返すようになる。おそらく、コンソールにコピペすると毎回JITが走るので、挙動が違うのだろう。 ちなみに、workaroun
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
rm -rfしちゃったけどどうする
rm -rf remains rm -rfの後に残りしもの 遊びのために、筆者は新しいLinuxサーバーを立ち上げて、rootでrm -rf /を実行して、何が残るかをみてみた。どうやら、今のrmというのは筆者のようなアホを相手にしなければならない未来に生きているようなので、実際に実行するには、--no-preserve-rootをつける必要があった。 # rm -rf --no-preserve-root / かかるおろかなる行為の後では、 /bin/ls /bin/cat /bin/chmod /usr/bin/file のような、偉大なるツールのたぐいはみな消え失せてしまった。まだ、ssh接続とbashセッションは生きているはずだ。つまり、bashの組み込みコマンドであるechoとかは残っているということだ。 Bashマクガイバーたれ root@rmrf:/# ls -bash: /
例外中に例外を投げるとか二重例外はエラーという俗説について
いよいよC++の参考書の執筆も例外にまで到達した。例外は、規格の文面量だけで言えば短いが、詳細を解説するのは難しい。なにせ、まともに日本語で解説している本は皆無だからだ。ついでに、規格の文面のバグも発見した。これはすでに報告済みなので、次のC++規格では修正されるはずだ。 ちなみに、"C++ 例外"で検索して出てくる情報の大半が間違っているか、十分な詳細を解説していない。責任は規格違反な実装、特にMSVCにある。MSVCの挙動が全てだと信じる愚者が、規格を参照せずMSVCの挙動をもとに解説を書いているからだ。 たとえば、例外をハンドルしていない状態でオペランドのないthrow式を実行すると、std::terminateが呼ばれる。 int main() { throw ; // std::terminateが呼ばれる } あるC++解説サイトでは、何故かstd::bad_exception
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
