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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 01:13 / Filesize : 241 KB / Number-of Response : 948
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
232 名前：デフォルトの名無しさん mailto:sage [04/06/21 00:21]: >>230
できれば根拠が知りたい。
233 名前：デフォルトの名無しさん mailto:sage [04/06/21 00:55]: >>232
良く>>230の言っている意味がわからんが、非GC環境で「メモリリーク」が
どんどん起こったとして、メインメモリを食いつぶしてスワップ起きまくりに
なるから遅くなる、とかそういう次元の話なのだろうか。
234 名前：デフォルトの名無しさん mailto:sage [04/06/21 01:07]: メモリリークは非GC環境に限った話じゃないんだが。
235 名前：デフォルトの名無しさん mailto:sage [04/06/21 01:25]: >>232-233

www.kmonos.net/alang/d/
より

C/C++ プログラマは明示的なメモリ確保と解放に慣れていて、
ガベージコレクタの効率や利点については懐疑的なようです。
私は、一からガベージコレクションを念頭に置いて書いたプロジェクトと、
既存のプロジェクトを GC を使うように方向転換した経験のどちらも持っていますが：

ガベージコレクトされたプログラムの方が高速です。これは直感に反するかもしれませんが、その理由は：
236 名前：デフォルトの名無しさん mailto:sage [04/06/21 01:25]: ●明示的なメモリ管理の際によく使われる手法は、参照カウントです。
代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、速度低下の原因になっています。
スマートポインタクラスでラップしても、速度的な解決にはなりません。（
またいずれにせよ、循環参照を削除できない参照カウント方式は、一般的な解決策ではありません。）
●オブジェクトによって獲得されたリソースの解放には、デストラクタが使用されます。
多くのクラスでは、このリソースとは割り当てられたメモリのことです。
GCを使えば、ほとんどのデストラクタが空になり、完全に削除してしまえます。
●メモリ管理のためのデストラクタは、オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、メモリを解放するような仕組みが必要となるのです。
もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを設定する必要がなくなり、コードは高速に実行されます。
●メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。
大きなプログラムになるほど、キャッシュに入らない部分が増え、ページングが多く発生し、プログラムが遅くなります。
●GCは、メモリが残り少なくなってきたときのみ実行されます。
メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。
●モダンなGCは、過去の遅いものより遙かに発展しています。世代型のコピーGCには、昔のマーク＆スイープアルゴリズムの非効率さはありません。
●モダンなGCはヒープの詰め直しを行います。これによってプログラムが活発に参照するページの数を減らし、キャッシュヒット率を高め、スワップ回数が減ります。
●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。
237 名前：デフォルトの名無しさん mailto:sage [04/06/21 09:34]: > ●GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、
> という事態に縁がありません。

これはウソだな
238 名前：初期不良 mailto:sage [04/06/21 10:07]: まあ、突っ込みたいのはわかるがメモリリークになる可能性は低くなっていると言う事でいいんじゃねーの？
239 名前：232 mailto:sage [04/06/21 10:57]: >>235
提示してくれたページ、GC周りをさらっと目を通した。ありがとう。
●スマートポインタは使いたいケースに応じて選ぶことができるから、
　参照カウントだけと比べるのはどうかなぁと思う。
●デストラクタが空になるのはスマートポインタでも同様。
●例外に関しては同意。
●メモリが少なくなって来た時にごっそりメモリ解放するんだと
　むしろその一瞬非常に不安定になるのではないか。（これは欠点に書いてあったな）

自分は例外バンバン投げたいのでデストラクタが重くならないなら
それはありがたい。
ただ、Dって面白そうだね。autoを使ってscopedに解放もできちゃうようだし。
きめ細やかな言語だと感じた。GCの話題から外れてゴメン。
240 名前：デフォルトの名無しさん mailto:sage [04/06/21 12:00]: まあ、スタイルにも依るんでしょうけど。
●明示的なメモリ管理の際によく使われる手法は、参照カウント...
shared_ptrってそんなに頻繁にコピーってする？
俺は所有権のはっきりしないリソース（ファイル・ハンドル等）の管理に
使うことが多く、参照カウンタが変化するのってタスク相当の粒度の
オブジェクト間の構成を初期化するときぐらい。

●またいずれにせよ、循環参照...
上記のような使い方をする場合は、保持するオブジェクトと
保持されるオブジェクトの関係が階層的になり、参照がループすることは
無い。むしろGC導入によるdtor呼び出し遅延のほうが俺的には大問題。

●メモリ管理のためのデストラクタは、オブジェクトがスタックに...
俺の場合、Appレベルでは例外って殆ど使わないし。

つうか、GCスレってないのね。
241 名前：デフォルトの名無しさん mailto:sage [04/06/21 18:54]: >>240
「コンパイラ・スクリプトエンジン」相談室が失速気味なので
良かったら使ってやってください。

ttp://pc5.2ch.net/test/read.cgi/tech/1070089173/
242 名前：デフォルトの名無しさん mailto:sage [04/06/21 20:27]: >>239
>●デストラクタが空になるのはスマートポインタでも同様。

同様じゃないよ。C++だと書かなくてよくなるだけで、実際はコンパイラが生成してる。
GCがあると、「完全に」削除できる。
243 名前：デフォルトの名無しさん mailto:sage [04/06/21 20:40]: 脳内コンパイラｷﾀ------
244 名前：デフォルトの名無しさん mailto:sage [04/06/21 20:47]: ？
245 名前：デフォルトの名無しさん mailto:sage [04/06/21 21:33]: >>242
dtorに書いてなくても暗黙的にメンバ変数のdtorが呼ばれるつう
意味ならその通りだけど。
ていうか、236の2番目のはどういうメリットなんだろう。
記述忘れてメモリリークって意味ではauto_ptr/shared_ptrで書けば
ありえないし。まともなC++erならメンバにauto_ptr等を含んだ
オブジェクトを頻繁に（例えばsortの比較関数オブジェクト内で）
生成・破棄するようなコードはかかないだろうし。

サイズが減ってキャッシュが云々ってのもいまいち説得力に欠ける。
246 名前：デフォルトの名無しさん mailto:sage [04/06/21 22:00]: >>242
オブジェクトのデストラクタは空
スマートポインタのデストラクタは空でない
ということがいいたいのだろう

オブジェクト内にスマートポインタをもつなら
結局オブジェクトのデストラクタも空でなくなるが
247 名前：232 mailto:sage [04/06/21 22:06]: >>242
デストラクタについては、
1. ソース上書かなくて良くなる
2. スコープが切れた瞬間に呼び出されるわけではなくなるから例外が効率良くなる
と言っているように見えた。だから1についてスマートポインタと同様と書いたんだが、
文意は違ったのかもな。でも、把握した事実は変わらないと思う。

完全に削除って表現が微妙だな。デストラクタが呼ばれなくなるわけじゃなくて
呼ばれるタイミングがスコープから抜けるタイミングではなくて、GCのタイミングになるよ
という意味だよね。

…C++から離れてる。そろそろやめたほうが良さそうだ。名無しに戻ります。
248 名前：デフォルトの名無しさん mailto:sage [04/06/21 22:50]: >>235
一般論としてGC付のが速いって言うなら
理屈はいいから実際のベンチ出せといいたい。
249 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:15]: >>248
お前もGC無しの方が早いというならベンチ出せコラ

つか、どういうベンチプログラムならうまく計れるんだコレ
250 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:17]: オブジェクトの生成と破棄（スコープアウト）をひたすら繰り返すベンチだな
251 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:20]: 計るんならゴミ回収遅延によるシステム全体の
ディスクキャッシュ効率の低下も考慮しとけって。
252 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:24]: >●GCは、メモリが残り少なくなってきたときのみ実行されます。
>メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。

これを素直に読むと
GC有りのプログラムを多数常駐させると互いにメモリ圧迫しあって
パフォーマンスががた落ちになりそうに聞こえるわけですが
253 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:27]: 言語とは関係ないとはいえ、現実的に
メモリが不足しがちだとOSまで不安定になるしねぇ。
254 名前：デフォルトの名無しさん mailto:sage [04/06/21 23:30]: あとDのコンパイラの最適化ってどの程度やってるの？
もともとコンパイラ屋だから能力的にはできるんだろうけど
言語仕様決めてライブラリガリガリ書いてその上最適化もやるって無理っぽくない？
255 名前：デフォルトの名無しさん mailto:sage [04/06/22 01:47]: ・メモリが不足したらGCが走る
・メモリが不足するとOSが不安定になる
ということは、これに
・論理メモリよりも物理メモリの方が小さい
をプラスすると
・GCが走るときはOSが不安定なとき
・OSが不安定になるまでGCが走らない
ってなことになるんじゃないかしら？
256 名前：デフォルトの名無しさん mailto:sage [04/06/22 01:59]: コンパイラ屋だけど、実際GCの方が総合的には速いと思う、
コンパイラ側が全部管理できればオプティマイザに特別なアプローチが出来るからね。
ただC++には似合わないと思う、最小限の機能強化でGCはライブラリにして今流のtemplateでエレガントに実装すべきだ！
と主張してみたかったりもする。
C/C++は、組み込みから汎用までいかなる環境にも耐えられる言語であって欲しいです。
言語本体は最小限の機能のみをもつ機械語翻訳機がいい。

ところでDはGCを自作で置き換えるとかできるのかな？
日に日に強力になってきているDに興味が沸きつつある今日この頃。
257 名前：デフォルトの名無しさん [04/06/22 05:44]: Cは恥かしすぎ
258 名前：デフォルトの名無しさん mailto:sage [04/06/22 10:13]: >>256
>総合的には速いと思う
GCの最適化で？それともコードの実行時最適化？

もっともC++でもそういう総合的に早くするって考えは
あるよね。例えばvectorにpush_backする時にサイズを
２倍ずつ増やすとか。C++erでもそういうトレードオフを
理解しないでSTLとか使ってる奴っているだろうし。
259 名前：デフォルトの名無しさん [04/06/24 17:21]: vectorが完全に連続したメモリを確保するのに対して、
dequeがブロック単位でしか連続したメモリを確保しない事を知らない香具師が多すぎ
260 名前：デフォルトの名無しさん mailto:sage [04/06/24 17:25]: 突然なんだ？
261 名前：デフォルトの名無しさん mailto:sage [04/06/24 17:29]: で、ベンチはまだか?
262 名前：デフォルトの名無しさん mailto:sage [04/06/25 00:25]: >>259
バッファ用のバイト配列をvectorで確保すると
知らない人間は面食らうよね
263 名前：デフォルトの名無しさん mailto:sage [04/06/25 01:43]: C++の難しさって殆んどtemplateが占めてんじゃねーの？

と思ったら>>144みたいなのも居るのね。。。
264 名前：デフォルトの名無しさん mailto:sage [04/06/25 10:04]: vector v(x);
read(&v[0]);
なんてやるなら、素直にscoped_arrayや、
それが許されないならコピペや自作で対応した方が
見た目にも易しいし。
265 名前：デフォルトの名無しさん mailto:sage [04/06/25 10:27]: >>264
同意しかねる。
その用法はvectorの設計コンセプトに合致するものであり、何の不満も無いよ。
266 名前：デフォルトの名無しさん mailto:sage [04/06/26 12:49]: 同じく同意しかねる。ただ不満はある。
C++の言語が難しくて聖書のようにあげられる代表的な数冊の本を
読破理解しないと使いこなせないような言語になっちゃうのは
見た目に直感的じゃないからと思う。
267 名前：デフォルトの名無しさん mailto:sage [04/06/26 13:02]: でも全体としての言語仕様の大きさはともかく、
すぐ上で挙げられている「テンプレート」や「STL」といった個々の要素に関しては、
習うより慣れろを地で行ってると思うよ。本はリファレンス的に使えばそれで。
268 名前：デフォルトの名無しさん mailto:sage [04/06/26 14:42]: C++の難しさは言語仕様よりも使用方法のノウハウの難しさのような気がする
個々はたいした事はないのに組み合わさったときの威力は大きく、それを利用するためだと思う。
template <typename H,typename T> struct TypeList
{
typedef H head ;
typedef T tail ;
} ;
と書かれれば、これがどんな定義なのかはC++をちょっと知っていれば判るが
これをどう活用するのかとなると急に難しくなる。
分りやすい書籍を作るのに従来通りの言語仕様の本とライブラリの本だけでは補えない部分があるのに
その部分を上手く解説した本はあまり無い気がする。
269 名前：デフォルトの名無しさん mailto:sage [04/06/26 15:16]: >>268
それ、発想が Lisp 的なんよね。
Lisp 知ってる人からすると、そのコードも見ただけで何がしたいかすぐ分かる。
template を使ったメタプログラミングって関数型言語と似てるらしくて、
Lisp 的表現が良く使われる。
270 名前：デフォルトの名無しさん mailto:sage [04/06/26 15:29]: 実際のコードは逐次処理的にかいてTypeList等で
それらのコードを組み合わせる構造を記述して
GenScatterHierarchy等で実際にコードを組み合わせて
実装を生成する。

関数型言語だと構造だけでなく実際に実行されるコードも
関数型っぽく記述しなきゃいけないってのが、慣れてない人間
にとっては厳しい。

そういう意味でC++でのMPっての有難いんだよな。
271 名前：デフォルトの名無しさん mailto:sage [04/06/26 21:29]: 馬鹿は馬鹿なりの使い方すればいいし、
頭いい奴は頭いいなりの使い方すればいい
ってだけの話なんじゃないの？
272 名前：デフォルトの名無しさん mailto:sage [04/06/26 21:40]: >>271
両者が一緒にいるときはどうしたらいいのでしょう。
273 名前：デフォルトの名無しさん mailto:sage [04/06/26 22:12]: 一番はバカにコードを書かせないで頭いいヤツに全部かかせることかな。

そっちの方が早く、優秀なモノが出来るだろう。
274 名前：デフォルトの名無しさん mailto:sage [04/06/26 22:21]: 根幹にあたる部分を、頭いい奴にザッと作らせる。
頭悪い奴には、ただひたすらそれを使うか、応用する部分を作らせる。

プログラミングに限った話じゃないがナ。
275 名前：デフォルトの名無しさん mailto:sage [04/06/27 02:40]: >>272
ベアプログラミングで鍛えるべし。
勉強するきないやつなら、いじめるべし。
276 名前：デフォルトの名無しさん [04/06/29 15:53]: ネタふり
C++のグローバル変数初期化タイミングは難しすぎ。

dynamic initilizationなグローバル変数にいたっては
main前に呼ばれることすら保証されてない。
dynamic initilizationなグローバル変数の初期化の
スレッド安全性とか考えると頭痛くなる。

また、main前の初期化順序もある程度は制御したい。
翻訳単位のモジュール性を向上させる意味でも。

