Post Unavailable
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
ANSIからC++11の規格書が$30で販売されている
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
大学に行くべきだったのか
C++の参考書は、ようやくテンプレートまで進んだ。この項目は、大胆な割愛や、簡略化した説明をしなければならないだろう。テンプレート仮引数とテンプレート実引数を完全に分離して説明するのは、さすがにわかりにくい。 しかし、いまさらになって、大学に行かなかったことが失敗ではないかと思いつつある。 理由はいろいろあるが、私は当時、大学に行かなかった。親の別居やら引越しやら、その理由を当時の外部要因に求めることはたやすいが、結局、大学に行かなかったのは私の責任である。 そして今、私がC++を学ぶために何をしているかというと、規格や論文の読解である。私は一度も、論文の構造とかプログラミング言語の規格書の構造について学んだことはないが、なんとなく感覚で会得していった。 これは正しくない学び方だ。最初に、学問を学問として、系統だてて学んだ方が良かったと思うのだが、いまさら悔やんでも始まらない。もちろん、論
GPGPU時代のハッシュアルゴリズム
Coding Horror: Speed Hashing xkcd: Password Strength GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。 もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。 ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、
DCPU-16用LLVMバックエンド
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
Goは32bit開発に不適
Do Not Use Go for 32bit Development 私は今、大量のGoのコードをCに書き換える作業をしている。時間は金で買えない。主たる開発者として、金はここで止まってしまう。わたしは顧客と話し、責任を負った訳だ。私の過ちは、Goを信頼したことだ。私は自分のモットーを思い出すべきだったのだ。Nullius in verba（政治信教の言を入るべからず） Goは1.0がリリースされたが、もし、32bitサポートが必須であれば、Goを選んではいけない。 32bit Goには多くのバグがあるが、特に問題なのがひとつある。 実行開始の初期化時に、Goは512MBの仮想アドレス空間を予約しようとする。予約できなければ、クラッシュする。Goは、ガベージコレクションのためにこの空間を必要とする、おそらく、すべてのGC言語、いや、すべての言語は、メモリ管理に対して、似たような手法を用い
詰んだかも
GNU/Linuxに移行してより、あらゆることが新鮮で充実した日々を送っている。急に身長が伸びたりはしないし、彼女もできないし、宝くじにも当たらないが、幸せだ。 ただ、どうも、道を誤った感がある。 ここ数年というもの、C++の参考書の執筆に専念してきた。規格書の読解、日本語による説明、ひとつの機能だけを使った完結なサンプルコード、そんなことを考えて日々を送っていた。その結果、C++の規格の知識は大幅に増えたが、その他の技術からは遠ざかってしまった。向上したのは、英語の読み書き能力とドキュメントを読む力だけだ。一部の能力だけに特化した結果、汎用的なプログラマーとしての力は、むしろ衰えてしまった。 新しい環境で新鮮な気持ちになり、久しぶりに色々とコードが書きたくなった。驚いたのは、ドキュメントを読む力が格段に上がっていて、全く馴染みのない環境やライブラリでも、楽に学べるようになっていることだ。
GNU/Linuxの方がWindowsより日本語サポートが優れている
今や、GNU/Linuxの方が不自由なWindowsより日本語サポートが優れている。これは純然たる事実である。 私は、UIが日本語化の質を論じているのではない。私はUIの言語を英語にしているので、UIの日本語の質についてはわからない。ただ、2012年となった今では、GNU/Linux/Xの環境の方が、圧倒的に日本語を扱う環境が優れていると考えているのだ。 まず、現行のまともなディストリは、文字エンコードをデフォルトでUTF-8にしている。このため、不自由なWindowsにおける、カオスな大量のマルチバイト文字コード混在環境の問題は存在しない。確かに、不自由なWindowsのネイティブの文字エンコードはUTF-16だが、下位互換性を保証するために、既存のマルチバイト文字をすべて継続してサポートしているために、未だにカオスな状況になっている。多くのプログラムは、嘆かわしいことに、いまだにANS
iconvがクソすぎる
思うに、私が最初のOSに不自由なWindowsを選んだのは正解だったかもしれない。すくなくとも、Win32 APIはPOSIXよりはるかに使いやすい。 問題はiconvだ。一体どこの糞が何をキメながら設計したらこうなったんだ。狂っているにも程がある。 size_t iconv (iconv_t cd, const char ** inbuf, size_t * inbytesleft, char ** outbuf, size_t * outbytesleft) ; ポインターのポインターであるには理由がある。iconvは、すべて書き換えるからだ。ポインターを書き換えるのでポインターへのポインターを要求する。当然だ。当然であって欲しくないが当然だ。 なんでそんなに馬鹿げた副作用を持ち込むんだ。それでは必ずlvalueを渡さなければならないし、大抵の場合、もとの値を保持しておきたいから、オブ
危険な誘惑
というわけで、私がGNU/Linuxに改宗してから10日たった。この間、新しい環境に慣れるため、色々と試している。必要なソフトウェアをインストールしたり、気に入らない設定を変更したりなどだ。本当に自分の好みに合うように調整しようとしたならば、結局、設定ファイルを手動でいじったり、CLIのツールを使う必要がある。これは、私にとっては、さほど問題ではない。私は自力で調べて解決するのが好きだし、英語も読めるのでドキュメントにも困らない。しかし、やはりこの状況は、一般人がデスクトップOSとして使うには、少々難しいことは否めない。 さて、ここで危険な誘惑がある。それは、現状に満足できないという状況だ。たとえば、今使っているソフトウェアは、最新のバージョンではない。たとえば、今この文章を入力するのに使っているMozcのバージョンは1.1.773.102だが、最新の安定板のバージョンは1.3.975.1
btrfsの圧縮規格をめぐる争い
btrfsという、現在開発中のファイルシステムがある。これは、既存のextの系譜に変わるべく開発されているファイルシステムである。ext系列のファイルシステムはすでに十分な実績があるが、いかんせん土台とする技術が古い。これは、extのオリジナル作者であるTheodore Ts'oも認めている事実である。つまり、抜本的な革新のためには、全く新しいファイルシステムを開発する必要がある。 そこでbtrfsだ。btrfsは、近代的な技術を使った新しいファイルシステムである。内部の実装はさておくとしても、ユーザーにとっても便利な近代的な機能を多数提供している。スナップショットやサブボリュームのサポート、ファイルシステムによるRAIDや圧縮のサポート、オンラインデフラグ、オンライン動的ディスクの追加と削除、さらには、将来的には暗号化などもサポートする予定である。 これらの機能は、従来、ファイルシステム
GNU/Linuxでfontconfigにより日本語フォントを優先させる方法
GNU/Linuxでは、fontconfigによりフォントの優先順位を設定している。この設定によって、フォントに存在しないグリフでも補完して表示できる。この機能は、モダンなOSなら大抵備えている機能である。しかし、もし、日本語と文字を共有している他言語のフォント、例えば簡体字や繁体字のフォントの優先順位が、日本語フォントより高い場合、そのフォントが日本語フォントより優先されてしまう。 どうも、この問題に対して、場当たり的に対処している人間が多いようだ。たとえば、該当の日本語以外のフォントを削除するという選択だ。PulseAudioの件と同じ場当たり的な対応である。なぜ問題の本質を探ろうとしないのか。そもそも、多言語環境を本当に実現したければ、重複数複数のフォントがあっても問題ないようにすべきである。問題を本当に解決するためには、フォントの優先順位の変更が必要だ。 日本人ならば、日本語フォン
PulseAudioの問題
PulseAudioについては、悪い話しか聞かない。まだ私が不自由なOSであるWindowsを使っていた頃から、PulseAudioは酷評されていた記憶がある。 これが不思議だ。そもそも、PulseAudioというのは、低レベルAPIをラップする高レベルAPIである。PulseAudioによって、すべてのプログラムが、あたかもサウンドデバイスを独占的に使用できているかのような環境をエミュレートしている。その実装の質はともかく、思想は至って普通だ。モダンなOSなら、当然ハードウェアなどは通常のプログラムから意識させないようにするべきである。いまや、OSはサウンドデバイスの制限のあるミキシングに頼らないのだ。CPUは十分に速くなった。ソフトウェアでのミキシングは、現代のCPUならパフォーマンス上、なんの問題もない。いまや、完全なソフトウェアによるリアルタイムのミキシングやリサンプリングは当たり
AdobeがFlashゲームのみかじめ料を要求しはじめた
Adobe Flash Player Premium Features for Gaming | Adobe Developer Connection Got a Profitable Flash-Based Video Game? Adobe Wants a Cut | Webmonkey | Wired.com Adobeの不自由なソフトウェアであるFlash Playerのプレミアムな機能を使っていて、$50000以上の売上のあるFlashで作られたゲームは、売上の9%をAdobeに差し出すこと。 この利用料を回避する方法は、プレミアムな機能を使わないか、売上を下げるか、今年の8月までにFlashゲームの公開を取り下げることである。 もちろん、我々が皆同意するように、不自由なソフトウェアであるFlashを使わないという選択肢が最も優れている。だから早く不自由なFlashの利用をやめる
不自由なソフトウェアの時代は終わった
もはや、不自由なソフトウェアの時代は終わった。単純に終わったのだ。もうこれ以上、不自由なソフトウェアの未来はない。金銭的な価値はともかく、ソフトウェアの質は自由な方が圧倒的に高い。だからWindowsとかiOSとかAndoridが手元にあるならば、窓から投げ捨てるべきである。 こう言ったからとて、私は何も、フリーソフトウェア原理主義に改宗したのではない。今や、自由なソフトウェアの方が質が高くなっているからという至極単純な理由から言っているのである。私は質を優先する。不自由なソフトウェアの方が優れているのならば、いくら金を払っても構わないし、ソースコードが公開されていなくても構わない。しかし、事実として、今や、不自由でクローズドソースなソフトウェアは劣っている。自由か、最低でもオープンソースなソフトウェアの方が優れている。わざわざ不自由でクローズドソースなソフトウェアを使う必要はない。まして
clangにinheriting constructorが実装されない理由
Clangにopaque-enum-declarationがコミットされた。これで、残す機能はあと２つ、AttributeとInheriting constructorsだ。おそらく、最後に残るのはInheriting constructorsになるだろう。なぜか。誰も興味がないからだ。 freenodeでDouglas Gregorとチャットしていてこれを聞いたのだが、Inheriting constructorsが未だに存在しない理由は、興味を持つ者がほとんどいないからだそうである。それに、Inheriting constructorsの文面には、未だに曖昧な部分もあるとか。 実は、Inheriting constructorsとほぼ同等機能を、Variadic Templatesによってエミュレートできるのだ。これは、Douglas Gregorもペーパーで書いている。 US-65:
ffmpegとlibavの背景事情
ffmpegをインストールしようとしたら、なにやらちょうど一年前あたり、大規模なforkが起こったらしい。いまや、ffmpegとlibavに分裂している。forkは自由なソフトウェアではいたって普通の出来事だ。大抵の場合、開発者の間での意見の不一致により起こる自然な現象だ。自由なソフトウェアであれば、fork自体はそれほど悪いことではない。どちらも自由であるので、双方の開発者がIRCやMLで広角泡を飛ばしながら喧嘩しつつ、何事もなかったかのように相手のコードをこちらのコードベースにマージできる。なぜならば、どちらも自由なソフトウェアという共通点を持っているからだ。 しかし、ffmpegは、だいぶ巨大なソフトウェアだ。おそらく、現時点でこれ以上にでかい動画と音声のソフトウェアは、mplayerしかあるまい。mplayerはffmpegを包括しつつ、さらに変態的なことをしている。これについては
汚いものは隠して解決？
Linuxについて調べていると、どうも引っかかることがある。それは、Linuxがどうも、汚いものは隠して解決するという文化を持っていることだ。 たとえばXだ。聞きかじったところによると、X11は相当に汚いらしい。使いづらいし、今となっては不必要な古びた機能が多数存在する。これは、ほとんどの文章にそう書いてあるし、また実際に人にたずねても、誰一人としてX11の醜悪を否定したりしない。XFree86からフォークしたX.Orgなどは、Xを直接使うなと公式に宣言している。GTK+とかQtなどの、汚いものを隠した上のレイヤーを使えと推奨している。 X.Org Wiki - Documentation では、何故未だにX11が使い続けられているのか。もし、ある標準のAPIの設計が悪いとしたら、より優れた標準のAPIを設計すべきではないのか。なぜ悪い標準のAPIをラップした非標準のAPIを多数生み出すの
C++11のstd::swapはC++03のstd::swapとは互換性がない
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
GCC 5はモジュール化できるか
[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を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
