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

このエントリーをはてなブックマークに追加
388361
>>379

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

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

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

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

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

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

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

"polymorphism" な。

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

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

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

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

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

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

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

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

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

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

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

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

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

あるからびっくりだ。
402デフォルトの名無しさん:04/09/15 19:32:31
全部同一人物?
403初期不良:04/09/15 21:23:16
>>400
モーフィングとフォーミングを勘違いするなら分かるけど
フォーリングと勘違いするというのは飛んでるなと思う。
3カウント入れちゃうよ
404361=別名ポリホ:04/09/15 21:35:53
だからマジtypoだって...。まだいりじるのか...。
本気で恥ずかしいんだからいじめんなよ。

405361=別名ポリホ:04/09/15 21:36:44
>>いりじる
いじるの間違いだ。またtypo。もう嫌...。
406デフォルトの名無しさん:04/09/15 21:38:17
ていうか、ポリフォーリズムをモリモーフィズムと間違えるのって恥ずかしすぎ。
407デフォルトの名無しさん:04/09/15 22:06:55
イリジウムのことね
408デフォルトの名無しさん:04/09/15 22:12:54
はずかしすぎ。
アンテナでかすぎ。
409デフォルトの名無しさん:04/09/15 22:24:30
どうtypoったらそうなるのか分からん
410デフォルトの名無しさん:04/09/15 22:47:57
typoだけに突っ込んでいる人は、
そうやって話をはぐらかそうとしている
厨房なので無視するべし。
411374:04/09/16 00:56:53
>>394
なんか、どちらかに誤解があるようだな。
>>364の [依存]ケース2 で言っていることは、
たとえば「あるメソッド」foo について、
 foo(T*);
というふうに引数の型として生ポインタを使うということじゃないの?
それに対して、
 foo(T&);
のほうが適切ではないかと言う突っ込みを>>374で入れている。
これは引数の型の話で、確保したインスタンスを
保持するための型は関係ないと思うんだけど、
漏れが>>364を誤読しているの?
412374:04/09/16 00:58:09
レスアンカー間違えた。
>>411>>398 宛てね。
413361=別名ポリホ:04/09/16 08:34:22
>>414

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

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

質問の意図は指摘しているところで参照をつかうと、
setterうんぬんのケースと一貫性を保とうとすると
無理がある場所がでるんじゃないかってことです。

415374:04/09/17 09:34:20
>>413
最初に突っ込みいれた箇所(>>364の[依存]ケース2)では
「渡されたインスタンスはそのメソッドの中でしかつかわれない」状況となっている。
「インスタンス変数に保持するメソッド」なら状況が違うんじゃないの?
これらの異なる二つの状況の間で一貫性なんてあるはずがない。

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

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

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

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

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

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

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

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

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

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

int* a, *b;

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

int *a, *b;

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

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

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








・・・レガシーという単語を使いたかっただけだ。気にしないでくれ。orz
428デフォルトの名無しさん:04/09/24 08:39:01
int* をtypedefして違う名前を与える
さらにはintを変えられるようにtemplate化
429デフォルトの名無しさん: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デフォルトの名無しさん:04/09/24 10:25:14
>>429
b=a;

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

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

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

使った事無いけど。多分。
447r:04/10/30 08:25:36
>>444
つーか

TEST_STRUCT srcData[] = ...;

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

じゃなくて?

448デフォルトの名無しさん: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デフォルトの名無しさん:04/10/30 19:41:55
>>446
「offsetof」なんて初めて聞いた!
…と思ったらひょっとしてC++の言語仕様にはないものですよね?
ぐぐってみたらどうやら「.NET Framework」なのかな?

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

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

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

