C++は難しすぎ 難易度:2

1 名前：前々スレ985 mailto:sage [03/12/18 06:52] 理解できないわけないだろ！ デザパタも知らずにC++使いの質を下げるC厨には げんあり 前スレ達 難易度:1 pc2.2ch.net/tech/kako/1058/10586/1058675178.html 難易度:2 1pc2.2ch.net/test/read.cgi/tech/1063323615/ 830 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 11:05:23 ] 一般論としてJAVAの方が習得が容易だといわれているんだから JAVAの方が生産性が高いって話 まぁ後からでた言語の方が生産性高いのは当然だろうけど 統計取ったのか？とか突っ込まれる悪寒 831 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 18:25:34 ] >>824 ＞流石マ板 オイ 832 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 08:52:09 ] ごめん マ、ム、は回転させると同じだからよく間違えるんだ。 母の胎内のようだ 833 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 09:49:20 ] >>830 > 統計 「"言語名" 人材募集」でググったのが統計になるらしいぞ。 ２ちゃんで見たから間違いない。 834 名前：デフォルトの名無しさん [2007/09/03(月) 10:44:30 ] C++は難しくない。ややこしくて複雑なだけ。 その複雑さを理解してだけで得意になってる馬鹿もいるし 835 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 13:00:39 ] 刃物は危なくない。切れたり刺さったりするだけ。 836 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 14:47:41 ] *気を付ければ* 837 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 15:00:22 ] もちろん安全装置だっていろいろあります。 838 名前：デフォルトの名無しさん mailto:sage [2007/09/25(火) 10:30:13 ] C++何年も使ってたのに1年ブランクあるとと書けないな Cならそんなことないのに 839 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 09:26:36 ] C++に不足してるのは名前付き引数だな。 オプション引数の順番いちいち覚えなきゃいけないとか、 テンプレート持ってる割に古臭い。 boostのいびつさと言ったら。 840 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 09:52:53 ] それね、検討されたらしいんだ。 でも、新しいパラダイムが来るわけでもより型安全になるわけでもないとか、 関数を引数名の分だけ呼ぶ側と呼ばれる側の束縛が強くなるとか そもそもそれが欲しくなるほど引数が多いなんて下手な証とか、 反対意見が多くて却下されたという過去があるんだ。 参照：D&E 6.5.1 キーワード引数 841 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 10:29:08 ] その割にはC99にはあったような気が…… 842 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 13:46:14 ] 名前付き初期化子のこと？配列と構造体限定でよければ確かにある。 843 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 14:56:14 ] ↑アホ 844 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 17:12:58 ] ↑ニンニク 845 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 23:22:34 ] 名前付き引数？ 仮引数に変数名つけるじゃん 846 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 23:24:54 ] と思ったら順番関係なくなるのか それはいいな 847 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 00:28:50 ] Python使ってるとキーワード引数の便利さはよくわかる。 C++でもクラステンプレートのPolicyとかでは出来るのにね。 848 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 05:52:03 ] boost.paramいやなんでもない 849 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 23:09:47 ] boostってまだ標準ちゃうしなぁ 850 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 09:53:49 ] テンプレートのチューリング完全性が意図したものではなく のちに発見されたものだというのがC++の複雑さを如実にあらわしてる その複雑さの果ても解明されようとしているが C++0xが新たなカオスを持ち込んでくれる 好き物プログラマーとしてはたまらないね 851 名前：デフォルトの名無しさん mailto:sage [2007/12/15(土) 11:34:37 ] templateでエラーの嵐に襲われて思いついたsage I am the bone of my type-parameter. 体は型で出来ている Class is my body, and tyepname is my blood. 血潮はclassで 心はtypename I have created over a thousand compile-errors. 幾たびのコンパイルエラーを超えて不敗 Unaware of export. ただ一度のexportはなく Nor aware of inline. ただ一度のinlineもなし Withstood pain to create many templates. プログラマはここに孤り waiting for compiler's error エラーを前にキーを叩く I have no regrets. This is the only template. ならば我がtemplateに意味は不要ず My whole life was "unlimited type parameters" この体は無限の型で出来ていた いくぞコンパイラ――――エラーメッセージの貯蔵は十分か 852 名前：デフォルトの名無しさん mailto:sage [2008/01/11(金) 09:25:02 ] タイプミスマッチや型候補なしのエラーの嵐は、conceptが導入されれば緩和される。 853 名前：デフォルトの名無しさん [2008/01/21(月) 20:41:39 ] 854 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:38:18 ] C++を難解にしてるのは、めったに使わない機能や、 よく知らずに使うと危険な機能がいっぱいあるから。 それらの機能をなくしてしまえば、いい言語になるのじゃない？ ・・・あっ、それがJavaか・・・ 855 名前：デフォルトの名無しさん mailto:sage [2008/01/21(月) 22:46:22 ] Java厨こんなところろにまで出張乙 856 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:15:54 ] C++を難解にしてるのは、めったに使わない機能や、 よく知らずに使うと危険な機能がいっぱいあるから。 それらの機能をなくしてしまえば、いい言語になるのじゃない？ ・・・あっ、それがC#か・・・ 857 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:18:18 ] C#厨こんなところにまで出張乙ｗ 858 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 00:59:50 ] C++を難解にしてるのは、めったに使わない機能や、 よく知らずに使うと危険な機能がいっぱいあるから。 それらの機能をなくしてしまえば、いい言語になるのじゃない？ ・・・あっ、それがCか・・・ 859 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:04:00 ] C厨こんなところにまで出張乙ｗ 860 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:07:05 ] C++を難解にしてるのは、めったに使わない機能や、 よく知らずに使うと危険な機能がいっぱいあるから。 それらの機能をなくしてしまえば、いい言語になるのじゃない？ ・・・あっ、それがDか・・・ 861 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 01:08:44 ] D厨こんなところにまで出張乙ｗ 862 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 03:43:35 ] 2chを難解にしてるのは、めったに使わない機能や、 よく知らずに使うと危険な機能がいっぱいあるから。 それらの機能をなくしてしまえば、いい言語になるのじゃない？ ・・・あっ、それが1chか・・・ 863 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 03:45:14 ] ニコ厨こんなところにまで出張乙ｗ 864 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 08:57:22 ] もはやなにがなにやら 865 名前：デフォルトの名無しさん mailto:sage [2008/01/22(火) 10:27:51 ] >>860 Dは逆だろｗ 866 名前：デフォルトの名無しさん mailto:sage [2008/01/26(土) 16:49:48 ] >>860 そういう言語を目指してたはずのJAVAやC#は同じ道を歩んでるしな よほどなオプソ開発者でもない限り、大幅仕様変更や削減は難しいからねぇ・・・ 867 名前：毛の生えたブリーフ mailto:sage [2008/01/26(土) 19:48:37 ] オマンコを難解にしてるのは、めったに使わない大陰唇や、 よく知らずに使うと危険なクリトリスがいっぱいあるから。 それらの機能をなくしてしまえば、いいオマンコになるのじゃない？ ・・・あっ、それがアヌスか・・・ 868 名前：デフォルトの名無しさん mailto:sage [2008/01/26(土) 20:02:03 ] アヌス厨こんなところにまで出張乙ｗ 869 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 16:22:19 ] なんなんだ 870 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 16:26:48 ] 純粋に言語としては C++が際立ってJavaやC#より難しいとは もう言えないんじゃないか DにいたってはもうC++より難しいのではｗ 871 名前：デフォルトの名無しさん mailto:sage [2008/01/27(日) 21:39:17 ] JavaやC#は、大規模な標準ライブラリが付属してるから簡単に感じるんだな C++だと、標準ライブラリの提供する機能が少なすぎる 設計は美しいんだがな。STLとか。 872 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 00:17:38 ] C++もBoostが（ゆっくりとだけど） よその言語が持っているようなものを（ようやく）用意し始めている。 スレッドとかシリアライぜーションとかネットワークとか。 XML読み書きも欲しいな。 873 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 09:42:08 ] domやsaxならいっぱいあるだろ 874 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 21:06:18 ] 拡張可能な暗号化・ハッシュ・圧縮インフラが標準で欲しいな 875 名前：デフォルトの名無しさん mailto:sage [2008/01/28(月) 21:10:37 ] C++のめったに使わない機能ってなんだろう virtual継承とかprotected継承ぐらい？ 876 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 01:22:18 ] export asm template template valarray ダイグラフ 877 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 04:09:45 ] asmは結構使ってるなぁ 俺のレベルって低いんだなｗ 878 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 04:23:55 ] asmはCPUをハードウェアレベルでいじりたい時に使うよな 879 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 09:22:13 ] >>874 C++にstream入出力ライブラリは標準でないの？ 880 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 18:09:50 ] VC++なんで__asmです。 881 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 20:26:41 ] template template は使えない期間が長過ぎたんで道具箱に入ってなかった でも明日から使うよ 882 名前：デフォルトの名無しさん mailto:sage [2008/01/29(火) 22:08:56 ] template templateは結構枯れている印象 883 名前：デフォルトの名無しさん [2008/02/18(月) 18:59:10 ] Cとの互換性だのメモリ管理だのは実のところ難しくない。Objective-Cを見よ。 俺から見たC++の難しいところ。 (1)例外安全 例外処理はどんな言語でも難しいが、GCもfinallyも無いから気を使う場面が多くなる。 (2)オーバーロードと関数template 暗黙の型変換が必要な命令型言語の世界に型推論を持ち込んだら複雑になって当たり前。 (3)iostreamの細かいところ ああいうstatefulで多彩なエラー処理が必要なクラスライブラリは、 規格をごりごり書くより参照実装を出す方が実際的だと思う。 884 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 19:11:46 ] >>874 それらの機能は時代とともに変化するし、ターゲットによって最適な手段が異なるので C++のように幅広く利用される物に標準として搭載するのはいかがなものか、と思う。 885 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 21:29:36 ] ハッシュは採用されるだろ 886 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 22:14:35 ] >>874が言ってるのはたぶんMD5とかSHA-1のような暗号的ハッシュ関数のことだと思う。 887 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 22:23:28 ] ライブラリ化するのはポリシークラスや関数オブジェクトをパラメータ化すれば容易いし、 拡張も容易だろうけど、時代の趨勢に標準が追いつかなそうだな 888 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 22:37:02 ] C++みたいに組み込みからサーバまで使われるようなものに、 ハッシュや暗号化のようなコスト、耐久性にいろいろとバラエティの取れるものを標準搭載してもなぁ、って気はする。 889 名前：デフォルトの名無しさん mailto:sage [2008/02/18(月) 22:43:23 ] 個人的には、フリー以上ホスト未満の分類をもう1つか2つ増やしてもいいと思う。 890 名前：デフォルトの名無しさん mailto:sage [2008/02/19(火) 00:07:14 ] CRC、zlibくらいはあってもいいんじゃないかという気は 891 名前：デフォルトの名無しさん mailto:sage [2008/02/19(火) 00:08:53 ] ライブラリを独立した規格にすればいいのにと思う。 892 名前：デフォルトの名無しさん mailto:sage [2008/02/19(火) 00:13:29 ] というかそういう声が多かったからBoostができたんじゃないかと 893 名前：デフォルトの名無しさん mailto:sage [2008/02/19(火) 03:40:18 ] そしてTR1へ 894 名前：デフォルトの名無しさん mailto:sage [2008/03/08(土) 08:44:52 ] 言語の細かいとこにあまり神経使いたくないね。 設計とかテストとか神経を使う重要なとこは他に一杯あるんだから。 重要でないが細かいとこに注意を向けるあまり肝心のことが抜けてるってのは ありすぎるほどある。 思い当たるだろ。 たぶん、個人の注意力の総量は一定なんだろう。 あるとこに注意を向ければ別のとこがおろそかになる。 それだったら重要度の高い部分に優先的に注意を向けたほうがいい。 しかし C++ だとこれが出来にくい。 言語に落とし穴が多いからいやでも注意しなければならない。 895 名前：デフォルトの名無しさん mailto:sage [2008/03/08(土) 21:16:27 ] >>894 抽象的過ぎてわからん 896 名前：デフォルトの名無しさん mailto:sage [2008/03/08(土) 21:34:24 ] >>894 落とし穴というのは適切な比喩でないな。道路脇の崖とでもいうべき。 道に慣れてる人間にとっては危険でもなんでもない。 897 名前：デフォルトの名無しさん [2008/03/09(日) 00:24:54 ] 初心者的な疑問なんだけど、 クラスとかからメンバを呼び出すときに .を使ったり->を使ったりするのって、具体的にどんな理由で２種類あるんでしょうか？ ->を使うところをすべて.で済ますようなことをすると、ソース的にありえないところが出てきたりするのですか？ 898 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 00:43:26 ] class foo {public: void memFunc();}があるとして、foo * bar = new fooしたときに bar->memFunc()する代わりに(*bar).memFunc()することに何の躊躇いもないならば、 どうぞご自由にアロー演算子を使うことをおやめくださいませ。 899 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 00:45:08 ] struct A foo; foo.val1 = 1; strct B * bar; bar->val2 = 2; // 初期化していないポインタへの演算ざけどそこらへんは気にせずに・・・ 900 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 01:41:50 ] >>897 ポインタかそうでないか 901 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 01:59:41 ] そうじゃなくて、なぜ実体／参照は.で、ポインタは->なのか、ポインタにも.でアクセスできる文法にしなかった理由は何なのか、ということじゃないかな。 902 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:13:02 ] それはつまり class Foo = new Foo(); という文法を認めろ、ということか・・・ 903 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:14:40 ] 何書いてんだ俺ｗ酔っ払いすぎだｗｗｗ ｆoo f = new foo();　という文法を認めろ、ということか・・・ に訂正＿|￣|○ 904 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:19:06 ] T1 p；のとき *p がT2&を返すような実装をしてると p.aの意味が不明になるでわかるかな 905 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:23:12 ] >>904 演算子オーバーロードできるC++で破綻するのはわかるんだけど、.演算子と->演算子はCからあるよね。 906 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:29:07 ] Dでは左辺がポインタでもそうでなくても常に . 択一だったはず。 文法上はそれでも成り立つのはわかる。 でもなんでCでは区別するのかという答えは出てこないけどな。 907 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:47:07 ] 演算子をそう定義したから、としか言えないのかな。 ドット演算子はポインタでない変数のメンバを参照するもの、という定義があって、 これをポインタ変数に適用しようとすると、dereference operatorの機能も入るから、 演算子を同一としてはいけない、と。 ドット演算子を「変数のメンバを参照するもの」と定義すれば、ポインタでもそれ以外でも 使えるようになるけど、Cではそれをしなかった。 そう考えるとC++のoperator overloadingって結構変態的な機能なんだね。 908 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 02:57:33 ] そうだなCでだと、p.a.a と p.a の区別をどうするか って言えばわかるかな 909 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 03:08:14 ] あんまり自信ないけど 要は誤って別の型にキャスト->ウヒャ を嫌ったんじゃないかと言う気がする 910 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 03:52:27 ] 当時のコンピュータとコンパイラの性能とあわせて コスト的に違うものだという意識が働いてたんじゃないのかね。 a = aa.bb.cc.dd と a = aa->bb->cc->dd じゃ 生成されるコードが全然違うからね。 と思ったが、配列とポインタの扱いを考えると違うか。 a->bが(*a).bという記法の省略であるというのはどこでも説明されているけど。 911 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 09:06:35 ] つーかメンバのポインタだけ -> なんて記号使っておきながら なんで他のポインタはアスタリスクだらけなんだろうか 912 名前：デフォルトの名無しさん mailto:sage [2008/03/09(日) 22:59:15 ] >>910 古い本には「ポインタを何回たぐる」といった表現が頻繁に出てきて、 間接アドレッシングのコストが強く意識されていた様子が読み取れる。 だから.と->でのコストの違いは大きな要因だったと思うよ。 ましてstructやunionは入れ子にしてaa.bb.cc.ddみたいに アクセスするのが前提っぽい設計だし。 913 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 09:26:47 ] Cの基本は値渡し。 構造体と配列は値渡しができないのでポインタ渡し。 そこで、構造体と配列については簡易にアクセスできる演算子を作った。 とか言ってみる。 914 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 10:48:42 ] ＞構造体と配列は値渡しができないのでポインタ渡し。 ？？？ 915 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 13:09:45 ] >>914 配列は値渡しできないだろ。 K&R時代は構造体も値渡しできなかったよ。 916 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 14:56:14 ] いや、配列はわかってるよ。構造体もできない時代があったのか・・・失礼。 VBでbyvalで渡せなくて「なんだこの糞言語は！」って思ったこともあったなぁ・・・ 917 名前：デフォルトの名無しさん mailto:sage [2008/03/10(月) 19:00:56 ] 正確には「配列の先頭アドレスを値渡し」だな 配列の中身は参照渡しに見えるけどな 918 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 00:07:31 ] むしろ、Cは全てにおいて値を渡す その値は変数の中身だったり（変数や配列を参照する）アドレスだったりする と考えるのが正確ではないか 919 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 09:34:06 ] >>918 その程度のことをもっともらしく語るなw 構造体、配列はその中身を渡したくても渡せなかった。 本当は中身を渡したくても、不本意ながらアドレスを渡すしかなかった。 だから[]や->を作ったと言うことでしょ。 920 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 09:52:05 ] その意味では、「全てにおいて値を渡す」ってのは低レベルの言語では極当たり前の話だよね。 プロセッサにおいて、何がしかの値以外のものを渡すって概念がないんだから。 921 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 12:53:43 ] でもこの基本中の基本が理解できなくて、 ポインタを覚えようとしている初心者は発狂する 解説書が悪いんだが 922 名前：デフォルトの名無しさん mailto:sage [2008/03/11(火) 21:03:44 ] typedef class foo{ ..... }bar; bar *ptr; ptr=new bar(); (*ptr).some_member=1; (*ptr).some_methode(); とかしても、正常にコンパイル出来て走るのに 型宣言の時 ptr -> bar; という書式で宣言できないのは、もしかするとちょっと問題かも知れませんね。型　変数という宣言時の並びを遵守してないという文句は <-も 認めて bar <- ptr; というようにするわけです。 そうすれば、ポインタは２通りの表記法(* ->)が使えるということに なって表記上の柔軟性が増加するわけです。*表現は算術演算の*と まぎわらしい場合があって多用されるとウザい場合が確かにありますね。 923 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:12:58 ] >>922 ->の意味わかってる？ｗ 924 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:32:29 ] 昔、Cﾏｶﾞだったか、operator < とoperator -を定義してop<-methodを実装するよーな 話があったような・・・ 925 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:33:07 ] =>と->があって+>が無いのはおかしい と一瞬思ったがそもそも=>なんて無かった 926 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:37:30 ] op>-.-<qo; 927 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:38:23 ] ・（中黒）やx（ｴｯｸｽ）ってオペラントにはならんよな 内積と外積をですね。あと|A|とか 928 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 00:39:20 ] そもそも中黒はASCIIに無いだろ 929 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 01:39:56 ] C/C++で使われない記号ってある？ キーボードをざっと見渡して$と@はソース上には出てこないかなと思ったけど・・・ 930 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 01:50:14 ] -> =|> ===||> だんだん貫通力が上がっていくぞ！ 931 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 02:00:33 ] >>929 @は使う 932 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 02:02:06 ] $もつかえるよ 933 名前：デフォルトの名無しさん mailto:sage [2008/03/12(水) 06:32:21 ] >>929 「`」はない 934 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:15:53 ] >>894 ポリモーフィズムが実行されるために、オーバーライドする関数にはvirtualをつけるべき オブジェクトスライシングが起こるからスーパークラスの変数にサブクラスの変数を入れないようにすべき 例外を投げる時はポインタではなく値で投げるべき、受ける時はオブジェクトスライシングしないように参照で受けるべき メソッドの実引数の値を変更したくない時で、組み込み型の場合は値渡しで、そうでない場合はconstリファレンスで定義すべき、 メソッドの実引数の値をメソッド内部で変更したい時で、組み込み型の場合はリファレンスで、そうでない場合はアドレス渡しで定義すべき… 意識的にそうしないという選択ができるという利点はあるのかもしれないけど… こういうことに気を使いながら、処理内容の方に注意の力点を置いて実装…自分にはムリだ('A`) 935 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 11:47:53 ] >>934 >メソッドの実引数の値をメソッド内部で変更したい時で、組み込み型の場合はリファレンスで、そうでない場合はアドレス渡しで定義すべき… 逆じゃないのか？ 936 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:16:28 ] >>935 逆でした('A`) 937 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:20:14 ] C++の参照渡しキモ杉 938 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:21:55 ] >>935-936 その区別、意味あんの？ 呼び出し元のオブジェクトいじってほしいときは全部参照渡しでよくね？ 939 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 13:39:59 ] > ポリモーフィズムが実行されるために、オーバーライドする関数にはvirtualをつけるべき C#もそうじゃない。Javaはそうじゃないけど。 > オブジェクトスライシングが起こるからスーパークラスの変数にサブクラスの変数を入れないようにすべき 基底クラスのコピーコンストラクタ・代入演算子はprivateにしろ。 これはこれで意識しないといけないことだけどさ。 >例外を投げる時はポインタではなく値で投げるべき、受ける時はオブジェクトスライシングしないように参照で受けるべき 受けるほうはともかく、投げるほうに意識する必要あるか？ 940 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 14:01:07 ] ポインタで例外を投げるってのは、 throw new Exception(hoge) って事だから 941 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 16:01:24 ] うん。何も考えなかったら、throw Exceptionって書くだろ。 Java/C#のくせでついうっかりってならともかく。 942 名前：934 mailto:sage [2008/03/15(土) 22:02:44 ] 元ネタは詳説C++です。 >>938 まず、コスト的にはリファレンスでもポインタでもそれほど変わらないということがあって、 組み込み型の場合、メソッド内で変更可の場合は引数をポインタとすることで、 変更不可の場合の呼び出し f(a) 変更可の場合の呼び出し f(&a) となり、呼び出している箇所を見ることでf()が引数の内容を変更するかどうかのヒントを得ることができる というのがその理由です。まあ好みの問題かもしれません。 後関係ないけれどNULLを渡す可能性がある場合はリファレンスではなくポインタにしなければならない…ってのも考慮しなきゃいけないですね… >>939 コピーコンストラクタを作るのが面倒で、じゃあポインタ渡しすればいいじゃんと思ったりとか…？ 自分はJava一辺倒なので、C++のプロジェクトに放り込まれたら慣れるまでは落とし穴にはまりまくりそうです。慣れてもどれか１つ忘れてポカしそう… C++でバリバリコード書きまくるというのには憧れるんですが…。 943 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 22:50:44 ] >>942 コピーコンストラクタを設けるかどうかは、どちらかというと設計の問題。 一般的に継承してポリモーフィックに扱うクラスはコピー不可とすることが多い。 あった、ちょうどこういう話。 www.ogis-ri.co.jp/otc/hiroba/technical/CppDesignNote/ Clonableにするかどうかというのが近いといえば近いのかな。 Javaはあまりやったことないけど。 944 名前：デフォルトの名無しさん [2008/04/03(木) 18:43:11 ] 顧客より保身のほうが大事なヤツなんていねーよ 馬鹿じゃねーのwwww 945 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 20:16:55 ] この世に馬鹿がいることがわかってるなら、「いねー」なんて口が裂けても言えないはずだが。 946 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 22:02:23 ] >>945 ヒント：嫌味 947 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 22:06:03 ] 社会保険事務所とかに行くとそんな感じの人が一杯いるよ！ ＞＜

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef