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