- 1 名前：デフォルトの名無しさん mailto:sage [2007/10/05(金) 20:16:30 ]
- プログラミング言語 D (D Programming Language) について語るスレッドです。
過去スレは >>2
■本家
ttp://www.digitalmars.com/d/
ttp://www.kmonos.net/alang/d/ (和訳)
■コンパイラ
ttp://www.digitalmars.com/d/dcompiler.html (DMD, 本家)
ttp://dgcc.sourceforge.net/ (GDC, gccフロントエンド)
ttp://gdcmac.sourceforge.net/ (GDCのmac用バイナリ)
■参考URL
ttp://f17.aaa.livedoor.jp/~labamba/ (D言語研究)
ttp://dsource.org/ (dsource)
ttp://www.sun-inet.or.jp/~yaneurao/dlang/
ttp://wisdom.sakura.ne.jp/programming/d/
- 331 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 22:25:30 ]
- ちなみに
Harmonia harmonia.terrainformatica.com/doku.php も
Ares www.dsource.org/projects/ares/ もすでにあるが
- 332 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 22:27:36 ]
- >>328
それいいけど名前資源の無駄遣いはそろそろ控えるべきだと思ったｗ
やるならマジでやって欲しい・・・
- 333 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 22:28:16 ]
- あるのかよ
だから無駄遣いはダメだと（ｒｙ
- 334 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:23:03 ]
- あったのか
ライブラリの名前資源の干渉は防げないもんなぁ
- 335 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:31:29 ]
- じゃあ、
com.digitalmars.phobosとかするか？ｗ
- 336 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 23:34:07 ]
- そんなことされたら勝手に名前変えるぞｺﾞﾙｱ
- 337 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:38:02 ]
- もう日本語にしちゃおうぜ
- 338 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:41:43 ]
- しかもひらがなな
- 339 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:44:24 ]
- 日本人である私たちがコードやコメントやパッケージ名に日本語を使わないのはおかしい！
って言ってみるテスト
- 340 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:45:24 ]
- import 標準.標準入出力;
void main() {
writefln("ほげほげ");
}
// こんなの嫌だぞ俺ｗ
- 341 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:47:01 ]
- でも
import std.stdio;
よりは意味が取れる罠ｗ
表意文字万歳
- 342 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:53:23 ]
- ヒント: タイプ数
- 343 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:55:16 ]
- じゃあひらがなかカタカナでいこう
- 344 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 00:57:55 ]
- ヒント: 文字幅
- 345 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:15:21 ]
- 輸入 標準.標準入出力;
無 主() {
整形書出改行("ほげほげ");
}
こんな中国産言語ならありそうだな
- 346 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:18:50 ]
- そしてブロックはPython風にインデントでやれば{}も消える！！
- 347 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:26:22 ]
- >>344
半カナはどうだ? タイプはかな入力で。
ﾄﾞｳﾆｭｳ ｷｶｸ.ｷｶｸﾆｭｳｼｭﾂ;
ﾅｼ ﾒｲﾝ(){
ｷﾞｮｳｶｷ("ﾎｹﾞﾎｹﾞ");
}
- 348 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:36:31 ]
- 話を広げておいて申し訳ないのだがものすごい既視感がｗｗｗ
前に似たような話してたお
- 349 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:36:58 ]
- >>347
かな入力なんてできる人はかなりレアだぞ…
俺にはつらいｗ
- 350 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:39:11 ]
- Phobos上でTangoが動作しつつ、キモイ名前をどうにかしてくれたらTangoはかなり使いやすいライブラリだと思うんだ。
って話だったっけ？
- 351 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 01:53:33 ]
- まったくそのとおりである
- 352 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 02:12:57 ]
- std::cout << "hoge" << std::endl; の悪習を引きずるかのような
Cout("hoge").newline; に代表される
気持ち悪いインタフェースがなくなればってのも加えておいてくれ
- 353 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 02:57:09 ]
- そもそも
std::cout << "hoge" << std::endl;
の良かったところはグローバルな演算子オーバーロードで簡単に拡張が加えられるところだったと思うんだ。
std::ostream& operator<<(std::ostream& strm, const Hoge& fuga);
逆にいえばこれが使えなければ意味がないわけで…
Cout("hoge").newline;
とかは何を意図してこんなことをしようと思ったのか…
まぁ、可変個数引数だと問題はあるけど。
String s;
Cout(s.append("aa"), s.append("bb"), s.append("cc"))).newline;
これだと
aabbccとなるかccbbaaとなるかわからん。
- 354 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:00:35 ]
- ここではおまいらが好き勝手言ってるだけだけど、
何か良くて何が悪いのかが評価できるなら素晴らしいライブラリを作ることもできそうなのになｗ
Phobosのobject.dをいじらず、The D Style準拠で
Cout周りのインタフェースをほげほげした（どうすんだこれ）
そんなTangoに改造したらいいってわけか
- 355 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:01:20 ]
- 2か所訂正…orz
auto s = new String; で aaaabbaabbccとなるかccccbbccbbaaとなるか…か。
- 356 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:03:07 ]
- >>353
待て待てその最後みたいなのはC++でもやっちゃいけないことになってるんじゃなかったか
それを問題視する必要はないことしようぜ
- 357 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:04:05 ]
- >>353
>演算子オーバーロード
ヒント: toString
- 358 名前：357 mailto:sage [2007/10/23(火) 03:05:52 ]
- あ、でもtoStringよりもストリーム演算子の方が効率的だわな。
- 359 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:08:47 ]
- >>353
>opCall_rまだー?
まで読んだ。
- 360 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:10:52 ]
- ("hogahage")Cout;
こうですか＞＜
- 361 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:11:59 ]
- 俺もそうおもたｗ
けどおかしいだろｗ
- 362 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 03:34:05 ]
- (Cout "hogahage");
じゃあこうですか＞＜
- 363 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:42:06 ]
- そして半角ひらがなの復活
- 364 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 17:17:25 ]
- 暇だから上げてみます。
自分用に作ったフレームワークです。
libwindowはライブラリでそっちをなるべくいじらない方向で設計されてます。
WorksMainはライブラリの実装で関数をガリガリ書くことでその目的を遂げます。
このライブラリはウインドウズ専用です。
www9.uploader.jp/dl/sukiyaki/sukiyaki_uljp00003.zip.html
- 365 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 17:37:53 ]
- >>363
ちょ！それスレ違い。
いや、俺もそのスレみてるからわかるんだが。
- 366 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 18:49:23 ]
- >>364
方向性にはげあがるほど同意
lowerCameｌはいかが？（参照>>308）
- 367 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 19:55:18 ]
- >>365-366
じゃああえて・・・DFLでよくね？
- 368 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 20:20:35 ]
- >>362
それなんてLisp?
- 369 名前：デフォルトの名無しさん [2007/10/23(火) 21:07:29 ]
- >>366
関数名はキャピタライズを採用して欲しかった俺がいる。
Time now = Now;
とかやりたかったのに・・
- 370 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 21:42:58 ]
- これで諦めてください＞＜；
Time now = Time.now();
- 371 名前：364 mailto:sage [2007/10/23(火) 23:33:54 ]
- www9.uploader.jp/home/sukiyaki/
ここのアップローダはD関係なら自由に使ってください。合計２００MBまで入りますから。
っていうか、人のライブラリがどうなってるか気になる！！！
そうそう、あとで後悔した時用に削除Passを忘れずに。
で！レスサンクス！！
>>366
こういう先頭大文字とかって名前あったんですね。。。
C++辺りからの癖になってるんですけど、次は小文字も検討してみます。
>>367
それ言われるとちょっと弱い。笑
⑨にも・・・を見るとTangoだとかvar1系だとかそういうのが良くわからないので使ってないんですけど、
将来的な移植性を考えるとやっぱ習得したいですねぇ。。。
- 372 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 23:57:44 ]
- 「ひとこぶらくだはひとこぶうんち ふたこぶらくだはふたこぶうんち これはうそ！」
lower/upper camel という字面を見てたら思い出した子供時代のはかない記憶。
- 373 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 12:20:43 ]
- Overload setっていうのでtoStringがかぶらなくなるのかと思ったら
import std.string;
class Foo {
void bar(char* ptr) {
string s = toString(ptr); // std.string.toString(char*)呼んで欲しい
// けどObjcet.toStringにマッチしないのでエラー
}
}
ダメなのか。まあstd.conv.toができたからいいけど
- 374 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 13:14:32 ]
- string s = .toString(ptr);
って書けばいいから、できなくても別に不便ではないな
- 375 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 13:29:20 ]
- ExceptionとErrorの使い分けがわかりません＞＜
おしえてくだしあ＞＜
- 376 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 13:31:57 ]
- class Exception;
回復可能な例外は全て Exception クラスから派生すべきです
class Error: object.Exception;
回復不可能な例外は Error クラスから派生すべきです
- 377 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 13:33:33 ]
- 回復が可能かそうでないかの区別がつきません＞＜＞＜＞＜
- 378 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 14:57:06 ]
- 例外が回復可能かどうかなんて設計段階で判断できるような。
設計で判断できなくても経験積めばここは復帰無理だなっていうのが直感で分かるように。
- 379 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 15:35:55 ]
- どの範囲で復帰不能か可能か、って話もあるしな
- 380 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 15:38:23 ]
- なにがどうなると回復不可能になるの？
- 381 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 15:46:00 ]
- 回復が不可能になるとだな
- 382 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 15:58:04 ]
- 場合によりけりでしょ。
タイムアウトなんかで期待される結果が帰ってこなかった場合に、
初期値等のテキトーな値代入して問題なく処理続行できるなら例外、
出来ないならエラーって言う感じでいいんでは。
- 383 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 16:29:31 ]
- 回復不可能だって分かった時点でErrorの子クラスでExceptionをラップして投げなおせばいい。
- 384 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 16:31:01 ]
- にゃる そういう意味なのか
システムがぬっ壊れたりするのかとおもた
- 385 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 18:59:27 ]
- 俺が分類したケース
回復不能
・root/admin権限が必要なのになかった
回復可能
・ファイルが見つからなかったが、指定しなおせばよい
>>384
最終的にはシステムがぬっ壊れない限りは回復の手段を用意することはできるかと思う
- 386 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:01:42 ]
- 処理続行できるような想定範囲内のエラーで例外投げるな。例外は例外的な事態に使用すべき。
……みたいなの（やや極端な言い方だけども）を信じてたんで微妙に慣れない。
多分戻り値でエラー処理みたいな文化が嫌なんだろうけど、効率なんかも考えると回復可能なエラーまで例外ってどうなの？ って気がしてしまう。
上みたいな（勝手な）文化を持ってたせいかExceptionに回復可能な、みたいなニュアンスも感じないし。
実際のところDでなんか書いてるときにみんなErrorとException使い分けてるの？
- 387 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:10:19 ]
- 俺の考えでは、プログラムの動作自体が危うい場合がError。
それ以外は全部Exception。
たとえば、ファイルをコピーするプログラム、copyを作るときに、
パラメータで指定されたファイルが見つからない場合は、Exception。
- 388 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:14:12 ]
- 基本的にException。
拾いたければ拾えばいいじゃん（たいていは回復可能だから）
というスタンス。
行列演算で要素数が不適切なときもException（動的に要素数を決められる場合）。
ただし契約違反は実装者が間違ってるからassertするときはErrorが多い。
- 389 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:18:20 ]
- >>386
引数、返り値が適切なほうがいいというのはあるかもしれない。
計画の中にpureという仕様が入ってるが、
ああいうのをまじめにやるならエラー処理のために引数や返り値がつぶされるのは好ましくない。
- 390 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 19:21:41 ]
- >>386
> 処理続行できるような想定範囲内のエラーで例外投げるな。例外は例外的な事態に使用すべき。
これは誰の教えなのかkwsk
- 391 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 20:44:55 ]
- 人生のExceptionが発生しました
- 392 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 20:58:52 ]
- >>391
回復可能なのか、よかったな
- 393 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 21:06:09 ]
- 回復には神権限が必要です
- 394 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 21:15:29 ]
- 引きこもりでごめんなさい→Exception
生まれてきてごめんなさい→Error
ってことか
- 395 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 21:33:52 ]
- お願い届いて！！私のException！！！
引きこもりでごめんなさい。
- 396 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 21:49:23 ]
- そろそろ人生のErrorが発生しそうで不安になってきた。
- 397 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:31:15 ]
- Javaみたく「こいつはこーいう例外投げるかもしれんからちゃんと対処しろよ！」ってコンパイラに言われないしなぁ。
意識してErrorを自前で投げたことはないや。
assert違反とか、デバッグモードで埋め込まれる配列境界チェックなんかはErrorか？ そんくらい。
あれ？ ErrorてExceptionの派生クラスだったのか？
つまり「Error is a Exception」「回復不可能は回復可能の一種」 ・・あれ？
おかしくないですかカテジナさん！
- 398 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:31:22 ]
- ファイル読み込みルーチンで、開くべきファイルがロックされてたり
ファイルがなかったりしたら、再試行とか考えてException、
そもそもファイルシステムや開くファイルの種類が非対応だったりして
なにをどうしようがファイル読み込みは無理、ってなのはError、とか。
ただ、それらを受け取るルーチンでは、たとえば別の読み込みルーチンを
使うとかで、（より大きな枠組みから考えると）復帰可能だったりするかもしれない。
という感じで、回復可能か否かが処理の段階によって変わることに注意して組むと
Errorの使い出もあるんじゃなかろうか。
- 399 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 22:53:29 ]
- Errorがでたのに何事もなくプログラムが動作し続けるってのは、ちょっとおかしいと思う。
それだと正常系に復帰してるじゃん、と。
OutOfMemoryぐらい致命的でないとErrorというのとはちょっと違うと思う。
- 400 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 23:08:48 ]
- >>399
回復不可能は回復可能がグレードアップ！
という考えで
- 401 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 23:11:16 ]
- つまり、ErrorをExceptionで捕えることができるのはおかしい、と。
Exceptionを派生したErrorってのがおかしいんだよな。
Errorを派生したExceptionとか、ErrorとExceptionはそれぞれ何からも派生してないってのがいいような気がするね。
Tangoみたいに安易に消しちゃうのはどうかとも思うが。
- 402 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 23:38:26 ]
- >>399
頑張ってメモリ解放して状況解消する頑健なプログラムだってありうるべ
メモリ食いつぶしかねないプログラムなら特に。
どんなエラーも何らかの処理がなされる、というのがDの例外機構なわけで、
399的な「絶対に正常系に復帰しない」発想だと、例外もクソもなく強制終了
するしかない状況じゃないとErrorを出さない、という意味のない話になるべ
何が正常動作かは処理の段階によって変わるんじゃね
- 403 名前：デフォルトの名無しさん mailto:sage [2007/10/24(水) 23:40:29 ]
- その処理の段階ってちゃんと定義されてるのかな？
今のままだとExceptionとErrorがごっちゃになりそうな悪寒
- 404 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 00:23:53 ]
- むしろError使ったことないし
必要な場面に出くわしたことがないし
これからも使わない気がしている
- 405 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 00:27:56 ]
- そういうのを定義するのが設計だべ
まあそんなまじめなプログラム俺も書いたことないけど
- 406 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 07:11:32 ]
- 2.006にしてみたらinvariant string関係の変更がtonほど出てきた
- 407 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 07:59:27 ]
- invariantのおかげでWin32API使うとき今まで以上にキャスト式書く機会が増えた。それ以外で特に気になるところはなし。
今は2.006でphobosが強化されたという話を聞いてわくわくしてるところ。
- 408 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 08:24:16 ]
- invariant stringとstd.stringの変更を解決してたら、設計の理由がなるほどと……
無駄なコピーを抑えたいという発想をどう実現するかがなんか分かってきた。
variant世界とinvariant世界が分かれてる感じで、
両者の窓口がcast(invariant)やidup、dupといった風情。
in char[]を受け取ってchar[]を返す関数の内部でstd.string関数を使う場合、
入り口でcast invariantして出口でdupすればおk、みたいな。
ただしこの方法だとスレッドセーフには気をつけないとならんので注意かも。
- 409 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 08:55:20 ]
- めぐりめぐって
invariantがなくなって、Cと同じになったりしてな・・・
- 410 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 09:41:42 ]
- 散々こねくり回して出た結論がそれならば、それもまたよし。
- 411 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 09:58:43 ]
- idupの個人的まとめ
・idupは本当にコピーを生成する
・idupしたコピーはGCに回収される
idupされた文字列を参照するようなstring（std.string中の関数の返り値など）をいつまでも受け渡し続けると、
いつまでたっても回収されずに残り続けることになるかもしれない。
巨大な文字列から1行だけ取り出すとかした場合はidupして、
巨大なやつをGCに回収してもらいやすくするのは考えられる。
idupは比較的気軽に使えるかなと思う。
長期的に生存する可能性があるプログラムについては知らね
- 412 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:25:51 ]
- ArrayBoundsErrorは回復不可能なんですか？
- 413 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:30:57 ]
- 配列の範囲外に対する不正なアクセスだからエラーなんでは？
そもそもDは配列のサイズがあらかじめ調べられるので、範囲外に対するアクセスは事前に防げるはず。
- 414 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:48:59 ]
- ほんとによく設計されたソフトウェアなら、モジュールがAssertErrorなんか投げてきても
catchして「このモジュールはバグってんな」って切り離て、
さらにそのモジュールに依存する別のモジュールにも通知したりして、
本当にコアなモジュールが生きてる限りは動きつづける、とか作りこむんだろーな。
apacheとかそんな感じになってるのか。Dじゃないけど。
気楽なDの個人アプリじゃそこまでやらんで、
void main(){
try{
myMain();
}catch(Exception e){
outputErrorMessage("ごめんちゃいバグで強制終了します。以下をコピペして送ってくれるとお互い幸せに。", e);
}
}
とかでいいよね？ 後は明らかに発生しそうなException（new File(stdin.readLine())とか）くらいは
その場でcatchすんの忘れないように気を付けなきゃ、で。
「catchすんの忘れてねぇか？ いいのか？」とコンパイラに言ってもらえればなぁ、とも思うけど、
そうなるとErrorとExceptionの違いが問題になってくる感じ。
- 415 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 10:55:20 ]
- もしかして関数呼び出すたびにtry-catch書くのが普通なのか
- 416 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 12:12:43 ]
- default: を書き忘れて例外出されたときはかなりビビッた。
何でswitchが例外投げるの！？って。
- 417 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 12:14:23 ]
- >>415
俺は！の話だけどさ、基本的に例外投げないな。だから、ほとんどtry構文使わない。
- 418 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 12:54:01 ]
- D言語で作られたアプリで参考になるのねーの？
- 419 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:10:04 ]
- >>415
それは普通、ではなく理想
- 420 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:45:58 ]
- 回復可能なもので例外投げるのは速度が・・・
- 421 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 13:52:39 ]
- 通常の実行ロジック部分のパフォーマンスが重要
例外時に速度重視？
- 422 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 14:13:54 ]
- ああ、なるほど。勘違いしてた
- 423 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 15:10:24 ]
- >>419
Cで関数呼び出しごとにエラーコードをチェックしてエラーコード返して・・・ってやるよりも
遥かにぐちゃぐちゃなコードが出来上がるだけな気がするのだけど。
それを無くして「正常な実行パス」だけを簡潔に書くための構造化例外やん？
- 424 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 16:07:23 ]
- >>423
分かっててもときどき変なことやっちゃうんだよね
特にC++とかJavaでね
try～catchはmainだけで充分なのかも知れない
- 425 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 16:35:20 ]
- >>423
すべての例外はどこかの階層で拾って、プログラムが適切に復旧するようにするのが理想。
別に、一関数ごとにtryで囲む必要はない。
- 426 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 18:13:59 ]
- in, body, outをはじめて使ってみたお^^
しかしenum/invariant structのような型で制限してしたほうが書くのは面倒だけど使えるお-_-;
- 427 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 20:35:06 ]
- >>426
でもoutとかで「戻り値にnullは絶対返さないよ！」とかassertしてあると使うのもコード読むのも安心するお^^
でも型だけで事足りるならちゃんと型設計してるってことだし偉いお^^
- 428 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 20:59:06 ]
- in/out/bodyってコード読むとき邪魔っぽくない？
- 429 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 21:05:16 ]
- ちょっとインデントに悩んだことはあった
- 430 名前：デフォルトの名無しさん [2007/10/25(木) 21:23:49 ]
- void hoge() in { assert(文); } body
{
// 処理
}
みたいに書いたり・・・？
in と out を関数内部に書きたかったりする・・・
void hoge()
{
in{ assert(文); }
out{ assert(文); }
}
あ、でもこれなら普通の scope 文でいいのか・・・？
- 431 名前：デフォルトの名無しさん mailto:sage [2007/10/25(木) 21:34:33 ]
- 公式の書き方は
ttp://www.digitalmars.com/d/dbc.html
中括弧を改行しないでくっつける派の俺としてはちょっと冗長に見える。
けどまあこれくらい改行するのもぱっと見わかりやすいのかな。
|
 |
