はてなブックマーク

C++11のstd::swapは、だいぶ大きく変更された。C++03までのswapは、<algorithm>にあり、CopyConstructibleかつAssignable（C++11のCopyAssignableに相当）を要求した。ところが、C++11では、<utility>に移されたあげく、MoveConstructibleかつMoveAssignableを要求するようになった。まるっきり別物になってしまっているのだ。果たして問題を起こさないものだろうか。おぼつかないものだ。 実装例は以下のようになる。 // C++03のswap template < typename T > void swap( T & a, T & b ) { T temp = a ; a = b ; b = temp ; } // C++11のswap template < typename T > void

[Phoronix] Talk Of GCC 5.0 To Be Modular, More Like LLVM David Malcolm - GCC 5? (was Re: GCC 4.7.0RC: Mangled names in cc1) 聞説、今のGCCのコードは、やや悲惨な部類に入るらしい。十分な実績があり正しく動くのは確かだが、コードはほとんどCで書かれており、名前空間もなく、グローバルな状態が多く、スレッドもない。これはつまり、GCCは他のソフトウェアに組み込むのが難しい。 一方、LLVMは、設計段階からモジュール化を念頭に置いており、GCCよりはるかに後発なのにもかかわらず、他のソフトウェアに組み込む用途で広く使われている。たとえば、 MesaのGallium3Dとか、OpenCLとか、Monoとかで、JITコンパイルを実現するために、すでに使われている。他にもLLVMを

どうもLinuxにおけるプログラムからのディレクトリの使い方の作法が難しい。 あるプログラムが、動作に設定ファイルとデータファイルを必要とする。これには、Linuxの作法では、それぞれbinとetcとshareを使うようだ。問題は、主要なものだけ挙げても、/binと/usr/binと/usr/local/binがあり、、etcとshareに関してもそれぞれ同じものがあるということだ。もちろん、これらのディレクトリの違いは解説されている。しかし、一体どうやって、どこに置いても正しく動作するプログラムを書けばいいのだろうか。 /usr/binに置かれたプログラムは、やはり/usr/etcを使うべきなのだろうし、/usr/local/binに置かれたプログラムは、/usr/local/etcを使うべきなのだろう。それ以外のディレクトリ下に置かれたプログラムも、やはりそこから見て相対的なetcやs

API Housekeeping | Twitter Developers 今日、Google ReaderがTwitterのユーザーへのURLから、フィードのためのURLを自動生成する挙動が止まっていることに気がついた。昨日あたりまでは確かに動いていたはずなのに、何故だろう。仕方ないので、Twitter APIを調べて追加した。Twitter APIの利用は非常に簡単だった。 やれやれと安心していたら、このアナウンスだ。 API Housekeeping | Twitter Developers 5月14日をもって、バージョン番号がないAPIはすべて廃止される。deprecatedなAPIも廃止される。ATOMフォーマットも廃止される。RSSは残るらしい。やれやれ。 さて、これで気になるのはGoogle Readerだ。Google Readerは、TwitterのユーザーのURLを渡す

最近、ボルダリングが伸び悩んでいるので、今日は追い込んでみた。 いつも行っているジムの8級から4級までの課題を休みをあまり入れずにすべて順番に登った上で、さらにまた8級から登ってみた。結果としては、二週目の5級の途中で力尽きた。帰宅して体重を計測したところ、1.3kg減っている。汗と排便のためだろう。 今回はスタティックに登ったので、疲労した筋肉に偏りがある気がする。最後に力尽きたところで、指はあまり疲労しておらず、ダイナミックな動きも問題はなかった。ただ保持力が消えていた。 次はダイナミックに登って追い込んでみようかと思う。 世間ではAppleの新しい製品に使われるARM64 CPUであるM1の話題でもちきりだ。ただし、日本語を話す記者というのは極めて非科学的かつ無能であり、M1の現物を手にしても、末端のソフトウェアを動かして、体感で早いだの遅いだのと語るだけだ。そういう感想は居酒屋で酒

Programming Language Challenges in Systems Codes システムコードにおけるプログラミング言語の挑戦、あるいは、なぜいまだにシステムプログラミングはCなのか。 著者がJonathan Shapiroであることが興味深い。Jonathan ShapiroはD&Eに頻出する名前である。Bjarne Stroustrupの記述からして、初期のC++の設計に多大な影響を与えた人物である。それに、最初にC++を使って本格的で大規模なプロジェクトを始めたのも、Jonathan Shapiroだ。しかし、今日、Jonathan Shapiroの名前はC++界では、あまり有名ではない。私はMLとかHaskellなどの言語には疎いので、この方面の話は知らなかった。 なぜシステム・プログラミングは、いまだに1970年代に開発された大昔の高級アセンブリ言語で書かれてい

目的 この記事は、C++0xのrvalue referenceを完全に解説せんとする目的を以て書かれた。サンプルコードは最小に留め、エラー処理等は省いた。この記事さえ読めば、今日からrvalue referenceを恐れることなく使う本物のC++0xプログラマになれるだろう。 lvalueとrvalueについて Cの時代では、lvalueとrvalueの違いは、代入演算子の左側か右側かという違いだけであった。つまり、left hand value, right hand valueの略である。従って、訳語も、左辺値、右辺値であった。C++においては、これはもはや正しくはない。従って、右辺値、左辺値というのも、誤訳である。それ故に、ここでは、これ以上、左辺値、右辺値という名称を使用しない。 誤解を恐れずにいえば、lvalueとは、明示的に実体のある、名前付きのオブジェクトであり、rvalue

freenodeでチャットしていたら、Clang開発者の一人から、Clangは現時点で最も優れたC++11コンパイラーである、と言われた。またまたご冗談を。たしか数ヶ月前に確認した時、ClangはGCCより実装している機能の数で劣っていたはずだ。Clangには確かに将来性を感じるが、まだまだ時間が掛かるだろう。どれ、どれだけ進んだか、一応確認してやるか、と、Clangの状況を確認してみた。 Clang - C++98 and C++11 Status なんだと！ コア言語では、Forward declarations for enumsとGeneralized attributesとInheriting constructors以外すべて実装し始めているではないか。このうち、ユーザーにも分かりやすい重要な機能はinheriting constructorぐらいなので、実質残すところの機能は

Walmart buys a Facebook-based calendar app to get a look at customers' dates これは非常に危険なニュースだ。Walmartが会社を一つ買収した。「なんだ、それだけか」と思うかもしれない。問題は、その会社とは、Facebookでカレンダーアプリを提供していた会社なのだ。しかも、1600万人ものユーザーがいるのだそうだ。 つまり、Walmartは会社をひとつ買収することで、その会社が得ていた1600万人分の誕生日やその他の予定などのプライバシー情報を得たことになる。しかもWalmartは、その情報を自社の販促に使うと明言している。 これが合法なのか？　たしかに、法的には同じ会社になったのかもしれないが、これまでカレンダーアプリを使っていた人間は、そういうことに使われることを期待していなかったはずだ。これが合法なのか？