…などと話していたので、興味を持った次第でつ。
これができるとどういうメリットがあるかという話ですが、
(C++Builderの話限定になってしまうのですが)
DBの不特定なテーブルから、フィールド名を指定せずに
不特定の構造体のメンバにデータを突っ込めるため、
プログラムの汎用性が高まるということらしいです。
450デフォルトの名無しさん:04/10/30 22:20:56
offsetofを知らないだけならともかく(それも問題だが)、C#って・・・
絞り込みも出来ない、googleのトップしか見ないで、2番目は無視する人かね
451448:04/10/31 01:07:37
>>449
offsetofなんて、Cでもマクロで簡単に書ける代物なんだけど。
標準ヘッダを探してみることもできないのかな?
452デフォルトの名無しさん:04/10/31 02:37:42
うわ〜ん、そんなにいじめるなぁ〜。ヽ(`Д´)ノ
簡単にできるというのがいいのだよ。
めんどっちいのはイヤ。
453デフォルトの名無しさん:04/10/31 02:45:31
しかし、とりあえずoffsetofというマクロが
標準的に用意されてることを教えていただき、
ありがとうございますた。m(_ _ )m
454r:04/10/31 17:05:43
クラスのメンバを、別々に、同じベクタに入れる意味がわからん
455デフォルトの名無しさん:04/11/25 02:44:24
最近書き込みがないね。
456デフォルトの名無しさん:04/11/25 04:01:13
重複スレだからな。
457デフォルトの名無しさん:04/11/26 03:07:57
C言語とJavaとRuby使って,そこそこ書きました.
次はC++にチャレンジするかと,プログラミング言語C++を買ってきました.
難しいです.何書いてるのかわかりません.
俺の頭が悪いのが原因でしょうが,C++の難しさに挫けそうです
458デフォルトの名無しさん:04/11/26 08:15:19
ヽ(冫、)ノズコーッ
何処が難しいか言ってみて。
十分習得出来る知識あるように見えるけど…
459デフォルトの名無しさん:04/11/26 10:26:54
>>458
>十分習得出来る知識あるように見えるけど…
んな事が >>457 読んで解るのか!ESPer でつか?
460デフォルトの名無しさん:04/11/26 10:52:23
>>459
Yep
461デフォルトの名無しさん: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デフォルトの名無しさん:04/11/26 14:07:40
C++のことがある程度わかってくると、++、--は前置にするもんです。
463デフォルトの名無しさん:04/11/26 16:44:04
運置
464デフォルトの名無しさん:04/11/26 21:17:08
>>462 どうして?
465デフォルトの名無しさん:04/11/26 21:20:14
>>464
前置の方がコピーのコストがかからないから
466デフォルトの名無しさん:04/11/26 21:27:04
>>465 どうして?
467デフォルトの名無しさん:04/11/26 21:32:47
>>466
More Effective C++の項目6を嫁
468デフォルトの名無しさん:04/11/26 21:36:34
>>467
読んでみた。ありがとう。
インライン展開されるような場合は別に気にしなくていいね。
469デフォルトの名無しさん:04/11/26 22:23:28
>>461
それ見てC++の方がタイプ量多い割にたいしたこと出来ない。
Cの方が1000万倍マシと悟った。
470デフォルトの名無しさん:04/11/26 22:24:18
>>469
それはちょっと勘違いだ。
C++ は C より便利だよ。
471デフォルトの名無しさん:04/11/26 22:24:53
>>467
んじゃ、これから
Effective ++C
と書くことにしちくりマンボ
472デフォルトの名無しさん:04/11/26 22:28:36
>>471
山田君、座布団一枚持ってっちゃって
473デフォルトの名無しさん:04/11/26 22:32:14
>>468
テンプレートでの汎用プログラミングのために常に
前置にしておくと後々組み込み型をクラスにしたくなった
とき修正量が減る。
474デフォルトの名無しさん:04/11/26 23:07:05
>>473
組み込み型かクラスかは別に関係ないような?
475デフォルトの名無しさん:04/11/26 23:35:39
>>474
クラスだとテンポラリオブジェクトが生成されるよ。
インライン展開されてもね。
476457:04/11/27 02:51:11
思ったよりレスが…ありがとうございます.

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

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

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

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

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

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

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

obj.Method(); // OK

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

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

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

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

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

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

「凄いC++技術者」の書いたプログラムを引き継いだ場合、
「凄くないC++技術者の私」が改修を加えるのは大変なんですよ。
523デフォルトの名無しさん:05/02/23 15:30:38
>>522
ごく普通なC++プログラマな私からすれば、他人のソースを引き継いだときに
ループが書いてあったらそれだけで要注意項目になります。
std::fillならそのまま読み飛ばせる分だけ、引き継ぎコストは抑えられるわけですな。
構造体も然り。初期化処理をその構造体を利用する側でやらなければいけないよりは
コンストラクタを書いておいてくれたほうがよっぽど確実。
まぁ、「凄くないC++技術者=C++をベターCとしてしか使えない技術者」というなら別ですが。
524デフォルトの名無しさん: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デフォルトの名無しさん:05/03/12 17:34:19
それはインライン展開しない方がいいと思うが。

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

ostream に対する operator << の戻り値は ostream& だから、
コンパイラに依らずエラーになるはず。
一時オブジェクトで処理しようとしているのが間違い。
529デフォルトの名無しさん: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デフォルトの名無しさん:05/03/13 13:12:54
>525
形式的には、一時オブジェクトは右辺値なので非 const 参照に変換できない。

非 const 参照→呼び出された側で変更される

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

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

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

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

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

まあメモリリーク回避だけならGC使う手もあるがなー。
GC使えるような環境なら今時Cなんて使うなよという話もあるが。
564デフォルトの名無しさん:2005/07/13(水) 23:42:53
この速度ならぬるぽ
565デフォルトの名無しさん:2005/07/13(水) 23:45:51
>564
ガッ!
ちゅーかまたお前かっ!
566デフォルトの名無しさん: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デフォルトの名無しさん:2005/07/31(日) 00:36:05
>>568
そのメリットは?
570デフォルトの名無しさん:2005/07/31(日) 01:25:38
>>569
コンストラクタ呼び出しで作った一時オブジェクトでローカル変数を直接初期化できる。

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

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

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

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

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

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

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

まで読んだ。
611デフォルトの名無しさん:2006/01/17(火) 18:50:02
普通に603より609のほうが深いのが悲惨だなw
612デフォルトの名無しさん:2006/01/26(木) 21:11:27
>>609
ではどうすれば正しいのか教えてくれ
613デフォルトの名無しさん:2006/01/26(木) 21:54:07
その使い方は正しい。>>608は変。
614デフォルトの名無しさん:2006/01/29(日) 20:48:13
>>613
どう変なのか説明よろ
615デフォルトの名無しさん:2006/01/30(月) 07:10:13
繋がりがまるでない。
616デフォルトの名無しさん:2006/01/30(月) 12:01:29
>>614
批判に対して「じゃあお前がやってみろ」というのは
反論にも何にもなってないわけですが、
小学生くらいだと別におかしいとは思わないようですね。
617デフォルトの名無しさん:2006/01/30(月) 22:33:06
お前らもっと生産的なことに労力を使うように汁。
618デフォルトの名無しさん:2006/04/21(金) 14:44:27
C++を使いはじめて10年以上になるが、
これまでC++をC++として使える奴って未だ見た事がない。
このスレでC++を絶賛している奴は本当にC++を使いこなしているのか疑問。
619デフォルトの名無しさん:2006/04/21(金) 19:12:33
2chだし、ピンキリいると思うよ。
620デフォルトの名無しさん:2006/04/21(金) 21:41:08
そもそも何を持ってC++をC++として使っているというのかが曖昧。
621デフォルトの名無しさん:2006/04/22(土) 01:17:52
622デフォルトの名無しさん:2006/04/22(土) 10:47:13
>>618
おまいの周囲の連中のレベルなんか知ったこっちゃないが
>このスレでC++を絶賛している奴は
「絶賛」する奴 (いたっけ?) は信用するな。
見た目だけで「あいついい女だよな」っつってる奴は
その女と付き合ってるわけではない。
623デフォルトの名無しさん:2006/04/29(土) 16:21:55
そもそもオブジェクト指向が難しすぎ
gotoを使って何が悪いんだ
624デフォルトの名無しさん:2006/04/29(土) 17:17:48
>>623
それはない。
625デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/24(水) 12:40:01
で、C++のどこが難しいんだ?
クラスが分からないのか?
629デフォルトの名無しさん:2006/05/24(水) 12:54:45
>>627
概ね頷けるところだが、
> koenig lookupなんかは、ライブラリの設計ミスを言語仕様側で
> 取り繕おうとして傷口を広げた例だね。
これだけ、聞いた事が無い話だった。
何のこと?
630デフォルトの名無しさん:2006/05/24(水) 13:05:06
>>627
>後方互換性にこだわらない
ここ同意
631デフォルトの名無しさん:2006/05/24(水) 13:12:19
後方互換性は、言語使用の複雑さの原因であることは確かなんだが
普及の速度には大きく貢献してるだろうから、単純に否定できないと思うんだ。
632デフォルトの名無しさん:2006/05/24(水) 15:52:15
まぁ、実際に携わってみれば誰もが苦しむところだろうな。
633デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/24(水) 20:17:10
D&Eを読めば嫌と言うほど互換性確保に努めてきた様子がひしひしと伝わってくる。
636デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/24(水) 23:17:26
>>637
それだと operator+ を定義していないクラスに + を使おうとしたとき、
plus_trais についてのエラーメッセージが出るよね?それもなんかおかしくね?
639デフォルトの名無しさん:2006/05/24(水) 23:25:01
>>637
わざわざstd::huck::plus_traitsに持っていく意味がわからない。
640デフォルトの名無しさん:2006/05/25(木) 00:19:15
>>638-639
std::hooksに含まれているテンプレートを部分特殊化してくれって意味。
オーバーロード解決に相当する処理をテンプレートで実装する必要があるから、
現行C++の機能だけで完全に実現できるかは分からんけど、
必要ならコンパイラにいくつか機能を追加すればいい。
641デフォルトの名無しさん:2006/05/25(木) 00:41:39
>>640
コンパイラに koenig lookup を追加すればいいってことだな。
642639:2006/05/25(木) 02:39:06
>>640
その意味はわかるけど意図が判らない。
直接operator +を特殊化すればよいのではないかと思った。
643デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/25(木) 02:47:08
>>637
より踏み込んだ議論として,そもそも hook の所有権・所在の
あり方に関する議論もあります.

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

少なくとも「ライブラリ設計の欠点とその補完としての ADL」という観点は
少し視野が狭すぎるような気がします.
645デフォルトの名無しさん:2006/05/25(木) 03:00:06
>>642
operator+ には特殊化するべきプライマリテンプレートがそもそもないです.
また,関数テンプレートの部分特殊化が現行規格に存在しないために,
一般にクラステンプレートに対して関数テンプレートを特殊化することができない,
という事情もあります.クラステンプレートの静的メンバ関数を
わざわざ持ち出すのは,関数テンプレートの部分特殊化の
エミュレーションのためだと思ってもらえれば良いかと思います.
646デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん: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用名前空間を1ヶ所用意して、
特殊な動作は全部そこに書く/書かせるということと同じでしょう。
もちろん名前空間の内部が第三者によって手を加えられる(特殊化ではなく)という問題はありますが。
649デフォルトの名無しさん: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);
650648:2006/05/25(木) 14:43:27
>>649
std::plus::operator()内のa1+a2のことを言っていると思いますが、
いまいちよくわからないので、推測しながら答えます。

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

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

どこを問題にしてるかを明らかにしてもらえれば、
より有意義に議論できると思います。
651648:2006/05/25(木) 14:55:55
よく考えてみたら、ADLがない場合には
two phase lookupの挙動が変わりそうな気がしてきましたが
そこまでは考えていませんでした。
652デフォルトの名無しさん:2006/05/25(木) 16:19:50
>>650
plusからはcomplexのoperator+は見えるけどvalarrayのoperator+は見えない。
646で書いたlazyoverloadというのはoperator+を全部見てくれという意味。
653デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/26(金) 01:10:18
>>655
>現在、boost.rangeなどで使われているものがあります。
>lazyoverloadによる結果と違うのは、
>fundamental type用のフックが定義できるかどうかということでしょうか。

あと、フック関数の定義される場所が
1ヶ所の名前空間になるか(lazyoverload)
複数の名前空間にまたがるか(boost.range)ということでも違いますね。
657デフォルトの名無しさん:2006/05/26(金) 01:38:15
>>655
> そのコードでは、nnn::good<char>()も0を返すはずです。
これですね。勉強になりました。
http://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デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん:2006/05/27(土) 02:46:35
個人的にはこれらの問題は C++ の言語規格あるいは
C++ のライブラリ設計を原因とする固有の問題だとは思っておらず,
(C++ の)汎用プログラミングにおいて非常に重要で魅力的な特性である
"non-intrusiveness" を成立させつつ,なおかつ hook をどう提供するか,
を考える上でかなり本質的な問題だと思っています.
将来的な言語機能の追加も視野に入れてよいならば,例えば
コンセプトに基づく特殊化・オーバーロードといった C++0x での
機能追加があるいは問題解決の1つの糸口になるのではないかと
個人的には思っています.
662デフォルトの名無しさん:2006/05/27(土) 07:30:03
ドラゴンボールにたとえてもう一回プリーズ
663デフォルトの名無しさん:2006/05/27(土) 10:42:33
神様、宇宙人、人造人間、とさらに強い敵を出すために世界観が滅茶苦茶。
技もどんどんインフレになっていき、何が強くて何がよわいのか、序列や使い方
が良くわからん。つまりドラゴンボール状態。
C++ is Dragon Ballというのは、アメリカのカンファレンスで良く聞くジョークでも
ある。
664デフォルトの名無しさん:2006/05/27(土) 14:27:51
(拍手)
665デフォルトの名無しさん:2006/05/27(土) 17:59:55
よく聞くのかよ
666デフォルトの名無しさん:2006/05/27(土) 21:39:59
毎日な
667デフォルトの名無しさん:2006/05/28(日) 23:12:30
『ゴクウが教えるC++』という書籍では、継承を説明するのに、サイヤ人←スーパーサイヤ人と
いう誰でも思いつきそうな例で説明されているらしい。
668デフォルトの名無しさん:2006/05/28(日) 23:18:13
例えで説明してもらわなくても、シンプルなソースと実行結果があれば概念なんて直ぐわかっちゃうのに。
例えての説明で一番分かってもらえるのは、既に知っている人なんだけどな。
しかもC++はあまり難しくないと言う罠。
669デフォルトの名無しさん:2006/06/02(金) 06:35:13
C++の難しさはbetterCとしても使えてしまうところじゃないか?
結局のところ、それでもかなりのことが行えるので、それで満足してしまって
C++の本域や可能性を見失ってしまう。
まぁ、STLにしてもほかのBoot(?)にしてもこれらを使いこなせるようになる前に
大概のことは楽にやってのけられるし、
これらを学んでも実践にどこまで投入していいか?の問題もある。

あと、Cの影響力が強すぎてC時代の財産とかが未だに尾を引いているのかもしれない。
(周りの人間との統合性とかを考えるとやっぱり Better Cぐらいが一番能率がいいのかもしれないし。)
670デフォルトの名無しさん: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デフォルトの名無しさん:2006/06/09(金) 17:11:22
>>672
マルチ氏ね
674デフォルトの名無しさん:2006/08/15(火) 17:53:21
Javaは引数の参照渡しができない
とんでもない駄作
675デフォルトの名無しさん:2006/08/15(火) 19:52:10
>>674
そーゆーこはJava厨が沢山居そうなスレにageで書き込みなさい。
676デフォルトの名無しさん:2006/12/26(火) 18:42:28
C++のマニピュレータはどこもマネしないくらい最強
677デフォルトの名無しさん:2006/12/26(火) 18:57:45
あれ使ったことない
難しいというか・・・鬱陶しいというか・・・
678デフォルトの名無しさん:2006/12/29(金) 02:07:53
アレはどっちかっていうと単にインターフェイス的にもパフォーマンス的にも
駄作(というか失敗作?)だから、みんなにそっぽ向かれただけ。printfマンセー!
679デフォルトの名無しさん:2006/12/29(金) 18:56:34
まああれはあれで、使いようによっては有用で便利なんだが

vector<int> vec_int;
 ・・・中略
cout << vec_int / "," % 3 << endl;

たとえばこれで、vec_intの中身全部を
一行に3要素ずつ( % 3)、カンマで区切って( / "," )
出力なんてことをやったりできる
680デフォルトの名無しさん:2006/12/29(金) 18:58:18
ああ↑はあくまで、こういうマニュピュレータを自分で定義したら、という話ね。
681デフォルトの名無しさん:2006/12/30(土) 01:44:13
そもそもstd::endlもマニピュレータだということを知らない人がかなり多い
682デフォルトの名無しさん:2006/12/31(日) 12:09:20
ライブラリに優劣があるのは仕方ない
iostreamは行き過ぎた抽象というやつかな
ファイルなんかランダムアクセスでいいんだよバカやろう
的なのが提案されてる

ともかくいまさらbindを取り込むDは不憫
683デフォルトの名無しさん:2006/12/31(日) 12:31:17
streamの名前の通りに素直に考えた設計だと思うけどね。
iostreamの出力をiostreamで読み込む。これは簡単。
問題は既存のファイルや人が読みやすいファイルがstreamとして扱いやすいかということだろうよ。
684デフォルトの名無しさん:2006/12/31(日) 14:45:01
iostreamは真似しちゃいけない設計の見本のような気がする。
685デフォルトの名無しさん:2006/12/31(日) 18:07:40
後のSTLともあまり噛み合ってないからな・・・。
686デフォルトの名無しさん:2007/01/09(火) 12:26:43
>>679
>カンマで区切って( / "," )
「<<」、「>>」で感性がマヒしてると、こういう
変態的な演算子を定義しちゃうようになるんでしょうか。
687デフォルトの名無しさん:2007/01/09(火) 22:39:57
templateとBoostで麻痺してるせいか
この程度は、きわめて直感的でわかりやすいと
自分では感じるんだが

まああれだ、素人はだまってろ
688デフォルトの名無しさん:2007/01/09(火) 23:30:20
まあでも他人と共同で書くときには控えようかなと思うよ、俺は。
689デフォルトの名無しさん:2007/01/09(火) 23:49:14
俺も、なんか気づいてみたら趣味で書いてる時と、仕事で書いてる時のコードに
とても同じ人物が書いたとは思えないようなギャップが発生している。






・・・ゴメン、本当は仕事で書いてるコードも基礎部分が極端にトリッキーなコードになってる。
690デフォルトの名無しさん:2007/02/10(土) 18:48:59
C++にclassって必要なの?
structで充分だろ
691デフォルトの名無しさん: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デフォルトの名無しさん:2007/03/03(土) 00:25:38
C++は1ヶ月も見てないととたんに忘れるな・・・
696デフォルトの名無しさん:2007/03/03(土) 02:12:03
スクリプト言語からC++に戻ってくると、
通常型とポインタと参照があることに安心する。
697デフォルトの名無しさん:2007/03/03(土) 17:27:52
あるあるwwww
698デフォルトの名無しさん:2007/03/03(土) 23:55:34
>>694
ツリ?_
699デフォルトの名無しさん:2007/03/04(日) 01:38:17
>>690
十分といえば十分ですね
まったく同じ子とできるわけだから
700デフォルトの名無しさん:2007/03/08(木) 22:08:43
コンテナクラスの継承マンドクセ
701デフォルトの名無しさん:2007/03/09(金) 00:00:58
std::vectorとかか?
あれは継承するような存在ではないから面倒で当然だ。
702デフォルトの名無しさん:2007/03/18(日) 02:46:25
>>684
具体的には?
istreamとostreamがiosを仮想継承して
iostreamがistreamとostreamを多重継承しているところとか?
703デフォルトの名無しさん:2007/03/18(日) 13:03:47
>> と << の気持ち悪いオーバーロードとかもかな。
704デフォルトの名無しさん:2007/03/18(日) 13:52:26
マニピュレータを新しく作るにしても
istream, ostream, iosを修正しなくてもできるの?
705デフォルトの名無しさん:2007/03/18(日) 14:23:27
>>704
できるよ。
やりかたよくわからないけど。
706デフォルトの名無しさん:2007/03/18(日) 15:13:16
わからんのに言うなーー
707デフォルトの名無しさん:2007/03/24(土) 18:12:59
C++の印象:
一貫性より無節操さかな。その無節操なところが難解にさせてるね。
無節操だと思うところは、オブジェクト指向にしても、ジェネリック
プログラミングにしても同じ統一した法則の元で成り立ってないわけで
それが複雑怪奇にさせているという指摘。

オブジェクト指向にジェネリック系の考えを入れてプログラミングを
すればわかるけど、よほど注意深く作っていかないとスパゲティになっ
てしまう。それだけバグ取りが難解になり易い弱点を持ってるね。
バグ取りだけじゃなくて、コーディングに時間がかかるね。効率的な
作成はまず不可能だと考えていいよ。javaでも最近テンプレート的な
動きがあるようだけど、あれは自滅の方向かもしれませんよ。

要するに余計なところばかりに神経を使って作らないといけなくなる
事がC++の問題点だと思うね。慣れたから大丈夫というレベルを超え
ちゃってるんで。
708デフォルトの名無しさん:2007/03/24(土) 18:38:17
>>707
直行してる概念を組み合わせても混乱は無いはずなんだが。
オマエのプログラムがスパゲッティになったのを誰かのせいに
したいだけに見えるぜ。
709デフォルトの名無しさん:2007/03/24(土) 18:47:09
>>708
???
710デフォルトの名無しさん:2007/03/24(土) 19:03:22
インターフェイス実装目的以外での継承禁止
711デフォルトの名無しさん:2007/03/24(土) 19:37:55
707は物事を組み合わせること自体を複雑怪奇になると表現しているように思う。
極論すればいい意味でプログラミングそのものの否定に結びつきそうな感じがする。
712デフォルトの名無しさん:2007/03/24(土) 20:30:09
C++は10年以上昔から存在し、かつ互換性も保ってきたのだから
文法が煩雑になるのは仕方ない。しかしそれだけ昔からあるのに
未だ高級言語の最前線に居り能力を認められているのは驚くべき事だ。
713デフォルトの名無しさん:2007/03/24(土) 21:23:53
むしろテンプレートが導入されたときから始まったと言っても過言ではない。
そのテンプレートが出てきたのもARMが出版された1990年頃。
それ以前から構想していたのだろうし、つい最近出てきたようで随分前からあるもんだな。
714デフォルトの名無しさん:2007/03/24(土) 21:50:35
708は相手にする価値がないと判断したから???としたが。

>>711
組み合わせたら複雑怪奇になるのは当然だが、言いたいのはその組み合わせの
ところがぐちゃぐちゃになってる。

テンプレとオブジェクト指向をまじめに組み合わせて作ってみればわかると思
うけど、かなり先の見通しが出来ない限りスパゲティになるのさ。熟孝がどう
しても必要になってくる。スパゲティにしないように工夫して作るのは結構大
変。この辺がわかってない奴がC++で組むと遅いものしか出来ない。実力差がで
易い言語だともいえるが。

また、必要悪なのかもしれないが仮想関数もスパゲティにしている原因だ。あ
れは極力使わないように工夫する必要がある。

テンプレの発想は凄く良いものだがね。
715デフォルトの名無しさん:2007/03/24(土) 22:02:01
>>714
原因と結果の因果関係が何も説明されてないから、「ふーん」としか思えない。

ダメなプログラマはどんな言語を使ってもスパゲッティを作るし、
優秀なプログラマはどんな言語を使っても良いコードを書く。
それだけのことだろ。
716デフォルトの名無しさん: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デフォルトの名無しさん:2007/03/25(日) 12:25:01
代数的なクラスでもない限り演算子オーバーロードは使わないと思うが
720デフォルトの名無しさん:2007/03/25(日) 12:43:04
> 他の言語との比較は荒れるもとなので意図的に控えてるけどね。

一連の書き込みから、どうも何か煽っているように見えてたんだけど、
荒れるのは嫌なのね。いったい何がしたいの?
721デフォルトの名無しさん:2007/03/25(日) 12:47:21
>>717
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまったか

まずその注意点を書くべきだぞ
722デフォルトの名無しさん:2007/03/25(日) 12:47:44
汎用的なコードを書こうと思ったらいろいろ気をつけなきゃいけなくなるのは
あたりまえなのにねぇ。
723デフォルトの名無しさん:2007/03/25(日) 13:01:52
>>719
stringを含めたクラスでクラス同士の足し算利用するようなことは
十分使えるものなんだが。そんなところまで意図して書いている。
かけ算までは利用する事はあまりないと思うがね。
やはり実際に作ってみないとわかりにくいのかもしれないね。実際に
テンプレートクラスを1から作ってご覧。

>>720
何がしたいの?ってこのスレのタイトルに対しての見解を書いてるだけ
だよ。仮に、C++賞賛スレならばこんな事は書かない。辛口なこと?は
十分受け入れられるスレだと判断したからだ。

同じルールの元で、いろんなパラダイムを持ってきたのではなくて、
つぎはぎの仕方が複雑になってるからだと言ってるわけ、その例が、
オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。

C++ではいろんな事は確かに出来るけど、複雑なルールの元で作られて
るために、保守点検も含めていろんな事が難しくなる。それが、C++人
気が廃れてきた原因だろうね。
724デフォルトの名無しさん:2007/03/25(日) 13:20:02
なんていうか、新しく覚えた手法は全部使わないと気がすまない病気なんじゃないだろうか?
ある程度知識欲のあるプログラマなら一度はかかる病だと思ってるけど。

必要なプログラムだけ書いてればいいんだよ。新しい機能を思いついても、
明らかな必要性がない限りやらないほうがいい。 YGANI ってやつ?
725デフォルトの名無しさん:2007/03/25(日) 13:23:42
批判精神に富んだ青年に
traits技術を駆使してテンプレートライブラリを設計して
いろんな注意点に気がついてしまわせたC++は
魅力的な言語だと言うことだな
726デフォルトの名無しさん:2007/03/25(日) 13:31:10
>>723
> オブジェクト指向とテンプレートの掛け合わせの問題を出しているだけ。

最初っから言われてるけど、さっぱり因果関係がわからん。
人に伝えるつもりなら「やってみれ」とかで済まさずに説明してくれ。
説明する気が無いなら長文 age ウザイからチラシの裏にでも書いててくれ。
727デフォルトの名無しさん:2007/03/25(日) 16:32:14
例えばBoostとか見てみ。何も複雑なことないでしょ?
言語機能を把握しきれなくて複雑に感じるというのなら納得。しかしオブジェクト指向、ジェネリックプログラミングはむしろ構造を素直に記述するために上手く働いてると思うんだけど。さらにテンプレートは最適化にも貢献してる。
同じことCで書こうとしたら大変だよ。
728デフォルトの名無しさん:2007/03/25(日) 16:41:59
ごめんなさい
boostのソース見てて発狂しました
729デフォルトの名無しさん:2007/03/25(日) 16:57:46
>>723が"具体的な"例を持ってくるまで待とうじゃないか
730デフォルトの名無しさん:2007/03/25(日) 17:01:18
まあ文法がひどいというのは納得。ただ機能面で同等なことしようと思ったらC++と大して変わらない言語になるんじゃない?コンパイラ任せの部分が増えると書くのが楽になっても機能面でのマイナスが多少はでるよね。

コンパイラより賢い人間がいるかぎりC++のような言語はなくならないんじゃないかな。
731デフォルトの名無しさん:2007/03/25(日) 21:38:42
言語仕様でなるべくスパゲッティにならないよう努力してもいいんでない?
C++は悪い意味で好きなように書け過ぎると思うんだ。

Javaの多重継承できないとか
Pythonのインデントみたいな試みは是非はともかく嫌いじゃない
732デフォルトの名無しさん:2007/03/26(月) 00:58:32
C++は凡人のための言語じゃないと思うんだよね.
研究心のある人が使えばいいのさ.
大きな自由度を残しておく事で,そこから新しい可能性を見つける事ができるんだよ.
Boostのライブラリとか見てるとすごく思うけど,C++はいろんな新しい考え方を生み出す実験台としての役割がすごく大きいと思う.
書いている人の好奇心を煽るとてもいい言語だと思うけどな.

実際にアプリケーションを書く言語として適しているかということとはまた別だけれどもね.
733デフォルトの名無しさん:2007/03/26(月) 01:41:20
C++の開発動機に"Better C"がある以上、Cとは可能な限り互換性を
保たねばならず、従ってC時代由来のアナクロニズムは除去できない。
ifブロックを中括弧なしで書けないようには出来ないわけだ。

他の新しい言語と比べると酷い言語のように見えるけど、
実際のところ禿が掲げた理念を大前提として考えれば、
今のC++は可能な範囲で望み得る、かなり良いものだと思う。

そもそもC++は大規模オブジェクト指向言語の元祖であって、
新しいパラダイムを開拓しつつも互換性を重視する立場からは古い仕様を変えられない、
そう考えると今までのC++が何か大きな間違いを犯したとは思えない。
C++のこういう点が気に入らないなら素直にDでも使うべきなんだろうと思うよ。
734デフォルトの名無しさん:2007/03/26(月) 03:09:53
>>733
C++を嫌って自由度を追いかけたら、DかLispに行き着くだろうな。
Dもネイティブコンパイラを持ってるようなLispも速度的には速いですから。
735デフォルトの名無しさん:2007/04/03(火) 21:17:20
>>1
ってよりか、C++で書かれたソフトってやたら重くね?
オブジェクト指向って重いの?
736デフォルトの名無しさん:2007/04/03(火) 21:27:48
何も考えないと重くなる。
でもC++自体は重くならずに済むよう努力したほう。
そうでなければC++が普及することは有り得なかったと禿は言っている。
737デフォルトの名無しさん: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デフォルトの名無しさん:2007/04/04(水) 00:38:41
C++でもATLでウインドウ制御すれば瞬発力があるソフトが書けるの。
MFCなどを使うと一呼吸動作が遅くなる。

だから言語の問題じゃない。
741デフォルトの名無しさん:2007/04/04(水) 00:51:26
ちょっとしたデータ変換ツールを作ってみたら、CでもC++でも殆ど同じアセンブラコードになった。
C++の方がテンプレート関数のお蔭でソース自体は短いのだが。
742デフォルトの名無しさん:2007/04/04(水) 08:24:20
>>741
禿もCがC++の最大の敵と言っているくらいだし、
Cと同じように書けばCと同じ機械語になるのは当然。
743デフォルトの名無しさん:2007/04/04(水) 21:48:57
一呼吸とか変なこといってんなよ
744デフォルトの名無しさん:2007/04/05(木) 06:20:47
何が変なのかさっぱり。
MFC擁護のバイトか何かですか?
745デフォルトの名無しさん:2007/04/05(木) 07:56:19
言葉が変なんだよ。きっと。
746デフォルトの名無しさん:2007/04/09(月) 15:42:24
templateを使った時にコンパイラの吐くエラーがカオスにな
747デフォルトの名無しさん:2007/04/11(水) 21:26:52
Cの方がトータルでみて生産性高いと感じる俺は
まだまだC++を使いこなせていない
748デフォルトの名無しさん:2007/04/11(水) 21:41:56
>>747
C++から入った身としては、そういうことがいえるほどCを使いこなせている人が居ることに驚く(強意表現だが)
すくなくとも、普通に使ってる分には、C++ のほうが適当に作ってても修正とか聞くし、
真面目にやるときも設計の目処が立ちやすいし、少ないコードで楽に進められるし、名前問題含め使い勝っていいと思うのだが、
参考までに、どんな所がCの方が生産性が高いのか教えて欲しい。
749デフォルトの名無しさん:2007/04/11(水) 22:15:57
俺の感性に合うっていうのかな。
Cでゴリゴリ書いてると魂磨いてるって感じ。
750デフォルトの名無しさん:2007/04/11(水) 23:02:56
たまにCを使うと、変数宣言がブロックの先頭でしかできないのが苦痛。
地味なところでは、for (int i = 0;とかbool型などがないのも嫌になる。

せめてC99を使いたい。
751747:2007/04/11(水) 23:09:43
誰だ勝手に答えているのはw

>>748
自分の場合、某悪評スクリプト言語からCに入ったので
関数主体で構造化できるってだけで感動しているレベル。
グローバル変数メインでサブルーチンで直接値を操作するのが
当たり前だったもんで…
とてもじゃないけどCを使いこなせているとすら言えない

C++の(というかオブジェクト指向の)クラスとかインスタンスという概念は
面白いとは思うけどオブジェクト単位でデータと関数がまとまっているよりは
命名規則(型ではなく用途で)をしっかりつけたグローバルな変数と関数を
一元管理した方が把握しやすいっていうか楽に感じる。
オブジェクトで分けるよりはシーンで分けた方が直感的というか。

趣味プログラマとしてはメソッド使わなきゃ属性にアクセスできないみたいな
データの隠避にも大した利点に感じない。
そんな間違いすることあるのか?って思ってしまう。

まぁスクリプト言語に浸りきった弊害なのと
C++をひとにみせても恥ずかしくないレベルまで習得するのが面倒なだけやけど。
constとかstringとか楽なところだけ使いつつスクリプト時代のようにダラダラと
手続き型で書いている。
Cの方がってよりも手続き型の方がって話だ。すまんす
752デフォルトの名無しさん:2007/04/11(水) 23:15:13
データの隠避は複数人での開発では特に重要
1人だとありがたみを感じないのも無理はないと思う
753デフォルトの名無しさん:2007/04/11(水) 23:37:36
一月前の俺と今の俺は他人
754デフォルトの名無しさん:2007/04/11(水) 23:37:57
データ隠蔽とかはブロックごとにファイル分けて
構造体に突っ込むことでまだなんとかなるけど
テンプレートのアルゴリズムはもうCではやる気が起きなくなるな。
755デフォルトの名無しさん:2007/04/12(木) 08:45:57
>>751
それ、全部C++でもできることじゃん。
要は、「Cの方が高い」じゃなくて、「C++である必要が無い」だな。
756デフォルトの名無しさん:2007/04/12(木) 09:11:09
まずnamespaceから
757デフォルトの名無しさん:2007/04/12(木) 16:58:53
まずC風に軽く組んで、
「ここの機能まとめたら分かりやすくなるかも」見たいな感じで
徐々にOOP「風」に組み直していくやり方でいっぱいおっぱいですよ
758デフォルトの名無しさん:2007/04/12(木) 19:34:38
自分も早く再利用可能なクラスをいっぱい作って
実際のプログラムは部品をドッキングさせるだけで良いみたいな状態になりたい
759デフォルトの名無しさん:2007/04/12(木) 20:42:41
結構気合い入れて「俺ライブラリ」を作るんだけど、
なかなかうまくいかないねえ、こう、なんというか、
「近未来の自分にすんげーフィットする汎用性と機能のバランス」ってやつは。
760デフォルトの名無しさん:2007/04/14(土) 02:42:16
各種文字列クラスとの相互変換テンプレートだらけで
俺ライブラリは統一性が無い。文字コード含めてわけかわらんよ。
比較関数だけでも20種類はある。
761デフォルトの名無しさん:2007/04/29(日) 02:53:25
難しいとは思わないけど
無駄に複雑
馬鹿みたい
762デフォルトの名無しさん:2007/04/29(日) 03:04:04
馬鹿みたいというか
馬鹿が複雑に書いてるんだ
でもビャーンのハゲは髪だと思う
763デフォルトの名無しさん:2007/04/29(日) 03:38:18
禿はインタブーで「わざと複雑にした」っつってる死ね
764デフォルトの名無しさん:2007/04/30(月) 00:06:44
頭の悪い奴には使いこなせない言語だよな、ホント。

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

やっぱ自分ひとりで組むのならC++だな
766デフォルトの名無しさん:2007/04/30(月) 22:29:37
Javaのgenericにはしょんぼりした記憶があるな
C++的なものを求めるのが間違っているんだけどさ・・・
767デフォルトの名無しさん:2007/04/30(月) 22:42:48
boostがやばすぎるぐらいに便利だからなぁ・・・
逆にC++より簡単な言語ってないんじゃね?って思えてくる
768デフォルトの名無しさん:2007/05/02(水) 21:35:05
boostって何がそんなに良いの?
導入すっかな
769デフォルトの名無しさん: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デフォルトの名無しさん:2007/05/03(木) 10:23:39
lexical_castやpolymorphic_downcast、numeric_cast、noncopyableあたりも地味に便利
772768:2007/05/03(木) 10:40:46
うむ
ありがとう
何を言ってるのかさっぱりな漏れにはまだ早いことは良くわかった。
ようやっとSTL使い始めたばかり
773デフォルトの名無しさん:2007/05/03(木) 18:47:17
コンパイル遅すぎなんだよ糞が
774デフォルトの名無しさん:2007/05/03(木) 18:54:15
何のための分割コンパイルだ、プリコンパイルヘッダだ
775デフォルトの名無しさん:2007/05/03(木) 23:16:29
速度なんてボチボチ、イラネな世界になってきたから
Rubyとかで良いんでない
776デフォルトの名無しさん:2007/05/08(火) 02:49:46
最近は専門用語が増えすぎ。
あーぎゅめんとでぃぺんでんとねーむるっくあっぷ
かりおすりーりかーりんぐてんぷれーと
えんぷてぃーべーすおぷてぃまいぜーしょん
えたーなるふぉーすぶりざーど
777デフォルトの名無しさん:2007/05/08(火) 03:16:12
クトゥルーさげ
778デフォルトの名無しさん:2007/05/09(水) 13:56:22
いあ いあ はすたあ!
779デフォルトの名無しさん:2007/06/02(土) 07:50:12
全部の機能を使うのはたいへん
780デフォルトの名無しさん:2007/06/19(火) 18:43:40
C++のどこがBetterCなんだ
むしろWorseCだ
781デフォルトの名無しさん:2007/06/19(火) 19:20:44
ローカル変数宣言がブロックの先頭に縛られないこと
特にforなどで変数宣言できること

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

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

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

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

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

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

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

>書いたときの意図は伝聞らしい
自分自身の意図を推量する事は無いんだから「らしい」は使えないよ。
826デフォルトの名無しさん:2007/09/01(土) 07:02:24
んなこたーない。使えるらしい。
827デフォルトの名無しさん:2007/09/01(土) 08:32:51
いやらしい
828デフォルトの名無しさん:2007/09/01(土) 10:03:02
推量でも伝聞でもいいが、理由も続けないと有益な議論にならないじゃん。
2chでそんなことを期待するほうがあほですかそうですか。
829デフォルトの名無しさん:2007/09/01(土) 10:41:22
自分が何もしないのに場が勝手に有益になるのを期待するのは確かにあほだね。
でもそれって2chに限らないよ。
830デフォルトの名無しさん:2007/09/01(土) 11:05:23
一般論としてJAVAの方が習得が容易だといわれているんだから
JAVAの方が生産性が高いって話
まぁ後からでた言語の方が生産性高いのは当然だろうけど

統計取ったのか?とか突っ込まれる悪寒
831デフォルトの名無しさん:2007/09/01(土) 18:25:34
>>824
>流石マ板
オイ
832デフォルトの名無しさん:2007/09/02(日) 08:52:09
ごめん
マ、ム、は回転させると同じだからよく間違えるんだ。
母の胎内のようだ
833デフォルトの名無しさん:2007/09/02(日) 09:49:20
>>830
> 統計

「"言語名" 人材募集」でググったのが統計になるらしいぞ。
2ちゃんで見たから間違いない。
834デフォルトの名無しさん:2007/09/03(月) 10:44:30
C++は難しくない。ややこしくて複雑なだけ。
その複雑さを理解してだけで得意になってる馬鹿もいるし
835デフォルトの名無しさん:2007/09/03(月) 13:00:39
刃物は危なくない。切れたり刺さったりするだけ。
836デフォルトの名無しさん:2007/09/03(月) 14:47:41
*気を付ければ*
837デフォルトの名無しさん:2007/09/03(月) 15:00:22
もちろん安全装置だっていろいろあります。
838デフォルトの名無しさん:2007/09/25(火) 10:30:13
C++何年も使ってたのに1年ブランクあるとと書けないな
Cならそんなことないのに
839デフォルトの名無しさん:2007/09/26(水) 09:26:36
C++に不足してるのは名前付き引数だな。
オプション引数の順番いちいち覚えなきゃいけないとか、
テンプレート持ってる割に古臭い。
boostのいびつさと言ったら。
840デフォルトの名無しさん:2007/09/26(水) 09:52:53
それね、検討されたらしいんだ。
でも、新しいパラダイムが来るわけでもより型安全になるわけでもないとか、
関数を引数名の分だけ呼ぶ側と呼ばれる側の束縛が強くなるとか
そもそもそれが欲しくなるほど引数が多いなんて下手な証とか、
反対意見が多くて却下されたという過去があるんだ。

参照:D&E 6.5.1 キーワード引数
841デフォルトの名無しさん:2007/09/26(水) 10:29:08
その割にはC99にはあったような気が……
842デフォルトの名無しさん:2007/09/26(水) 13:46:14
名前付き初期化子のこと?配列と構造体限定でよければ確かにある。
843デフォルトの名無しさん:2007/09/26(水) 14:56:14
↑アホ
844デフォルトの名無しさん:2007/09/26(水) 17:12:58
↑ニンニク
845デフォルトの名無しさん:2007/09/26(水) 23:22:34
名前付き引数?
仮引数に変数名つけるじゃん
846デフォルトの名無しさん:2007/09/26(水) 23:24:54
と思ったら順番関係なくなるのか
それはいいな
847デフォルトの名無しさん:2007/09/27(木) 00:28:50
Python使ってるとキーワード引数の便利さはよくわかる。
C++でもクラステンプレートのPolicyとかでは出来るのにね。
848デフォルトの名無しさん:2007/09/27(木) 05:52:03
boost.paramいやなんでもない
849デフォルトの名無しさん:2007/10/19(金) 23:09:47
boostってまだ標準ちゃうしなぁ
850デフォルトの名無しさん:2007/10/23(火) 09:53:49
テンプレートのチューリング完全性が意図したものではなく
のちに発見されたものだというのがC++の複雑さを如実にあらわしてる

その複雑さの果ても解明されようとしているが
C++0xが新たなカオスを持ち込んでくれる

好き物プログラマーとしてはたまらないね
851デフォルトの名無しさん: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デフォルトの名無しさん:2008/01/11(金) 09:25:02
タイプミスマッチや型候補なしのエラーの嵐は、conceptが導入されれば緩和される。
853デフォルトの名無しさん:2008/01/21(月) 20:41:39
854デフォルトの名無しさん:2008/01/21(月) 22:38:18
C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない?

・・・あっ、それがJavaか・・・
855デフォルトの名無しさん:2008/01/21(月) 22:46:22
Java厨こんなところろにまで出張乙
856デフォルトの名無しさん:2008/01/22(火) 00:15:54
C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない?

・・・あっ、それがC#か・・・
857デフォルトの名無しさん:2008/01/22(火) 00:18:18
C#厨こんなところにまで出張乙w
858デフォルトの名無しさん:2008/01/22(火) 00:59:50
C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない?

・・・あっ、それがCか・・・
859デフォルトの名無しさん:2008/01/22(火) 01:04:00
C厨こんなところにまで出張乙w
860デフォルトの名無しさん:2008/01/22(火) 01:07:05
C++を難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない?

・・・あっ、それがDか・・・
861デフォルトの名無しさん:2008/01/22(火) 01:08:44
D厨こんなところにまで出張乙w
862デフォルトの名無しさん:2008/01/22(火) 03:43:35
2chを難解にしてるのは、めったに使わない機能や、
よく知らずに使うと危険な機能がいっぱいあるから。

それらの機能をなくしてしまえば、いい言語になるのじゃない?

・・・あっ、それが1chか・・・
863デフォルトの名無しさん:2008/01/22(火) 03:45:14
ニコ厨こんなところにまで出張乙w
864デフォルトの名無しさん:2008/01/22(火) 08:57:22
もはやなにがなにやら
865デフォルトの名無しさん:2008/01/22(火) 10:27:51
>>860
Dは逆だろw
866デフォルトの名無しさん:2008/01/26(土) 16:49:48
>>860
そういう言語を目指してたはずのJAVAやC#は同じ道を歩んでるしな
よほどなオプソ開発者でもない限り、大幅仕様変更や削減は難しいからねぇ・・・
867毛の生えたブリーフ:2008/01/26(土) 19:48:37
オマンコを難解にしてるのは、めったに使わない大陰唇や、
よく知らずに使うと危険なクリトリスがいっぱいあるから。

それらの機能をなくしてしまえば、いいオマンコになるのじゃない?

・・・あっ、それがアヌスか・・・
868デフォルトの名無しさん:2008/01/26(土) 20:02:03
アヌス厨こんなところにまで出張乙w
869デフォルトの名無しさん:2008/01/27(日) 16:22:19
なんなんだ
870デフォルトの名無しさん:2008/01/27(日) 16:26:48
純粋に言語としては
C++が際立ってJavaやC#より難しいとは
もう言えないんじゃないか
DにいたってはもうC++より難しいのではw
871デフォルトの名無しさん:2008/01/27(日) 21:39:17
JavaやC#は、大規模な標準ライブラリが付属してるから簡単に感じるんだな
C++だと、標準ライブラリの提供する機能が少なすぎる

設計は美しいんだがな。STLとか。
872デフォルトの名無しさん:2008/01/28(月) 00:17:38
C++もBoostが(ゆっくりとだけど)
よその言語が持っているようなものを(ようやく)用意し始めている。
スレッドとかシリアライぜーションとかネットワークとか。

XML読み書きも欲しいな。
873デフォルトの名無しさん:2008/01/28(月) 09:42:08
domやsaxならいっぱいあるだろ
874デフォルトの名無しさん:2008/01/28(月) 21:06:18
拡張可能な暗号化・ハッシュ・圧縮インフラが標準で欲しいな
875デフォルトの名無しさん:2008/01/28(月) 21:10:37
C++のめったに使わない機能ってなんだろう
virtual継承とかprotected継承ぐらい?
876デフォルトの名無しさん:2008/01/29(火) 01:22:18
export
asm
template template
valarray
ダイグラフ
877デフォルトの名無しさん:2008/01/29(火) 04:09:45
asmは結構使ってるなぁ
俺のレベルって低いんだなw
878デフォルトの名無しさん:2008/01/29(火) 04:23:55
asmはCPUをハードウェアレベルでいじりたい時に使うよな
879デフォルトの名無しさん:2008/01/29(火) 09:22:13
>>874
C++にstream入出力ライブラリは標準でないの?
880デフォルトの名無しさん:2008/01/29(火) 18:09:50
VC++なんで__asmです。
881デフォルトの名無しさん:2008/01/29(火) 20:26:41
template template は使えない期間が長過ぎたんで道具箱に入ってなかった
でも明日から使うよ
882デフォルトの名無しさん: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デフォルトの名無しさん:2008/02/18(月) 19:11:46
>>874
それらの機能は時代とともに変化するし、ターゲットによって最適な手段が異なるので
C++のように幅広く利用される物に標準として搭載するのはいかがなものか、と思う。
885デフォルトの名無しさん:2008/02/18(月) 21:29:36
ハッシュは採用されるだろ
886デフォルトの名無しさん:2008/02/18(月) 22:14:35
>>874が言ってるのはたぶんMD5とかSHA-1のような暗号的ハッシュ関数のことだと思う。
887デフォルトの名無しさん:2008/02/18(月) 22:23:28
ライブラリ化するのはポリシークラスや関数オブジェクトをパラメータ化すれば容易いし、
拡張も容易だろうけど、時代の趨勢に標準が追いつかなそうだな
888デフォルトの名無しさん:2008/02/18(月) 22:37:02
C++みたいに組み込みからサーバまで使われるようなものに、
ハッシュや暗号化のようなコスト、耐久性にいろいろとバラエティの取れるものを標準搭載してもなぁ、って気はする。
889デフォルトの名無しさん:2008/02/18(月) 22:43:23
個人的には、フリー以上ホスト未満の分類をもう1つか2つ増やしてもいいと思う。
890デフォルトの名無しさん:2008/02/19(火) 00:07:14
CRC、zlibくらいはあってもいいんじゃないかという気は
891デフォルトの名無しさん:2008/02/19(火) 00:08:53
ライブラリを独立した規格にすればいいのにと思う。
892デフォルトの名無しさん:2008/02/19(火) 00:13:29
というかそういう声が多かったからBoostができたんじゃないかと
893デフォルトの名無しさん:2008/02/19(火) 03:40:18
そしてTR1へ
894デフォルトの名無しさん:2008/03/08(土) 08:44:52
言語の細かいとこにあまり神経使いたくないね。
設計とかテストとか神経を使う重要なとこは他に一杯あるんだから。
重要でないが細かいとこに注意を向けるあまり肝心のことが抜けてるってのは
ありすぎるほどある。
思い当たるだろ。
たぶん、個人の注意力の総量は一定なんだろう。
あるとこに注意を向ければ別のとこがおろそかになる。
それだったら重要度の高い部分に優先的に注意を向けたほうがいい。
しかし C++ だとこれが出来にくい。
言語に落とし穴が多いからいやでも注意しなければならない。
895デフォルトの名無しさん:2008/03/08(土) 21:16:27
>>894
抽象的過ぎてわからん
896デフォルトの名無しさん:2008/03/08(土) 21:34:24
>>894
落とし穴というのは適切な比喩でないな。道路脇の崖とでもいうべき。
道に慣れてる人間にとっては危険でもなんでもない。
897デフォルトの名無しさん:2008/03/09(日) 00:24:54
初心者的な疑問なんだけど、
クラスとかからメンバを呼び出すときに
.を使ったり->を使ったりするのって、具体的にどんな理由で2種類あるんでしょうか?

->を使うところをすべて.で済ますようなことをすると、ソース的にありえないところが出てきたりするのですか?
898デフォルトの名無しさん:2008/03/09(日) 00:43:26
class foo {public: void memFunc();}があるとして、foo * bar = new fooしたときに
bar->memFunc()する代わりに(*bar).memFunc()することに何の躊躇いもないならば、
どうぞご自由にアロー演算子を使うことをおやめくださいませ。
899デフォルトの名無しさん:2008/03/09(日) 00:45:08
struct A foo;
foo.val1 = 1;
strct B * bar;
bar->val2 = 2; // 初期化していないポインタへの演算ざけどそこらへんは気にせずに・・・
900デフォルトの名無しさん:2008/03/09(日) 01:41:50
>>897
ポインタかそうでないか
901デフォルトの名無しさん:2008/03/09(日) 01:59:41
そうじゃなくて、なぜ実体/参照は.で、ポインタは->なのか、ポインタにも.でアクセスできる文法にしなかった理由は何なのか、ということじゃないかな。
902デフォルトの名無しさん:2008/03/09(日) 02:13:02
それはつまり
class Foo = new Foo();
という文法を認めろ、ということか・・・
903デフォルトの名無しさん:2008/03/09(日) 02:14:40
何書いてんだ俺w酔っ払いすぎだwww

foo f = new foo(); という文法を認めろ、ということか・・・

に訂正_| ̄|○
904デフォルトの名無しさん:2008/03/09(日) 02:19:06
T1 p;のとき *p がT2&を返すような実装をしてると
p.aの意味が不明になるでわかるかな
905デフォルトの名無しさん:2008/03/09(日) 02:23:12
>>904
演算子オーバーロードできるC++で破綻するのはわかるんだけど、.演算子と->演算子はCからあるよね。
906デフォルトの名無しさん:2008/03/09(日) 02:29:07
Dでは左辺がポインタでもそうでなくても常に . 択一だったはず。
文法上はそれでも成り立つのはわかる。
でもなんでCでは区別するのかという答えは出てこないけどな。
907デフォルトの名無しさん:2008/03/09(日) 02:47:07
演算子をそう定義したから、としか言えないのかな。
ドット演算子はポインタでない変数のメンバを参照するもの、という定義があって、
これをポインタ変数に適用しようとすると、dereference operatorの機能も入るから、
演算子を同一としてはいけない、と。
ドット演算子を「変数のメンバを参照するもの」と定義すれば、ポインタでもそれ以外でも
使えるようになるけど、Cではそれをしなかった。

そう考えるとC++のoperator overloadingって結構変態的な機能なんだね。
908デフォルトの名無しさん:2008/03/09(日) 02:57:33
そうだなCでだと、p.a.a と p.a の区別をどうするか
って言えばわかるかな
909デフォルトの名無しさん:2008/03/09(日) 03:08:14
あんまり自信ないけど
要は誤って別の型にキャスト->ウヒャ
を嫌ったんじゃないかと言う気がする
910デフォルトの名無しさん:2008/03/09(日) 03:52:27
当時のコンピュータとコンパイラの性能とあわせて
コスト的に違うものだという意識が働いてたんじゃないのかね。
a = aa.bb.cc.dd と
a = aa->bb->cc->dd じゃ
生成されるコードが全然違うからね。

と思ったが、配列とポインタの扱いを考えると違うか。
a->bが(*a).bという記法の省略であるというのはどこでも説明されているけど。
911デフォルトの名無しさん:2008/03/09(日) 09:06:35
つーかメンバのポインタだけ -> なんて記号使っておきながら
なんで他のポインタはアスタリスクだらけなんだろうか
912デフォルトの名無しさん:2008/03/09(日) 22:59:15
>>910
古い本には「ポインタを何回たぐる」といった表現が頻繁に出てきて、
間接アドレッシングのコストが強く意識されていた様子が読み取れる。
だから.と->でのコストの違いは大きな要因だったと思うよ。
ましてstructやunionは入れ子にしてaa.bb.cc.ddみたいに
アクセスするのが前提っぽい設計だし。
913デフォルトの名無しさん:2008/03/10(月) 09:26:47
Cの基本は値渡し。
構造体と配列は値渡しができないのでポインタ渡し。
そこで、構造体と配列については簡易にアクセスできる演算子を作った。

とか言ってみる。
914デフォルトの名無しさん:2008/03/10(月) 10:48:42
>構造体と配列は値渡しができないのでポインタ渡し。
???
915デフォルトの名無しさん:2008/03/10(月) 13:09:45
>>914
配列は値渡しできないだろ。
K&R時代は構造体も値渡しできなかったよ。
916デフォルトの名無しさん:2008/03/10(月) 14:56:14
いや、配列はわかってるよ。構造体もできない時代があったのか・・・失礼。
VBでbyvalで渡せなくて「なんだこの糞言語は!」って思ったこともあったなぁ・・・
917デフォルトの名無しさん:2008/03/10(月) 19:00:56
正確には「配列の先頭アドレスを値渡し」だな
配列の中身は参照渡しに見えるけどな
918デフォルトの名無しさん:2008/03/11(火) 00:07:31
むしろ、Cは全てにおいて値を渡す
その値は変数の中身だったり(変数や配列を参照する)アドレスだったりする
と考えるのが正確ではないか
919デフォルトの名無しさん:2008/03/11(火) 09:34:06
>>918
その程度のことをもっともらしく語るなw
構造体、配列はその中身を渡したくても渡せなかった。
本当は中身を渡したくても、不本意ながらアドレスを渡すしかなかった。
だから[]や->を作ったと言うことでしょ。
920デフォルトの名無しさん:2008/03/11(火) 09:52:05
その意味では、「全てにおいて値を渡す」ってのは低レベルの言語では極当たり前の話だよね。
プロセッサにおいて、何がしかの値以外のものを渡すって概念がないんだから。
921デフォルトの名無しさん:2008/03/11(火) 12:53:43
でもこの基本中の基本が理解できなくて、
ポインタを覚えようとしている初心者は発狂する
解説書が悪いんだが
922デフォルトの名無しさん: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;
というようにするわけです。
そうすれば、ポインタは2通りの表記法(* ->)が使えるということに
なって表記上の柔軟性が増加するわけです。*表現は算術演算の*と
まぎわらしい場合があって多用されるとウザい場合が確かにありますね。
923デフォルトの名無しさん:2008/03/12(水) 00:12:58
>>922
->の意味わかってる?w
924デフォルトの名無しさん:2008/03/12(水) 00:32:29
昔、Cマガだったか、operator < とoperator -を定義してop<-methodを実装するよーな
話があったような・・・
925デフォルトの名無しさん:2008/03/12(水) 00:33:07
=>と->があって+>が無いのはおかしい

と一瞬思ったがそもそも=>なんて無かった
926デフォルトの名無しさん:2008/03/12(水) 00:37:30
op>-.-<qo;
927デフォルトの名無しさん:2008/03/12(水) 00:38:23
・(中黒)やx(エックス)ってオペラントにはならんよな
内積と外積をですね。あと|A|とか
928デフォルトの名無しさん:2008/03/12(水) 00:39:20
そもそも中黒はASCIIに無いだろ
929デフォルトの名無しさん:2008/03/12(水) 01:39:56
C/C++で使われない記号ってある?
キーボードをざっと見渡して$と@はソース上には出てこないかなと思ったけど・・・
930デフォルトの名無しさん:2008/03/12(水) 01:50:14
->
=|>
===||>

だんだん貫通力が上がっていくぞ!
931デフォルトの名無しさん:2008/03/12(水) 02:00:33
>>929
@は使う
932デフォルトの名無しさん:2008/03/12(水) 02:02:06
$もつかえるよ
933デフォルトの名無しさん:2008/03/12(水) 06:32:21
>>929
「`」はない
934デフォルトの名無しさん:2008/03/15(土) 11:15:53
>>894
ポリモーフィズムが実行されるために、オーバーライドする関数にはvirtualをつけるべき
オブジェクトスライシングが起こるからスーパークラスの変数にサブクラスの変数を入れないようにすべき
例外を投げる時はポインタではなく値で投げるべき、受ける時はオブジェクトスライシングしないように参照で受けるべき
メソッドの実引数の値を変更したくない時で、組み込み型の場合は値渡しで、そうでない場合はconstリファレンスで定義すべき、
メソッドの実引数の値をメソッド内部で変更したい時で、組み込み型の場合はリファレンスで、そうでない場合はアドレス渡しで定義すべき…

意識的にそうしないという選択ができるという利点はあるのかもしれないけど…
こういうことに気を使いながら、処理内容の方に注意の力点を置いて実装…自分にはムリだ('A`)
935デフォルトの名無しさん:2008/03/15(土) 11:47:53
>>934
>メソッドの実引数の値をメソッド内部で変更したい時で、組み込み型の場合はリファレンスで、そうでない場合はアドレス渡しで定義すべき…
逆じゃないのか?
936デフォルトの名無しさん:2008/03/15(土) 13:16:28
>>935
逆でした('A`)
937デフォルトの名無しさん:2008/03/15(土) 13:20:14
C++の参照渡しキモ杉
938デフォルトの名無しさん:2008/03/15(土) 13:21:55
>>935-936
その区別、意味あんの?
呼び出し元のオブジェクトいじってほしいときは全部参照渡しでよくね?
939デフォルトの名無しさん:2008/03/15(土) 13:39:59
> ポリモーフィズムが実行されるために、オーバーライドする関数にはvirtualをつけるべき
C#もそうじゃない。Javaはそうじゃないけど。
> オブジェクトスライシングが起こるからスーパークラスの変数にサブクラスの変数を入れないようにすべき
基底クラスのコピーコンストラクタ・代入演算子はprivateにしろ。
これはこれで意識しないといけないことだけどさ。
>例外を投げる時はポインタではなく値で投げるべき、受ける時はオブジェクトスライシングしないように参照で受けるべき
受けるほうはともかく、投げるほうに意識する必要あるか?
940デフォルトの名無しさん:2008/03/15(土) 14:01:07
ポインタで例外を投げるってのは、
throw new Exception(hoge)
って事だから
941デフォルトの名無しさん:2008/03/15(土) 16:01:24
うん。何も考えなかったら、throw Exceptionって書くだろ。
Java/C#のくせでついうっかりってならともかく。
942934:2008/03/15(土) 22:02:44
元ネタは詳説C++です。

>>938
まず、コスト的にはリファレンスでもポインタでもそれほど変わらないということがあって、
組み込み型の場合、メソッド内で変更可の場合は引数をポインタとすることで、
変更不可の場合の呼び出し
f(a)
変更可の場合の呼び出し
f(&a)
となり、呼び出している箇所を見ることでf()が引数の内容を変更するかどうかのヒントを得ることができる
というのがその理由です。まあ好みの問題かもしれません。

後関係ないけれどNULLを渡す可能性がある場合はリファレンスではなくポインタにしなければならない…ってのも考慮しなきゃいけないですね…

>>939
コピーコンストラクタを作るのが面倒で、じゃあポインタ渡しすればいいじゃんと思ったりとか…?
自分はJava一辺倒なので、C++のプロジェクトに放り込まれたら慣れるまでは落とし穴にはまりまくりそうです。慣れてもどれか1つ忘れてポカしそう…
C++でバリバリコード書きまくるというのには憧れるんですが…。
943デフォルトの名無しさん:2008/03/15(土) 22:50:44
>>942
コピーコンストラクタを設けるかどうかは、どちらかというと設計の問題。
一般的に継承してポリモーフィックに扱うクラスはコピー不可とすることが多い。
あった、ちょうどこういう話。
http://www.ogis-ri.co.jp/otc/hiroba/technical/CppDesignNote/

Clonableにするかどうかというのが近いといえば近いのかな。
Javaはあまりやったことないけど。
944デフォルトの名無しさん:2008/04/03(木) 18:43:11
顧客より保身のほうが大事なヤツなんていねーよ
馬鹿じゃねーのwwww
945デフォルトの名無しさん:2008/04/03(木) 20:16:55
この世に馬鹿がいることがわかってるなら、「いねー」なんて口が裂けても言えないはずだが。
946デフォルトの名無しさん:2008/04/03(木) 22:02:23
>>945
ヒント:嫌味
947デフォルトの名無しさん:2008/04/03(木) 22:06:03
社会保険事務所とかに行くとそんな感じの人が一杯いるよ! ><
948デフォルトの名無しさん:2008/07/10(木) 18:59:33
>>943
つ CopyConstructible (20.1.3 [lib.copyconstructible])
949デフォルトの名無しさん:2008/08/28(木) 23:13:44
ほしゅ
950デフォルトの名無しさん:2008/09/09(火) 18:57:31
必死に時間や金かけてC++学んだ連中には悪いが、俺もC++はゴミだと思う。
習得に時間かかりすぎ。コードの可読性低すぎ。バグ産みやすすぎ。
自由度高すぎて他人のコードが理解しずらいったらありゃしない。
そのうえ未だにSTL周りなどコンパイラの互換性すら怪しい。
言語仕様の設計思想は理解できなくもないが、業務では使いたくない。
趣味で使いたい奴だけが使う言語にとっととなりさがって欲しい。
忌々しきStroustrup。
951デフォルトの名無しさん:2008/09/09(火) 19:11:27
業務で使うならC++
日本語つかうのに、言語学から始める必要はない
STLが怪しいなら使うヘッダとコンパイラを統一して問題がないという判断の出たやつ仕えよ
952デフォルトの名無しさん:2008/09/09(火) 19:42:59
>>950
こういう事を言う奴に限ってC++使った事ないんだよな
953デフォルトの名無しさん:2008/09/09(火) 19:59:23
× 使った事ない
○ 使えるようになる前に挫折した
954デフォルトの名無しさん:2008/09/09(火) 20:02:49
なんだそうか
単に頭悪いだけじゃん
955デフォルトの名無しさん:2008/09/09(火) 22:53:52
STLの互換性が悪いというあたりから挫折した時期がわかるな
956デフォルトの名無しさん:2008/09/10(水) 03:15:04
C++はそのあまりにHENTAIチックに入り組んだ構造がたまらなくおもしろいんだよ〜。超遊べるよ〜。
957デフォルトの名無しさん:2008/09/10(水) 06:09:20
>>955
ここ5年くらいの間にC++始めた人間だと、
ニュアンスがよくわからないだろうな。
958デフォルトの名無しさん:2008/09/10(水) 16:46:49
>>957
まぁ、もう歴史の闇の中だよなその辺の事柄はw
今はもうわざわざSTLPort入れたりしなくていいんだぜ、いい時代じゃないか
959デフォルトの名無しさん:2008/09/10(水) 17:00:41
STLportがtr1に対応してないと話にならない時代になってきたな
960デフォルトの名無しさん:2008/09/10(水) 17:02:33
あの・・・うちまだVC6なんです・・・
961デフォルトの名無しさん:2008/09/10(水) 17:09:08
窓から投げ捨てろ
962デフォルトの名無しさん:2008/09/10(水) 21:20:10
>>956
同意ですよ
C++の変態コードのレベルは果てが見えない・・・
最高だ・・・
そんじょそこらの素人を黙らせてしまうようなコードを
書けたときには快感すぎてしびれる・・・
この言語はまさしく神
963デフォルトの名無しさん:2008/09/10(水) 22:18:05
そしてLispのマクロの変態さを見たらどう反応するか。
964デフォルトの名無しさん:2008/09/11(木) 06:45:54
2chに居ると誰もが使える言語だと錯覚していたが
C++使っているというだけで驚かれることに驚いた。
965デフォルトの名無しさん:2008/09/11(木) 06:59:19
ずいぶんレベルの低いところにいるんですね。
966デフォルトの名無しさん:2008/09/11(木) 11:49:49
うちで販売しているパッケージはほとんどがvc製だから、
しーぷらできませんじゃ話にならんお。
もっともテンプレートマジックは敬遠されるけども。

最近はJava製品も手掛けるようになったけど、
swingは社内的にも客的にもうけがわるいw
967デフォルトの名無しさん:2008/09/11(木) 18:52:08
C++で書いてCより生産性上げられる人材なんてそうそう集まらんしな。
968デフォルトの名無しさん:2008/09/11(木) 19:00:05
C++のほうが生産性が高いのは当然
そうでないやつは給料泥棒かアマチュア学生
969デフォルトの名無しさん:2008/09/11(木) 19:03:25
Windows (GUI) プログラム、DirectXプログラムに比べたらC++の文法など大したことがない。
STLやオブジェクト指向は強力でバグが出にくい設計になっている。 
利用する側としてのバグね。もともとあったら知らんが。
970デフォルトの名無しさん:2008/09/11(木) 19:04:40
>>968
同意なんだが現実はそうはいかんぜ。
今度のプロジェクトで
「構造体とかポインタとかわかるか?
なら○○よりは上だな」
って言われたぜhya!!
971デフォルトの名無しさん:2008/09/11(木) 19:15:05
すくなくともSTLは、標準のC言語よりも、易しく生産性が高いぞ。
とりあえずSTLで作っておいて不都合が出たら、C言語やアセンブラやAPIをいじくればいい。
機械に近いほど難易度が増すのが普通だろ。
機械語よりアセンブラは易しく、アセンブラよりC言語、C言語よりC++が易しいはずなんだよ。
わざわざ難解な言語つくっても意味がない。 利用者はすべてを習得する必要はない。
C++の文法のほとんどは、STLを実装するためにあるようなもの。
972デフォルトの名無しさん:2008/09/11(木) 19:28:44
>>971
高級言語になれば単純に難易度が下がるのか?
単純に文法レベルでの話ならc++よりよっぽどcやasmの方が覚える事も
少ないし、習得も早いと思うぞ。
973デフォルトの名無しさん:2008/09/11(木) 19:30:21
難易度を、同等のものを生産するのにかかる労力で測った場合。
974デフォルトの名無しさん:2008/09/11(木) 20:00:05
なんだか、「漢字は何万文字もあるけど、アルファベットは
26文字しかないから、漢字やめようぜ」みたいな頭悪さを感じる
975デフォルトの名無しさん:2008/09/11(木) 20:05:23
>>974
習得工数と実際にやる内容を天秤にかけたら
漢字を捨てるのも十分ありじゃね?
976デフォルトの名無しさん:2008/09/11(木) 21:57:57
仕事の度に漢字を勉強しなおすならそうなるな
977デフォルトの名無しさん:2008/09/11(木) 22:25:26
習得の難易だけで人々の使用言語が決まるのならば、
世界標準語は英語ではなくエスペラント語になっていただろうな。
978デフォルトの名無しさん:2008/09/11(木) 22:37:43
>>975
言語の習得にかかるコストを「工数」という形で定量化して見積もっている
会社ってあるの?
979デフォルトの名無しさん:2008/09/11(木) 22:52:16
>>978
や、そこまで厳密な意味でいったわけでもないんで突っ込まれても困るが。
「手間」でもいいよ。

今のプロジェクトC++で書かれているんだけど
1つのクラスに5000ステップくらいの長編小説が書いてあってそれを保守せんといかん。
C++がどうとかいう以前の問題の気もするが…
980デフォルトの名無しさん:2008/09/12(金) 11:44:15
以前の問題ですな。
981デフォルトの名無しさん:2008/09/13(土) 11:34:48
とりあえず勃起する
982デフォルトの名無しさん:2008/09/13(土) 11:36:50
俺の裸みて鎮めろ
983デフォルトの名無しさん:2008/09/14(日) 12:17:55
>>979
それに近いことは、やる場合もある。
たとえば、ある機能を使うときにまたは機能の選定とかをやるときに、
これを採用すると学習コストがかかるから、ここはやめて。。。みたいな。
あと、チームの何名かを研修に参加させるために、それを見積もったりとかさ。
984デフォルトの名無しさん
ごめん>>983>>978だった。