こればっかりはjavaが羨ましいよ...。
277 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:37]: グローバル変数使うなよ
278 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:46]: データメンバ　≒　グローバル変数
279 名前：デフォルトの名無しさん [04/06/29 17:54]: Cをやってきた人はC++が出来ないと嘆く人が多いですよね？
自分はC++から入ったんでCの理解はさほど困らなかったんですが、
教授でもそういう人が居ますよ。駄文失礼しました。
280 名前：デフォルトの名無しさん mailto:sage [04/06/29 17:57]: 出来ないんじゃなくてやる気が無いだけだろ。
CとJavaがあればC++いらないし。
281 名前：デフォルトの名無しさん mailto:sage [04/06/29 19:19]: >>279
多い？そんなに聞かないけど。。
プログラムスタイルの違いに始め戸惑うだけじゃない？
282 名前：デフォルトの名無しさん mailto:sage [04/06/30 00:13]: >>281
現場では意外に多いよ。テンプレートや継承を勉強せずにいきなりソース見るから理解できるわけもないんだけど。
283 名前：デフォルトの名無しさん mailto:sage [04/06/30 04:34]: >>276
そういうのは処理系依存になる事も多いね
#pragma で明示的に指示できる処理系もあるよ
組み込み向けでは、コンパイラメーカーにリクエストだすと機能追加してくれる事もあるし
判り難い標準仕様よりも、そっちに頼っていたりする事が多いです。
284 名前：276 mailto:sage [04/06/30 10:14]: >>283
確かに、処理系依存では有るけど・・・。

言語内でそういうのを保証しようとするとstaticなlocal変数とか
利用する羽目になるけど、スレッド安全性とかコストとかの問題も
あるし。main先頭でいちいちリソース初期化等の処理を書くってのも
モジュール性の観点から考えるといまいちな気がするしなぁ。
285 名前：デフォルトの名無しさん mailto:sage [04/07/02 00:35]: >>279
C++よりもCのほうが難しいだろう。
C++なら簡単にできたことがCだといくつかの要素に還元せねばならず、
しかも全部横並びの関数になるため凝集度が低くなってしまう。
あとからメンテするのが大変。
C++を極めた人間のC++ソースと
Cを極めた人間のCのソースなら
前者のほうが分かりすい。
286 名前：デフォルトの名無しさん mailto:sage [04/07/02 00:39]: >>285
ソースの分かりやすさと言語の難しさは違うと思われ。
287 名前：デフォルトの名無しさん mailto:sage [04/07/02 22:26]: >>282
ヴァカみたいにテンプレートや継承使いまくってるタコソースなんか見る気がしないということでは ?
288 名前：デフォルトの名無しさん mailto:sage [04/07/03 01:27]: >>285
C++で本格的にプログラムを書いた事が一度もありませんね？
289 名前：デフォルトの名無しさん mailto:sage [04/07/03 09:06]: >>288
煽っているつもりだろうが、それはむしろ逆だろ、本格的に書けばC++の方がやさしい
C++の言語仕様は厄介だから、ちょこっと書く分には難しい。
変な煽りはヤメレ
290 名前：デフォルトの名無しさん mailto:sage [04/07/03 23:43]: >>289
別に、C++でも、C風に書くこともできる
291 名前：デフォルトの名無しさん mailto:sage [04/07/04 04:21]: おじさんはextern "C" {}のトリコ
292 名前：デフォルトの名無しさん mailto:sage [04/07/05 02:14]: Ｃ＋＋の仕様準拠率がもっとも高いコンパイラって、
現時点では何になるのでしょうか？
もしかしたらスレ違いかもしれないけど、
これだけ「難しい言語」だと
仕様に準拠するのも大変そうだなぁということで…。
293 名前：デフォルトの名無しさん mailto:sage [04/07/05 14:53]: 準拠度そのものを比較したってのは知らないけど、
Boostのレギュレーションテストは参考になるね。
ttp://boost.sourceforge.net/regression-logs/
294 名前：デフォルトの名無しさん mailto:sage [04/07/05 18:25]: 本格論議はよくわかんないけど、std::map なんかがやっぱり便利だから、
よく初心者の勉強用に用いられる「単語の出現頻度を調べよ」みたいな
プログラムは、C の場合より著しく簡単になるよね・・・
295 名前：デフォルトの名無しさん mailto:sage [04/07/10 14:16]: >>282
それはソース云々より設計がタコ
どんな言語で書いてもタコはタコ
まC++はタコさ加減が露呈しやすい言語ではあるが
VBなんかだとみんなタコだからカモフラージュになるしな
タコじゃないほうが浮いて目立って困る
296 名前：デフォルトの名無しさん mailto:sage [04/07/10 14:20]: 295=タコじゃないつもりのタコ
297 名前：デフォルトの名無しさん mailto:sage [04/07/10 16:32]: いきなり設計云々が出てくる辺りがとっても蛸。
298 名前：295 mailto:sage [04/07/10 18:48]: >>287と>>282を間違えたあたりがタコorz
299 名前：デフォルトの名無しさん [04/08/07 19:46]: 言語仕様がタコなC++の時代は終わった
これからはtemplateを使う必要がないJavaの時代です
300 名前：デフォルトの名無しさん mailto:sage [04/08/07 19:50]: >>299
ｳｾﾞｰあげんなﾎﾞｹ　程度の低い釣りは秋田
301 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:33]: >>293
やっぱりboostなんて使えないってことかな。
302 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:34]: >>301 意味がわかりません。
303 名前：デフォルトの名無しさん mailto:sage [04/08/08 01:45]: >>302
移植性が低いってことでは
304 名前：デフォルトの名無しさん mailto:sage [04/08/08 09:08]: boost が使えなくて泪目で boost なんて必要ないんだぁぁぁっ
て事ですな。
305 名前：デフォルトの名無しさん mailto:sage [04/08/11 03:38]: >>299
>templateを使う必要がないJavaの時代です
1.4でがんばってね。
306 名前：デフォルトの名無しさん mailto:sage [04/08/12 06:24]: 現場だと継承、テンプレート一切使わないってこと多いな。
テンプレートなんてそんな難しいか？
boostはともかく、STLと簡単なテンプレートぐらいなら誰でも理解できるだろ？
テンプレートが難しいってのは、一部の天才が作った
ジェネリックプログラムとかのこと？
307 名前：デフォルトの名無しさん mailto:sage [04/08/12 06:55]: サイズが10倍になるのでプロの現場では使われません。
308 名前：デフォルトの名無しさん mailto:sage [04/08/12 07:00]: テンプレートが難しいんじゃなくて、テンプレートを使って書かれたコードに、
テンプレートパラメータの名前省略されたものが多かったり
traitsとかpolicyに分解されてコードが細切れの散り散りだったり
その上、#ifdef等で切り刻まれていて全体像を把握しづらいコードが多いというだけのこと。
309 名前：デフォルトの名無しさん mailto:sage [04/08/12 07:38]: そりゃぁセンスのない奴が書けばテンプレートに限らずね。

>>307
仮令10倍であっても作業効率が上がるのであればプロだからこそ使いますが。
#サイズ云々する現場なんて寧ろ限られるって。
310 名前：デフォルトの名無しさん mailto:sage [04/08/12 17:09]: DinkumwareのSTLはセンスの無い奴が書いたのか？
311 名前：デフォルトの名無しさん mailto:sage [04/08/13 05:03]: C++の仕様はセンスの無い奴が書いた
312 名前：デフォルトの名無しさん mailto:sage [04/08/14 01:18]: >>310
コンパイル時のリソース消費を少しでも軽減するためらしい。
あとは、真似防止か。
313 名前：デフォルトの名無しさん mailto:sage [04/09/03 12:27]: Loki を理解するよりも、STL のソースを読むほうが難しいと思う。
314 名前：デフォルトの名無しさん mailto:sage [04/09/03 13:54]: 実装によるだろ（ｒｙ
315 名前：デフォルトの名無しさん mailto:sage [04/09/04 23:55]: >>313
じゃあ、M$版の奴。
316 名前：デフォルトの名無しさん [04/09/06 13:52]: C++使えると豪語する奴=本当はCしかできない低脳
pc5.2ch.net/test/read.cgi/prog/1094445966/
317 名前：デフォルトの名無しさん mailto:sage [04/09/06 22:56]: 漏れはC++よりもVBが難しい
318 名前：デフォルトの名無しさん [04/09/08 11:03]: C#やっとけ。嫌ならDやっとけ。嫌なら(ry
319 名前：Ruby!! mailto:Ruby!! [04/09/08 17:09]: Ruby!!!!!!!!!!!!!
320 名前：デフォルトの名無しさん mailto:sage [04/09/08 19:10]: C++って使いどころがない。
for_eachとかいつ使うんだこんなの、forの劣化版でしかない。
321 名前：デフォルトの名無しさん mailto:sage [04/09/08 20:10]: 例の「ほげ言語のパラドックス」の意味がよくわかるねｗ
322 名前：デフォルトの名無しさん [04/09/08 22:51]: >>302
inline
323 名前：デフォルトの名無しさん [04/09/08 23:25]: >>320
お前、あれだろ。車を「こんなの地球温暖化の原因になるだろ」って難癖つけて
乗らないだろ。
324 名前：デフォルトの名無しさん [04/09/08 23:44]: 車と地球温暖化って？
なに言っての、このボンクラ
どこかで聞きかじったのかしらん？ｗ
325 名前：デフォルトの名無しさん [04/09/09 00:47]: 車と地球温暖化の二つの単語から
「聞きかじった」とかいう発想が出てくるのが凄いｗ

「なに言っての」のあたりといい、かなり必死なようで。
理由はわからんが。げらげら
326 名前：デフォルトの名無しさん [04/09/09 01:29]: ↑またまた新手の厨が出現ｗ
327 名前：デフォルトの名無しさん [04/09/09 01:30]: >>325ってきっと、偉そうなこと言っときながら、GUIなPCしか触ったことないんでしょうね。
DOS時代を知らないんだな、こういう香具師。
328 名前：デフォルトの名無しさん [04/09/09 02:02]: 悔しいからって二つも書かなくていいぞ、324ｗ
329 名前：デフォルトの名無しさん mailto:sage [04/09/09 03:01]: C++は使いまくりだろ。俺はCの方がよく使うけど。
一番使うとこがないのはRubyとJava。
330 名前：デフォルトの名無しさん mailto:sage [04/09/09 03:35]: 言うまでも無いけど、仕事によって使用頻度が違ってくるからなあ。
普通は使わない言語の方が多いだろ。
逆に、まんべんなく使用するとなったら、それ部署たらいまわしにさ（ｒｙ
331 名前：デフォルトの名無しさん [04/09/10 22:07:23]: Java言語仕様も包含してC+++ つーのはどう？

えーい、こうなったら、VBやDelphiも許してしまう
てんこもり言語「C+++++」のお出ましだ！

・・・もうマニアしか使えねぇな
332 名前：デフォルトの名無しさん mailto:sage [04/09/10 22:21:24]: class C+++++: public C++, public Java, public VB, public Delphi, protected C#;
333 名前：デフォルトの名無しさん [04/09/10 22:26:06]: 最強言語Ruby!!!!!!!!!!!!!!!
334 名前：デフォルトの名無しさん mailto:sage [04/09/10 22:46:31]: class 最強言語: public C+++++, private Ruby;
335 名前：デフォルトの名無しさん [04/09/11 13:34:55]: >>332-334
　 (ﾟДﾟ );;; ＜ｽｹﾞｪ・・・
336 名前：デフォルトの名無しさん mailto:sage [04/09/11 13:39:36]: private Rubyという言葉に笑った。
言いえて妙
337 名前：デフォルトの名無しさん mailto:sage [04/09/11 14:07:08]: C++って、何でもできるのがいいよね。
ビットフィールドとか共用体をCから引き継いでるから
エンベディッドのきつい環境でも、メモリを節約しつつ
ある程度見やすく書けるし。
メンバ関数ポインタを配列に突っ込んだりやりたい放題。

