Boost総合スレ part6
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/04/09(水) 23:04:01part 5 http://pc11.2ch.net/test/read.cgi/tech/1192662575/
part 4 http://pc11.2ch.net/test/read.cgi/tech/1175663346/
part 3 http://pc11.2ch.net/test/read.cgi/tech/1158991211/
part 2 http://pc8.2ch.net/test/read.cgi/tech/1139313234/
part 1 http://pc8.2ch.net/test/read.cgi/tech/1091198276/
■関連サイト■
Boost C++ Libraries
http://www.boost.org/
Boost 翻訳プロジェクト
http://boost.cppll.jp/HEAD/
Let's Boost
http://www.kmonos.net/alang/boost/
boost info
http://shinh.skr.jp/boost/
0232デフォルトの名無しさん
2008/06/27(金) 17:59:320233デフォルトの名無しさん
2008/06/27(金) 18:03:16gzipもbzip2も空白になってるが。
0234デフォルトの名無しさん
2008/06/27(金) 18:52:33>90-91
0235デフォルトの名無しさん
2008/06/27(金) 21:50:26興味がおありでしたらVC2008用ライブラリ一式をどこかに上げますが如何致しましょう。
0236デフォルトの名無しさん
2008/06/27(金) 22:23:300237デフォルトの名無しさん
2008/06/27(金) 22:29:580238デフォルトの名無しさん
2008/06/27(金) 23:12:25>>236
ビルド方法なんて散々既出だとおもうが。
0239デフォルトの名無しさん
2008/06/28(土) 00:50:25こんな感じで如何でしょう。
ttp://booster.x0.to/build.txt
ついでにライブラリも。全部揃ってるかな？
ttp://booster.x0.to/boost_1_36_svn46766.rar
あ、私>>108でございます。
0240デフォルトの名無しさん
2008/06/28(土) 00:58:080241デフォルトの名無しさん
2008/06/28(土) 01:01:20Boostはビルドしているだけで未だ利用迄手が回っていない状態でございます・・・
0242デフォルトの名無しさん
2008/06/28(土) 03:14:420243デフォルトの名無しさん
2008/06/28(土) 05:29:58GJGJ
0244デフォルトの名無しさん
2008/06/28(土) 09:37:11サンクス
次からテンプレに入れたいなこれ
0245デフォルトの名無しさん
2008/06/28(土) 10:40:43朝起きてSVNを更新してみたらFixが大量に為されていたので、svn46798をビルドして上げておきました。
ttp://booster.x0.to
ドメインbooster.x0.toは一時公開用に取っただけだったのですが、
割と需要があるみたいですのでこのまま維持して週一位の間隔でSVNをビルドして上げていこうかと思います。
0246デフォルトの名無しさん
2008/06/28(土) 12:26:280247デフォルトの名無しさん
2008/06/29(日) 15:39:09つhttp://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Googleがお前らを気狂い認定ｗ
0248デフォルトの名無しさん
2008/06/29(日) 15:46:34C++ユーザーなんて認定上等！ だろうなぁw
0249デフォルトの名無しさん
2008/06/29(日) 16:33:020250デフォルトの名無しさん
2008/06/29(日) 16:40:150251デフォルトの名無しさん
2008/06/29(日) 16:50:53>such as metaprogramming and other advanced template techniques,
>and an excessively "functional" style of programming.
フヒヒｗ
>Currently, only boost/compressed_pair.hpp is permitted.
何故にcompressed pairだけ許可されているんだろう。
0252デフォルトの名無しさん
2008/06/29(日) 17:04:52続きの文章をコピペしないのは公平とはいえないな。
>We are actively considering adding other Boost features to the list, so this rule may be relaxed in the future.
我々は他のBoost機能をリストに加えることを活発に考えているので、この規則は将来緩和されるかもしれません。
0253デフォルトの名無しさん
2008/06/29(日) 17:24:18We do not use C++ exceptions.
We do not use Run Time Type Information (RTTI).
ってどうよ
0254デフォルトの名無しさん
2008/06/29(日) 17:39:56想像するだけでもぞっとしないし、至極妥当だと思うけど
なんか問題あったら適当に諦めて試合終了していいオモチャじゃなきゃ
そこらは慎重にならざるを得ないんじゃないの
0255デフォルトの名無しさん
2008/06/29(日) 17:59:340256デフォルトの名無しさん
2008/06/29(日) 18:05:24いや、それはどうでもいいんだ。
何で現時点で、compressed pairだけ許可されているのか気になるんだ。
あれってそんなに使い勝手がいいものじゃないだろ？
>>253
Googleにとって大抵のエラーは例外的なエラーではないんじゃない？
基本的に奴らは多数のコンピュータでスケールさせりゃいいって考えだし、
ハードの故障なんてしょっちゅうだし。
dynamic_castとかtypeidとかは、普通使う必要はないだろ。
ユニットテストには使っていいって書いてあるし。
実際デバッグぐらいに使うのが妥当だろ。
0257デフォルトの名無しさん
2008/06/29(日) 18:07:36Joel Spolskyも例外嫌いと言ってたけど
大体googleと同じ理由だったな
C++にはRAIIのようなテクニックはあるけど、彼らは非常に多くの顧客を
相手にしていて信頼性や性能の要求水準が非常に高いから、
例外を使いつつ、同時に要求される信頼性や性能を達成するってのが、
結局割に合わないってだけなんだよ
0258デフォルトの名無しさん
2008/06/29(日) 18:49:35それ例外の使い方間違ってないか?
例外安全意識して書いてれば
> なんか問題あったら適当に諦めて試合終了
なんてことにはならないんだが。
0259デフォルトの名無しさん
2008/06/29(日) 18:51:57万一拾い忘れたとき(コード人為的ミス)
(1) 例外の場合 : プログラム停止
(2) エラー値返しの場合 : エラー無視
で、デフォルトとしては(2)の方がまだましということかな？
だとすればRAIIとは関係ない論点ということになる？
0260デフォルトの名無しさん
2008/06/29(日) 18:59:35(1) のほうがマシと考える人も相当数いるとおもうから、それは理由には
ならないんじゃないか？
・例外使う派（既存のコードや人）と使わない派を組み合わせるとマズイ。
・例外安全という新しい概念が前面に押し出されていて面倒。
こんなところかと。
後者はエラーコードでも同じ話が出てくるはずなんだけどな。なぜか
例外に限った話だという迷信（？）が根強い。
0261デフォルトの名無しさん
2008/06/29(日) 19:23:440262デフォルトの名無しさん
2008/06/29(日) 19:36:330263デフォルトの名無しさん
2008/06/29(日) 19:37:28その程度のレベルの話はgoogle的には問題にもなっていない。
RAIIはあくまで「リソースリークを避けられる」だけだ。
RAIIさえ使ってれば例外安全、と思ってるならそれは違う、と言わざるを得ない。
例えば何か複雑なデータ構造を更新している最中に例外を投げられても
それで諦めて試合終了してはいけないプログラムであるような場合に、
真にコードが真に「例外安全」であることを保障するためのコストが、
例外により儲かるbenefitと全く釣り合ってないって話だろ。
0264デフォルトの名無しさん
2008/06/29(日) 19:44:53例外使わなければエラー発生時の安全性を保証するのが簡単になるの？
0265デフォルトの名無しさん
2008/06/29(日) 19:48:38Joelが書いているが、極端な話、非常にクリティカルな場所では
例外安全性を保障するために一文ごとにtry .. catchを使うことになる。
それは恐ろしく冗長で醜い。
それぐらいなら、古きよきエラーハンドリングのほうがまだマシだって話だろ。
0266デフォルトの名無しさん
2008/06/29(日) 19:54:05まさか、URL文字列の解読なんかじゃないよね？
0267デフォルトの名無しさん
2008/06/29(日) 19:54:060268デフォルトの名無しさん
2008/06/29(日) 19:58:18googleやJoelに言えよ。
カーネルがinodeやbtree更新してる最中に放り投げてファイルシステム
ぶっこわれたら困るだろ？
無論、i++;みたいな例外を投げないことが分かっているコードなら別だが、
関数呼び出しのようなものを含む場合は、それが例外を直接ないし間接に
投げないことを保障するにはcall treeを全部たどるしかない。
つまり、そのコードが例外安全かどうか、「正しい」コードかどうかを
判断するのが読み手にとってずっと困難になる。
言っておくが、皆が皆例外を使うべきじゃないなんて俺は一言も言ってないぞ。
奴らの要求水準にとってはそれが妥当なコーディングルールなのだろうと
言ってるだけだ。
0269デフォルトの名無しさん
2008/06/29(日) 20:03:16例外処理で吹き飛ぶファイルシステムって、停電でも吹き飛びそうで怖いな。
しかし、なぜに例外を禁止するかの具体的な理由は後学のために知りたいもんだけど。
0270デフォルトの名無しさん
2008/06/29(日) 20:05:170271デフォルトの名無しさん
2008/06/29(日) 20:05:380272デフォルトの名無しさん
2008/06/29(日) 20:33:250273デフォルトの名無しさん
2008/06/29(日) 20:42:22C++、Java、PythonがGoogleの公用語だったはず。
JavaはSUNと共同開発だかなんだかする位。
Pythonは作者を雇っちゃってる。
0274デフォルトの名無しさん
2008/06/29(日) 20:47:050275デフォルトの名無しさん
2008/06/29(日) 21:58:33不具合対処のデバッグが極端に難しくなるのが、原因だと思う。
少なくともWindowsだと落ちてくれる方が、不具合対処はよっぽど楽だし。
0276デフォルトの名無しさん
2008/06/29(日) 22:43:00１行目は、終了処理はデストラクタで。
２行目は、なんだろう？
３行目は、落ちてくれるほうがいいなら例外マジおすすめ。
ってことで、２行目詳しく。
0277デフォルトの名無しさん
2008/06/29(日) 22:57:32mainでcatchしてると、例外の箇所でデバッガがブレークしてくれないよー。なんてことじゃないことを祈る
0278デフォルトの名無しさん
2008/06/30(月) 00:17:50後付けでまだまだうまくライブラリ群に融合してないからでしょう。
例外機構そのものには問題はない。
> カーネルがinodeやbtree更新してる最中に放り投げてファイルシステム
> ぶっこわれたら困るだろ？
例外を全く理解してない。30年くらい前の頭。
0279デフォルトの名無しさん
2008/06/30(月) 00:21:07しつこく食い下がる割に、ビッグネームの言い分に立ち向かうことには及び腰で
あくまで「ここの連中の言葉」だけ相手にしたがるお前にﾜﾗﾀ。
0280デフォルトの名無しさん
2008/06/30(月) 00:21:140281デフォルトの名無しさん
2008/06/30(月) 00:24:00短絡思考
0282デフォルトの名無しさん
2008/06/30(月) 00:24:42解説お願いします
0283275
2008/06/30(月) 01:14:223行目の"落ちる"は例外処理してプロセス終了させる意味ではなくて、
アプリケーションエラー(メモリ参照エラー等)で落ちるの意味。
で、2行目と3行目は大体同じ意味。Windows前提だけど、例外処理を捕捉して
ログ吐かせるのに手間ヒマかけるよりか、自動起動のデバッガのスタックトレースを
追っかけた方が対処が早いし確実。
tryブロック内でnewしたオブジェクトの後片付けは、finallyとかあったら楽なのかも。
>>277
昔、ネストしたクラスで例外処理していた時に、子クラスから親クラスへ順々に
catch (ex) ⇒ throw ex していたら、どこで異常処理になっているのか
さっぱり分からなくなった記憶が…。例外処理のセオリー(デザインパターン？)
みたいなものってあるんでしょか？
0284デフォルトの名無しさん
2008/06/30(月) 01:16:22例外機構事態に問題がある、とかいう話じゃねえよ。
問題があってもきちんとロールバックやリカバリを行って動作し続けなければ
ならないような、間違ってもデータ構造更新中に中途半端な状態で放置
してはならないような種類のプログラムで、例外機構を使って信頼性のあるコードを
書くのが難しいし、そのコードの例外安全性を保障することは、さらに難しいって
話だろ。
勿論、エラーを送出し得る全てのコード（関数呼び出し）を逐一try/catchで囲めば
意味的には例外を使わず全ての関数呼び出しの戻り値をチェックするのと同じだ。
が、そんなことをやるコードは、単に戻り値をチェックしてエラー処理をする
コードよりも汚く冗長で、その上無用なオーバーヘッドを抱えることになる。
つまり、ちっとも嬉しくないだろ。例外使っても。
0285デフォルトの名無しさん
2008/06/30(月) 01:19:12VCのデバッガ場合ハンドルされている例外はブレークしないのがデフォ設定になってる。
デバッガの例外の設定でブレークがかかるようにできる。
0286デフォルトの名無しさん
2008/06/30(月) 01:19:34> 自動起動のデバッガのスタックトレースを
構造化例外を捕捉して起動してますが…
0287デフォルトの名無しさん
2008/06/30(月) 01:20:160288283
2008/06/30(月) 01:50:07知らなかった…orz。ありがとうございます。
>>286
なるほど、構造化例外(SEH)は書籍でしか見たことがなかったもので…。
ありがとうございます。
>>287
すいません、初期化子について良く分かってないんですが、以下のサイトに書いてあることと関連あるんでしょうか？
ttp://rararahp.cool.ne.jp/cgi-bin/lng/vc/vclng.cgi?print+200407/04070024.txt
0289デフォルトの名無しさん
2008/06/30(月) 01:57:290290デフォルトの名無しさん
2008/06/30(月) 02:45:06うんうん、これよくわかった。どうもありがとう。
想定エラーケースのうち :
ちまちま細かいリカバー継続処理(数ステップ程度)が求められるケースが多いプログラムの場合
-> 返り血方式の方が書くのが楽
(場合によってはブロックも越えて)どかんと飛ぶようなスキップ・再試行が求められるケースが多いプログラムの場合
-> 例外方式の方が書くのが(相当)楽
ということね。
まあ、みんなもそうだろうけど、ちまちまとどかんの両方あることわかってて、
例外方式だけで統一するか、返り血方式だけで統一するか、設計時に岐路に立たされるよね。
余談だが、実は例外使うのなかなかハードル高いよね。
別の人も書いてたけど、両方式まぜまぜが一番イクナイというか怖い、のだが、
既存ライブラリやAPIは返り血方式をとってるのが多かったりするという第一の壁。
あと例外は拾い損ねが一番恐ろしいわけなのだけど
JAVAのように独占的な１製作者が例外クラスを統一的に設計してくれてればcatchもしやすいんだが、
MSでいえば、標準ライブラリ・MS COMラッパー・MFCなど例外乱立しててぷぎゃー。第二の壁。
デザパタとかでどうにかなる問題なのだろうか。
0291デフォルトの名無しさん
2008/06/30(月) 02:47:24しまった、名前のほうに番号書くべきだったみたいだな
0292デフォルトの名無しさん
2008/06/30(月) 03:12:02例外を送出するかもしれないコードを、
例外使ってないコードから利用するのは難しいからだってさ。
んで、Googleにはすでに例外を使ってないコードがたくさんあるから、
そこから新しいコードを使うことを考えると、例外は使えないと。
スクラッチから始められるなら例外使うかもしれんらしい。
0293デフォルトの名無しさん
2008/06/30(月) 04:56:17リファクタリングする気もないわけですな
0294デフォルトの名無しさん
2008/06/30(月) 05:08:300295259
2008/06/30(月) 07:19:00横着して原文読まずスレだけ読んでたんだが、適切な説明ありがとん。
ビッグネームの言い分に立ち向かうとか、んな大袈裟な話でもなかったわけな。
0296デフォルトの名無しさん
2008/06/30(月) 08:13:170297デフォルトの名無しさん
2008/06/30(月) 08:29:59> 問題があってもきちんとロールバックやリカバリを行って動作し続けなければ
> ならないような、間違ってもデータ構造更新中に中途半端な状態で放置
> してはならないような種類のプログラムで、例外機構を使って信頼性のあるコードを
> 書くのが難しいし、そのコードの例外安全性を保障することは、さらに難しいって
> 話だろ。
これの理由がわからん。なんで信頼性が変わるんだ？
例外安全性の保証についても、戻り値を使う派はエラー安全性の問題を無視して
「ほら簡単でしょ」と言っているだけのような気がする。ほんとに戻り値使ってエラー安全な
コード書いた上で比べてるのか？酷いもんだぞ。
0298デフォルトの名無しさん
2008/06/30(月) 08:32:37プログラムが関与できる原因によって発生した例外とがごちゃ混ぜになってるから信頼性が変わるって話だろ。
0299デフォルトの名無しさん
2008/06/30(月) 08:37:46プログラムが関与できる・できないの区別が具体的にどんなものかわからない。
それもあって当然、それらが混ざってると信頼性が変わる理由がわからない。
もうすこし詳しい説明希望。
0300デフォルトの名無しさん
2008/06/30(月) 08:57:30例外処理の記述が恐ろしいほどシンプルになる。
0301デフォルトの名無しさん
2008/06/30(月) 09:14:38古いコードから新しいコードを使いにくいからか。
変な理由だな。
0302デフォルトの名無しさん
2008/06/30(月) 09:18:17新しいライブラリに置き換えるのは大変なはずだけどなw
0303デフォルトの名無しさん
2008/06/30(月) 13:18:170304デフォルトの名無しさん
2008/06/30(月) 15:23:31例外だとだめで返値ならＯＫって、んなバカな話はない。
Joelが言ってるのだって、例外を知らないバカ対策でしかない。
0305デフォルトの名無しさん
2008/06/30(月) 17:42:57してるとでも思ってるのかｗ
少なくともお前よりは優秀な人間しかJoelの周りにはいないだろうよ
0306デフォルトの名無しさん
2008/06/30(月) 18:43:31バカ対策ではない理由を挙げてくれよ。ソース付きで。
0307デフォルトの名無しさん
2008/06/30(月) 19:10:180308デフォルトの名無しさん
2008/06/30(月) 19:11:480309デフォルトの名無しさん
2008/06/30(月) 20:51:49つhttp://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
0310デフォルトの名無しさん
2008/06/30(月) 21:09:262要素のタプルは使用頻度が高い＆データ数が数百億単位になる
Google では1要素あたり1バイトでも節約したいとかそんな感じだろうか？
別のエントリで shared_ptr を使おうとかいってんのになあ
0311デフォルトの名無しさん
2008/06/30(月) 21:32:050312デフォルトの名無しさん
2008/06/30(月) 21:51:44こいつだろ。知らない奴なんているのかよ。
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
これはアプリケーションハンガリアンの説明として有名な文書だが、
例外に関する彼の主張も書いてあるから読んどけ。
0313デフォルトの名無しさん
2008/07/01(火) 00:11:14Googleは社内の馬鹿対策してる会社だよ。
http://labs.google.com/papers/mapreduce.html
> This allows programmers without any experience with parallel and
> distributed systems to easily utilize the resources of a large
> distributed system.
本文や関連資料を読んでいただくとより明確に分かるが、
雇われも含めて社内のプログラマを対象とした話。
0314デフォルトの名無しさん
2008/07/01(火) 00:11:26しかし、悲しいかな彼は英語を読めなかった。
それが、自らの主張を真っ向から否定する証拠そのものだと言うことを、
彼は理解出来なかったのだ。
0315デフォルトの名無しさん
2008/07/01(火) 01:24:05> Joel Spolskyも例外嫌いと言ってたけど
> 大体googleと同じ理由だったな
そもそもジョエル・スポルスキーはそんなこと言ってたのかという
挙げ足取りが過ぎるか。。。
プログラム板ってIDないから、どいつがどいつなのかわかんないのが不便。
0316デフォルトの名無しさん
2008/07/01(火) 06:59:020317デフォルトの名無しさん
2008/07/01(火) 07:02:17ここにエスパーはいませんよ。
0318デフォルトの名無しさん
2008/07/01(火) 07:06:250319デフォルトの名無しさん
2008/07/01(火) 08:07:30エラーの内容すら無いんじゃ答えようも無いな
0320デフォルトの名無しさん
2008/07/01(火) 10:06:260321デフォルトの名無しさん
2008/07/01(火) 10:21:13「このままじゃ全員黙ったままだよ」
っていうのを、急に親切に教えてあげたくなってねｗ
0322デフォルトの名無しさん
2008/07/01(火) 10:56:09対策が無いなら良いんです。
0323デフォルトの名無しさん
2008/07/01(火) 10:56:18それじゃ、おいらがとっておきと対策を伝授しよう。
諦めろ。
0324デフォルトの名無しさん
2008/07/01(火) 10:58:530325デフォルトの名無しさん
2008/07/01(火) 11:39:16最近>>320みたいな嵐が沸いてるから、酉つけたほうがいいぞ
0326デフォルトの名無しさん
2008/07/03(木) 00:46:240327デフォルトの名無しさん
2008/07/03(木) 10:36:15人間のクズめ。
0328デフォルトの名無しさん
2008/07/04(金) 00:46:570329デフォルトの名無しさん
2008/07/04(金) 18:05:48モノの聞き方を考えてから投稿しろ
0330デフォルトの名無しさん
2008/07/04(金) 21:20:10ttp://booster.x0.to/
0331デフォルトの名無しさん
2008/07/04(金) 23:27:31■ このスレッドは過去ログ倉庫に格納されています