日銀が7月の決定会合で、政策金利の0.25%への引き上げを決定しました。これまで日銀は、利上げの条件として、『安定的持続的な物価上昇率2%』という目標達成が見通せたら、と説明してきました。しかし、今回は…
日銀が7月の決定会合で、政策金利の0.25%への引き上げを決定しました。これまで日銀は、利上げの条件として、『安定的持続的な物価上昇率2%』という目標達成が見通せたら、と説明してきました。しかし、今回は…
Waylandは、将来的に、Xを代替する目的で開発されている、相当に野心的なソフトウェアである。 今、GNU/LinuxでまともにGUIのソフトウェアをつくろうとしたら、Xは直接使わない。GTK+やQtなどといったライブラリを使う。これらのライブラリは、様々なバックエンドを持っている。たとえば、SVGやHTML5バックエンドなどもある。だから、これらのライブラリを利用していれば、Waylandへの移行は、理想的には、再コンパイルだけで済むはずである。とはいえ、現実には、再コンパイルだけで済むことはないだろう。 XからWaylandに移行するためには、Waylandが使われるようにならなければならない。しかし、既存のXバックエンドのソフトウェアが動かないのでは意味がない。そこで今考えられているのは、XとWaylandを両方動かすというものである。 Waylandが裏で必要に応じてX Serv
Diego Novillo - Switching to C++ by default in 4.8 GCC開発者の一人でGooglerのDiego Novilloは、今月の3日にMLで、GCC 4.8のビルドをデフォルトでC++にしようと提案している。これは、GCC自体をビルドする際のデフォルトの言語をC++にするという意味である。GCCがコードをデフォルトでC++としてコンパイルするのではない。現在のGCCビルドシステムの言語モードをC++に切り替えるのは非常に簡単で、必要なのはテストだけだという。 2011年、GCCの実装で、C++を使用可能にする採択が受け入られている。GCC自体のコンパイルをデフォルトでC++にすることは、GCC実装におけるC++の利用を更に加速するだろう。 GCCにおけるC++利用のコーディング規約は、目下作成中である。コーディング規約が完成する前に、GCCのビ
江添亮 自由ソフトウェア主義者 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
思うに、私が最初の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の方が不自由なWindowsより日本語サポートが優れている。これは純然たる事実である。 私は、UIが日本語化の質を論じているのではない。私はUIの言語を英語にしているので、UIの日本語の質についてはわからない。ただ、2012年となった今では、GNU/Linux/Xの環境の方が、圧倒的に日本語を扱う環境が優れていると考えているのだ。 まず、現行のまともなディストリは、文字エンコードをデフォルトでUTF-8にしている。このため、不自由なWindowsにおける、カオスな大量のマルチバイト文字コード混在環境の問題は存在しない。確かに、不自由なWindowsのネイティブの文字エンコードはUTF-16だが、下位互換性を保証するために、既存のマルチバイト文字をすべて継続してサポートしているために、未だにカオスな状況になっている。多くのプログラムは、嘆かわしいことに、いまだにANS
tupleのネスト template parameter packを固定長のtemplate parameter listに展開するのは、gcc 4.6では未実装である。ただ、gccのエラーメッセージが、これを正しく判定できない場合がある。 template < typename T1, typename T2 > struct A { } ; template < typename T, typename ... Types > void f( T, Types ... ) { A< T, Types ... > a ; } int main(int argc, char* argv[]) { f( 0, 0 ) ; } この場合は正しく未実装だというコンパイルエラーになるが。 template < typename T1, typename T2 > struct A { } ; te
というわけで、私がGNU/Linuxに改宗してから10日たった。この間、新しい環境に慣れるため、色々と試している。必要なソフトウェアをインストールしたり、気に入らない設定を変更したりなどだ。本当に自分の好みに合うように調整しようとしたならば、結局、設定ファイルを手動でいじったり、CLIのツールを使う必要がある。これは、私にとっては、さほど問題ではない。私は自力で調べて解決するのが好きだし、英語も読めるのでドキュメントにも困らない。しかし、やはりこの状況は、一般人がデスクトップOSとして使うには、少々難しいことは否めない。 さて、ここで危険な誘惑がある。それは、現状に満足できないという状況だ。たとえば、今使っているソフトウェアは、最新のバージョンではない。たとえば、今この文章を入力するのに使っているMozcのバージョンは1.1.773.102だが、最新の安定板のバージョンは1.3.975.1
Willus.com's 2011 Win32/64 C Compiler Benchmarks これはすごい。Windows上で動くCコンパイラーを様々な面から比較している。ベンチマークに使ったソースコードは、すべて純粋なC言語である。アセンブリやインラインアセンブリは無効にしてある。これは純粋なCコンパイラーの性能を図るためだからだ。 まず、コンパイラー自体の問題がある。Intelのコンパイラーは、デブすぎるにもほどがある。Intelのパッケージだけで1.6GiBもあるのに、これにさらにVisual Studioを別途インストールしなければ使えない。さらに、Intelのインストーラーは40個以上もの別個のソフトウェアをインストールする。それぞれ、バッチスクリプト用にPATHを追加するので、PATH環境変数に何十個も追加されることになる。Windows 7では、インストール済みのソフトウ
btrfsという、現在開発中のファイルシステムがある。これは、既存のextの系譜に変わるべく開発されているファイルシステムである。ext系列のファイルシステムはすでに十分な実績があるが、いかんせん土台とする技術が古い。これは、extのオリジナル作者であるTheodore Ts'oも認めている事実である。つまり、抜本的な革新のためには、全く新しいファイルシステムを開発する必要がある。 そこでbtrfsだ。btrfsは、近代的な技術を使った新しいファイルシステムである。内部の実装はさておくとしても、ユーザーにとっても便利な近代的な機能を多数提供している。スナップショットやサブボリュームのサポート、ファイルシステムによるRAIDや圧縮のサポート、オンラインデフラグ、オンライン動的ディスクの追加と削除、さらには、将来的には暗号化などもサポートする予定である。 これらの機能は、従来、ファイルシステム
自由なソフトウェアの力は素晴らしい。とすれば、自由の威力はドキュメントにも及ぶはずだ。現在、ほとんどの紙書籍は不自由である。Web上にホストされている検索可能なドキュメントの多くは、後述する通り、複製や公衆送信や翻案を暗黙に許しているわけだが、たいてい、明示的な許諾が与えられていない。そのため、Web上のドキュメントは真に自由なのではなく、ある程度は自由のように振る舞うことを黙認されているだけである。この現状は不自由である。 いかに現行法が実情にそぐわないものであったとしても、今を生きる我々は現行法に従わねばならぬ。コピーレフトなライセンスは、著作権法を利用した賢いハックである。著作権法は、著作物の利用の独占を許している。本来、独占は禁止されているが、著作権法や特許法や商標法などは、独占を実現することが目的なので、独占を禁止する法律の適用外である。独占者たる著作者は、著作物の利用許諾を与え
会社のMacを新しいもの(OSがLionのもの)に変更した所、時刻が表示されなくなりました。 以下のサイトにてiStat Menusが原因だと判明しました。 メニューバーに日付や時間等が表示されない: Apple サポートコミュニティ https://discussionsjapan.apple.com/thread/10082711?start=0&tstart=0 対処方法はiStat Menusの削除。 しかし、自分の場合はバージョンが異なるのか、インストールされている場所が記載されているパスと異なっていました。 自分のバージョンでは以下のフォルダに有る iStat のフォルダ内のuninstallerを実行してiStatを削除した所、解決できました。 /ライブラリ/Application Support/
C++標準ライブラリのI/Oストリームにある暗黙のユーザ定義変換(user-defined conversion)のせいで、プログラマが意図しない動作を引き起こすケースがある。 #include <iostream> int main() { std::cout << std::cin; // ?? } 上記コードは正常にコンパイル可能。gcc 4.6.3でコンパイルしたときの実行結果の例。 $ g++ -W -Wall -Wextra -pedantic source.cpp $ ./a.out 0x6c504048 ここではbasic_istream<char>型のcinオブジェクトに対して、その公開基底クラスbasic_ios<char>のユーザ定義変換関数operator void*() constが暗黙的に呼び出されている。C++03 27.4.4.3/p1より引用。 opera
元記事:Benign Data Races Considered Harmful | Corensic, Bartosz Milewski氏, 2011/6/7 自分自身の理解のために日本語訳を行ったC++11でのデータ競合に関する記事。(タイトルはいわゆる"〜 Considered Harmful"ネタ) 良性データ競合は有害である 最近、本ブログで大いに論争を巻き起こした良性データ競合(訳注:同記事の拙訳)に関する一連の投稿があり、また多数のディスカッションが行われました。2つの陣営が形成され、一方はデータ競合は良性たりえないと主張し、他方はデータ競合はパフォーマンスを得るために必要だと主張しています。そしてデータ競合の定義すらも合意できていないと分かりました。特に、C++11での定義は従来の概念からは逸しているようです。 データ競合っていったい何? まず初めに、議論の対象を明確にしま
元記事:Dealing with Benign Data Races the C++ Way | Corensic, Bartosz Milewski氏, 2011/5/9 自分自身の理解のために日本語訳を行ったC++11のデータ競合に関する記事。 良性データ競合へのC++的対応 データ競合(data race)は未定義動作(undefined behavior)を引き起こします。でも、実際にはどれほどマズいことなのでしょうか?前回の記事では良性のデータ競合*1にふれて、Windowsカーネルでの実例をいくつか示しました。カーネルの場合は、特定プロセッサ向けに特定コンパイラを用いてコンパイルされるため、これらの実例は正しく動作していました。ただし一般論としては、コードをポータブルにしたいならば、データ競合を含んでいてはいけません。以上。 明確に“未定義(undefined)”と定義されたも
C++言語の定義済みマクロ__cplusplusについてメモ。 C++ソースコードとしてコンパイルされるときのみ定義され、C/C++言語共用ライブラリヘッダ等でよく利用される。 // C/C++共用ヘッダファイル #ifdef __cplusplus extern "C" { #endif // ここでの宣言はC言語の場合はそのまま処理され、 // C++言語の場合は"C"リンケージ指定として処理される。 #ifdef __cplusplus } #endif C++言語仕様での定義 __cplusplusマクロの値は、準拠するC++規格バージョンによって異なる。C++98/03とC++11(N3337) 16.8/p1よりそれぞれ該当箇所を引用。(太字は強調) The following macro names shall be defined by the implementation
昨日、4月1日に3月末に退社した社員のパスワード(ここに詳しくは書けない)がわからなくなって困っているという相談をあるお客さんから受けた。 その社員は、そこの上司に個人的な怨恨があるらしく「死ね!」と言い残して辞めていったのだそうだ。パスワードを教えなかったのは何かの腹いせなのだろうか。 ともかく、その社長の許可を取り、私はダメ元で総当り攻撃をしてみることにしたが、1時間ほどやってみて、無理そうだから切り上げ。 次に辞書攻撃をしてみることにした。辞書は英語辞書やWikipedia等から集めてきた私のお手製のものだ。これも1時間ほどやって無理そうだから切り上げ。 辞書の単語の組み合わせも試してみることにした。 私が攻撃に使う辞書はそれぞれの単語のIDなどに出現する頻度を統計的に求めてある。 これを使って、例えば、10%で出現する単語flowerと20%で出現する単語catを組み合わせたflo
C++11言語仕様ではif/for/while/do-while構文における条件部(condition)の扱いが微妙に変更された。また、これに関連してC++標準ライブラリのインタフェースも一部変更されている。(→[id:yohhoy:20120406:p1]など) この仕様変更により、C++98/03におけるSafe bool Idiom*1はC++11では時代遅れとなる。C++11では明示的ユーザ定義変換関数 explicit operator bool() const; を定義しておけば良い。 C++03、C++11(N3337) 6.4/p4よりそれぞれ該当箇所を引用(下線部は強調)。 The value of a condition that is an initialized declaration in a statement other than a switch state
AMDのForward+以来Tiled Forward Shadingの話題が盛り上がってるようですが,ちょっと先月の記事ですが”2012 Theory for Forward Rendering”というエントリがありました. 2012 Theory for Forward Rendering http://aras-p.info/blog/2012/03/02/2012-theory-for-forward-rendering/ それから同じblogの方で,関連する話題のリンク集がありました. Tiled Forward Shading links http://aras-p.info/blog/2012/03/27/tiled-forward-shading-links/ 今年は,Tile-basedなForward Renderingの議論が活発になりそうですね.
ちょっとコマンドラインでぽちぽちやる必要がでてきて、解析するのがめんどくさいので Boost.ProgramOptions でも使おうと思います。 このライブラリはビルドしないと使えない(ヘッダオンリで利用できない)ので、そこは注意して下さい。 名前空間は長すぎて泣けるので省略しましょう。 example でやってる形で po にします。 #include <boost/program_options.hpp> namespace po = boost::program_options; コマンドラインだけでなく、hogehoge.conf などのようにファイルから読み取る事もできるらしいのですが、そこまではいらないので省略。 #include <boost/program_options.hpp> #include <iostream> int main(int argc, char**
std::arrayに、fill()という指定した値で配列を埋めるメンバ関数があるのですが、 boost::arrayにはないのでどういう経緯で入ったのか調べました。 該当するissueはこれでした。 776. Undescribed assign function of std::array Suggest substituting "fill" instead of "assign". 元々はassign()という名前だったようです。この名前ならboost::arrayにもありますし、std::vectorにも同じ名前・同じ機能のメンバ関数があるので納得できます。 ただ、fill()メンバ関数があっても、アルゴリズムの方のfill()があるので別にいらないですね…。
Coding Horror: Speed Hashing xkcd: Password Strength GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。 もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。 ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、
中国の教科書クッソワロタwwwwwwwwwwwwwwwwwwwwwwwwwwww
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
水素を安全かつ効率的に貯蔵できる技術が登場! 水素燃料の未来はバラ色か!?2012.04.06 16:00 水素って燃やしても二酸化炭素が出ないので、クリーンなイメージがありますが、一方で爆発性の気体だったりで、非常に扱いにくい燃料なんですよね。 そんな水素を安全かつ効率的に貯蔵できる技術を日本の産業技術総合研究所とアメリカのブルックヘブン国立研究所が共同で開発したそうですよ。 この技術...何が凄いかということ以下の3点を実現したことにあるそうです。 ・二酸化炭素と水素からギ酸、ギ酸から二酸化炭素と水素への変換をpHで制御できる触媒を開発したこと ・新開発の触媒により、常温常圧の水中で二酸化炭素と水素をギ酸に変換することが可能になり、貯蔵や運搬が容易になったこと ・新開発の触媒により、ギ酸を分解し、二酸化炭素と燃料電池に適した高圧水素の供給が可能になったこと これまでの技術だと、高圧高温
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く