一人で組むんなら最高の言語だよ。
338 名前：デフォルトの名無しさん mailto:sage [04/09/11 15:32:40]: >>337
>一人で組むんなら
人数が何か関係してるのか？
339 名前：デフォルトの名無しさん mailto:sage [04/09/11 19:22:16]: >>338
多人数で組むなら、あんまりトリッキーなコードは書けないじゃん。
それならJavaでも大差ない。
340 名前：デフォルトの名無しさん [04/09/12 00:43:44]: 俺、最近<boost/preprocessor.hpp>の利用による繰り返し処理を勉強中何だけど
もしかして、これって、perlなどの言語でちょちょいと書いて、出力して、コピペ
したほが可読性の面からもいいんじゃないかと気づいてしまったんだけど
まだまだ理解が足りないというかとなのかな。
341 名前：デフォルトの名無しさん [04/09/12 01:32:06]: C++ってそんなに難しいか？
STLが超便利でCなんてやってらんない体になってしまった
342 名前：デフォルトの名無しさん mailto:sage [04/09/12 02:08:55]: >>341
幸せな時期だね。
343 名前：デフォルトの名無しさん [04/09/12 05:17:05]: 286上のQuick C、MASMの時代からC、C++一筋で趣味、仕事でやってきて
他の言語はいらないとまじめに思ってたんだが・・・最近、C#をCつながりで
やってみるかと覗いてみたら・・・もうC++の時代は終わりかもしれんな。
C++を身につけた人間があえて乗り換える必要はないが、新人にC++を教えたり
薦めたりする気はなくなったよ。これからやる人はC#やった方が良いな。
.NET→WinFXと進んでいこうとするならなおさらだな。
344 名前：デフォルトの名無しさん [04/09/12 05:55:31]: www.square-enix.co.jp/shop/goods/images/series_cre4_06.gif
小さすぎて見えんがな('Д`)

112 名前：名前が無い＠ただの名無しのようだ：04/09/09 21:07 ID:s4msPAUO
www.ffcompendium.com/EspMon/necron9-b.jpg
www.ffcompendium.com/EspMon/necron9-a.jpg
345 名前：デフォルトの名無しさん [04/09/12 17:33:17]: >>343
C#は絶対にC＋＋は超えらんないと思うよ
C#って実質Windowsでしかつかえねーじゃん
WindowsでもDLL内の関数なりクラスを使うとなると
面倒だし・・・
挙げだすと枚挙に暇がない
WindowsではVC++&MFCこれ最強
ま　ち　が　い　な　い！
346 名前：デフォルトの名無しさん mailto:sage [04/09/12 18:51:02]: オトトイ、キ・ヤ・ガ・レ！
347 名前：デフォルトの名無しさん [04/09/12 19:26:19]: Windows + C言語のみでMFCも使わずWin32APIネイティブ。
自分でWinProcからMSGをディスパッチしる！　＜これ最強。
348 名前：デフォルトの名無しさん mailto:sage [04/09/12 20:10:59]: >>345
> C#は絶対にC＋＋は超えらんないと思うよ

それはそうなんだ、言語の汎用性という意味からするとあなたの言ってる事は
非常に正しいんだ。

> C#って実質Windowsでしかつかえねーじゃん

これもまさしくそうなんだ。

でも、仕事って、まぁ俺の場合はそうなんだけど、９割方Win絡みなんだよね。
でもって、次の世代のWindowsが06年に出るかどうかは別として何時か、近い
将来は必ず出るんだよね。で、そのWindowsからはWin32Apiはネイティブじゃなくて
WinFXでエミュレートされるんだよね。となると、これから始める人があえてwin32api
に精通する必要はなくなるんだよなぁ。むしろ、今は.NETのクラスライブラリの使い方
に精通した方が良いと言える。

> WindowsではVC++&MFCこれ最強
> ま　ち　が　い　な　い！

現行ではね。Win32Apiがその存在意義を失うであろう、ここ２～３年の間わって話し
だよな。OSのネイティブAPIがWinFXのクラスライブラリになれば話しはがらっと変わるよ。

まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ただ、間口を広げるという観点からは他のプラットフォームでも使えるC&C++を知っとく
ってのは悪くないとは思うけどね。
349 名前：デフォルトの名無しさん [04/09/12 21:27:02]: じゃあ、その画像処理処理コードをC++で書き直してみたら？
C#がC++を凌げない答えがそこにあるから。
350 名前：デフォルトの名無しさん mailto:sage [04/09/12 21:27:08]: >>348
> まぁ、ハードに近い分野をMSがどうやってクラスライブラリにのっけてくるか、お手並み
> 拝見だけど、.NETの最適化も1.1→2.0βで大幅に進んでるからね。画像処理のコードを
> 1.1と2.0βで同じようにコンパイルしたら5倍ほど速度アップしてた。1.1上で約16秒
> 要してた処理がコンパイルし直すだけで3秒程で終わるようになってたからね。

ま、まじっすかそれ？
351 名前：デフォルトの名無しさん mailto:sage [04/09/12 21:52:58]: >>349
やりましたよ。C++だと.3秒で終わりました。テスト用に作ってる
画像処理用ライブラリなんですけどね。巨大なサイズのビットマップを
読み込んでフィルタ処理するって奴です。
現行だとC++の方が10倍程速いですね。しかしですね、ここが大きな問題
なんですが、C#でもbitmapクラスを使わずにそのままメモリに展開して
ポインタ使ってアクセスすると.4秒程度で終わってしまうんですね。ファイル
読み込みにはもちろん.NETのクラスライブラリを使用してます。
個人的にはC#でunsafeなコードを書くのは邪道だとは思うんですが、やろうと
思えば問題ないって話ですね。dll呼び出しするほど手間でもないですし。
インラインアセンブラ使うような感じですね。となると話しはややこしくなってきます。
C#に対するC++の現行での利点は、
・ポインタを駆使出来る。
・win32apiへのアクセスが容易である。
・ネイティブコードを吐ける。
とまぁ既存のライブラリ資産の問題を抜きにすればこんなところです。後ろの２つは
ここ２～３年で利点でもなんでもなくなってしまう訳です。で、１つ目に関してもボトル
ネックとなるような肝い部分ではC#でも問題なく使用出来る、となればほとんど差は
なくなってしまうんですね。やはり考え込んでしまいますね。ただ、プロジェクトの規模
が非常に大きくなってきた時のGCの挙動というのがどの程度パフォーマンスに影響を
与えるのか現時点では読めません。コードでの工夫のしようはありますが、最終的には
VM任せですから。まぁこのあたりもMSが最適化していくような気はしますが。
一つはっきりしときたいのは私はC++を否定するつもりは毛頭ありません。ただ、スレタイ
にもあるとおり「C++は難しすぎ」と感じる人がいるのだとすれば無理して今から覚える
必要は、Win上での開発を念頭に置いているのなら、ないんじゃないかなと思っただけです。

>>350
ほんとです。ソースはそのままコンパイルやり直しただけでその程度のパフォーマンスの
向上が見られました。βがとれた時はそれなりに期待しても良いのかなという気にはなり
ましたね。
352 名前：デフォルトの名無しさん [04/09/12 22:14:50]: 俺はc#がVBSのような運命を辿るような気がして成らないんだけど・・・
353 名前：デフォルトの名無しさん mailto:sage [04/09/12 23:16:22]: > C#に対するC++の現行での利点は、
> ・ポインタを駆使出来る。
> ・win32apiへのアクセスが容易である。
> ・ネイティブコードを吐ける。

C#はどれもできるぞう。
ところで、最初のはあんまりうれしくないなあ。
354 名前：デフォルトの名無しさん [04/09/12 23:23:24]: Ｒｕｂｙ最強言語
Ｒｕｂｙ！！！！！
Ｒｕｂｙ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞Ｃω
355 名前：デフォルトの名無しさん mailto:sage [04/09/12 23:59:55]: >>353
脊髄反射？

ポインタ使える事は >>351 も知ってるようだぞ？
ポインタは確かにアレなんだけど、本流になるには絶対必要だと思うね・・・残念ながら。

Native 呼び出しはモノによっては結構面倒。単にアクセスの容易さだけなら C++ のが当然上だよ。
確かに普通の Win32 API はそれほど面倒なのに突き当たった事はないけど、
COM だとラッパー作るのが大変なの多いね。TLB とか無い場合は。
もちろん JNI みたいなのよりは全然マシだけど。

それから、C# で直接ネイティブコードは吐けないんじゃない？
インストールしたマシン上で変換はできるけど。
356 名前：デフォルトの名無しさん mailto:sage [04/09/13 00:10:56]: まぁ何にせよ楽なのはC#だわな。
別に両方使えれば問題ないさね。適材適所。
357 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:36:37]: >>355
本流ってよくわからんが、洗練されたC++コードにはポインタは登場しないよ。
ポインタが飛び交うなら、それはC++の顔をしたCだと思う。
358 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:38:54]: っつうか355みたいなのは若い（よね？）ならいいけど
年くってたらヤバいと思いなされ。
359 名前：デフォルトの名無しさん mailto:sage [04/09/13 01:47:40]: >>358
何か言いたいならはっきり言えよ
360 名前：デフォルトの名無しさん [04/09/13 02:06:50]: >>357
それはおまいがC++が書けないからだよ　ｗ
361 名前：デフォルトの名無しさん mailto:sage [04/09/13 02:13:48]: >>357

すまん。自分はポインタつかいまくり。
スタックに積むオブジェクトとヒープに確保する
オブジェクトは明確に区別している。

それでヒープに確保するためのオブジェクトはどうしても
ポインタになる。スマートポインタはつかっているけど
生のポインタのほうが適切だと思う場所もあるので
それで生のポインタをつかっている。
362 名前：デフォルトの名無しさん mailto:sage [04/09/13 09:04:59]: >>361
> 生のポインタのほうが適切だと思う場所もあるので

そういう場所がほとんどなくなるのが、最近のC++のやりかただと思うのよ。

特殊な例を特長なんかにしないほうがいいよ。
363 名前：デフォルトの名無しさん mailto:sage [04/09/13 14:18:22]: >>362
どうやって？
364 名前：361 [04/09/13 16:54:41]: 自分の場合、ヒープに確保するタイプのインスタンスは
以下のような管理の使い分けをしている。
(依存、関連、集約、コンポジションぐらいは理解しているよね)

[依存]

ケース1 :
あるメソッドローカルでつかわれるインスタンスで
メソッドをぬけるとインスタンスが不要になる場合。
auto_ptrかscoped_ptrをつかう。

ケース2 :
あるメソッドの引数として渡されるインスタンス。
渡されたインスタンスはそのメソッドの中でしかつかわれない。
この場合は生ポインタ。理由はインスタンスの寿命にメソッドは
関知しないためスマートポインタにする意味がない。

[単項関連]

ケース1 :
格納するクラスがインスタンスの寿命の管理をしないといけない場合。
この場合はauto_ptrかscoped_ptrかshared_ptr。

ケース2 :
格納するクラスがインスタンスの寿命に関知しない場合。
この場合は生ポインタかweak_ptr。
365 名前：361 [04/09/13 16:55:34]: [集約]
基本的な方針は単項関連と同じ。集約のコンテナにはSTLコンテナ
をつかい、スマートポインタをつかう場合にはshared_ptr
(これじゃないとコンテナに格納できないから)をつかう。

[コンポジション]
問答無用にSTLコンテナ+shared_ptr。

こんな感じ。依存のケース2のような場合はスマートポインタを
つかう意味がないし、別に特別なケースでもなくてよくあるんだけど。
366 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:01:42]: 洗練されたC++の流儀とは、boostを使う事だったようです。
最近使えるようになったんでしょうね、うれしくてたまらないみたいです。
367 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:08:53]: ↑Boost分かってない香具師の僻みｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!
368 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:17:20]: 標準がしょぼいせいでいろんなもんが乱立する事態になってる
369 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:23:25]: なんたらptrとかほにゃららptrとか確かにウザィよね。
ライブラリレベルでやるもんじゃねえよ。
370 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:29:55]: >>367
と言う事にしたいのですね。

自分の場合とか言いながら、長々と何を言うかと期待すれば
boost入門ページの最初の方に書いてある事を書いてみただけ。
ヤレヤレ

そんな事はboostの名前を知ってるような人間は誰でも（活用しているかはともかく）承知している事で、
それでもあえて生ポインタを使っているケースは多々あるのに、それを否定するだけの説得力（代案）が
先の文章には無い。
371 名前：デフォルトの名無しさん mailto:sage [04/09/13 17:37:11]: とりあえず否定だけしてみて自分の意見は無い香具師ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!
372 名前：361 [04/09/13 17:44:29]: だからスマートポインタ最大限に利用したとしても
生ポインタをつかうケースがあるって例をあげてみた
んだけど。

>そんな事はboostの名前を知ってるような人間は誰でも
>（活用しているかはともかく）承知している事で、
>それでもあえて生ポインタを使っているケースは多々あるのに、
>それを否定するだけの説得力（代案）が先の文章には無い。
361の発言みれって。自分も生ポインタつかいまくりだって。
373 名前：デフォルトの名無しさん mailto:sage [04/09/13 18:01:12]: >>372
使いまくったらダメだろｗ
374 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:56:19]: >>364
依存のケース２で生ポインタ使ってるところは参照が適切だと思うが、いかがか？
375 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:58:55]: 話の途中で悪いが、今の「ポインタを使いまくる」の意味は、
自力でnew/deleteしまくるって意味だよな？
376 名前：デフォルトの名無しさん mailto:sage [04/09/14 00:59:47]: >>375 ちがうだろう。
377 名前：デフォルトの名無しさん [04/09/14 00:59:58]: void******** (********a)(void******** (********)(void********));
なんて普通に使ってますが、何か？
378 名前：361 mailto:sage [04/09/14 01:19:12]: >>374
ヒープに確保するオブジェクト限定の話なので、生ポインタです。
個人的にヒープに確保したインスタンスの参照をとるのは
抵抗があるかな。

たしかにスタックに積むオブジェクトや構造体ならむしろ参照の
ほうが望ましいと思います。
379 名前：デフォルトの名無しさん mailto:sage [04/09/14 01:49:54]: >>378
その抵抗には何か根拠がある？
まるで意味の無い区別だと思うが。

ヒープ上の（動的）オブジェクトを引数に取る関数と
スタック上の（自動）オブジェクトを引数に取る関数とで
オーバーロードでもするつもりか？
380 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:44:40]: いつのまにかスレタイに沿った話題になってる
381 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:47:18]: >>375
「生の」な。

