- 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/
- 652 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 16:19:50 ]
- >>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。
- 653 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 17:56:54 ]
- >>652
一応確認しておきますが、通常のC++における>>649のコードの問題点は、
両方のoperator+がstd名前空間内にないことですよね？
>>649の"ような"コードでは、complexのoperator+もstd::plus::operator()からは呼ばれませんし、
（>>649のコード単体ではcomplexのoperator+は呼ばれますが、
std::basic_string等のoperator+がstd名前空間内に定義されてしまうと呼ばれなくなる）
逆に、両方のoperator+がstd名前空間内にあれば、両方ともplusから呼ばれます。
で、本題に戻りますが、>>643で指摘された問題点と
lazyoverloadには何の関連があるのでしょうか？
今の段階では、
> ADL による hook は loose match で済む，
という部分を勘違いされているように思えます。
あと、
>lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
の全部というのは、名前空間を無視して全部ということでしょうか？
- 654 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 23:59:35 ]
- >>653
>>643の問題を普通のC++で解決するのが大変or不可能であることは認識している。
で、その解決策として部分特殊化でなくオーバーロードでhookを実現
できるようにする(>>646)か、メタプログラミング向けの機能を追加する(>>647)
ことを考えた。
> >lazyoverloadlazyoverloadというのはoperator+を全部見てくれという意味。
> の全部というのは、名前空間を無視して全部ということでしょうか？
lazyoverload宣言をした名前空間の中だけ。解決したいのは次の問題。
namespace nnn {
int fff(int) { return 0; }
template <class T> int good() { return fff(T()); }
template <class T> int bad() { return nnn::fff(T()); }
int fff(char) { return 1; }
}
と定義されているとき、nnn::good<char>()は1を返すけどnnn:bad<char>()は
0を返してしまう。テンプレートを定義した時点で見える関数だけでなく、
インスタンス化した時点で見える関数を全部候補にしてくれ、というのが
lazyoverloadの意味。
- 655 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 00:55:41 ]
- >>654
標準準拠のコンパイラでは、
そのコードでは、nnn::good<char>()も0を返すはずです。
というのは、point of instantiationの文脈で名前解決を行うためには、
unqualifiedな関数呼び出しで（これはOK）、かつADLを介する必要があります。
しかし、charにはassociated namespaceがないため、ADLが行われません。
その結果、point of definitionの文脈で名前解決が行われます。
というのを昔、>>643の中の人（多分）にどこかのスレッドで教えてもらった記憶があります。
ちなみに、>>643に対する一つの解決法として
現在、boost.rangeなどで使われているものがあります。
lazyoverloadによる結果と違うのは、
fundamental type用のフックが定義できるかどうかということでしょうか。
- 656 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 01:10:18 ]
- >>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。
あと、フック関数の定義される場所が
１ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。
- 657 名前：デフォルトの名無しさん mailto:sage [2006/05/26(金) 01:38:15 ]
- >>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#197
> fundamental type用のフックが定義できるかどうかということでしょうか。
ADLが利用できて、operator以外であれば、フックにダミーの引数を入れて
無理矢理ADLをやらせる手がありますね。
namespace hooks {
struct hack;
}
template <T> int really_good() { return fff(hooks::hack(), T()); }
struct hooks {
int fff(hack, int) { return 0; }
int fff(hack, char) { return 1; }
}
struct abc {
struct A {};
int fff(hooks::hack, A) { return 2; }
}
- 658 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 02:44:49 ]
- lazyoverload を持ち出している方の動機は一応理解できているつもりです．
ですが， lazyoverload という提案はあくまで今手に入る
言語の仕様ではないので，これに関する議論は少し避けさせてもらいます．
提案自体に対しても，特に後方互換性の点で色々あら捜しはできるかとも
思いますけれど，それも指摘したところであまり実になるとは思わないので，
もうちょっと一般的なことをつらつら書かせてもらいたいと思います．
hook をある名前空間に集約するべきか，あるいは
あらゆる名前空間（associated namespace）に散在させるべきかは
一般に非常に難しい問題だと思います．
例えば swap という hook を考えたとき（これは現行規格の文言では
ADL 経由で発見される hook であるとは明示されていませんが），
swap という操作は問題ドメインをほとんど限らない非常に一般的な操作・概念で，
1つの名前空間に集約する方向性はそれほど正しいとは思えない．
どちらかというと各ユーザ定義型の associated namespace においておくほうが
おそらく正しい． std 名前空間に集約するという方策もある意味中立性が高いので，
std 名前空間に swap という hook を集約してしまう考え方もあるかとは思いますが，
そうした場合，今度はそれまで考慮されてこなかった新しい hook が登場してきた
場合に，その hook をどこに集約するべきなのかという問題が常についてまわります．
- 659 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 02:45:30 ]
- もちろん ADL による hook でも問題はあります．
先の swap を ADL 経由の hook とする場合，あらゆる名前空間において
"swap" という名前の非メンバ関数の意味を潜在的に予約してしまいます，
これのため，あらゆるドメインで "swap" という名前に対する共通のコンセンサス
（つまり2つのオブジェクトの状態を交換するという操作の名前であるという共通認識）
が取れるという（楽観的な）前提が必要になります．
実際， swap に対する将来的な規格の方向性は現在のところこの立場のようですが，
一方でこの話を金融関連のドメインで仕事をしている方たちにしたところ，
「swap という言葉は金融関連のドメインではまったく違う意味で使われる
（ので swap という名前に共通のコンセンサスが取れるという認識は甘い）」
と異論がきてしまった，という話もあったようです．
swap という非常に一般的と思われる名前1つでこの状況ですから，
おそらくある名前を全ての名前空間で潜在的に予約してしまう ADL hook のあり方は
一般には非常に受け入れがたい．
現在， Boost.Range などで導入されている ADL hook の名前では，
この問題を避けるため，マクロの名前規則を髣髴とさせる
boost_ なんて prefix が付いています．
しかしこれでは ADL による hook の大きな利点であった
「hook の所在の中立性」をかなり殺してしまっています．
実際，この観点から名前を boost_begin じゃなくて range_begin にしたら？
という議論も見受けられます．
- 660 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 02:46:12 ]
- ライブラリ設計を考える上でユーザの使い勝手は非常に重要で，
そして hook をユーザにどう提供させるかはまさにライブラリの
インタフェース設計そのもので，ユーザの使い勝手に直結する部分だと思います．
今ここで議論されている方々は造詣が深く，
hook の提供における問題点を把握され整理されておられるので，
>>646 >>647 >>657 といった手法も自然に受け入れられ，
各々の手法の長短も理解されておられますが，
世間一般の大多数から見れば非常に理解しづらい難解な問題であり，
ライブラリ利用者の立場でこれらの手法を利用して
hook を提供しようとする場合，大多数はいわゆるバッドノウハウ，要するに
「関心のある問題の解決に直結しない，不必要に難しい手法と知識」
としか評価してくれないかと思います．
そしてこれはそのままライブラリ全体の評価に直結すると思います．
こういった，特にライブラリを利用する上でのバッドノウハウは
うまく隠蔽できるならばそれに越したことはないかと思います．
ADL hook はもちろん色々な問題は抱えますが， 利用者の立場から見れば，
他の手法と比較しても，次善策としてはある程度妥協できるレベルに
あるんじゃないでしょうか？
Boost.Serialization では，アーカイブのバージョンを指定する引数に
>>657 で示されているような hack を巧妙に隠蔽することで，
two-phase lookup での問題を解決しつつ， hook のためのオーバーロードを
boost::serialization 名前空間に集約させることに成功していますが
（ライブラリ作者の名前から Ramey trick とか呼ばれることもあります），
あのレベルに到達して初めてライブラリのインタフェースとしては
成功と言えるのではないかと思っています．
もちろん，あの手法は非常に特殊な状況で偶発的に成功した例だと思いますので，
汎用性が全く欠けていて応用が利かないのですが……．
- 661 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 02:46:35 ]
- 個人的にはこれらの問題は C++ の言語規格あるいは
C++ のライブラリ設計を原因とする固有の問題だとは思っておらず，
（C++ の）汎用プログラミングにおいて非常に重要で魅力的な特性である
"non-intrusiveness" を成立させつつ，なおかつ hook をどう提供するか，
を考える上でかなり本質的な問題だと思っています．
将来的な言語機能の追加も視野に入れてよいならば，例えば
コンセプトに基づく特殊化・オーバーロードといった C++0x での
機能追加があるいは問題解決の1つの糸口になるのではないかと
個人的には思っています．
- 662 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 07:30:03 ]
- ドラゴンボールにたとえてもう一回プリーズ
- 663 名前：デフォルトの名無しさん [2006/05/27(土) 10:42:33 ]
- 神様、宇宙人、人造人間、とさらに強い敵を出すために世界観が滅茶苦茶。
技もどんどんインフレになっていき、何が強くて何がよわいのか、序列や使い方
が良くわからん。つまりドラゴンボール状態。
C++ is Dragon Ballというのは、アメリカのカンファレンスで良く聞くジョークでも
ある。
- 664 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 14:27:51 ]
- （拍手）
- 665 名前：デフォルトの名無しさん [2006/05/27(土) 17:59:55 ]
- よく聞くのかよ
- 666 名前：デフォルトの名無しさん mailto:sage [2006/05/27(土) 21:39:59 ]
- 毎日な
- 667 名前：デフォルトの名無しさん [2006/05/28(日) 23:12:30 ]
- 『ゴクウが教えるC++』という書籍では、継承を説明するのに、サイヤ人←スーパーサイヤ人と
いう誰でも思いつきそうな例で説明されているらしい。
- 668 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:18:13 ]
- 例えで説明してもらわなくても、シンプルなソースと実行結果があれば概念なんて直ぐわかっちゃうのに。
例えての説明で一番分かってもらえるのは、既に知っている人なんだけどな。
しかもC++はあまり難しくないと言う罠。
- 669 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 06:35:13 ]
- C++の難しさはbetterCとしても使えてしまうところじゃないか？
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot（？）にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか？の問題もある。
あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
（周りの人間との統合性とかを考えるとやっぱり Better Cぐらいが一番能率がいいのかもしれないし。）
- 670 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 14:47:20 ]
- >>669
休刊直前くらいのCマガにそれと同じこと書かれてたな。
- 671 名前：デフォルトの名無しさん [2006/06/09(金) 03:28:13 ]
- C++がドラゴンボールというのは、なんとか仙人とか何とか王様とか変な権威ありそうな
奴がいろいろ御託を並べるが、実は何か奥が深い物があるわけではない、という点でも
似てるな。
- 672 名前：デフォルトの名無しさん [2006/06/09(金) 16:48:52 ]
- MFCで自作簡易レンダリングエンジンって出来ませんか。（IEに依存しない）
何方か方法おしえて＞＞＞
- 673 名前：デフォルトの名無しさん mailto:sage [2006/06/09(金) 17:11:22 ]
- >>672
マルチ氏ね
- 674 名前：デフォルトの名無しさん mailto:sage [2006/08/15(火) 17:53:21 ]
- Javaは引数の参照渡しができない
とんでもない駄作
- 675 名前：デフォルトの名無しさん mailto:sage [2006/08/15(火) 19:52:10 ]
- >>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。
- 676 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 18:42:28 ]
- C++のマニピュレータはどこもマネしないくらい最強
- 677 名前：デフォルトの名無しさん mailto:sage [2006/12/26(火) 18:57:45 ]
- あれ使ったことない
難しいというか・・・鬱陶しいというか・・・
- 678 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 02:07:53 ]
- アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作？)だから、みんなにそっぽ向かれただけ。printfマンセー！
- 679 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 18:56:34 ]
- まああれはあれで、使いようによっては有用で便利なんだが
vector<int> vec_int;
・・・中略
cout << vec_int / "," % 3 << endl;
たとえばこれで、vec_intの中身全部を
一行に３要素ずつ（ % 3）、カンマで区切って（ / "," ）
出力なんてことをやったりできる
- 680 名前：デフォルトの名無しさん mailto:sage [2006/12/29(金) 18:58:18 ]
- ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。
- 681 名前：デフォルトの名無しさん mailto:sage [2006/12/30(土) 01:44:13 ]
- そもそもstd::endlもマニピュレータだということを知らない人がかなり多い
- 682 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 12:09:20 ]
- ライブラリに優劣があるのは仕方ない
iostreamは行き過ぎた抽象というやつかな
ファイルなんかランダムアクセスでいいんだよバカやろう
的なのが提案されてる
ともかくいまさらbindを取り込むDは不憫
- 683 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 12:31:17 ]
- streamの名前の通りに素直に考えた設計だと思うけどね。
iostreamの出力をiostreamで読み込む。これは簡単。
問題は既存のファイルや人が読みやすいファイルがstreamとして扱いやすいかということだろうよ。
- 684 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 14:45:01 ]
- iostreamは真似しちゃいけない設計の見本のような気がする。
- 685 名前：デフォルトの名無しさん mailto:sage [2006/12/31(日) 18:07:40 ]
- 後のSTLともあまり噛み合ってないからな・・・。
- 686 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 12:26:43 ]
- >>679
>カンマで区切って（ / "," ）
「<<」、「>>」で感性がマヒしてると、こういう
変態的な演算子を定義しちゃうようになるんでしょうか。
- 687 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 22:39:57 ]
- templateとBoostで麻痺してるせいか
この程度は、きわめて直感的でわかりやすいと
自分では感じるんだが
まああれだ、素人はだまってろ
- 688 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 23:30:20 ]
- まあでも他人と共同で書くときには控えようかなと思うよ、俺は。
- 689 名前：デフォルトの名無しさん mailto:sage [2007/01/09(火) 23:49:14 ]
- 俺も、なんか気づいてみたら趣味で書いてる時と、仕事で書いてる時のコードに
とても同じ人物が書いたとは思えないようなギャップが発生している。
・・・ゴメン、本当は仕事で書いてるコードも基礎部分が極端にトリッキーなコードになってる。
- 690 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:48:59 ]
- C++にclassって必要なの？
structで充分だろ
- 691 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:24:31 ]
- >>690
そう思うなら使わなければよろしいのでは?
- 692 名前：デフォルトの名無しさん [2007/02/28(水) 06:53:06 ]
- CとC++じゃ明らかに生産性が違うよ
- 693 名前：デフォルトの名無しさん [2007/02/28(水) 07:00:11 ]
- えっ、そうなんですか、つまり 生産性は C >> C++と
- 694 名前：デフォルトの名無しさん [2007/02/28(水) 21:44:20 ]
- C++は再利用性が高くてメンテナンスも容易
オブジェクトを組み合わせるだけでほとんど完成する
- 695 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 00:25:38 ]
- C++は１ヶ月も見てないととたんに忘れるな･･･
- 696 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 02:12:03 ]
- スクリプト言語からC++に戻ってくると、
通常型とポインタと参照があることに安心する。
- 697 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 17:27:52 ]
- あるあるｗｗｗｗ
- 698 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 23:55:34 ]
- >>694
ツリ?＿
- 699 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 01:38:17 ]
- >>690
十分といえば十分ですね
まったく同じ子とできるわけだから
- 700 名前：デフォルトの名無しさん mailto:sage [2007/03/08(木) 22:08:43 ]
- コンテナクラスの継承ﾏﾝﾄﾞｸｾ
- 701 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 00:00:58 ]
- std::vectorとかか？
あれは継承するような存在ではないから面倒で当然だ。
- 702 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 02:46:25 ]
- >>684
具体的には?
istreamとostreamがiosを仮想継承して
iostreamがistreamとostreamを多重継承しているところとか?
- 703 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:03:47 ]
- >> と << の気持ち悪いオーバーロードとかもかな。
- 704 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:52:26 ]
- マニピュレータを新しく作るにしても
istream, ostream, iosを修正しなくてもできるの?
- 705 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 14:23:27 ]
- >>704
できるよ。
やりかたよくわからないけど。
- 706 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 15:13:16 ]
- わからんのに言うなーー
- 707 名前：デフォルトの名無しさん [2007/03/24(土) 18:12:59 ]
- C++の印象：
一貫性より無節操さかな。その無節操なところが難解にさせてるね。
無節操だと思うところは、オブジェクト指向にしても、ジェネリック
プログラミングにしても同じ統一した法則の元で成り立ってないわけで
それが複雑怪奇にさせているという指摘。
オブジェクト指向にジェネリック系の考えを入れてプログラミングを
すればわかるけど、よほど注意深く作っていかないとスパゲティになっ
てしまう。それだけバグ取りが難解になり易い弱点を持ってるね。
バグ取りだけじゃなくて、コーディングに時間がかかるね。効率的な
作成はまず不可能だと考えていいよ。javaでも最近テンプレート的な
動きがあるようだけど、あれは自滅の方向かもしれませんよ。
要するに余計なところばかりに神経を使って作らないといけなくなる
事がC++の問題点だと思うね。慣れたから大丈夫というレベルを超え
ちゃってるんで。
- 708 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 18:38:17 ]
- >>707
直行してる概念を組み合わせても混乱は無いはずなんだが。
オマエのプログラムがスパゲッティになったのを誰かのせいに
したいだけに見えるぜ。
- 709 名前：デフォルトの名無しさん [2007/03/24(土) 18:47:09 ]
- >>708
???
- 710 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:03:22 ]
- インターフェイス実装目的以外での継承禁止
- 711 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 19:37:55 ]
- 707は物事を組み合わせること自体を複雑怪奇になると表現しているように思う。
極論すればいい意味でプログラミングそのものの否定に結びつきそうな感じがする。
- 712 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 20:30:09 ]
- C++は10年以上昔から存在し、かつ互換性も保ってきたのだから
文法が煩雑になるのは仕方ない。しかしそれだけ昔からあるのに
未だ高級言語の最前線に居り能力を認められているのは驚くべき事だ。
- 713 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 21:23:53 ]
- むしろテンプレートが導入されたときから始まったと言っても過言ではない。
そのテンプレートが出てきたのもARMが出版された1990年頃。
それ以前から構想していたのだろうし、つい最近出てきたようで随分前からあるもんだな。
- 714 名前：デフォルトの名無しさん [2007/03/24(土) 21:50:35 ]
- 708は相手にする価値がないと判断したから???としたが。
>>711
組み合わせたら複雑怪奇になるのは当然だが、言いたいのはその組み合わせの
ところがぐちゃぐちゃになってる。
テンプレとオブジェクト指向をまじめに組み合わせて作ってみればわかると思
うけど、かなり先の見通しが出来ない限りスパゲティになるのさ。熟孝がどう
しても必要になってくる。スパゲティにしないように工夫して作るのは結構大
変。この辺がわかってない奴がC++で組むと遅いものしか出来ない。実力差がで
易い言語だともいえるが。
また、必要悪なのかもしれないが仮想関数もスパゲティにしている原因だ。あ
れは極力使わないように工夫する必要がある。
テンプレの発想は凄く良いものだがね。
- 715 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:02:01 ]
- >>714
原因と結果の因果関係が何も説明されてないから、「ふーん」としか思えない。
ダメなプログラマはどんな言語を使ってもスパゲッティを作るし、
優秀なプログラマはどんな言語を使っても良いコードを書く。
それだけのことだろ。
- 716 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 08:36:41 ]
- C++は自由度の高さと抽象化のレベルのバランスがちょうどいいんだよね。あれだけ抽象的なプログラムが書けながら低レイヤーでの処理がはっきり見えてくる言語は他にないな。抽象化をしながらそれでいてブラックボックスが限りなく少ないんだよ。自分は好き。
オブジェクト指向とテンプレートを組み合わせるとスパゲッティになるという主張は全く意味が分からない。設計が下手なんだな。
- 717 名前：デフォルトの名無しさん [2007/03/25(日) 11:42:45 ]
- >>716
下手なんだなじゃなくて、慣れてないとうまくいかないよって話だよ。
慣れていたって、ジェネリックにする為の穴はかなり作ってしまい易い。
そこは熟孝なしに作れないところで生産性を損なうんだよね。その熟
孝の方向が作ろうとするものよりその周辺にばかり気をかける比率が
高いの。これがテンプレのライブラリの難しくする場所でもある。ボ
トムアップ的な思想だけではうまく作れないものなの。トップダウン
的な発想をしつつトップダウンな作り方が求められるからね。
オブジェクトごとに算術オペレータとかも丁寧に作っていかないといけ
なくなったりしますから、どうしても助長なプログラムになってしまう
し、見通しが複雑になり易い。traits技術とか切り抜ける方法はいくら
でもあるけど、実際に作ろうとするものよりその周辺ばかりに注意しな
きゃいけなくなって、制作のテンポも悪いよ。
C++は自由度は高いけど、複雑なルールに基づいているだけに難しくなる。
わからないのは頭だけで考えているからだよ。実際にテンプレートライブ
ラリを設計してみたらいい。いろんな注意点に気がつく事になるよ。
他の言語との比較は荒れるもとなので意図的に控えてるけどね。
- 718 名前：デフォルトの名無しさん [2007/03/25(日) 11:44:41 ]
- トップダウン
的な発想をしつつトップダウンな作り方が求められるからね
→
トップダウン
的な発想をしつつボトムアップな作り方が求められるからね
- 719 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 12:25:01 ]
- 代数的なクラスでもない限り演算子オーバーロードは使わないと思うが
- 720 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 12:43:04 ]
- > 他の言語との比較は荒れるもとなので意図的に控えてるけどね。
一連の書き込みから、どうも何か煽っているように見えてたんだけど、
荒れるのは嫌なのね。いったい何がしたいの？
- 721 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 12:47:21 ]
- >>717
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまったか
まずその注意点を書くべきだぞ
- 722 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 12:47:44 ]
- 汎用的なコードを書こうと思ったらいろいろ気をつけなきゃいけなくなるのは
あたりまえなのにねぇ。
- 723 名前：デフォルトの名無しさん [2007/03/25(日) 13:01:52 ]
- >>719
stringを含めたクラスでクラス同士の足し算利用するようなことは
十分使えるものなんだが。そんなところまで意図して書いている。
かけ算までは利用する事はあまりないと思うがね。
やはり実際に作ってみないとわかりにくいのかもしれないね。実際に
テンプレートクラスを１から作ってご覧。
>>720
何がしたいの？ってこのスレのタイトルに対しての見解を書いてるだけ
だよ。仮に、C++賞賛スレならばこんな事は書かない。辛口なこと？は
十分受け入れられるスレだと判断したからだ。
同じルールの元で、いろんなパラダイムを持ってきたのではなくて、
つぎはぎの仕方が複雑になってるからだと言ってるわけ、その例が、
オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。
C++ではいろんな事は確かに出来るけど、複雑なルールの元で作られて
るために、保守点検も含めていろんな事が難しくなる。それが、C++人
気が廃れてきた原因だろうね。
- 724 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 13:20:02 ]
- なんていうか、新しく覚えた手法は全部使わないと気がすまない病気なんじゃないだろうか？
ある程度知識欲のあるプログラマなら一度はかかる病だと思ってるけど。
必要なプログラムだけ書いてればいいんだよ。新しい機能を思いついても、
明らかな必要性がない限りやらないほうがいい。 YGANI ってやつ？
- 725 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 13:23:42 ]
- 批判精神に富んだ青年に
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまわせたC++は
魅力的な言語だと言うことだな
- 726 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 13:31:10 ]
- >>723
> オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。
最初っから言われてるけど、さっぱり因果関係がわからん。
人に伝えるつもりなら「やってみれ」とかで済まさずに説明してくれ。
説明する気が無いなら長文 age ウザイからチラシの裏にでも書いててくれ。
- 727 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 16:32:14 ]
- 例えばBoostとか見てみ。何も複雑なことないでしょ？
言語機能を把握しきれなくて複雑に感じるというのなら納得。しかしオブジェクト指向、ジェネリックプログラミングはむしろ構造を素直に記述するために上手く働いてると思うんだけど。さらにテンプレートは最適化にも貢献してる。
同じことCで書こうとしたら大変だよ。
- 728 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 16:41:59 ]
- ごめんなさい
boostのソース見てて発狂しました
- 729 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 16:57:46 ]
- >>723が"具体的な"例を持ってくるまで待とうじゃないか
- 730 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 17:01:18 ]
- まあ文法がひどいというのは納得。ただ機能面で同等なことしようと思ったらC++と大して変わらない言語になるんじゃない？コンパイラ任せの部分が増えると書くのが楽になっても機能面でのマイナスが多少はでるよね。
コンパイラより賢い人間がいるかぎりC++のような言語はなくならないんじゃないかな。
- 731 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 21:38:42 ]
- 言語仕様でなるべくスパゲッティにならないよう努力してもいいんでない？
C++は悪い意味で好きなように書け過ぎると思うんだ。
Javaの多重継承できないとか
Pythonのインデントみたいな試みは是非はともかく嫌いじゃない
- 732 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 00:58:32 ]
- C++は凡人のための言語じゃないと思うんだよね.
研究心のある人が使えばいいのさ.
大きな自由度を残しておく事で,そこから新しい可能性を見つける事ができるんだよ.
Boostのライブラリとか見てるとすごく思うけど,C++はいろんな新しい考え方を生み出す実験台としての役割がすごく大きいと思う.
書いている人の好奇心を煽るとてもいい言語だと思うけどな.
実際にアプリケーションを書く言語として適しているかということとはまた別だけれどもね.
- 733 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 01:41:20 ]
- C++の開発動機に"Better C"がある以上、Cとは可能な限り互換性を
保たねばならず、従ってC時代由来のアナクロニズムは除去できない。
ifブロックを中括弧なしで書けないようには出来ないわけだ。
他の新しい言語と比べると酷い言語のように見えるけど、
実際のところ禿が掲げた理念を大前提として考えれば、
今のC++は可能な範囲で望み得る、かなり良いものだと思う。
そもそもC++は大規模オブジェクト指向言語の元祖であって、
新しいパラダイムを開拓しつつも互換性を重視する立場からは古い仕様を変えられない、
そう考えると今までのC++が何か大きな間違いを犯したとは思えない。
C++のこういう点が気に入らないなら素直にDでも使うべきなんだろうと思うよ。
- 734 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 03:09:53 ]
- >>733
C++を嫌って自由度を追いかけたら、DかLispに行き着くだろうな。
Dもネイティブコンパイラを持ってるようなLispも速度的には速いですから。
- 735 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:17:20 ]
- >>1
ってよりか、C++で書かれたソフトってやたら重くね？
オブジェクト指向って重いの？
- 736 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:27:48 ]
- 何も考えないと重くなる。
でもC++自体は重くならずに済むよう努力したほう。
そうでなければC++が普及することは有り得なかったと禿は言っている。
- 737 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:23:18 ]
- C++が重いんじゃなくって、C++のフレームワークにクソ重いのが多いんでないの？
MFCとかQtとか
- 738 名前：デフォルトの名無しさん [2007/04/03(火) 22:44:21 ]
- STLを使うと実行速度が10倍に？！
- 739 名前：デフォルトの名無しさん [2007/04/04(水) 00:20:31 ]
- Cで書けば、フリーウェアでソースも公開してて
Win標準装備のコピーより何倍も早いfastcopyは
さらに早くなるのか！？
ソース見る限り俺は作った人に「すごいよ、あんたすごいよ」
って言いたくなるソースで、ま、結局のところ頭の良い人
はC++で何か作ろうとするとき頭の中にクラスの設計図が
自ずと浮かび上がってくるんだろうな。
- 740 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:38:41 ]
- C++でもATLでウインドウ制御すれば瞬発力があるソフトが書けるの。
MFCなどを使うと一呼吸動作が遅くなる。
だから言語の問題じゃない。
- 741 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:51:26 ]
- ちょっとしたデータ変換ツールを作ってみたら、CでもC++でも殆ど同じアセンブラコードになった。
C++の方がテンプレート関数のお蔭でソース自体は短いのだが。
- 742 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 08:24:20 ]
- >>741
禿もCがC++の最大の敵と言っているくらいだし、
Cと同じように書けばCと同じ機械語になるのは当然。
- 743 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 21:48:57 ]
- 一呼吸とか変なこといってんなよ
- 744 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 06:20:47 ]
- 何が変なのかさっぱり。
MFC擁護のバイトか何かですか？
- 745 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 07:56:19 ]
- 言葉が変なんだよ。きっと。
- 746 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 15:42:24 ]
- templateを使った時にコンパイラの吐くエラーがカオスにな
- 747 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 21:26:52 ]
- Cの方がトータルでみて生産性高いと感じる俺は
まだまだC++を使いこなせていない
- 748 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 21:41:56 ]
- >>747
C++から入った身としては、そういうことがいえるほどCを使いこなせている人が居ることに驚く（強意表現だが）
すくなくとも、普通に使ってる分には、C++ のほうが適当に作ってても修正とか聞くし、
真面目にやるときも設計の目処が立ちやすいし、少ないコードで楽に進められるし、名前問題含め使い勝っていいと思うのだが、
参考までに、どんな所がCの方が生産性が高いのか教えて欲しい。
- 749 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 22:15:57 ]
- 俺の感性に合うっていうのかな。
Cでゴリゴリ書いてると魂磨いてるって感じ。
- 750 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 23:02:56 ]
- たまにCを使うと、変数宣言がブロックの先頭でしかできないのが苦痛。
地味なところでは、for (int i = 0;とかbool型などがないのも嫌になる。
せめてC99を使いたい。
- 751 名前：747 mailto:sage [2007/04/11(水) 23:09:43 ]
- 誰だ勝手に答えているのはｗ
>>748
自分の場合、某悪評スクリプト言語からCに入ったので
関数主体で構造化できるってだけで感動しているレベル。
グローバル変数メインでサブルーチンで直接値を操作するのが
当たり前だったもんで…
とてもじゃないけどCを使いこなせているとすら言えない
C++の（というかオブジェクト指向の）クラスとかインスタンスという概念は
面白いとは思うけどオブジェクト単位でデータと関数がまとまっているよりは
命名規則（型ではなく用途で）をしっかりつけたグローバルな変数と関数を
一元管理した方が把握しやすいっていうか楽に感じる。
オブジェクトで分けるよりはシーンで分けた方が直感的というか。
趣味プログラマとしてはメソッド使わなきゃ属性にアクセスできないみたいな
データの隠避にも大した利点に感じない。
そんな間違いすることあるのか？って思ってしまう。
まぁスクリプト言語に浸りきった弊害なのと
C++をひとにみせても恥ずかしくないレベルまで習得するのが面倒なだけやけど。
constとかstringとか楽なところだけ使いつつスクリプト時代のようにダラダラと
手続き型で書いている。
Cの方がってよりも手続き型の方がって話だ。すまんす
- 752 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 23:15:13 ]
- データの隠避は複数人での開発では特に重要
1人だとありがたみを感じないのも無理はないと思う
|
 |
