C++は難しすぎ 難易度 ..
669:デフォルトの名無しさん
06/06/02 06:35:13
C++の難しさはbetterCとしても使えてしまうところじゃないか？
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot（？）にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか？の問題もある。
あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
（周りの人間との統合性とかを考えるとやっぱり Better Cぐらいが一番能率がいいのかもしれないし。）
670:デフォルトの名無しさん
06/06/02 14:47:20
>>669
休刊直前くらいのCマガにそれと同じこと書かれてたな。
671:デフォルトの名無しさん
06/06/09 03:28:13
C++がドラゴンボールというのは、なんとか仙人とか何とか王様とか変な権威ありそうな
奴がいろいろ御託を並べるが、実は何か奥が深い物があるわけではない、という点でも
似てるな。
672:デフォルトの名無しさん
06/06/09 16:48:52
MFCで自作簡易レンダリングエンジンって出来ませんか。（IEに依存しない）
何方か方法おしえて＞＞＞
673:デフォルトの名無しさん
06/06/09 17:11:22
>>672
マルチ氏ね
674:デフォルトの名無しさん
06/08/15 17:53:21
Javaは引数の参照渡しができない
とんでもない駄作
675:デフォルトの名無しさん
06/08/15 19:52:10
>>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。
676:デフォルトの名無しさん
06/12/26 18:42:28
C++のマニピュレータはどこもマネしないくらい最強
677:デフォルトの名無しさん
06/12/26 18:57:45
あれ使ったことない
難しいというか・・・鬱陶しいというか・・・
678:デフォルトの名無しさん
06/12/29 02:07:53
アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作？)だから、みんなにそっぽ向かれただけ。printfマンセー！
679:デフォルトの名無しさん
06/12/29 18:56:34
まああれはあれで、使いようによっては有用で便利なんだが
vector<int> vec_int;
・・・中略
cout << vec_int / "," % 3 << endl;
たとえばこれで、vec_intの中身全部を
一行に３要素ずつ（ % 3）、カンマで区切って（ / "," ）
出力なんてことをやったりできる
680:デフォルトの名無しさん
06/12/29 18:58:18
ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。
681:デフォルトの名無しさん
06/12/30 01:44:13
そもそもstd::endlもマニピュレータだということを知らない人がかなり多い
682:デフォルトの名無しさん
06/12/31 12:09:20
ライブラリに優劣があるのは仕方ない
iostreamは行き過ぎた抽象というやつかな
ファイルなんかランダムアクセスでいいんだよバカやろう
的なのが提案されてる
ともかくいまさらbindを取り込むDは不憫
683:デフォルトの名無しさん
06/12/31 12:31:17
streamの名前の通りに素直に考えた設計だと思うけどね。
iostreamの出力をiostreamで読み込む。これは簡単。
問題は既存のファイルや人が読みやすいファイルがstreamとして扱いやすいかということだろうよ。
684:デフォルトの名無しさん
06/12/31 14:45:01
iostreamは真似しちゃいけない設計の見本のような気がする。
685:デフォルトの名無しさん
06/12/31 18:07:40
後のSTLともあまり噛み合ってないからな・・・。
686:デフォルトの名無しさん
07/01/09 12:26:43
>>679
>カンマで区切って（ / "," ）
「<<」、「>>」で感性がマヒしてると、こういう
変態的な演算子を定義しちゃうようになるんでしょうか。
687:デフォルトの名無しさん
07/01/09 22:39:57
templateとBoostで麻痺してるせいか
この程度は、きわめて直感的でわかりやすいと
自分では感じるんだが
まああれだ、素人はだまってろ
688:デフォルトの名無しさん
07/01/09 23:30:20
まあでも他人と共同で書くときには控えようかなと思うよ、俺は。
689:デフォルトの名無しさん
07/01/09 23:49:14
俺も、なんか気づいてみたら趣味で書いてる時と、仕事で書いてる時のコードに
とても同じ人物が書いたとは思えないようなギャップが発生している。
・・・ゴメン、本当は仕事で書いてるコードも基礎部分が極端にトリッキーなコードになってる。
690:デフォルトの名無しさん
07/02/10 18:48:59
C++にclassって必要なの？
structで充分だろ
691:デフォルトの名無しさん
07/02/10 19:24:31
>>690
そう思うなら使わなければよろしいのでは?
692:デフォルトの名無しさん
07/02/28 06:53:06
CとC++じゃ明らかに生産性が違うよ
693:デフォルトの名無しさん
07/02/28 07:00:11
えっ、そうなんですか、つまり 生産性は C >> C++と
694:デフォルトの名無しさん
07/02/28 21:44:20
C++は再利用性が高くてメンテナンスも容易
オブジェクトを組み合わせるだけでほとんど完成する
695:デフォルトの名無しさん
07/03/03 00:25:38
C++は１ヶ月も見てないととたんに忘れるな･･･
696:デフォルトの名無しさん
07/03/03 02:12:03
スクリプト言語からC++に戻ってくると、
通常型とポインタと参照があることに安心する。
697:デフォルトの名無しさん
07/03/03 17:27:52
あるあるｗｗｗｗ
698:デフォルトの名無しさん
07/03/03 23:55:34
>>694
ツリ?＿
699:デフォルトの名無しさん
07/03/04 01:38:17
>>690
十分といえば十分ですね
まったく同じ子とできるわけだから
700:デフォルトの名無しさん
07/03/08 22:08:43
コンテナクラスの継承ﾏﾝﾄﾞｸｾ
701:デフォルトの名無しさん
07/03/09 00:00:58
std::vectorとかか？
あれは継承するような存在ではないから面倒で当然だ。
702:デフォルトの名無しさん
07/03/18 02:46:25
>>684
具体的には?
istreamとostreamがiosを仮想継承して
iostreamがistreamとostreamを多重継承しているところとか?
703:デフォルトの名無しさん
07/03/18 13:03:47
>> と << の気持ち悪いオーバーロードとかもかな。
704:デフォルトの名無しさん
07/03/18 13:52:26
マニピュレータを新しく作るにしても
istream, ostream, iosを修正しなくてもできるの?
705:デフォルトの名無しさん
07/03/18 14:23:27
>>704
できるよ。
やりかたよくわからないけど。
706:デフォルトの名無しさん
07/03/18 15:13:16
わからんのに言うなーー
707:デフォルトの名無しさん
07/03/24 18:12:59
C++の印象：
一貫性より無節操さかな。その無節操なところが難解にさせてるね。
無節操だと思うところは、オブジェクト指向にしても、ジェネリック
プログラミングにしても同じ統一した法則の元で成り立ってないわけで
それが複雑怪奇にさせているという指摘。
オブジェクト指向にジェネリック系の考えを入れてプログラミングを
すればわかるけど、よほど注意深く作っていかないとスパゲティになっ
てしまう。それだけバグ取りが難解になり易い弱点を持ってるね。
バグ取りだけじゃなくて、コーディングに時間がかかるね。効率的な
作成はまず不可能だと考えていいよ。javaでも最近テンプレート的な
動きがあるようだけど、あれは自滅の方向かもしれませんよ。
要するに余計なところばかりに神経を使って作らないといけなくなる
事がC++の問題点だと思うね。慣れたから大丈夫というレベルを超え
ちゃってるんで。
708:デフォルトの名無しさん
07/03/24 18:38:17
>>707
直行してる概念を組み合わせても混乱は無いはずなんだが。
オマエのプログラムがスパゲッティになったのを誰かのせいに
したいだけに見えるぜ。
709:デフォルトの名無しさん
07/03/24 18:47:09
>>708
???
710:デフォルトの名無しさん
07/03/24 19:03:22
インターフェイス実装目的以外での継承禁止
711:デフォルトの名無しさん
07/03/24 19:37:55
707は物事を組み合わせること自体を複雑怪奇になると表現しているように思う。
極論すればいい意味でプログラミングそのものの否定に結びつきそうな感じがする。
712:デフォルトの名無しさん
07/03/24 20:30:09
C++は10年以上昔から存在し、かつ互換性も保ってきたのだから
文法が煩雑になるのは仕方ない。しかしそれだけ昔からあるのに
未だ高級言語の最前線に居り能力を認められているのは驚くべき事だ。
713:デフォルトの名無しさん
07/03/24 21:23:53
むしろテンプレートが導入されたときから始まったと言っても過言ではない。
そのテンプレートが出てきたのもARMが出版された1990年頃。
それ以前から構想していたのだろうし、つい最近出てきたようで随分前からあるもんだな。
714:デフォルトの名無しさん
07/03/24 21:50:35
708は相手にする価値がないと判断したから???としたが。
>>711
組み合わせたら複雑怪奇になるのは当然だが、言いたいのはその組み合わせの
ところがぐちゃぐちゃになってる。
テンプレとオブジェクト指向をまじめに組み合わせて作ってみればわかると思
うけど、かなり先の見通しが出来ない限りスパゲティになるのさ。熟孝がどう
しても必要になってくる。スパゲティにしないように工夫して作るのは結構大
変。この辺がわかってない奴がC++で組むと遅いものしか出来ない。実力差がで
易い言語だともいえるが。
また、必要悪なのかもしれないが仮想関数もスパゲティにしている原因だ。あ
れは極力使わないように工夫する必要がある。
テンプレの発想は凄く良いものだがね。
715:デフォルトの名無しさん
07/03/24 22:02:01
>>714
原因と結果の因果関係が何も説明されてないから、「ふーん」としか思えない。
ダメなプログラマはどんな言語を使ってもスパゲッティを作るし、
優秀なプログラマはどんな言語を使っても良いコードを書く。
それだけのことだろ。
716:デフォルトの名無しさん
07/03/25 08:36:41
C++は自由度の高さと抽象化のレベルのバランスがちょうどいいんだよね。あれだけ抽象的なプログラムが書けながら低レイヤーでの処理がはっきり見えてくる言語は他にないな。抽象化をしながらそれでいてブラックボックスが限りなく少ないんだよ。自分は好き。
オブジェクト指向とテンプレートを組み合わせるとスパゲッティになるという主張は全く意味が分からない。設計が下手なんだな。
717:デフォルトの名無しさん
07/03/25 11:42:45
>>716
下手なんだなじゃなくて、慣れてないとうまくいかないよって話だよ。
慣れていたって、ジェネリックにする為の穴はかなり作ってしまい易い。
そこは熟孝なしに作れないところで生産性を損なうんだよね。その熟
孝の方向が作ろうとするものよりその周辺にばかり気をかける比率が
高いの。これがテンプレのライブラリの難しくする場所でもある。ボ
トムアップ的な思想だけではうまく作れないものなの。トップダウン
的な発想をしつつトップダウンな作り方が求められるからね。
オブジェクトごとに算術オペレータとかも丁寧に作っていかないといけ
なくなったりしますから、どうしても助長なプログラムになってしまう
し、見通しが複雑になり易い。traits技術とか切り抜ける方法はいくら
でもあるけど、実際に作ろうとするものよりその周辺ばかりに注意しな
きゃいけなくなって、制作のテンポも悪いよ。
C++は自由度は高いけど、複雑なルールに基づいているだけに難しくなる。
わからないのは頭だけで考えているからだよ。実際にテンプレートライブ
ラリを設計してみたらいい。いろんな注意点に気がつく事になるよ。
他の言語との比較は荒れるもとなので意図的に控えてるけどね。
718:デフォルトの名無しさん
07/03/25 11:44:41
トップダウン
的な発想をしつつトップダウンな作り方が求められるからね
→
トップダウン
的な発想をしつつボトムアップな作り方が求められるからね
719:デフォルトの名無しさん
07/03/25 12:25:01
代数的なクラスでもない限り演算子オーバーロードは使わないと思うが
720:デフォルトの名無しさん
07/03/25 12:43:04
> 他の言語との比較は荒れるもとなので意図的に控えてるけどね。
一連の書き込みから、どうも何か煽っているように見えてたんだけど、
荒れるのは嫌なのね。いったい何がしたいの？
721:デフォルトの名無しさん
07/03/25 12:47:21
>>717
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまったか
まずその注意点を書くべきだぞ
722:デフォルトの名無しさん
07/03/25 12:47:44
汎用的なコードを書こうと思ったらいろいろ気をつけなきゃいけなくなるのは
あたりまえなのにねぇ。
723:デフォルトの名無しさん
07/03/25 13:01:52
>>719
stringを含めたクラスでクラス同士の足し算利用するようなことは
十分使えるものなんだが。そんなところまで意図して書いている。
かけ算までは利用する事はあまりないと思うがね。
やはり実際に作ってみないとわかりにくいのかもしれないね。実際に
テンプレートクラスを１から作ってご覧。
>>720
何がしたいの？ってこのスレのタイトルに対しての見解を書いてるだけ
だよ。仮に、C++賞賛スレならばこんな事は書かない。辛口なこと？は
十分受け入れられるスレだと判断したからだ。
同じルールの元で、いろんなパラダイムを持ってきたのではなくて、
つぎはぎの仕方が複雑になってるからだと言ってるわけ、その例が、
オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。
C++ではいろんな事は確かに出来るけど、複雑なルールの元で作られて
るために、保守点検も含めていろんな事が難しくなる。それが、C++人
気が廃れてきた原因だろうね。
724:デフォルトの名無しさん
07/03/25 13:20:02
なんていうか、新しく覚えた手法は全部使わないと気がすまない病気なんじゃないだろうか？
ある程度知識欲のあるプログラマなら一度はかかる病だと思ってるけど。
必要なプログラムだけ書いてればいいんだよ。新しい機能を思いついても、
明らかな必要性がない限りやらないほうがいい。 YGANI ってやつ？
725:デフォルトの名無しさん
07/03/25 13:23:42
批判精神に富んだ青年に
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまわせたC++は
魅力的な言語だと言うことだな
726:デフォルトの名無しさん
07/03/25 13:31:10
>>723
> オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。
最初っから言われてるけど、さっぱり因果関係がわからん。
人に伝えるつもりなら「やってみれ」とかで済まさずに説明してくれ。
説明する気が無いなら長文 age ウザイからチラシの裏にでも書いててくれ。
727:デフォルトの名無しさん
07/03/25 16:32:14
例えばBoostとか見てみ。何も複雑なことないでしょ？
言語機能を把握しきれなくて複雑に感じるというのなら納得。しかしオブジェクト指向、ジェネリックプログラミングはむしろ構造を素直に記述するために上手く働いてると思うんだけど。さらにテンプレートは最適化にも貢献してる。
同じことCで書こうとしたら大変だよ。
728:デフォルトの名無しさん
07/03/25 16:41:59
ごめんなさい
boostのソース見てて発狂しました
729:デフォルトの名無しさん
07/03/25 16:57:46
>>723が"具体的な"例を持ってくるまで待とうじゃないか
730:デフォルトの名無しさん
07/03/25 17:01:18
まあ文法がひどいというのは納得。ただ機能面で同等なことしようと思ったらC++と大して変わらない言語になるんじゃない？コンパイラ任せの部分が増えると書くのが楽になっても機能面でのマイナスが多少はでるよね。
コンパイラより賢い人間がいるかぎりC++のような言語はなくならないんじゃないかな。
731:デフォルトの名無しさん
07/03/25 21:38:42
言語仕様でなるべくスパゲッティにならないよう努力してもいいんでない？
C++は悪い意味で好きなように書け過ぎると思うんだ。
Javaの多重継承できないとか
Pythonのインデントみたいな試みは是非はともかく嫌いじゃない
732:デフォルトの名無しさん
07/03/26 00:58:32
C++は凡人のための言語じゃないと思うんだよね.
研究心のある人が使えばいいのさ.
大きな自由度を残しておく事で,そこから新しい可能性を見つける事ができるんだよ.
Boostのライブラリとか見てるとすごく思うけど,C++はいろんな新しい考え方を生み出す実験台としての役割がすごく大きいと思う.
書いている人の好奇心を煽るとてもいい言語だと思うけどな.
実際にアプリケーションを書く言語として適しているかということとはまた別だけれどもね.
733:デフォルトの名無しさん
07/03/26 01:41:20
C++の開発動機に"Better C"がある以上、Cとは可能な限り互換性を
保たねばならず、従ってC時代由来のアナクロニズムは除去できない。
ifブロックを中括弧なしで書けないようには出来ないわけだ。
他の新しい言語と比べると酷い言語のように見えるけど、
実際のところ禿が掲げた理念を大前提として考えれば、
今のC++は可能な範囲で望み得る、かなり良いものだと思う。
そもそもC++は大規模オブジェクト指向言語の元祖であって、
新しいパラダイムを開拓しつつも互換性を重視する立場からは古い仕様を変えられない、
そう考えると今までのC++が何か大きな間違いを犯したとは思えない。
C++のこういう点が気に入らないなら素直にDでも使うべきなんだろうと思うよ。
734:デフォルトの名無しさん
07/03/26 03:09:53
>>733
C++を嫌って自由度を追いかけたら、DかLispに行き着くだろうな。
Dもネイティブコンパイラを持ってるようなLispも速度的には速いですから。
735:デフォルトの名無しさん
07/04/03 21:17:20
>>1
ってよりか、C++で書かれたソフトってやたら重くね？
オブジェクト指向って重いの？
736:デフォルトの名無しさん
07/04/03 21:27:48
何も考えないと重くなる。
でもC++自体は重くならずに済むよう努力したほう。
そうでなければC++が普及することは有り得なかったと禿は言っている。
737:デフォルトの名無しさん
07/04/03 22:23:18
C++が重いんじゃなくって、C++のフレームワークにクソ重いのが多いんでないの？
MFCとかQtとか
738:デフォルトの名無しさん
07/04/03 22:44:21
STLを使うと実行速度が10倍に？！
739:デフォルトの名無しさん
07/04/04 00:20:31
Cで書けば、フリーウェアでソースも公開してて
Win標準装備のコピーより何倍も早いfastcopyは
さらに早くなるのか！？
ソース見る限り俺は作った人に「すごいよ、あんたすごいよ」
って言いたくなるソースで、ま、結局のところ頭の良い人
はC++で何か作ろうとするとき頭の中にクラスの設計図が
自ずと浮かび上がってくるんだろうな。
740:デフォルトの名無しさん
07/04/04 00:38:41
C++でもATLでウインドウ制御すれば瞬発力があるソフトが書けるの。
MFCなどを使うと一呼吸動作が遅くなる。
だから言語の問題じゃない。
741:デフォルトの名無しさん
07/04/04 00:51:26
ちょっとしたデータ変換ツールを作ってみたら、CでもC++でも殆ど同じアセンブラコードになった。
C++の方がテンプレート関数のお蔭でソース自体は短いのだが。
742:デフォルトの名無しさん
07/04/04 08:24:20
>>741
禿もCがC++の最大の敵と言っているくらいだし、
Cと同じように書けばCと同じ機械語になるのは当然。
743:デフォルトの名無しさん
07/04/04 21:48:57
一呼吸とか変なこといってんなよ
744:デフォルトの名無しさん
07/04/05 06:20:47
何が変なのかさっぱり。
MFC擁護のバイトか何かですか？
745:デフォルトの名無しさん
07/04/05 07:56:19
言葉が変なんだよ。きっと。
746:デフォルトの名無しさん
07/04/09 15:42:24
templateを使った時にコンパイラの吐くエラーがカオスにな
747:デフォルトの名無しさん
07/04/11 21:26:52
Cの方がトータルでみて生産性高いと感じる俺は
まだまだC++を使いこなせていない
748:デフォルトの名無しさん
07/04/11 21:41:56
>>747
C++から入った身としては、そういうことがいえるほどCを使いこなせている人が居ることに驚く（強意表現だが）
すくなくとも、普通に使ってる分には、C++ のほうが適当に作ってても修正とか聞くし、
真面目にやるときも設計の目処が立ちやすいし、少ないコードで楽に進められるし、名前問題含め使い勝っていいと思うのだが、
参考までに、どんな所がCの方が生産性が高いのか教えて欲しい。
749:デフォルトの名無しさん
07/04/11 22:15:57
俺の感性に合うっていうのかな。
Cでゴリゴリ書いてると魂磨いてるって感じ。
750:デフォルトの名無しさん
07/04/11 23:02:56
たまにCを使うと、変数宣言がブロックの先頭でしかできないのが苦痛。
地味なところでは、for (int i = 0;とかbool型などがないのも嫌になる。
せめてC99を使いたい。
751:747
07/04/11 23:09:43
誰だ勝手に答えているのはｗ
>>748
自分の場合、某悪評スクリプト言語からCに入ったので
関数主体で構造化できるってだけで感動しているレベル。
グローバル変数メインでサブルーチンで直接値を操作するのが
当たり前だったもんで…
とてもじゃないけどCを使いこなせているとすら言えない
C++の（というかオブジェクト指向の）クラスとかインスタンスという概念は
面白いとは思うけどオブジェクト単位でデータと関数がまとまっているよりは
命名規則（型ではなく用途で）をしっかりつけたグローバルな変数と関数を
一元管理した方が把握しやすいっていうか楽に感じる。
オブジェクトで分けるよりはシーンで分けた方が直感的というか。
趣味プログラマとしてはメソッド使わなきゃ属性にアクセスできないみたいな
データの隠避にも大した利点に感じない。
そんな間違いすることあるのか？って思ってしまう。
まぁスクリプト言語に浸りきった弊害なのと
C++をひとにみせても恥ずかしくないレベルまで習得するのが面倒なだけやけど。
constとかstringとか楽なところだけ使いつつスクリプト時代のようにダラダラと
手続き型で書いている。
Cの方がってよりも手続き型の方がって話だ。すまんす
752:デフォルトの名無しさん
07/04/11 23:15:13
データの隠避は複数人での開発では特に重要
1人だとありがたみを感じないのも無理はないと思う
753:デフォルトの名無しさん
07/04/11 23:37:36
一月前の俺と今の俺は他人
754:デフォルトの名無しさん
07/04/11 23:37:57
データ隠蔽とかはブロックごとにファイル分けて
構造体に突っ込むことでまだなんとかなるけど
テンプレートのアルゴリズムはもうCではやる気が起きなくなるな。
755:デフォルトの名無しさん
07/04/12 08:45:57
>>751
それ、全部C++でもできることじゃん。
要は、「Cの方が高い」じゃなくて、「C++である必要が無い」だな。
756:デフォルトの名無しさん
07/04/12 09:11:09
まずnamespaceから
757:デフォルトの名無しさん
07/04/12 16:58:53
まずC風に軽く組んで、
「ここの機能まとめたら分かりやすくなるかも」見たいな感じで
徐々にOOP「風」に組み直していくやり方でいっぱいおっぱいですよ
758:デフォルトの名無しさん
07/04/12 19:34:38
自分も早く再利用可能なクラスをいっぱい作って
実際のプログラムは部品をドッキングさせるだけで良いみたいな状態になりたい
759:デフォルトの名無しさん
07/04/12 20:42:41
結構気合い入れて「俺ライブラリ」を作るんだけど、
なかなかうまくいかないねえ、こう、なんというか、
「近未来の自分にすんげーフィットする汎用性と機能のバランス」ってやつは。
760:デフォルトの名無しさん
07/04/14 02:42:16
各種文字列クラスとの相互変換テンプレートだらけで
俺ライブラリは統一性が無い。文字コード含めてわけかわらんよ。
比較関数だけでも20種類はある。
761:デフォルトの名無しさん
07/04/29 02:53:25
難しいとは思わないけど
無駄に複雑
馬鹿みたい
762:デフォルトの名無しさん
07/04/29 03:04:04
馬鹿みたいというか
馬鹿が複雑に書いてるんだ
でもビャーンのハゲは髪だと思う
763:デフォルトの名無しさん
07/04/29 03:38:18
禿はインタブーで「わざと複雑にした」っつってる死ね
764:デフォルトの名無しさん
07/04/30 00:06:44
頭の悪い奴には使いこなせない言語だよな、ホント。
でもこの「頭の悪い奴には使いこなせない」の意味を、頭の悪い奴は理解できない。
そして見当違いの方向に怒り出すｗ
765:デフォルトの名無しさん
07/04/30 22:07:18
こないだ仕事でJava使わされたけど
あまりの遅さと自由度の低さに愕然とした
やっぱ自分ひとりで組むのならC++だな
766:デフォルトの名無しさん
07/04/30 22:29:37
Javaのgenericにはしょんぼりした記憶があるな
C++的なものを求めるのが間違っているんだけどさ・・・
767:デフォルトの名無しさん
07/04/30 22:42:48
boostがやばすぎるぐらいに便利だからなぁ・・・
逆にC++より簡単な言語ってないんじゃね？って思えてくる
768:デフォルトの名無しさん
07/05/02 21:35:05
boostって何がそんなに良いの？
導入すっかな
769:デフォルトの名無しさん
07/05/02 22:09:17
std::for_each(r.begin(), r.end(), f);がboost::for_each(r, f);と書けるようになったり、
std::bind1st. bind2ndより見た目わかりやすいbindが書けたり、正規表現ができたり。
770:デフォルトの名無しさん
07/05/03 08:56:18
>>768
少なくとも言語マニアの素養がある椰子には
boost::lambda, boost::function →関数型パラダイム
boost::mpl, boost::preprocessor →メタプログラミング
boost::spirit →構文解析
あたりは垂涎もの。使ってるとJavaとかC#ですら塵に思えてくる
そんなの無くても不自由しねえよって人でも
スマートポインタとかは確実に有用
771:デフォルトの名無しさん
07/05/03 10:23:39
lexical_castやpolymorphic_downcast、numeric_cast、noncopyableあたりも地味に便利
772:768
07/05/03 10:40:46
うむ
ありがとう
何を言ってるのかさっぱりな漏れにはまだ早いことは良くわかった。
ようやっとSTL使い始めたばかり
773:デフォルトの名無しさん
07/05/03 18:47:17
コンパイル遅すぎなんだよ糞が
774:デフォルトの名無しさん
07/05/03 18:54:15
何のための分割コンパイルだ、プリコンパイルヘッダだ
775:デフォルトの名無しさん
07/05/03 23:16:29
速度なんてボチボチ、イラネな世界になってきたから
Rubyとかで良いんでない
776:デフォルトの名無しさん
07/05/08 02:49:46
最近は専門用語が増えすぎ。
あーぎゅめんとでぃぺんでんとねーむるっくあっぷ
かりおすりーりかーりんぐてんぷれーと
えんぷてぃーべーすおぷてぃまいぜーしょん
えたーなるふぉーすぶりざーど
777:デフォルトの名無しさん
07/05/08 03:16:12
クトゥルーさげ
778:デフォルトの名無しさん
07/05/09 13:56:22
いあ いあ はすたあ！
779:デフォルトの名無しさん
07/06/02 07:50:12
全部の機能を使うのはたいへん
780:デフォルトの名無しさん
07/06/19 18:43:40
C++のどこがBetterCなんだ
むしろWorseCだ
781:デフォルトの名無しさん
07/06/19 19:20:44
ローカル変数宣言がブロックの先頭に縛られないこと
特にforなどで変数宣言できること
inline関数
constで定数宣言できること
強力な型安全性の保障（ベターCとして使うならvoid*から他のポインタ型への暗黙の変換まで禁じられるのはきついが）
782:デフォルトの名無しさん
07/06/20 02:40:13
>>781
最後以外は C99 で十分だな。
改めて C99 と比べると、
- restrict
- __VA_ARGS__
- stdint
- 複合型リテラル
- 要素指定の初期化
とか、いろいろ抜けてるので十分 WorseC と呼ぶに値する。
783:デフォルトの名無しさん
07/06/20 06:01:43
>>780
使う人間のレベルによっては、変わるかもしれないな。
784:デフォルトの名無しさん
07/06/20 06:16:32
仕様としてC99が充分だとしても
C99のコンパイラ自体がまだまだ普及してないというのが、一番の大問題。
785:デフォルトの名無しさん
07/06/20 06:27:22
gccにicc、Sunのccもc99に対応していて、これでも普及していないと言い張るとはDozerはこれだから……
つーか、M$儲というべきか?
786:デフォルトの名無しさん
07/06/20 06:36:47
で、「世間一般の人」の中で、そのDozerとやらの割合はどれほどですか？
787:デフォルトの名無しさん
07/06/20 06:39:16
今はもう、理系の大学のプログラミング言語の課程ですら
Windowsを使う方がずっと多いでしょ。
昔の人はSunとかで覚えたんだろうけど。
788:デフォルトの名無しさん
07/06/20 08:36:06
世間一般の人はプログラミングなんてせんなぁ。
789:デフォルトの名無しさん
07/06/20 08:37:31
gccもiccもWindows版があることを知らないのでは?
790:デフォルトの名無しさん
07/06/20 08:42:39
で、そのMingw等で作られたアプリケーションの比率はどのくらい？
もちろん、VBやdelphi等を除いた、C/C++の中での比較で良いけど。
791:デフォルトの名無しさん
07/06/20 08:47:36
>>788
「世間一般の人が使っているOS」をコンパイルするコンパイラや
「そのOS上で動くアプリケーション」をコンパイルするコンパイラは
C99に対応してますか？
一般じゃない人(大学の教養課程は一般の人は通らないのですね)は、
betterCのコードをコンパイルする時に
「多数のアプリケーションが使っているC++コンパイラ」を避けて
「該当する環境ではかなりマイナーなC99コンパイラ」を使うべきというわけですね？
792:デフォルトの名無しさん
07/06/20 09:04:47
俺は>>781の中では、最後の型安全保障が一番重要だと思うのだけど
793:デフォルトの名無しさん
07/06/20 09:42:36
>>785
君が海胆糞erか犬糞erか知らんが、職業マは
そんなもんだけで喰っていけるわけじゃない。
794:デフォルトの名無しさん
07/06/20 10:02:38
媚びへつらいと責任転嫁で喰うのが一般的。
795:デフォルトの名無しさん
07/06/20 19:00:08
C99ってconstが定数になるの？
796:デフォルトの名無しさん
07/06/20 21:30:52
>>793
Windowsで、VisualStudio使ってiccでコンパイルしてますが何か。
797:デフォルトの名無しさん
07/06/21 05:53:46
お前が何をしていようが、誰も何も思うことなんて無いよ。どうでもいい存在だもの。
798:デフォルトの名無しさん
07/06/21 07:59:18
visual studioからgccとかicc使うような環境作れるんですか？
799:デフォルトの名無しさん
07/06/21 08:35:47
gccはともかく、iccはリンカがないからVisualStudioと連携させざるを得ない。
ついでに言えば、誰もやりたがらないだけでgccもVisualStudioから使える。
#つーか、まさかVisualStudioがコンパイラだと思ってないよね。
800:デフォルトの名無しさん
07/06/21 08:45:10
>>797
その割にはずいぶんとご執心で。
801:デフォルトの名無しさん
07/06/21 09:08:12
あれ、Win上のiccってプラグインだよね。
で、もしかして、コンパイラに対するアドオンじゃなくて完全に入れ替えちゃうわけ？
gccが使えるってんなら、gccはその通りだろうけど。
つまり、インテリセンスとかのIDEのメリットって奴が活かせなくなっちゃうわけ？
(だって文法変わるしpragmaやifdefだって変わってくるし)
ていうか、必死にgccを主張して頑張ってる人は
「C99とC++のどちらか」といわれた場合にC99を選択するのかね。
俺は100%間違いなくC++の方を選ぶけど。
OSSなんかで移植性優先でC89ってのはいくらでも見つかるけど
C99のメリットなんてどの程度あるのかね。
いや、頑張ってずっと「betterCとして使うなら、そんなことはC99でも出来るからC++は要らない」
と言ってるくらいだから、C++を避けてC99にする方がメリットがあると思ってるんだろうけどさ。
あ、どんなメリットがあるかなんて、別に書かなくていいよ。
「大多数の人にはC++(のbetterCな点)で充分」なことは判りきってるんだから。
802:デフォルトの名無しさん
07/06/21 09:15:59
いや、俺だって、「C99だったら楽なのに」と思うことはあるよ。
配列の要素数が定数じゃなくていい、なんてのは(std::vectorを使う)俺には必要ないけど
可変長構造体が公式に認められたこととか、
あと、<stdint.h>はあったら随分楽になるとは思う。
(もちろん、多くの非C99環境でも、<inttypes.h>があるから大抵は足りるけど
標準Cでは非公式だから、無い環境のことを考えて#ifdefを使った自前ヘッダを用意しなきゃいけない)
でも、それでもC++のメリットに比べたら、C99のメリットなんて微々たるもの。
その上「C++が使える環境(処理系)」が「C99が使える環境(処理系)」よりずっと多いのだから
「C99でも出来るからC++は要らない」なんて、俺にはとても言えないね。
803:デフォルトの名無しさん
07/06/21 09:16:56
> 必死にgccを主張して頑張ってる人
> 頑張ってずっと「（略）C99でも出来るからC++は要らない」と言ってる
妄想乙
804:デフォルトの名無しさん
07/06/21 09:18:51
>>803
>>782
805:デフォルトの名無しさん
07/06/21 09:21:21
>>784以降の人も、同一人物か同じ意見の人でしょ。
Windowsがどうのと言ってる人。
806:デフォルトの名無しさん
07/06/21 09:23:49
>>804
やっぱり妄想乙。行間に何か見えてしまう人なんだろうか。
807:デフォルトの名無しさん
07/06/21 09:26:40
煽っている人の方は単発でピンポイントで突っ込んでるだけなのに、
一人でそれを真に受けて顔真っ赤にして反論しちゃってるんだろうな。
808:デフォルトの名無しさん
07/06/21 09:30:24
じゃああげようよ
809:デフォルトの名無しさん
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();
という文法を認めろ、ということか・・・
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5386日前に更新/241 KB
担当:undef