生のポインタを渡したり、受け取ったり、コピーしたり、
インクリメントしたり、引き算したり、足し算したりすることかなあ。
そういうCみたいなコードはさすがにメンテするのも疲れる。
382 名前：デフォルトの名無しさん [04/09/14 02:48:46]: それはおまいが`使えない'香具師だからだYo
383 名前：デフォルトの名無しさん mailto:sage [04/09/14 02:50:29]: む、「Cみたいな」は禁句か？
384 名前：デフォルトの名無しさん [04/09/14 04:32:03]: >>382
話についていけないお馬鹿さんが
無視して書き込まなくてもいいのでは? ;-)
385 名前：デフォルトの名無しさん [04/09/14 05:22:30]: 無視して書き込む? ;-)
386 名前：デフォルトの名無しさん mailto:sage [04/09/14 07:03:25]: つーかね、
システムコールがiteratorに移行しない以上、
ポインタ（アドレス渡し）は永遠に不滅です。
387 名前：デフォルトの名無しさん mailto:sage [04/09/14 09:05:47]: システムコールなんてwrapされる最たるもんだろ

主パスの処理にシステムコールが出てきたりするなら、C以前だなそりゃ
388 名前：361 [04/09/14 09:53:58]: >>379

設計の段階でヒープに確保するオブジェクトとスタックに積む
オブジェクトは「明確に区別している」ので、同じクラスの
インスタンスがヒープに確保されたりスタック積んだりとまちまちに
なることはないので、オーバーロードする必要はない。
クラスによってヒープに確保かスタックに積むかが決定している。

ヒープに確保するオブジェクトの例をあげればポリフォーリズムが
必要なクラス、スタックに積むクラスは通貨型やベクトル型、
複素数型、クォーターニオンなど。

C++ではオブジェクトをヒープで確保することを強制できないので
とりあえずコピーコンストラクタや代入演算子をprivate属性に
するぐらいはやっているが、最終的にはドキュメントに書いている。

Compositeパターンのように子ノードの削除の責任が親ノードにある
場合、delete演算子かスマートポインタで破棄するんですが、
これがスタックにつまれていると親ノードの都合で削除できない
ので問題になる。こういうのは仕様できっちりきめるしか
回避方法がないのはC++の欠点だと思っている。

...というか、こういうガイドラインって一般的ではないのかな。
とりあえずつかいわけとしてはC#の値型と参照型に近い
感じなんですが。
389 名前：デフォルトの名無しさん mailto:sage [04/09/14 10:15:27]: >>388
> 設計の段階でヒープに確保するオブジェクトとスタックに積む
> オブジェクトは「明確に区別している」ので、同じクラスの

クラスを使う側のローカルな操作なら自分の決定を前提とできるだろうけど、
クラスや関連関数を提供する側では、どちらに確保されるかと言う前提は持てないだろう。

> ヒープに確保するオブジェクトの例をあげればポリフォーリズムが

"polymorphism" な。

> C++ではオブジェクトをヒープで確保することを強制できないので

コンストラクタを protected にして、ヒープに確保するstaticな
生成関数を用意すればできるよ。

> これがスタックにつまれていると親ノードの都合で削除できない
> ので問題になる。こういうのは仕様できっちりきめるしか
> 回避方法がないのはC++の欠点だと思っている。

他の言語なら仕様でキッチリ決めないで回避できるの？

> ...というか、こういうガイドラインって一般的ではないのかな。
> とりあえずつかいわけとしてはC#の値型と参照型に近い

C#は詳しくないけど、それを表したいなら、
　C#:値型 → C++:メンバを並べたクラス型
　C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
こんな感じの対応付けにならないか？
390 名前：361 [04/09/14 10:40:07]: >"polymorphism" な。
すんまそん。typoです。マジで恥ずかしい。

>コンストラクタを protected にして、ヒープに確保するstaticな
>生成関数を用意すればできるよ。
そういえばそうだった。忘れていました。

C#だと構造体は必ずスタックにつまれる(ボキシングするとヒープに
移るけど)し、クラスはヒープに確保される。まあC#の場合はも
ともとGCがあるからインスタンスの破棄のことは考えなくていいんだけど。
391 名前：361 [04/09/14 11:13:37]: >C#:参照型 → C++:実装へのスマートポインタひとつをメンバに持つクラス型
これって俗にいうHandle-Bodyだよね。これも設計ポリシーによってはアリですね。
昔の(今は知らん)xerces-cもそうだったような覚えがある。
392 名前：デフォルトの名無しさん mailto:sage [04/09/14 14:17:40]: 横槍ですが...

>>388
>Compositeパターンのように子ノードの削除の責任が親ノードに
>ある場合
むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
分離する設計が殆どです。Compositeパターンにより関連付けられた
オブジェクト群を利用するオブジェクトと同じ寿命を持った
オブジェクトを用意し、それに保持させるって感じです。

そういった意味では、ライブラリがクライアントの用意するオブジェクト
の寿命を管理する設計よりも、ライブラリはあくまでもそのオブジェクト間の
関連性だけを利用するようにし、その関連性の利用期間を外部に通知できる
ようなインターフェースを用意します。オブジェクトの寿命が本質的に
あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
393 名前：361 [04/09/14 14:48:48]: >むしろ私の場合は、Compositeパターンによる関連性と寿命管理を
>分離する設計が殆どです。Compositeパターンにより関連付けられた
>オブジェクト群を利用するオブジェクトと同じ寿命を持った
>オブジェクトを用意し、それに保持させるって感じです
イメージとしてはFlyweightのようなオブジェクトプールを
つかうって感じでしょうか?ちがったらすみません。
一応、GoFの本を確認したところ「component を削除するのは誰か」
という段落で「通常は親ノードが子ノードを削除するのが最もよい」
とは書いてありますが、そうでなければいけないとは書いてないですし、
例外のケースもあげられています。

>あいまいな場合のみshared_ptrを使いますが、稀なような気がします。
個人的にもshared_ptrをガーベージコレクションのかわりに
つかうことは殆どないです。thisポインタ問題(shred_ptrの
thisポインタはスマートポインタで管理されていない。
一応回避策はありますが)や循環参照でメモリリークが
発生したりするので意外とつかいにくいです。むしろ
コンテナに入れることができる唯一のスマートポインタ
というつかいかたが多いです。

クライアントが生成したインスタンスをライブラリ側で
寿命を管理する必要があるかどうかは議論の余地がありますね。
394 名前：デフォルトの名無しさん mailto:sage [04/09/14 14:49:56]: とりあえず、俺に責任は無い。
395 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:50:16]: C++でポリモーフィズムを使う時って、ヒープに実態確保して、ポインタ使うしかないの？
396 名前：デフォルトの名無しさん mailto:sage [04/09/14 23:56:41]: スタックに確保して参照を使うのもアリです。
397 名前：デフォルトの名無しさん mailto:sage [04/09/15 01:24:57]: で、361よ。
> 個人的にヒープに確保したインスタンスの参照をとるのは
> 抵抗があるかな。
これは具体的な根拠があるわけじゃない、ってこと？
398 名前：361 [04/09/15 12:58:23]: ヒープに確保したインスタンスを参照にすると削除するときに&演算子で
ポインタに戻してやらないといけないのと、スマートポインタをつかう
ことも多いので、参照をつかっているところとスマートポインタを
つかっているところで表記がまちまちになって好きじゃない。
一貫性のある表記が好きという個人的な好みの問題。でも本当に
わざわざヒープに確保したインスタンスを参照にする人って
いるの?

ポリモーフィズムは別にスタックに確保したオブジェクトでも
できるけど、スタックに確保しちゃうとインスタンスの寿命の
管理の自由度が下がる。それにスタックに確保しちゃうと
Factoryメソッドのようなメソッド内部で生成したインスタンス
をメソッドの外部に提供するときにコピーコンストラクタが
必要になるのでそういうときに困る。例えばオブジェクトが
ビットマップのような巨大なデータをもつ場合、コピーコン
ストラクトのコストは大きいし、コピーコンストラクタを
書くのが難しいオブジェクトもある。なので必要のない
コピーコンストラクタはprivateにして使用禁止にして
つかわないようにしている。巨大なデータを持つオブジェクトは
前にもいった人がいるようにHandle-Bodyなんかでもいい
(実際にHandle-Bodyをつかっていたり、文字列クラスなんかは
CopyOnWriteをつかっている実装も多い)が、自分はHandle-Bodyを
つかうスタイルではない。これもスタイルの問題。
399 名前：デフォルトの名無しさん mailto:sage [04/09/15 13:42:11]: >>398
どこを縦読みすればいいのですか？
400 名前：デフォルトの名無しさん [04/09/15 14:16:46]: ポリフォーリズムをポリホと略すスレはここです
401 名前：デフォルトの名無しさん mailto:sage [04/09/15 17:20:36]: |　　ポリフォーリズムの検索結果のうち日本語のページ約 7 件中 1 - 3 件目 (0.54 秒)

あるからびっくりだ。
402 名前：デフォルトの名無しさん mailto:sage [04/09/15 19:32:31]: 全部同一人物？
403 名前：初期不良 mailto:sage [04/09/15 21:23:16]: >>400
モーフィングとフォーミングを勘違いするなら分かるけど
フォーリングと勘違いするというのは飛んでるなと思う。
3カウント入れちゃうよ
404 名前：361=別名ポリホ mailto:sage [04/09/15 21:35:53]: だからマジtypoだって...。まだいりじるのか...。
本気で恥ずかしいんだからいじめんなよ。
405 名前：361=別名ポリホ mailto:sage [04/09/15 21:36:44]: >>いりじる
いじるの間違いだ。またtypo。もう嫌...。
406 名前：デフォルトの名無しさん mailto:sage [04/09/15 21:38:17]: ていうか、ポリフォーリズムをモリモｰフィズムと間違えるのって恥ずかしすぎ。
407 名前：デフォルトの名無しさん [04/09/15 22:06:55]: イリジウムのことね
408 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:12:54]: はずかしすぎ。
アンテナでかすぎ。
409 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:24:30]: どうtypoったらそうなるのか分からん
410 名前：デフォルトの名無しさん mailto:sage [04/09/15 22:47:57]: typoだけに突っ込んでいる人は、
そうやって話をはぐらかそうとしている
厨房なので無視するべし。
411 名前：374 mailto:sage [04/09/16 00:56:53]: >>394
なんか、どちらかに誤解があるようだな。
>>364の [依存]ケース2 で言っていることは、
たとえば「あるメソッド」foo について、
　foo(T*);
というふうに引数の型として生ポインタを使うということじゃないの？
それに対して、
　foo(T&);
のほうが適切ではないかと言う突っ込みを>>374で入れている。
これは引数の型の話で、確保したインスタンスを
保持するための型は関係ないと思うんだけど、
漏れが>>364を誤読しているの？
412 名前：374 mailto:sage [04/09/16 00:58:09]: レスアンカー間違えた。
>>411 は >>398 宛てね。
413 名前：361=別名ポリホ mailto:sage [04/09/16 08:34:22]: >>414

何度も同じようなことを書いてすまんけど、
1.クラス設計時にヒープかスタックか決めている
2.ヒープに確保するオブジェクトは常に(スマートポインタを含めた)
ポインタとしてつかいたい
3.参照をつかわないのは参照とポインタが混ざって表記の揺れに
なるからという好みの問題
別に参照をつかっちゃまずいっていう決定的な理由はない。
設計ポリシーとしてメソッドの引数は一貫して参照をつかうの
であればそれはそれでいいんじゃないでしょうか?っていうか俺が
文句いうことじゃないけど。

逆にちょっと質問。setterのようなあるインスタンスを引数の値とって
それをインスタンス変数に保持するメソッドで、かつ削除の権限が
そのsetterを持つインスタンスにある場合、これも参照で渡すの?
そうだとするとどこかの段階で参照からポインタに変換しないと
削除できないような気がするんですが。それともこの場合は
特別にポインタで渡すんでしょうか?
414 名前：361=別名ポリホ mailto:sage [04/09/16 08:38:54]: すまんレスの先が411だった。

質問の意図は指摘しているところで参照をつかうと、
setterうんぬんのケースと一貫性を保とうとすると
無理がある場所がでるんじゃないかってことです。
415 名前：374 mailto:sage [04/09/17 09:34:20]: >>413
最初に突っ込みいれた箇所（>>364の[依存]ケース2）では
「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
これらの異なる二つの状況の間で一貫性なんてあるはずがない。

生ポインタ使う場所の例として挙げられた箇所に
参照のほうが適切だと突っ込みいれたのに、
スマートポインタ使う場所を挙げて反論されても困る。
416 名前：デフォルトの名無しさん mailto:sage [04/09/17 12:25:53]: > 削除の権限がそのsetterを持つインスタンスにある場合
どういう状況だかよく分からんが、std::auto_ptrみたいなものを
作ろうとしてるなら、素直にコピーを作成したオブジェクトが責任を持って
オブジェクトを破壊すべきだ。
参照渡しされたものを受け取った側で破壊するのは、分かりづらい。

とりあえずスマートポインタ勉強してから出直せ。
417 名前：デフォルトの名無しさん mailto:sage [04/09/17 12:56:51]: 漏れはリアルタイム画像処理をよくやるんだけど、
画像のピクセルデータにアクセスするときはなんとなく生ポインタ使っちゃうな。

あったり無かったりするものを引数にしたいとき、T* 型の引数にして 0 渡すと
「無し」みたいなこともたまにやるし。C# や Java のライブラリでも null 渡せる
メソッドは結構あるから、実装面ではポインタ型の使いどころはそこそこあるん
じゃねーの？
418 名前：デフォルトの名無しさん mailto:sage [04/09/17 15:26:19]: まあ、あれだ

参照渡しでもポインタ渡しでもコピー渡しでもなんでもいいけど、
参照剥しをするのは控えた方がいいな。

あとでdeleteするオブジェクトはポインタで保持しとけ。
419 名前：ポリホ [04/09/17 17:46:25]: >参照渡しされたものを受け取った側で破壊するのは、分かりづらい。
からポインタつかえっていってんだろ。

>「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
>「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの？
>これらの異なる二つの状況の間で一貫性なんてあるはずがない。
状況が違うから一貫性がなくてもよいという判断なら別にいい。
自分はポインタにすると2つの状況で整合がとれるから好きなだけだ。

メソッドの引数はポインタうんぬんという話はヒープに確保した
インスタンスに限定の話だ。しかもコーディングスタイルの問題
だから人のことはとやかくいうつもりはない。

ヒープに確保したインスタンスの参照剥がしが好きじゃないといったら
根拠を求められるし、好きじゃない理由をいったらなぜか参照剥がしは
わかりずらいっていう謎のつっこみが入るし、わけがわかりません。

いったい自分にどうしてもらいたいんだろう。
420 名前：デフォルトの名無しさん mailto:sage [04/09/17 20:42:41]: >>411
foo を書いていて引数にnull 値のようなものを許したいとき、
foo(T*) にするか、foo(T&) にして T::Null を提供するかっていうと、
漏れはメンドクサイから大抵前者だけど。
421 名前：デフォルトの名無しさん mailto:sage [04/09/17 21:28:32]: ＞ポリホ
もうちっと日本語勉強しろよ
422 名前：デフォルトの名無しさん mailto:sage [04/09/18 11:32:18]: >>419
>いったい自分にどうしてもらいたいんだろう。
いじられ役に徹してくだちい。
423 名前：デフォルトの名無しさん mailto:sage [04/09/23 02:34:10]: とりあえずＣ＋＋ではヒープではなく「フリーストア」って呼ぶんじゃなかったっけ？
まぁ、データメンバを「メンバ変数って呼んじゃダメなの？」くらいの勢いだけど。
424 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:05:22]: int* a,b; と int* a; int* b; って違うんだな・・・
425 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:10:23]: >>424

いや、それは違いすぎだから…。
両方ポインタにするなら

int* a, *b;

じゃないとね。
だけどこういう書き方になるから型の後にアスタを付けるスタイルは好きではない。

int *a, *b;

のほうが美しいじゃん。好みの問題かもしれないけど。
426 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:14:44]: >>424
所詮C++はC言語のころの呪縛から逃れられてないのよ。

>>425
int* a;
int* b;
と2行に分けることを推奨。
427 名前：デフォルトの名無しさん mailto:sage [04/09/24 04:48:24]: >>426
＞所詮C++はC言語のころの呪縛から逃れられてないのよ。

だがそれが(・∀・)ｲｲ!!
というか、仕様変更するとコンパイルエラーが発生するレガシーコードが
混在してしまう可能性があるから仕方ないっしょ。

・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz
428 名前：デフォルトの名無しさん [04/09/24 08:39:01]: int* をtypedefして違う名前を与える
さらにはintを変えられるようにtemplate化
429 名前：デフォルトの名無しさん mailto:sage [04/09/24 09:23:41]: C言語の型とは何か。

typedef int *iptr;
int *は ptr->int
iptrも ptr->int
int *[]はarray->ptr->int
int (*)();はptr->function as int
int *();はfunction as ptr->int
struct { int a,b;} *;はptr->struct{int a;int b;}

構造が同じなら互換性があると言う。

iptr a;
int *b;
a = b; // ok

しかし
struct { int x,y;} a;
struct { int x,y;} b;
b = a; // error '=' : 互換性のない型が含まれています。

これはいったい、どうしたことか。
430 名前：デフォルトの名無しさん mailto:sage [04/09/24 10:25:14]: >>429
b=a;
が
b.x=a.x;
b.y=a.y;
と同義であるとはいえない。
直感的にはそうであるが。
同義であるなら同義であるとoperator=なりで
コンパイラに教えなきゃわからん。
431 名前：デフォルトの名無しさん mailto:sage [04/09/24 10:43:24]: >>429
struct A { int x,y;} a;
struct B { int x,y;} b;

名前を省略しただけの扱いなんだろ。
別々の構造体で、たまたまメンバの並びが同じになっただけで代入ができたら困る。
432 名前：デフォルトの名無しさん mailto:sage [04/09/24 11:45:46]: C++スレでC虫臭い話を続けるな
433 名前：デフォルトの名無しさん mailto:sage [04/09/24 17:58:58]: >>424-425
こんな解決法もある。
typedef int *PINT;
PINT a, b;
434 名前：デフォルトの名無しさん mailto:sage [04/09/24 18:03:42]: それ終わってる。
とっくに。
435 名前：デフォルトの名無しさん mailto:sage [04/10/07 00:13:22]: >>429
基本的に別の型に代入はできない。当たり前だけど。Java だって C# だってそうでしょ。
typedef は単なる別名で、新しい型を作る訳では無いって、仕様で決まってますから。
436 名前：デフォルトの名無しさん mailto:sage [04/10/26 17:24:17]: メンバの並びが同じな別々の構造体を作る必要性はあるのか？
437 名前：デフォルトの名無しさん mailto:sage [04/10/26 18:09:29]: あたりまえ
438 名前：デフォルトの名無しさん mailto:sage [04/10/26 19:18:18]: >>436
「今はたまたま同じメンバだけど、将来的には拡張されるかも知れない」
ってことはありそう泣きガス
439 名前：デフォルトの名無しさん mailto:sage [04/10/26 19:56:30]: >>438
その場合、直接代入できる必然性はないよね。
440 名前：デフォルトの名無しさん mailto:sage [04/10/27 11:48:39]: >>439
ふむ。そりゃそうだ。
441 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:42:08]: ふと思ったんだけど、構造体やクラスの（データ）メンバを
while文のようなループ文でくるくる回しながら順番に取れたら便利かも？
名前とか個数とかデータ型を意識せずにクルクル…。
そういうのってうまいこと出来ないかな？
442 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:46:03]: >>441
意味が判らない
443 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:53:58]: >>441
型の違うデータメンバのいったい何が取得したいのか？ってことだね。
たとえば各メンバの文字列表現が取得したいのなら
そのような関数を用意すればすむ。
444 名前：デフォルトの名無しさん mailto:sage [04/10/30 03:34:49]: うっ、わかりにくかったか…。orz　例えば擬似的なコードを書いてしまうと…。

struct TEST_STRUCT
{
　int mInt;
　long mLong;
　char mChar[255 + 1];
};

void main()
{
　vector<VARIANTのような型> dstArray;
　　　　　^^^^^^^^^^^^^^^^^^^^^
　TEST_STRUCT srcData; //適当に初期化済みの状態とする
　int i = 0;
　while( 1 )
　{
　　dstArray.push_back( srcData.○[ i ] );
　　i++;　　　　　　　　　　　　　　　　^^^^^^
　}
}

こんな感じで、データメンバを「名前ではない方法」でアクセスできれば、
結構便利な使い方ができそうだなぁと思ったのでつ。
「○[ i ]」の部分って必ずデータメンバの名前で指定しなければならないから…。

dstArray.push_back( srcData.mInt );
dstArray.push_back( srcData.mLong );

…のように一つ一つ全部指定しなきゃいけないし、型に「VARIANTのような型」が無い以上、
そういうやり方すら出来ないではないでつか…。
関数にしても結局はすべて名前で指定しなければならないし…。
445 名前：444 mailto:sage [04/10/30 03:37:25]: >>444

しまった、ループの脱出条件を書いてないから無限ループケテ～イだ…。orz
まぁ、その辺は突っ込み入れないでちょ。
446 名前：r mailto:sage [04/10/30 08:20:36]: >>444
offsetof

使った事無いけど。多分。
447 名前：r mailto:sage [04/10/30 08:25:36]: >>444
つーか

TEST_STRUCT srcData[] = ...;

for( int i = 0; i < ...; i++ )
dstArray.push_back( srcData[i] );

じゃなくて？
448 名前：デフォルトの名無しさん mailto:sage [04/10/30 09:57:07]: >>444
実体でなくポインタを維持すればいいなら、
std::vector<void *>dstArray;
dstArray.push_back(reinterpret_cast<void *>(&srcData.mInt));
dstArray.push_back(reinterpret_cast<void *>(&srcData.mLong));
dstArray.push_back(reinterpret_cast<void *>(srcData.mChr));
構造体のメンバの列挙は誰かがやらないといけないからねぇ。
static const unsigned sOffsets[] = {
offsetof(TEST_STRUCT, mInt),
offsetof(TEST_STRUCT, mLong),
offsetof(TEST_STRUCT, mChr),
};
for (unsigned i = 0; i < sizeof(sOffsets) / sizeof(*sOffsets); ++i) {
dstArray.push_back(reinterpret_cast<void *>(reinterpret_cast<char *>(&srcData) + sOffsets[i]));
}
これでもなんとかなるかな。
449 名前：デフォルトの名無しさん mailto:sage [04/10/30 19:41:55]: >>446
「offsetof」なんて初めて聞いた！
…と思ったらひょっとしてC++の言語仕様にはないものですよね？
ぐぐってみたらどうやら「.NET Framework」なのかな？

>>448
ふむふむ、ポインタを駆使すれば結構なことが出来そうですね。
しかしなんていうか難しいというかちょっぴり複雑に…。(^^;

基本的に私もメンバを一つ一つ指定することになんの抵抗も無かったんですが、
最近職場でBorlandC++Builderに慣れた同僚が、

「構造体のメンバって一つ一つ名前でアクセスしないといけないんですかねぇ？
　面倒くさいですねぇ」

…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
（C++Builderの話限定になってしまうのですが）
ＤＢの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。
450 名前：デフォルトの名無しさん mailto:sage [04/10/30 22:20:56]: offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、２番目は無視する人かね
451 名前：448 mailto:sage [04/10/31 01:07:37]: >>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?
452 名前：デフォルトの名無しさん mailto:sage [04/10/31 02:37:42]: うわ～ん、そんなにいじめるなぁ～。ヽ(`Д´)ﾉ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。
453 名前：デフォルトの名無しさん mailto:sage [04/10/31 02:45:31]: しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m
454 名前：r mailto:sage [04/10/31 17:05:43]: クラスのメンバを、別々に、同じベクタに入れる意味がわからん
455 名前：デフォルトの名無しさん [04/11/25 02:44:24]: 最近書き込みがないね。
456 名前：デフォルトの名無しさん mailto:sage [04/11/25 04:01:13]: 重複スレだからな。
457 名前：デフォルトの名無しさん mailto:sage [04/11/26 03:07:57]: C言語とJavaとRuby使って，そこそこ書きました．
次はC++にチャレンジするかと，プログラミング言語C++を買ってきました．
難しいです．何書いてるのかわかりません．
俺の頭が悪いのが原因でしょうが，C++の難しさに挫けそうです
458 名前：デフォルトの名無しさん mailto:sage [04/11/26 08:15:19]: ヽ（冫、）ノｽﾞｺｰｯ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…
459 名前：デフォルトの名無しさん mailto:sage [04/11/26 10:26:54]: >>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか！ESPer でつか？
460 名前：デフォルトの名無しさん mailto:sage [04/11/26 10:52:23]: >>459
Yep
461 名前：デフォルトの名無しさん mailto:sage [04/11/26 14:05:17]: >>457
CからC++に移ったばかりの人
for (int i = 0; i < 10; i++) {
v[i] = 1;
}

C++を使い慣れてきた人
for (std::vector<int>::iterator it = v.begin(); it != v.end(); it++) {
*it = 1;
}

C++が「使える」と言えるレベルの人
std::fill(v.begin(), v.end(), 1);

これでやっと中級に入門です。先は長いです。くじけそうです。
462 名前：デフォルトの名無しさん mailto:sage [04/11/26 14:07:40]: C++のことがある程度わかってくると、++、--は前置にするもんです。
463 名前：デフォルトの名無しさん mailto:sage [04/11/26 16:44:04]: 運置
464 名前：デフォルトの名無しさん [04/11/26 21:17:08]: >>462 どうして？
465 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:20:14]: >>464
前置の方がコピーのコストがかからないから
466 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:27:04]: >>465 どうして？
467 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:32:47]: >>466
More Effective C++の項目6を嫁
468 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:36:34]: >>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。
469 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:23:28]: >>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。
470 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:24:18]: >>469
それはちょっと勘違いだ。
C++ は C より便利だよ。
471 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:24:53]: >>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ
472 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:28:36]: >>471
山田君、座布団一枚持ってっちゃって
473 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:32:14]: >>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。
474 名前：デフォルトの名無しさん mailto:sage [04/11/26 23:07:05]: >>473
組み込み型かクラスかは別に関係ないような？
475 名前：デフォルトの名無しさん mailto:sage [04/11/26 23:35:39]: >>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。
476 名前：457 mailto:sage [04/11/27 02:51:11]: 思ったよりレスが…ありがとうございます．

>>458
最初は俺も楽勝だろーとか思っていたのですが，何故か頭が受け付けません．

>>461
今の俺の書き方だと，モロ最初の書き方ですね…
477 名前：デフォルトの名無しさん mailto:sage [04/11/27 03:07:44]: >>461
C++を究めた人はアセンブリに戻る。
478 名前：デフォルトの名無しさん mailto:sage [04/11/27 03:10:04]: >>477
そういう内容のメガデモ作品があったな
479 名前：デフォルトの名無しさん mailto:sage [04/11/27 06:47:22]: >>461の二番目みたいに、全く抽象化されてもいないのに
無理やりイテレータ使う意義って、全くないように思えるんだが
480 名前：デフォルトの名無しさん mailto:sage [04/11/27 09:02:51]: インポラリ
481 名前：デフォルトの名無しさん mailto:sage [04/11/27 09:22:04]: >>457
> C++の難しさに挫けそうです
「プログラミング言語C++」の難しさに挫けそうなだけだろ。
482 名前：デフォルトの名無しさん mailto:sage [04/11/27 09:34:42]: >>479
そんなことはない。
少なくともコンテナを差し替えられる。
483 名前：デフォルトの名無しさん mailto:sage [04/11/27 23:14:25]: そんなこといったら、最初の書き方ならば
vectorを配列にさしかえれるという利点があるなｗ
484 名前：デフォルトの名無しさん mailto:sage [04/11/27 23:16:08]: >>483
vectorを配列に差し替えても、あまり嬉しくはないだろう。
485 名前：デフォルトの名無しさん mailto:sage [04/11/27 23:37:44]: 速くなるやん
486 名前：デフォルトの名無しさん mailto:sage [04/11/28 04:04:31]: >>485
そういう用途なら、boost::arrayがあるから利点とはならない。
487 名前：デフォルトの名無しさん mailto:sage [04/11/28 04:36:03]: boost::rangeでcontainerとbuilt-in arrayが汎用に扱えるようにもなったしね
488 名前：デフォルトの名無しさん mailto:sage [04/11/28 11:09:50]: 後からコンテナを差し替えやすいってのが利点。
489 名前：デフォルトの名無しさん mailto:sage [04/11/28 17:27:41]: コンテナの差し替えなんかするのか？ホントか？

テンプレート引数で型を受け取るときに、
どのコンテナでもOKなのは、確かに意義があるといえるが

前述の例はそういうわけでは全くないし、
正直、三つある例のどの書き方でも、優劣はないと思うが
490 名前：デフォルトの名無しさん mailto:sage [04/11/28 20:57:16]: 前述の例だけみればたしかにどれでもいいレベルの話だけど、
意識の持ち方のことを言ってるんじゃないの？
できるだけSTLコンテナやSTLアルゴリズムを使おうという。
491 名前：デフォルトの名無しさん mailto:sage [04/11/28 21:39:47]: しっかし、組み込み型(intとかdoubleとか)のコンテナならSTLのアルゴリズムは
教科書通りに使えるんだが、クラスになると途端に使い物にならなくなるのは
どういうこと?
STLの範囲で済ます場合、メンバ関数ならアダプタでなんとかなるが、メンバ変数は
叙述関数・関数オブジェクトを用意しなければならない。
正直、boost::bindやboost::lambdaが無かったらやってられないよ。
でもこれも一長一短で、boost::lambdaは動かないコンパイラもあるし(bcc32)、
boost::bindは遅いし。
492 名前：デフォルトの名無しさん mailto:sage [04/11/28 22:55:18]: > boost::bindは遅いし。
なんで？
493 名前：デフォルトの名無しさん mailto:sage [04/11/28 23:17:06]: >>492
なんでだろう? 俺が聞きたいよ。
アセンブリコード見たけどよく分からん。あまり最適化されてない様子。
lambdaは早いんだけどな。
単純なlambda式なら、イテレータをループで回すより早かったりする。
494 名前：デフォルトの名無しさん mailto:sage [04/11/28 23:47:31]: >>493
テストコード出せる？
495 名前：デフォルトの名無しさん [04/11/28 23:49:47]: boostの一部のライブラリを見てると、素直にC++にクロージャを足した
新しい言語を作って使えよと言いたくなる。
496 名前：デフォルトの名無しさん mailto:sage [04/11/28 23:55:10]: boost使ってる時点で負け組み
497 名前：デフォルトの名無しさん mailto:sage [04/11/28 23:57:22]: >>496
何を使うと勝ち組みになれるの？
boost のめざそうとしているものを使わなくてもいいってこと？
498 名前：デフォルトの名無しさん mailto:sage [04/11/29 03:52:25]: >>495
C++Builder言語
499 名前：デフォルトの名無しさん [04/11/29 08:41:38]: C++が難しいのは、テンプレートのがポリモルフィズムより速いからだと思う。
500 名前：デフォルトの名無しさん [04/11/29 08:55:56]: pc5.2ch.net/tech/kako/1058/10586/1058675178.html
pc5.2ch.net/test/read.cgi/tech/1063323615/
501 名前：デフォルトの名無しさん [04/11/29 09:53:18]: >>495
templateの良し悪しはともかくとして、
言語のコアとしてそういった概念のシンタックスを
持つのではなく、メタプログラミングによって後から
追加できるのっていいなと思うけど。
502 名前：デフォルトの名無しさん [04/11/29 11:15:07]: このスレ見てるとげんなりしてくるなｗ
503 名前：デフォルトの名無しさん mailto:sage [04/11/29 11:19:09]: >>501
同感、クロージャーなどを突っ込むよりtemplate機能をもっと整理して
この種の機能はライブラリとして実装してもらいたい。
クロージャー以外にもデザパタ一式ガベコレ一式程度は自働ジェネレートできるくらいがいい。
言語のコアはあくまでシンプルで高速な物がいい。
504 名前：デフォルトの名無しさん [04/11/29 12:55:33]: VC++で計算した数値を引数で表示したいんですが、printfで表示されません。だからMessageBoxを使って表示したいんですがエラーがでます。どうしたらいいんでしょうか？どなたか分かる人教えてください。
505 名前：デフォルトの名無しさん mailto:sage [04/11/29 13:10:08]: ( ﾟДﾟ)ﾎﾟｶｰﾝ
506 名前：デフォルトの名無しさん [04/11/29 15:55:09]: 505うぜーよ！！
知らないならくるな！！！
消えちまえーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
507 名前：モウモウ mailto:sage [04/11/29 21:13:40]: >>504
とりあえず、現状のソース見せて。
508 名前：デフォルトの名無しさん mailto:sage [04/11/29 21:15:44]: 質問した本人はそのスレ全てを覚えてるとは思えないが…(笑)
509 名前：デフォルトの名無しさん mailto:sage [04/12/04 16:22:48]: 「ファイアーエムブレム」は難しすぎ
game.2ch.net/poke/kako/1020/10203/1020340325.html
Linuxは難しすぎ
pc.2ch.net/linux/kako/1025/10252/1025263879.html
三連複は難しすぎ
cocoa.2ch.net/keiba/kako/1025/10252/1025257025.html
メモ帳は難しすぎ
pc5.2ch.net/test/read.cgi/win/1101205340/
510 名前：デフォルトの名無しさん mailto:sage [04/12/13 13:46:51]: C++はSTLと継承を使いこなし始めた辺りが
生産性・理解向上の分水嶺だった記憶がある。
511 名前：釣られたか(w mailto:sage [04/12/13 14:01:00]: >504
ConsoleとWinアプリは違うから。
デバイスコンテキストをキーワードに勉強しる。

あとこの手の質問はVC++のスレ・・・って適当なの無いな今は　MFC限定しか
512 名前：デフォルトの名無しさん mailto:sage [04/12/13 14:44:57]: >>511
★初心者にVisual C++を教えるスレ★ Part16
513 名前：デフォルトの名無しさん mailto:sage [05/01/01 23:35:39]: C++には、他に類を見ない自由と絶対的な○○が与えられている。
514 名前：デフォルトの名無しさん mailto:sage [05/02/15 18:08:52 ]: C++の機能限定版とか無いの？
515 名前：デフォルトの名無しさん mailto:sage [05/02/15 18:32:19 ]: >>514
例外、クラス、関数オーバーロードや
デフォルト引数などの機能を取り除いた
C というものがあります。
516 名前：デフォルトの名無しさん mailto:sage [05/02/16 18:00:21 ]: >>514
EC++なんてものもある。
ja.wikipedia.org/wiki/Embedded_C_Plus_Plus
517 名前：デフォルトの名無しさん mailto:sage [05/02/17 00:39:05 ]: >>516
だがしかし、はっきり言ってウンコだ。
518 名前：デフォルトの名無しさん mailto:sage [05/02/19 00:11:41 ]: >>516
例外処理が省かれてるのが最大の問題だな。
519 名前：361=別名ポリホ mailto:sage [05/02/19 00:26:05 ]: >>518

テンプレートも名前空間もない。
実際にEC++環境があったのでコーディングしてみたことがあるけど、
全然C++らしくない。
520 名前：デフォルトの名無しさん mailto:sage [05/02/19 06:54:53 ]: まああくまでもembeddedだからねえ。
521 名前：デフォルトの名無しさん mailto:sage [05/02/22 15:21:43 ]: 時々、ECMAScript をバイナリに落とすことが出来ればと考えることがある。

obj = new Object;
obj["Method"] = function( a, b )
{
　echo("OK");
}

obj.Method(); // OK

441 がやりたいことも、プロトタイプ取得で簡単OK
522 名前：デフォルトの名無しさん mailto:sage [05/02/23 14:30:47 ]: 漏れの考えはこうだ！

>461 様の例で「ＣからＣ＋＋に移ったばかりの人」の書き方は
いかにも効率が悪そうな印象を受けるけど、
漏れが「仕事で」プログラムを作るなら、
迷わずこのやり方を取る。
（かなり馬鹿にされるだろうけど…。）

そして趣味で（個人的な事情で）プログラムを作るなら、
「Ｃ＋＋を使い慣れてきた人」や「Ｃ＋＋が『使える』というレベルの人」のような
書き方ができるように努力するだろう。

なぜなら仕事でプログラムを作り、それを他の技術者に引き継ぐ場合、
単純な書き方がもっとも無駄な手間を省くからだ。

そして多くの場合、理解しにくいバグの発生を予め抑制することができる。
また、改修を加えるときや、
不幸にしてプラットフォームの異なる環境へ移植する場合にも、
少ないコストで作業を終えることができるであろう。

スレ違いで申し訳ないけど、
引継ぎ作業によるコストって、
プログラムの書き方で随分変わるんですよ。

「凄いＣ＋＋技術者」の書いたプログラムを引き継いだ場合、
「凄くないＣ＋＋技術者の私」が改修を加えるのは大変なんですよ。
523 名前：デフォルトの名無しさん mailto:sage [05/02/23 15:30:38 ]: >>522
ごく普通なC++プログラマな私からすれば、他人のソースを引き継いだときに
ループが書いてあったらそれだけで要注意項目になります。
std::fillならそのまま読み飛ばせる分だけ、引き継ぎコストは抑えられるわけですな。
構造体も然り。初期化処理をその構造体を利用する側でやらなければいけないよりは
コンストラクタを書いておいてくれたほうがよっぽど確実。
まぁ、「凄くないC++技術者=C++をベターCとしてしか使えない技術者」というなら別ですが。
524 名前：デフォルトの名無しさん mailto:sage [05/02/23 18:11:34 ]: ようするに522が凄いC++技術者になればいいだけ。
525 名前：デフォルトの名無しさん [05/03/12 16:40:27 ]: なんで一時オブジェクトは非const参照に変換できないんだ
template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>& rstr, Value t) {
　　return rstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
} //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。
#define ToStr0(t) ToString(std::string(), t)

template<typename E, typename T, typename A, typename Value>
inline std::basic_string<E, T, A>& ToString(std::basic_string<E, T, A>* pstr, Value t) {
　　return *pstr = static_cast<std::basic_ostringstream<E, T, A>&>(std::basic_ostringstream<E, T, A>() << t).str();
}
#define ToStr1(t) ToString(&std::string(), t)

int main() {
　　cout << ToStr0(5) << endl;　　//エラー：一致するものが見つからない
　　cout << ToStr1(.125) << endl; //OK
　　return 0;
}
って書こうと思ったんだよ。
そしたらふと思いついてこうしたら動くんだよ。
#define ToStr0(t) ToString((std::string&)std::string(), t)
頼むからこんなのキャスト無しでも適当にやってくれよ。

そもそもオブジェクトを値渡しで返そうとするとインライン展開できない
ってのがなけりゃこんなことで悩む必要は無かったんだよ＞Borland
526 名前：デフォルトの名無しさん mailto:sage [05/03/12 17:34:19 ]: それはインライン展開しない方がいいと思うが。

つうか、boost::lexcal_castとか素直に使った方がええんじゃないの？
527 名前：デフォルトの名無しさん mailto:sage [05/03/12 19:06:53 ]: >>526
lexcal_cast.hppをインクルードするとエラーになってしまうもんで。
528 名前：デフォルトの名無しさん mailto:sage [05/03/13 04:15:03 ]: >>525
> //static_castしないとエラーを吐く。これはコンパイラのせいだと思う。

ostream に対する operator << の戻り値は ostream& だから、
コンパイラに依らずエラーになるはず。
一時オブジェクトで処理しようとしているのが間違い。
529 名前：デフォルトの名無しさん mailto:sage [05/03/13 11:35:07 ]: >>523
for ( xxx i = foo.begin(); i != foo.end(); ++i.) {
　nannka(*i, arg1, arg2, arg3);
　kannka(*i, arg4, arg5);
｝

こんなのは、NGで
一回しか使わんつまんねえファンクタわざわざ宣言して
for_eachなりつかわんとNGなんだよな？

アンタがそうゆう主義なのはかまわんが
それがごく普通かねえ？

つうか、実務経験なさそうなふいんき
530 名前：デフォルトの名無しさん mailto:sage [05/03/13 13:12:54 ]: >525
形式的には、一時オブジェクトは右辺値なので非 const 参照に変換できない。

非 const 参照→呼び出された側で変更される
＋
一時オブジェクト→もともと定数だった可能性がある / すぐに破棄される
＝定数のものを変更しようとしている / 変更された値が破棄される
ということでデフォルト安全側に倒してるんじゃないでしょうか。
531 名前：523 mailto:sage [05/03/13 15:09:14 ]: >>529
んにゃ、一々ファンクタ書くまでもない処理ならループでもいいんでない?
ただ、ファンクタもいらんような単純な処理まで一々ループを書くなって話。
適切な比較オペレータを持っているクラスだというのに一々findループを書く神経は疑うってことね。
まぁ、>529の例ならファンクタ書かれるよりはループで書かれた方がよっぽどまし。
更に言えば、for (int i = 0; i < foo.size(); i++) なんて書かれるよりずっとまし。
532 名前：デフォルトの名無しさん mailto:sage [05/03/15 02:44:42 ]: そこでlambdaですよﾜﾗ
533 名前：デフォルトの名無しさん mailto:sage [05/03/19 05:54:34 ]: >>531
しょーもないことにこだわってるあたり覚えたての学生とみた（遠い目
534 名前：デフォルトの名無しさん mailto:sage [05/03/19 10:29:39 ]: 「まし」とか繰り返して、さも自分にはもっといい案があるかのように匂わせておいて
結局そのまま書かずに退散するのが「らしい」ですよね ;-)
535 名前：523 mailto:sage [05/03/19 10:41:38 ]: んー、ないよ～
単にどっちがいいかって書いただけだし。
ファンクタを作らなくてもalgorithmのfind使えるケースで自分でループ書くのや
iterator使わずに制御変数でループを回すのが要注意だって話で。
>529の例ならそれでなんも問題ないんでない?
#そもそも私自身がファンクタ作るの苦手だw
536 名前：デフォルトの名無しさん mailto:sage [2005/03/21(月) 12:01:02 ]: C++よりMLの方がいいよ。
537 名前：デフォルトの名無しさん mailto:sage [2005/03/24(木) 05:34:21 ]: まあバランスが大事だよな
538 名前：デフォルトの名無しさん [2005/03/25(金) 07:52:46 ]: Ｃ＋＋はすさまじく肥大化した言語。しかし、慣れると機能が多くて便利なのも事実だったりする。
シンプルといわれていたJAVAもバージョンが新しくなるにつれて肥大化が進んでいる。
Ｃ＃はＣ＋＋から機能を削ったとはいえ、機能を付け加えているから最初から肥大化している。
機能が多い言語は必ず肥大化し、複雑になってしまう。

シンプルで初心者に優しいけど「不便な言語」よりは、複雑で便利な言語のほうが良いと思が、
複雑な言語は初心者には優しくない。

初心者にやさしい「複雑な言語」があれば望ましいけど、それは無理かもしれない。
539 名前：デフォルトの名無しさん mailto:sage [2005/03/25(金) 08:59:47 ]: >>538
(行き着く先は)自然言語。
そして曖昧さと冗長性が増える罠。
540 名前：デフォルトの名無しさん mailto:sage [2005/04/25(月) 00:25:10 ]: シーピーピー　シーピーピー　シーピーピー　シーピーピー
シーピーピー　シーピーピー　シーピーピー　シーピーピー
ろ　く　な　も　ん　じ　ゃ　ね　ー
541 名前：デフォルトの名無しさん mailto:sage [2005/04/25(月) 08:41:55 ]: 負け犬?
542 名前：デフォルトの名無しさん [2005/04/26(火) 23:11:19 ]: int n;
n.~int();
これがコンパイルを通ってしまうのに驚いた。
こんな関数にint型の値を渡してもコンパイルが通ったからまさかと思ってやってみたら通った。
template <class T>
void Destroy(T& t)
{
　　t.~T();
}
543 名前：デフォルトの名無しさん mailto:sage [2005/04/26(火) 23:52:59 ]: >>542
VS.net2003だと下のテンプレ関数のみ通った。
n.~int();は error C2059: 構文エラー : ''<L_TYPE_ambig>'' って出る。
544 名前：デフォルトの名無しさん mailto:sage [2005/04/27(水) 00:21:50 ]: テンプレートじゃなくても通るのが正しいような気がする。
545 名前：デフォルトの名無しさん mailto:sage [2005/04/27(水) 13:49:42 ]: >>538
今ならまだＤ言語のライブラリは少ない…貧弱
546 名前：デフォルトの名無しさん mailto:sage [2005/04/27(水) 14:17:59 ]: C++もなにかしようと思ったら機能が貧弱だよ
GCもないし、拡張工事をせざるを得ない
良くも悪くもCなんだな
547 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 00:29:01 ]: >>546
そうだね、あせんぶらにもGCつければべんりだね（わら
548 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 05:10:40 ]: >>546
そうじゃなくて、君の頭じゃC++は無理なんだよ。
549 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 05:16:58 ]: 何見当違いの煽りをしてるんだか。
550 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 07:44:37 ]: javaは.closeを書かせておいてGCがあると
主張するのは無理がある。同期のコードなんてCそのものだ。
そういえばGenericsもプリプロセッサで実装しているし
assertの実装は失笑である。javaは新しいCなのだろう。
DはRAIIというのがあるようだ
551 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 17:52:40 ]: C++はむずかしいので、機械語で書いてます。
552 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 18:04:09 ]: >551
俺にはそっちの方がムズい…
553 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 02:10:38 ]: BCBのヘルプに
「alloca 関数の使用はあまりお勧めできません。」
って書いて有るんですけど、そうなんですか？
554 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 09:14:17 ]: >>553
スタックを食い潰すし、移植性に乏しいからでは?
555 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 10:02:13 ]: C99ならVariable Length Arraysを使ったほうが良いかと。
556 名前：デフォルトの名無しさん mailto:sage [2005/04/29(金) 17:30:06 ]: C++ならstd::auto_ptrを使ったほうが良いかと。
557 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 20:59:36 ]: 仮想関数を使えばswitch-caseの嵐から抜けられるわけで、個人的にはそれだけで大満足です。
558 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 23:37:01 ]: >557
だね。場合分けをすることなしに、異なる振る舞いを事前に記述して、コンパイラ任せにできる
有利性、というか。

でも、その有利性を理解できない層というのも確実にあって、それは何かっつーと、
仮想関数という概念、というか言語仕様を知らない層なんだよね。C++はもちろん、
Javaも知らないという層。switch-caseで、あり得る場合分けが全部ソース上に
明記してあった方が判りやすいしデバッグしやすいじゃん、と主張してきそうな、
えてしてそういう層が実装仕様を決めやがるんだよなあ。おっとこれはグチだな。すまん。
誰か強力に布教してくんねーかな。俺はもー疲れた。
559 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 05:12:20 ]: >>558
無理。そういう層は大抵「学習意欲」＜「日々の仕事をこなすこと」だから。
560 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 11:21:57 ]: switch-case の代わりとしての仮想関数なら C でも出来るわけで。
561 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 11:26:56 ]: >>560
だからどうした？
562 名前：デフォルトの名無しさん mailto:sage [2005/06/04(土) 00:16:50 ]: C++儲のおいらでも560には半分同意。
switchの代わりなら構造体+関数ポインタでも
それほど労力がふえるとも思えない。
勿論、仮想関数の方が楽なのは事実だけど。

むしろ、Cで困るのはコンストラク・デストラクタ・templateがない事。
auto_ptrを見ても分かるようにデストラクタが非仮想であっても、
templateと組み合わせればものすごく便利になる。
これが無い故に生成と破棄がセットになったリソースを複数作る
処理で、生成失敗時の破棄処理を書いてるとうんざりする。
563 名前：デフォルトの名無しさん mailto:sage [2005/06/04(土) 01:28:29 ]: 要するに、リソースリークを避けるための下らない労力、プログラムの本質
から大きく外れたロジックやコードがCでは多くを占めてしまうってこったよな。
文字列やリストなんて単純なものも、Cでは悩みの種だ。

まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。
564 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:42:53 ]: この速度ならぬるぽ
565 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:45:51 ]: >564
ｶﾞｯ!
ちゅーかまたお前かっ！
566 名前：デフォルトの名無しさん mailto:sage [2005/07/20(水) 22:15:59 ]: sageてぬるぽもなかろうに
それよか、こんな過疎スレで
sageぬるぽに3分でｶﾞｯした565の方が神
567 名前：デフォルトの名無しさん [2005/07/24(日) 23:15:44 ]: int main()
{
std::locale::global(std::locale("japanese"));
_bstr_t bs(L"ほげ");
std::wcout << bs << std::endl; //static_cast<const wchar_t *>(bs)とすれば無問題。
return 0;
}

VC7.1だとbsはconst wchar_t *か悪くてwchar_t *へ変換されるかと思いきゃ、
なぜかこれに解決される。せめてconst wchar_t *とであいまいにしてくれよ。
template<class _Elem, class _Traits> inline
basic_ostream<_Elem, _Traits>& __cdecl operator<<(
basic_ostream<_Elem, _Traits>& _Ostr, const char *_Val)
568 名前：デフォルトの名無しさん [2005/07/30(土) 10:43:10 ]: 今更だけどブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのにと思う。
569 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 00:36:05 ]: >>568
そのメリットは？
570 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 01:25:38 ]: >>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。

struct S0 { S0(); };
struct S1 { S1(S0 zero); };

int main()
{
　S1 x(S0()); // 現行の規格では関数宣言
　...
}
571 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 04:20:58 ]: >570
S1 x = S0(); で回避できると思うけど、いちいち気にするのがいやってこと？
572 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 04:45:26 ]: >>571
その書き方だと暗黙の変換とコピーコンストラクタが必要になる。
S1を↓のようにするとコンパイルできない。
struct S1 { explicit S1(S0 zero); };
struct S1 { S1(S0 zero); private: S1(S1 const&); };
573 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 05:09:49 ]: >>569
ブロック内で関数宣言する奴なんて見かけない。みんなヘッダをインクルードする。
570みたいなコードは誰もが最初変数宣言だと思ってはまる。
それだったら全部変数宣言にするほうが、わかりやすいんじゃないかと考えた。

たとえば「ブロック内では関数宣言をしたければexternを付ける必要がある。
externなしで関数・変数宣言どちらともとれるときは変数宣言」とでもすればよかったのにと思う。
574 名前：デフォルトの名無しさん mailto:sage [2005/07/31(日) 10:32:18 ]: >>573
Cとの互換性を最優先した結果、なんだろうなあ。
575 名前：デフォルトの名無しさん mailto:sage [2005/08/01(月) 12:09:55 ]: >>570
S1 x((S0()));

()の2バイト分も面倒か？
576 名前：デフォルトの名無しさん mailto:sage [2005/08/01(月) 14:22:05 ]: 対処法の有無はこの話題には関係無いだろう。
577 名前：デフォルトの名無しさん mailto:sage [2005/08/02(火) 00:55:12 ]: >576
その対処法によって、570のいう、
> コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。
ことができない(実際にはできる)という、現行規格への不満が解消されるのだから関係ある。

まぁ570が、一時オブジェクトをローカル変数のコンストラクタに渡す文法を知らなかっただけのようだが。
578 名前：570 mailto:sage [2005/08/02(火) 01:51:48 ]: 知ってたよ。
579 名前：デフォルトの名無しさん mailto:sage [2005/08/02(火) 03:51:30 ]: 一見変数宣言に見えてしまうややこしさを問題としてるという論点に気付かない>>577を暖かく見守る俺が579ゲットですよ
580 名前：577 mailto:sage [2005/08/02(火) 10:28:59 ]: 結局568の主張は、
とくに機能的な違いはないけど、今の文法は見た目がわかりにくいから、
ブロック内での関数宣言を廃止し、全て変数宣言と見なすという仕様にすれば良かったのに
ってことなのね。

ぱっと見のわかりやすさは重要だと思うけど、もう二重に括弧つける癖がついたんで、どうでもいいかなと思う。
>579 サンキュー。これからも暖かく見守ってください。
581 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 01:15:34 ]: このスレの人たちは英文をバリバリに読めるのか？
俺全然読めない。
582 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 06:24:21 ]: 英語しかなければ読むけど、ちょっと下手という程度なら日本語に喜んで飛びつきますが何か。
規格だってISOではなくJISの訳を読むし。
583 名前：デフォルトの名無しさん mailto:sage [2005/08/05(金) 10:31:42 ]: キチガイ翻訳はお断りだが
584 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 16:18:38 ]: >>583
じゃお前が翻訳してくれ
585 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 18:40:15 ]: それが出来りゃ原書読むわい
586 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 09:49:34 ]: 糞　ス　レ　勃　て　て　ん　じ　ゃ　ね　え　よ　脳　挫　傷　！
587 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 12:19:58 ]: >>586
今頃何言ってんの？m9(ry
588 名前：デフォルトの名無しさん mailto:sage [2005/08/15(月) 13:32:23 ]: ﾌﾟｷﾞｬ（ｒｙ
589 名前：デフォルトの名無しさん [2005/09/03(土) 20:06:30 ]: OSのベータ版を市販するやり方は
どこにもマネできないくらい最強
590 名前：デフォルトの名無しさん mailto:sage [2005/11/21(月) 20:30:09 ]: JavaScriptは難しすぎ
pc8.2ch.net/test/read.cgi/hp/1132400636/
591 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 14:52:04 ]: ポインタと参照を混ぜるとややこしいから、ポインタで統一してるんだけど
参照しか使えない場合もあるしなんなんだよ！！
592 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 15:29:17 ]: 俺はなるべく参照を使って、仕方ない時だけポインタを使う
593 名前：591 mailto:sage [2005/11/29(火) 14:48:00 ]: あっそうかスマートポインタ使えばいいんだって使ってるプロジェクト
見たことねえorz
594 名前：デフォルトの名無しさん [2006/01/04(水) 11:55:46 ]: もっともっと難しくなって構わないから早く来いC++0x。
なんてこのスレで言うとぼこぼこにされそうだ。
595 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:21:22 ]: C#に慣れてきたらC++触るのﾃﾗダルくなってきた…
つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ
596 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:35:56 ]: >>595
(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ
597 名前：デフォルトの名無しさん [2006/01/08(日) 01:29:03 ]: >>595
Ｃ＃はＭ＄が作った言語だからＪａｖａ、Ｄｅｌｐｈｉ潰しをしながら
普及のために本気にならんといかんのだよ
Ｃ＋＋についてはＭ＄の都合におかまいなく拡張されたりするから
ほんとはサポートすんのヤなの
だけどＣ＃がコケた時の保険のつもりで一応サポートしとくの
これが戦略。わかる？
ほんとはＣ＃、ＶＢで世界を支配したいの
あとはオマケ
598 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:30:39 ]: >>597
2バイト文字使うなら
せめて♯を使えよと。
599 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 19:48:58 ]: エディタはEmacs系を使えばいいのだ、勝手に補間するVSの親切エディタとは手を切れ、
あれは人を堕落させる。
600 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 00:59:30 ]: >>595
言語仕様が複雑でC#よりﾏﾝﾄﾞｸｾからじゃないかなあ。
601 名前：デフォルトの名無しさん mailto:sage [2006/01/09(月) 21:15:09 ]: >>595
なんか、MSはC#を無理やり推し進めている感じだしね。
FXではWIN32 API呼ぶのにオーバーヘッドがあるようだし・・・
602 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 23:05:13 ]: つーかアプリのパフォーマンスにAPIのオーバーヘッドなんざ
ほとんど関係ないと思うが。処理の9割以上は自分のコード
の中だろ？
603 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 12:29:12 ]: だから、３０歳過ぎて、社会の政治的な要因に太刀打ちできるような
立場になってからもデザインパターンみたいな一技術で重宝されるような
人物に対して「逃げ道だよな」って言ってるの。２０代の奴がやりたくてもできないような
ところで自分をアピールする術を持ってないのかって。
中堅者のやることっていったら、２０代の奴が仕事をしやすいように、いろいろと根回しすることだろ？
年齢重ねても、やることが２０代の延長だったら会社に居る意味ねーよ。
スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。
むしろ、２０代の奴が気付いて、中堅社員に意見をＵＰして、それから中堅社員が根回しするのが理想。
要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。
604 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 13:44:16 ]: >>603
> だから

まで読んだ。
605 名前：デフォルトの名無しさん mailto:sage [2006/01/13(金) 18:34:11 ]: >>603
日本語でおｋ
606 名前：デフォルトの名無しさん mailto:sage [2006/01/14(土) 03:46:11 ]: 日頃誰にも吐き出せず溜め込んでいたモノを一気に吐き出したようだが、
そうやって長年熟成させてきた割には深みゼロなのが哀しいね。
まぁ、この程度の頭だから、誰にも認められずストレス溜めてるんだな。
607 名前：デフォルトの名無しさん [2006/01/14(土) 13:09:20 ]: >>603
デジャブか。
どっかでみたレスだ。
608 名前：デフォルトの名無しさん mailto:sage [2006/01/16(月) 18:52:13 ]: >>606
では君が深みのある話をしてくれ。ぜひ読みたい
609 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 11:53:19 ]: >>608
「では」の使い所が変ですね。
610 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 17:23:19 ]: >>603
> 「で

まで読んだ。
611 名前：デフォルトの名無しさん mailto:sage [2006/01/17(火) 18:50:02 ]: 普通に603より609のほうが深いのが悲惨だなｗ
612 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:11:27 ]: >>609
ではどうすれば正しいのか教えてくれ
613 名前：デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:54:07 ]: その使い方は正しい。>>608は変。
614 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 20:48:13 ]: >>613
どう変なのか説明よろ
615 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 07:10:13 ]: 繋がりがまるでない。
616 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 12:01:29 ]: >>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。
617 名前：デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:33:06 ]: お前らもっと生産的なことに労力を使うように汁。
618 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 14:44:27 ]: C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。
619 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 19:12:33 ]: 2chだし、ピンキリいると思うよ。
620 名前：デフォルトの名無しさん mailto:sage [2006/04/21(金) 21:41:08 ]: そもそも何を持ってC++をC++として使っているというのかが曖昧。
621 名前：デフォルトの名無しさん mailto:sage [2006/04/22(土) 01:17:52 ]: 2chでなくてもピンキリ
ttp://sourceforge.jp/softwaremap/trove_list.php?form_cat=165
622 名前：デフォルトの名無しさん mailto:sage [2006/04/22(土) 10:47:13 ]: >>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ？) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。
623 名前：デフォルトの名無しさん mailto:sage [2006/04/29(土) 16:21:55 ]: そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ
624 名前：デフォルトの名無しさん mailto:sage [2006/04/29(土) 17:17:48 ]: >>623
それはない。
625 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 12:07:03 ]: >623
オブジェクト指向とgoto不要論を同じレベルで論じるなよ
626 名前：デフォルトの名無しさん [2006/05/22(月) 14:29:18 ]: >>595
>つーか、同じVisualStudioなのにエディタの出来があからさまにVC#＞＞＞＞＞＞VCなのは何の嫌がらせだよ
だよな
627 名前：デフォルトの名無しさん [2006/05/24(水) 11:55:09 ]: C++の標準化委員会は冒険的に過ぎるところがある。
C++がこれだけ強力な言語になったのは彼らの力だけど、
いろいろと取り返しの付かない失敗をしている。
slice_arrayで大恥をかき、exportや<cNNN>ヘッダで実装者を悩ませ、
言語仕様の穴を利用してauto_ptrを実装してしまう。
koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
取り繕おうとして傷口を広げた例だね。
もう少しやる気の無い連中、あるいは後方互換性にこだわらない連中が
標準化をやっていればこんなに難しい言語にはならなかっただろうに。
628 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 12:40:01 ]: で、C++のどこが難しいんだ？
クラスが分からないのか？
629 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 12:54:45 ]: >>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと？
630 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 13:05:06 ]: >>627
>後方互換性にこだわらない
ここ同意
631 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 13:12:19 ]: 後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。
632 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 15:52:15 ]: まぁ、実際に携わってみれば誰もが苦しむところだろうな。
633 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 17:05:09 ]: >>631
まあそうなんだけど、予約語の使いまわしが
初学者を混乱させてんじゃないかな、と。
634 名前：デフォルトの名無しさん [2006/05/24(水) 18:51:51 ]: ケーニヒがなかったら
a + 1 // OK a.operator+(1)
1 + a // NG
my_namespace::operator+(1,a) // OKだが書いてられるか
635 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 20:17:10 ]: D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。
636 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 21:43:18 ]: 初学者のためにOSのカーネルがコンパイルできなくなるなんて
許されないからな
637 名前：デフォルトの名無しさん [2006/05/24(水) 23:01:13 ]: >>629 >>634
operatorやswapをこんな感じにしておけばKoenig lookupは要らなかった。
lessを提供すればless_equalも勝手に実装してくれるとか、
そういう仕組みを作ることもできる。

namespace std {
...
namespace hooks {
template <class T1, class T2>
struct plus_traits;

template <class T>
struct plus_traits<std::complex<T>, std::complex<T> > {
typedef std::complex<T> result_type;

static std::complex<T>
plus(const std::complex<T> &a1, const std::complex<T> &a2)
{ ... }
}
}
}

template <class T1, class T2>
std::hooks::plus_traits<T1, T2>::result_type
operator+(const T1 &a1, const T2 &a2)
{ return std::hooks::plus_traits<T1, T2>::plus(a1, a2); }
638 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 23:17:26 ]: >>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね？それもなんかおかしくね？
639 名前：デフォルトの名無しさん mailto:sage [2006/05/24(水) 23:25:01 ]: >>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。
640 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 00:19:15 ]: >>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。
641 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 00:41:39 ]: >>640
コンパイラに koenig lookup を追加すればいいってことだな。
642 名前：639 mailto:sage [2006/05/25(木) 02:39:06 ]: >>640
その意味はわかるけど意図が判らない。
直接operator +を特殊化すればよいのではないかと思った。
643 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 02:46:28 ]: >>637
これはこれで一時期は真剣に考察されていた案ですけれど，
結局「分かりにくい」ということで一度標準委員会で否決されているんですよね．
swap の場合ですけれど．

特にデフォルトがない hook の場合，特殊化に基づく hook の提供は
exact match を要求する，つまり特殊化したい型それぞれに
いちいち全部特殊化を用意しなければならない
（これは base-derived や cv-qualification まで含めて厳密にやらないといけない）
のに対して， ADL による hook は loose match で済む，
例えば base に対する特殊化が derived に自動的に適用されるような
直感的なあり方に一応適合します．
この議論は関数テンプレートの部分特殊化 (FTPS) が導入されても
基本的な議論の流れに大きな変化はないでしょう．
（というか，クラステンプレートの静的メンバ関数を用いるそもそもの動機は，
FTPS が現行規格で存在しないことの workaround だったはずです）

もちろん ADL による hook の提供の場合も，一般に挙動が非常に予測しにくい，
つまり，名前空間お構いなしでありとあらゆる名前空間を潜在的にぶち破る
凶悪な特性を持ちえることと，一般に汎用プログラミング特有の構文指向な面が
強く出る（hook がどう定義されているか（signature-oriented）ではなくて
hook をどう呼び出したか (syntax-oriented) に意味が左右されやすい）
という非常に大きな欠点を抱えるのも確かです．
644 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 02:47:08 ]: >>637
より踏み込んだ議論として，そもそも hook の所有権・所在の
あり方に関する議論もあります．

特殊化に基づく hook の提供の場合，特定の名前空間に hook の所在が
固定されますが，それはそもそも正しいのか？
全く関係の無いサードパティが提供するヘッダとプライマリテンプレートに依存し，
その名前空間を開けて hook を提供しなければならなくなる状況も想定され，
それは本当に正しいのか？という疑問です．
そういう意味では ADL による hook があらゆる名前空間を
潜在的にぶち破る特性を逆手にとって，
「大域の ADL hook 用名前空間（global ADL namespace）に hook をおく」と
考えることも， hook の所在の中立性という観点からは
あるいは悪くないともいえます．

少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします．
645 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 03:00:06 ]: >>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです．
また，関数テンプレートの部分特殊化が現行規格に存在しないために，
一般にクラステンプレートに対して関数テンプレートを特殊化することができない，
という事情もあります．クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは，関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います．
646 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 05:56:24 ]: >>643-644
> ADL による hook は loose match で済む，
こいつの解決策だけど、
案1: オーバーロードを追加するとき、新しい名前を導入したとみなさないで
部分特殊化と同様に扱えるような構文を導入する
lazyoverload operator+;
namespace std {
...
namespace hooks {
lazyoverload swap;

template <class T, class Alloc> void
swap(std::vector<T, Alloc> &a1, std::vector<T, Alloc> &a2)
{ a1.swap(a2); }
}
}
template <class T> std::complex<T>
operator+(const std::complex<T> &a1, const std::complex<T> &a2)
{ ... }
コンパイラから見ればKoenig lookupとほとんど同じ機能だから、
実装は不可能ではないはず。
647 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 06:09:37 ]: 案2: typeofなどの機能を導入してオーバーロード解決の機構を
テンプレートから活用できるようにする
template <class U>
struct plus_traits<std::complex<int>, U> {
static std::complex<int>
plus(const std::complex<int> &a1, int a2)
{ ... }
static std::complex<double>
plus(const std::complex<int> &a1, double a2)
{ ... }

typedef typeof(plus(const std::complex<int> &, U)) result_type;
};
実現性がどの程度なのかは分からんけど、可能ならテンプレートの力はかなり増す。
648 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 13:11:41 ]: >>646
>>643さんが指摘されてる、クラステンプレートの部分特殊化による手法の問題は、
class Aに対してstd::hooks::???_traits<A>を実装したとして、
その後AのサブクラスであるB,C,...Zを作成した際に
全く同じstd::hooks::???_traits<B>, ... std::hooks::???_traits<Z>を
実装しなければならないということだと思うのですが。
この点、ADLの場合は基底クラスを引数にとる関数一つで用は足ります。

派生クラスと基底クラスの関係は、
オーバーロード解決では考慮されますが（部分）特殊化の解決では考慮されません。

>>643のコードを見る限り、operator+(T,T)の部分特殊化として
operator(const complex<T>&, const complex<T>&)を定義しているようですが、
これでは、>>643で言及された問題は解決できません。

ただし、ADLがない世界を仮定して、更にlazyoverload云々を無視して
普通のオーバーロードだと考えれば、>>643の問題はないように思います。
これは、hook用名前空間を１ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる（特殊化ではなく）という問題はありますが。
649 名前：デフォルトの名無しさん mailto:sage [2006/05/25(木) 13:51:00 ]: >>648
普通のオーバーロードだとこれが動かない。
template <class T>
std::complex<T> operator+(std::complex<T> a1, std::complex<T> a2);

namespace std {
template <class T>
struct plus : public std::binary_function<T, T, T> {
T operator()(const T &a1, const T &a2) const
{ return a1 + a2; }
};
}

template <class T>
std::valarray<T> operator+(std::valarray<T> a1, std::valarray<T> a2);
650 名前：648 mailto:sage [2006/05/25(木) 14:43:27 ]: >>649
std::plus::operator()内のa1+a2のことを言っていると思いますが、
いまいちよくわからないので、推測しながら答えます。

まず、complexのoperator+が、
plus内部から解決されないことを問題にしているのであれば、
>ADLがない世界を仮定して、
ということです。
もう少し補足すると、ADLがない結果として、
std名前空間内にoperator+がないことも仮定しています。

また、valarrayのoperator+が最後に定義されていることから、
two phase lookupを問題にしているとも推測できますが、
それでも特に問題がないのではないでしょうか？

どこを問題にしてるかを明らかにしてもらえれば、
より有意義に議論できると思います。
651 名前：648 mailto:sage [2006/05/25(木) 14:55:55 ]: よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。
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人だとありがたみを感じないのも無理はないと思う
753 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 23:37:36 ]: 一月前の俺と今の俺は他人
754 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 23:37:57 ]: データ隠蔽とかはブロックごとにファイル分けて
構造体に突っ込むことでまだなんとかなるけど
テンプレートのアルゴリズムはもうCではやる気が起きなくなるな。
755 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 08:45:57 ]: >>751
それ、全部C++でもできることじゃん。
要は、「Cの方が高い」じゃなくて、「C++である必要が無い」だな。
756 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 09:11:09 ]: まずnamespaceから
757 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 16:58:53 ]: まずC風に軽く組んで、
「ここの機能まとめたら分かりやすくなるかも」見たいな感じで
徐々にOOP「風」に組み直していくやり方でいっぱいおっぱいですよ
758 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 19:34:38 ]: 自分も早く再利用可能なクラスをいっぱい作って
実際のプログラムは部品をドッキングさせるだけで良いみたいな状態になりたい
759 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:42:41 ]: 結構気合い入れて「俺ライブラリ」を作るんだけど、
なかなかうまくいかないねえ、こう、なんというか、
「近未来の自分にすんげーフィットする汎用性と機能のバランス」ってやつは。
760 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 02:42:16 ]: 各種文字列クラスとの相互変換テンプレートだらけで
俺ライブラリは統一性が無い。文字コード含めてわけかわらんよ。
比較関数だけでも20種類はある。
761 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 02:53:25 ]: 難しいとは思わないけど
無駄に複雑
馬鹿みたい
762 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 03:04:04 ]: 馬鹿みたいというか
馬鹿が複雑に書いてるんだ
でもビャーンのハゲは髪だと思う
763 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 03:38:18 ]: 禿はインタブーで「わざと複雑にした」っつってる死ね
764 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:06:44 ]: 頭の悪い奴には使いこなせない言語だよな、ホント。

でもこの「頭の悪い奴には使いこなせない」の意味を、頭の悪い奴は理解できない。
そして見当違いの方向に怒り出すｗ
765 名前：デフォルトの名無しさん [2007/04/30(月) 22:07:18 ]: こないだ仕事でJava使わされたけど
あまりの遅さと自由度の低さに愕然とした

やっぱ自分ひとりで組むのならC++だな
766 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:29:37 ]: Javaのgenericにはしょんぼりした記憶があるな
C++的なものを求めるのが間違っているんだけどさ・・・
767 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:42:48 ]: boostがやばすぎるぐらいに便利だからなぁ・・・
逆にC++より簡単な言語ってないんじゃね？って思えてくる
768 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 21:35:05 ]: boostって何がそんなに良いの？
導入すっかな
769 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 22:09:17 ]: std::for_each(r.begin(), r.end(), f);がboost::for_each(r, f);と書けるようになったり、
std::bind1st. bind2ndより見た目わかりやすいbindが書けたり、正規表現ができたり。
770 名前：デフォルトの名無しさん [2007/05/03(木) 08:56:18 ]: >>768
少なくとも言語マニアの素養がある椰子には
boost::lambda, boost::function　→関数型パラダイム
boost::mpl, boost::preprocessor　→メタプログラミング
boost::spirit　→構文解析
あたりは垂涎もの。使ってるとJavaとかC#ですら塵に思えてくる

そんなの無くても不自由しねえよって人でも
スマートポインタとかは確実に有用
771 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:23:39 ]: lexical_castやpolymorphic_downcast、numeric_cast、noncopyableあたりも地味に便利
772 名前：768 mailto:sage [2007/05/03(木) 10:40:46 ]: うむ
ありがとう
何を言ってるのかさっぱりな漏れにはまだ早いことは良くわかった。
ようやっとSTL使い始めたばかり
773 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 18:47:17 ]: コンパイル遅すぎなんだよ糞が
774 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 18:54:15 ]: 何のための分割コンパイルだ、プリコンパイルヘッダだ
775 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 23:16:29 ]: 速度なんてボチボチ、イラネな世界になってきたから
Rubyとかで良いんでない
776 名前：デフォルトの名無しさん mailto:sage [2007/05/08(火) 02:49:46 ]: 最近は専門用語が増えすぎ。
あーぎゅめんとでぃぺんでんとねーむるっくあっぷ
かりおすりーりかーりんぐてんぷれーと
えんぷてぃーべーすおぷてぃまいぜーしょん
えたーなるふぉーすぶりざーど
777 名前：デフォルトの名無しさん mailto:sage [2007/05/08(火) 03:16:12 ]: クトゥルーさげ
778 名前：デフォルトの名無しさん mailto:sage [2007/05/09(水) 13:56:22 ]: いあいあはすたあ！
779 名前：デフォルトの名無しさん mailto:sage [2007/06/02(土) 07:50:12 ]: 全部の機能を使うのはたいへん
780 名前：デフォルトの名無しさん mailto:sage [2007/06/19(火) 18:43:40 ]: C++のどこがBetterCなんだ
むしろWorseCだ
781 名前：デフォルトの名無しさん mailto:sage [2007/06/19(火) 19:20:44 ]: ローカル変数宣言がブロックの先頭に縛られないこと
特にforなどで変数宣言できること

inline関数
constで定数宣言できること

強力な型安全性の保障（ベターCとして使うならvoid*から他のポインタ型への暗黙の変換まで禁じられるのはきついが）
782 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 02:40:13 ]: >>781
最後以外は C99 で十分だな。

改めて C99 と比べると、
- restrict
- __VA_ARGS__
- stdint
- 複合型リテラル
- 要素指定の初期化
とか、いろいろ抜けてるので十分 WorseC と呼ぶに値する。
783 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 06:01:43 ]: >>780
使う人間のレベルによっては、変わるかもしれないな。
784 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 06:16:32 ]: 仕様としてC99が充分だとしても
C99のコンパイラ自体がまだまだ普及してないというのが、一番の大問題。
785 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 06:27:22 ]: gccにicc、Sunのccもc99に対応していて、これでも普及していないと言い張るとはDozerはこれだから……
つーか、M$儲というべきか?
786 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 06:36:47 ]: で、「世間一般の人」の中で、そのDozerとやらの割合はどれほどですか？
787 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 06:39:16 ]: 今はもう、理系の大学のプログラミング言語の課程ですら
Windowsを使う方がずっと多いでしょ。
昔の人はSunとかで覚えたんだろうけど。
788 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 08:36:06 ]: 世間一般の人はプログラミングなんてせんなぁ。
789 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 08:37:31 ]: gccもiccもWindows版があることを知らないのでは?
790 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 08:42:39 ]: で、そのMingw等で作られたアプリケーションの比率はどのくらい？
もちろん、VBやdelphi等を除いた、C/C++の中での比較で良いけど。
791 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 08:47:36 ]: >>788
「世間一般の人が使っているOS」をコンパイルするコンパイラや
「そのOS上で動くアプリケーション」をコンパイルするコンパイラは
C99に対応してますか？

一般じゃない人(大学の教養課程は一般の人は通らないのですね)は、
betterCのコードをコンパイルする時に
「多数のアプリケーションが使っているC++コンパイラ」を避けて
「該当する環境ではかなりマイナーなC99コンパイラ」を使うべきというわけですね？
792 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 09:04:47 ]: 俺は>>781の中では、最後の型安全保障が一番重要だと思うのだけど
793 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 09:42:36 ]: >>785
君が海胆糞erか犬糞erか知らんが、職業マは
そんなもんだけで喰っていけるわけじゃない。
794 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 10:02:38 ]: 媚びへつらいと責任転嫁で喰うのが一般的。
795 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 19:00:08 ]: C99ってconstが定数になるの？
796 名前：デフォルトの名無しさん mailto:sage [2007/06/20(水) 21:30:52 ]: >>793
Windowsで、VisualStudio使ってiccでコンパイルしてますが何か。
797 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 05:53:46 ]: お前が何をしていようが、誰も何も思うことなんて無いよ。どうでもいい存在だもの。
798 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 07:59:18 ]: visual studioからgccとかicc使うような環境作れるんですか？
799 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 08:35:47 ]: gccはともかく、iccはリンカがないからVisualStudioと連携させざるを得ない。
ついでに言えば、誰もやりたがらないだけでgccもVisualStudioから使える。
#つーか、まさかVisualStudioがコンパイラだと思ってないよね。
800 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 08:45:10 ]: >>797
その割にはずいぶんとご執心で。
801 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:15:59 ]: いや、俺だって、「C99だったら楽なのに」と思うことはあるよ。
配列の要素数が定数じゃなくていい、なんてのは(std::vectorを使う)俺には必要ないけど
可変長構造体が公式に認められたこととか、
あと、<stdint.h>はあったら随分楽になるとは思う。
(もちろん、多くの非C99環境でも、<inttypes.h>があるから大抵は足りるけど
標準Cでは非公式だから、無い環境のことを考えて#ifdefを使った自前ヘッダを用意しなきゃいけない)

でも、それでもC++のメリットに比べたら、C99のメリットなんて微々たるもの。
その上「C++が使える環境(処理系)」が「C99が使える環境(処理系)」よりずっと多いのだから
「C99でも出来るからC++は要らない」なんて、俺にはとても言えないね。
803 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:16:56 ]: > 必死にgccを主張して頑張ってる人
> 頑張ってずっと「（略）C99でも出来るからC++は要らない」と言ってる

妄想乙
804 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:18:51 ]: >>803
>>782
805 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:21:21 ]: >>784以降の人も、同一人物か同じ意見の人でしょ。
Windowsがどうのと言ってる人。
806 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:23:49 ]: >>804
やっぱり妄想乙。行間に何か見えてしまう人なんだろうか。
807 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:26:40 ]: 煽っている人の方は単発でピンポイントで突っ込んでるだけなのに、
一人でそれを真に受けて顔真っ赤にして反論しちゃってるんだろうな。
808 名前：デフォルトの名無しさん [2007/06/21(木) 09:30:24 ]: じゃああげようよ
809 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:32:40 ]: いや、俺には>>785みたいな負け惜しみというか捨て台詞というのが笑えるんですけど。
現実をあえて無視して、必死になってとりつくろってるし。
810 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:35:47 ]: C99の、普及していないという最大の欠点を指摘されてよほど悲しかったのか
何故かWindows批判までして、でもWindowsでも使えると反論してみたり。
811 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 09:37:29 ]: それが信者というもの
812 名前：デフォルトの名無しさん mailto:sage [2007/06/21(木) 10:00:08 ]: >>806
というより、誰が誰なのか決め打ちでもの言ってる奴はどれも妄想にしか見えん。
813 名前：デフォルトの名無しさん mailto:sage [2007/06/23(土) 03:35:32 ]: C99 マクロ (sourceforge.net/projects/chaos-pp)
vs
C++98 template (Boost.MPL)

この戦いは壮絶なものになる
もはや何言語なのか分からない
814 名前：デフォルトの名無しさん mailto:sage [2007/06/23(土) 20:38:16 ]: >>813
ライブラリ名の時点ですでにカオスなんだが・・・
815 名前：デフォルトの名無しさん mailto:sage [2007/06/23(土) 23:48:47 ]: ドキュメントのビルドの仕方が分からなくて手つけてないぜ…
816 名前：デフォルトの名無しさん mailto:sage [2007/08/28(火) 21:53:56 ]: 難しすぎる。
JAVAの方が生産性高いらしい。
817 名前：デフォルトの名無しさん mailto:sage [2007/08/29(水) 12:40:34 ]: なぁ、みんなはwarp.povusers.org/FunctionParser/fparser28.zip
にあるFunctionParserのソースを見ただけで、「ここが、こうなって、ああなって」
みたいに、読み解きほぐせるの？
俺全然読みとけねぇ。
818 名前：デフォルトの名無しさん mailto:sage [2007/08/29(水) 22:42:26 ]: 再帰降下型パーサだな。
実行部分はスタックマシン。
これはもうパターンみたいなもんで、自分で一回作ったことがあればほぼおんなじ構造だから大体わかる。
819 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 15:19:01 ]: >>816
1行目はただの感想だろうからいいが、
らしいなんて憶測でモノを語るなよ。
820 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 00:10:55 ]: 「らしい」は憶測ではなく伝聞を表す表現ではないか、というのが一つと、
憶測がまずいのは、それが事実のように書かれた場合であって、事実を語っているわけではないことが
明らかに文面からわかる場合は、別に語ったっていいんじゃないか、ってのが一つ。
821 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 01:02:56 ]: 横から失礼。
「らしい」は伝聞じゃなくて推量を表す表現だよ。
推量の基になった外部情報が伝聞という事はあり得るけれども。
822 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 01:31:48 ]: 憶測でも自分の偏見でもここで語る分には何の遠慮も考慮もいらないと思う。
ここは「そういう場」であるんじゃないかな。
823 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 01:40:41 ]: つまり、ぬるぽOKという事ですね？
824 名前：816 mailto:sage [2007/09/01(土) 06:13:18 ]: ちょｗナニこの超展開
流石マ板
書いたときの意図は伝聞らしい
825 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 06:44:31 ]: >>824
＞JAVAの方が生産性高いらしい。
伝聞の助動詞は「そうだ」だよ。
→JAVAの方が生産性高いそうだ。

＞書いたときの意図は伝聞らしい
自分自身の意図を推量する事は無いんだから「らしい」は使えないよ。
826 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 07:02:24 ]: んなこたーない。使えるらしい。
827 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 08:32:51 ]: いやらしい
828 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 10:03:02 ]: 推量でも伝聞でもいいが、理由も続けないと有益な議論にならないじゃん。
2chでそんなことを期待するほうがあほですかそうですか。
829 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 10:41:22 ]: 自分が何もしないのに場が勝手に有益になるのを期待するのは確かにあほだね。
でもそれって2chに限らないよ。
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