この板見てるとＣ＋＋良いって意見ばっかなんだが

ドトネトのSystem::Generics::Listはヒドいとおもた。

QValueVector< QString >

STLのコンテナとアルゴリズムよりエレガントな設計のコンテナなんて見たことねーぞ

>>506
そもそも、MFCの前身が作られた時期には、STLは未だ承認されていない。

ぁ ゃι ぃ

MSC7.0が1992だっけか

>>572
美しさと効率は、必ずしもいっちしない

でも、STLってそんな効率悪い実装をせざるを得ない仕様だったっけ？

中身までちゃんとみてないが、vectorは単に[]で
アクセスするだけでも、ただの配列の2倍以上は遅い。
ａｔ()だとさらに遅い。
DEBUGビルドだとさらに10倍くらい遅い。

何でもかんでもvector使うのはさすがにアレだな

馬鹿がいる。

>>578

んなぁーこたない。

>>573

そうだとしてもSTL完成した時点で揃えりゃいいだろ？

>>580
こんな感じで時間計ると、Debugビルド(最適化なし)で100倍くらい差が付く。
最適化ありのReleaseビルドでも3倍は差がつくんだが、何か俺が間違ってるのか？

std::vector<int> vec(2);
int ary[2];
DWORD time1, time2;

ary[0] = 1;
vec[0] = 1;

time1 = GetTickCount();
for(int i=0; i < 10000000; i++) {
ary[0] += 1;
ary[1] = ary[0];
}
time1 = GetTickCount() - time1;

time2 = GetTickCount();
for(int i=0; i < 10000000; i++) {
vec[0] += 1;
vec[1] = ary[0];
}
time2 = GetTickCount() - time2;

>>581
何故MFC3.0以上にもなって互換性犠牲にして使われてもいないSTLに擦り寄る必要があるんだ?

vectorがはやったったぞ
#include <iostream>
#include <vector>
using namespace std;
main(){
std::vector<int> vec(2);
int ary[2];
DWORD time1, time2;

ary[0] = 1;
vec[0] = 1;

time1 = GetTickCount();
for(int i=0; i < 10000000; i++) {
ary[0] += 1;
ary[1] = ary[0];
}
time1 = GetTickCount() - time1;

time2 = GetTickCount();
for(int i=0; i < 10000000; i++) {
vec[0] += 1;
vec[1] = ary[0];
}
time2 = GetTickCount() - time2;
cout<<time1<<" "<<time2;}

>>583
おまいばかじゃね？
Ｍ＄がＭＦＣを亡き者にしてドトネトに逝こうしてるのに。
ＭＦＣ終焉。

1994年にドトネトはない

STL.NET

>>587
劣化パチモン

>>582
Visual C++か？
それならSTLの仕様ではなく、実装の問題。
セキュリティ対策で範囲チェックが入るから、素の配列に比べて遅くなる。
_SECURE_SCLを0に定義しておけば範囲チェックは無くなる。
また、&vec[0]でポインタを得て操作するという手もある。

俺もVC++ 9でそのコードをコンパイルしてみたが、
/O2や/Oxだと配列のループは消滅する。
ダミーの関数呼出を入れて、_SECURE_SCL 0定義してやれば/O2や/Oxで両者互角だった。

Cの関数と違って_sみたいな見た目の違いが出ないから見た目わからないけど、
C++ライブラリも安全対策へ注力しているのが近頃のVC++。

>>589
なるほど、そういうことだったのね。

MSってこれだから嫌なんだよ
なんでもかんでもMSルールで染め上げようとするんだもの

何もしなければ、セキュリティ対策がなっていないと叩かれるネタになる。
やってもやらなくても叩かれるMS涙目ｗ

人気者だから仕方ないんじゃね？信者もアンチも人気の証。

Dinkumware?(もう忘れた。確かVC++に付属してる奴)それともSTLport？
自分は直接試してないから強くは主張できないけどね。

でも、STLってかなりよくできてると聞いたけど最適化についてはわからない。
案外、ライブラリによってはIntel C++と相性が悪いかもしれないどろうけど
どうだろ？

少なくともValarrayよりはましだと思うけど。

↓qsort対std::sortネタが振られる

ここでPrologに一票ｗｗ

>>596
プロローグ？プロログ？どっちが正しいん？

Windowsには期待するけどVC++には期待しません。

Vi$taはｶﾞｶｰﾘだたので、Win7頑張って。

というか、at()があるのにoperator[]も範囲チェックするってどんだけ馬鹿なの。

iostream ｷﾓﾁﾜﾙｽ

>>599
それだけプログラマが当てにされない現実。

>>597
プロログ

>>599
>>601
at()は範囲チェックで例外、operator[]はassertじゃなかったっけ。

>>603
なるほどね。メモリ保護に任せると割当単位によってはSEGVにならないし、reserveして書くみたいな馬鹿コードも検出できるからまあ確実ではあるか>assert

>>582
その手のテストは最適化効いてコード消されてて速くなってる場合もあるぞー。
実際俺のとこだとそのintの配列はReleaseだとアセンブリはごっそりなく
なっててループしてない。
vectorの方はoperatorとか通るからか、勝手な最適化は効かないでご丁寧に
ループしてる。

てかさ、vectorの利点というのは実体が&vec[0]から連続して
並んでいることが保障されていることでしょ。

だから、普通はループ処理とかで、vec[0]=とかやらないって。
ポインタ取り出して操作するに決まってるじゃない。

>>582
参照されないint配列のfor操作とかは最適化されて消える。
後ろで配列内の値を参照(sum取って表示とか)するようにすると同一になるはず。
というか試してみたがvectorとint配列の[]で速度に差は出ない。

vectorのポインタが変わってしまうのは要素数が増えたとき、
でしたっけ？

先頭の要素が削除されたら？

>>608>>609
いいえ。

要素数がリザーブサイズを超えたときに再配置かな。

stringの[]遅い・・
string 7813
vector 1594
char[] 1578
こんな感じだった

VC6においては、
stringの reference operator[](size_type _P0)
{if (_Len < _P0 || _Ptr == 0)
return ((reference)*_Nullstr());
_Freeze();
return (_Ptr[_P0]); }

vectorの[] reference operator[](size_type _P)
{return (*(begin() + _P)); }

いつまでもふたりこのままで
いっしょにいたいとねがうように
それはほんのいっしゅんで
ひかるほしにかわってゆく
だれよりもいちばんちかくで
えがおのゆくへをだきしめたい
めぐりあえたこのきせき
ずっとずっとゆめのなかからさめないように

いいそひだえめず？

でょほほりのあず

抗しろああしろざま

けっきょく九割くらいはMFC書いてるだけだろ

M$の中の人ですか

流れぶった切るけど、ネームスペースのエイリアス切れる機能が便利だと思う。
シンボル名単体か、フルパッケージ名をタイプするしか選択肢がない言語に戻ると
ちょっとキツい。
結果的に、同時に使いそうなクラスのこと考えて結構長いクラス名になりがちな気がするし。

流れどころか、最近は澱んでた印象。

>>620
マクロ定義すれば、なんとかなるんじゃね。

そういえば、Javaで１００以上もある分岐条件とかってどうやって表現する？
具体的にはネットワークプログラミングで受け取ったパケットの先頭8ビットを見て処理を分けるような場合。
CやC++だったら、構造体と、関数ポインタがあるから、例え分岐条件が1万あったとしても

for (int i = 0; i < sizeof(構造体A); i++) {
if (構造体A[i] == receiveData) {
構造体A[i].処理();
}
}

ってかなり短く表現できるじゃん？これって他の言語だとどうやるんだ？
スレ違いかもしれんが、前々から疑問だった。

あ、しばらくCを書いてないからバグってるや。
if分の比較は以下に修正。、

if (構造体A[i].data == receiveData) {

>>623
Windowsメッセージのように数千あるメッセージをswitch/caseで処理するのだ。
これが最速。後は好みでその上にクラスでもかぶせりゃいい。

>625
返事ありがとう。私もJavaではif/elseもしくはswitch/caseで書いている。
でもその方法、最速なのはわかるけど、コード量増えるよね。
コピペミスとかもおきやすいし。
条件が増えてcaseの後にダラダラと条件がつくと理解しにくいと思う。

構造体で条件を一元管理すると、Excelからコピペで持ってこれるし、
ソースで見ても、きれいで見やすいし
条件が一個増えたとしてもすぐに対応可能だから、
なんで構造体使えないのかと思うわけですよ。

条件が一個増えた場合↓
if ((構造体A[i].data == receiveData) && (構造体A[i].state == state)){

100以上ある、switch/caseで条件の数がcaseごとに違うのとかって
バグっているんじゃないかと不安になる。

構造体、クラスを比較しろよ

>>623
for (int i = 0; i < クラスA.length; i++) {
if (クラスA[i].isEqual(receiveData)) {
クラスA[i].処理();
}
}

その構造体の関数ポインタに処理をセットする部分はswitch/caseと同程度の
コード量になるはずじゃないのか？

メッセージマップみたいなのをExcelの仕様書から自動生成するんじゃね？

switch/caseを自動生成させても同じじゃないのか？

for if を展開してコンパイラに渡せばよい

>628
クラスAの配列ってことは、receiveData と比較する、
クラスAのインスタンス変数dataに値を設定する箇所が必要だよね？
あと、呼ばれるメソッド名を、きれいにクラスに渡せる？

>629
struct test
{
int a[2];
void (*pf[])();
};

const struct test test1[] = {
　　　　　　　　　　　　　　 {0x0001, funcPointer1},
　　　　　　　　　　　　　　 {0x0002, funcPointer2},
　　　　　　　　　　　　　　 {0x0003, funcPointer3}
　　　　　　　　　　　　　　};

分岐条件が増えたとしても

const struct test test1[] = {
　　　　　　　　　　　　　　 {0x0001, 0x0003, true, false, funcPointer1},
　　　　　　　　　　　　　　 {0x0002, 0x0003, true, false, funcPointer2},
　　　　　　　　　　　　　　 {0x0003, 0x0003, true, false, funcPointer3}
　　　　　　　　　　　　　　};
どんどん増えていくけど、私には一覧で見えるのですごく見やすい。

C++なんてどんどん使われなくなってくだろ

LLになれるとC++なんて二度と使いたくないって気になる。

普段は LL で、性能が気になる所だけ C のモジュールを作るというのが良いよね
LL 拡張専用言語として使うなら C++ より C の方が効率的だし活用範囲が広い

C++ってLispだなって思うｗ

Lisp くらいパースが簡単で、Lisp くらいマクロが強力で、
REPL が備わっていたら良いんだけどね。

Ｊａｖａのガーベッジコレクションは欠陥設計
そもそも、スタティック領域を持つことが
許されているんだから、誰かがグローバル域に
オブジェクト参照持ち続けてたら、どんどんメモリーを
圧迫していく。
最悪なことにＪａｖａはメモリー管理を意識しなくて良いような
嘘がまかり通って、知的障害者がぼこぼこオブジェクトを作っては
放置していく。
はっきり言ってC/C++の方がよっぽどまし。
素人を使ってＷＥＢアプリとか作るって頭おかしいでしょ（ｗ

＞６２３
Ｃ/C++の関数ポインターってvirtualで表現できるだろ
根本的に抽象化してないオブジェクト設計がおかしい

LLとC（C++）があればJavaの出番はないんじゃないかって最近思う

趣味でLLを作るときはC++が良い感じｗ

>>639
他の言語を貶しても誰も褒めてくれないよ。
不服なら、その言語スレで、解決方法を提案してみなされ。

>>633
interface func {
  public abstract void func();
}
class test {
  public int data;
  func func;
  public test(int data, func func){
    this.data = data;
    this.func = func;
  }
}
class func1 implements func {
  public void func() {}
}
final class funcs {
  static final test[] test1 = {
    new test(0x001, new func1()),
    new test(0x002, new func2()),
    new test(0x003, new func3())
  };
}

> LLになれるとC++なんて二度と使いたくないって気になる。

中高生向け学習用言語で誰でも書けるhtml出力コードを安い労働単価で
書き続けていてください。

>>645
中高生相手にムキになるなよ。

LOGOの時代がきます。

>>647
http://dolittle.eplang.jp/index.php?Logo%BE%F0%CA%F3%BC%BC
>LOGOは過去の言語です。ロゴ坊もすでに開発を終えていますので、
>興味のある方は後継のプログラミング言語「ドリトル」など新しい言語をお使いください。

過去の言語になってるじゃねーかｗｗｗ

そういう評価の質は評価者の質と対になっている物だよな。
ドリトルを勧める評価者の評価ってどうなんだろう。

>>649
しらねｗｗｗ

OS開発に採用された時点でC/C++はもう勝ち組言語。
OSのあらゆる機能に容易にアクセスできるわけで。

実際ここ数十年は結局、オブジェクト指向とか関数型とか簡単とかを
売り文句にした一山いくらの言語がはやりすたりしただけで、どれも
C/C++の薄いラッパーに過ぎないね。

つまり FFI で OS のあらゆる機能に用意にアクセス出来る Lisp は最強と言う事か。
ラッパーも要らんし。確かに C は OS 開発言語として不動の位置を占めているが、
C++ は C があるからいつ居なくなっても困らんな。

>>649
変な意見も、無知が見れば結構まともっぽく見えちゃうから危険だよな。

>>652
Lisp最強にするには、まずはLispマシンはやらせるとっからじゃね。

JavaもC#も、夢を叶えようと頑張ってC++の仕様から色々引き算してシンプルさを意識したけど、
だんだん「広く深く濃く」使われていくうちに、現実をちゃんと見なきゃいけなくなって
結局はどんどん複雑怪奇になっていってる。

「俺が世界の支配者ならこの世は理想郷に限りなく近いのに」と思ってた思春期のボーヤが、
働き始めて数年経ってようやく、自分がツバ吐きかけてたものがいかに「現実を切り抜ける」ために
有効だったか思い知り始めたという感じ。

まあWin32APIもLinuxのシステムコールもインターフェースがCだからね。
C/C++以外はどれもラッパーが必要になる。

ただまあ難しい事やらない限りは言語なんてどれでもできること同じだし、
なんつーか言語なんてOSとかアルゴリズムを利用するためのインターフェースに
過ぎないんだよね。

>>655
そこで妥協したら負けかなと思ってる。

>>656
それはそうだけどさ、デモ用の簡単なツールとか、自分が楽するための
ツール作成にはＬＬって限りなく便利。で、Ｐｅｒｌはもともとそのための
言語じゃなかったのだろうか。

Ｊａｖａが目指した理想は素晴らしいものだったけど。

>>655
それでもC++よりは余計な機能が削ぎ落とされてていいと思う

>>656
WindowsはPASCAL呼び出しじゃね。

>>659
君の思うC++の余分な機能ってなによ？

そもそも作るものによって言語変えること自体がすげー不便。
せいぜいC++とPerlくらいでいいよ。

>>659
余計な機能は使わなければいい。C++はそれができる。

たとえば、パフォーマンスが理由で特定のメンバ関数を仮想関数にしたくないならそれが自由にできる。
文字列処理も、パフォーマンスを理由に固定長のバッファにしたいとか、好きなレベルの処理を自由に実装できる。
自由なんだ。

>>662
Perlはなぁ・・・本当に自分しかソースさわらないもの限定ならいいけどさｗ

>>661
C++というものの性格上しょうがないとはいえ、まずdelete
ようはガベージコレクションのありなしで、これを解決するには
ライブラリの知識を得る必要がある
そして、STLでも頻繁に使われる演算子オーバーロード
これも可読性を下げる
個別にあげつらうことは出来ないが、複雑怪奇な文法のせいで
IDEのエラー検出機能や補完機能が制限されるのもマイナス

>そして、STLでも頻繁に使われる演算子オーバーロード
>これも可読性を下げる

バカまるだし

>>660
typedef追っかけてくと最終的に__stdcallに辿り着くよ

>>660
stdcall
引数のスタックの積み上げは右から左＝C(cdecl)
スタックポインタの引き戻しはサブ側で行う＝PASCAL∴可変長引数は×

>>666
標準入出力の<<などは、意味を知ってるから便利に思えるものの、
初見で見たら多くの人は戸惑うのではないか？
演算子オーバーロードの乱用を誘発する悪しき例とも言える
演算子オーバーロードの乱用で可読性が下がるってのは良く言われてること
馬鹿だけが言ってるわけではない

>>665
演算子のオーバーライドが可読性を下げるというのは、使い方間違ってないか？。
deleteもガベージコレクタが無いから、ライブラリが補ってるって事で、余計な機能ではない。ライブラリの選択で必要な機能だけを追加してるのだ。

>>670
逆に言えば、ガーベッジコレクションがないということで、deleteや
ライブラリのポインタの機能など余計な機能をくっつけざるを
得なかったってことだろ

余計な機能は使わなければいいって言うが、他人が使う以上そうも言ってられないんだよな

言語の組み込み機能が増えるよりいいだろ
実際不自由してないし

C++が設計されたときにもうGCはあったの。C++が参考にした言語は
GCがついてて遅すぎたの。実用性を重視してGCを外したの。で、一番使われる
ようになったの。
コンピュータ速くなってきたからJavaはうっかりGCで設計しちゃったの。
でも、また結局遅い遅いと叩かれちゃったの。
だからね、言語みたいな基本的なところは速くなくっちゃいけないの。

>>671
ガベージコレクションってよしあしじゃない？プログラマが本当の意味で、
メモリを管理できない。スマートポインタで十分なように思う。

で、プログラマって本当にいわれるようにメモリが管理できないもの？
メモリリークで痛い目見た経験はあるけど。本当に数えるくらいしかない。

>>674
そんな経緯はどうでもいい
C++が今現在余計な機能を持っていると思うことに変わりはない

>>675
例えば、スマートポインタも、auto_ptr、shared_ptr、weak_ptrといろいろあって
それぞれの特徴、使い方を覚えなくてはいけない
その時点でかなり「余計な機能」だと思う
正直言って、weak_ptrだけで十分
あと、良し悪しなのは当然で、余計かどうかは個人個人の主観でしかない
もともと好き嫌いを話してるだけなのだからこれは当たり前

俺はoperator<<<とかoperator===とかもOKにしてもらいたいくらいだぜ

System.out.print("Hello");
より
cout << "Hello";
でおｋ

>>677
まあ確かに<<は便利な点もあると思う
しかし、<<の意味がわかってる今だからいいだけで、
最初は戸惑うだろうし、真似して変な文脈で<<を
使い出す馬鹿が続出するという欠点もある

C++は多重継承とテンプレートがどうかと思うな
二つを組み合わせたりするから意味わからん

>>676
経緯を知らないからお前の知識が浅いんだと思う

>>680
ちなみに、C++と設計と進化は読んでて、ガーベッジコレクションの
経緯は知っていたが

>>676
それはGCとか余計な機能が無いって事ではないのか？

>>682
どっちを余計と捉えるかという主観の問題だね
量的にも後者にまつわるルールの方が多いと感じるが

くくって書くととエラーになる

なんかGCを基本機能に入れるかどうかなんて古典的な議論だな。
新しい言語作るからどうしようって言うんならわかるが、C++はなしだし、
Javaはありだしって事実について言いあってなにを発見したいんだ？

>>675
GC をプログラマの負担低減だけで捕らえるとそうなる
スループットの向上やフラグメンテーション対策と考えると
必要性が見える。なんで鯖向けに向いているかも

<<676
今はauto_ptrしか無いぞ。
あと次の標準ではauto_ptrはdeprecatedになるから安心しろ。

んなこた知ってるよｗ

力比べでつか？

>>686
なるほど。オモシロイ。

http://edocs.beasys.co.jp/e-docs/jrockit/geninfo/diagnos/tuning_tradeoffs.html

こっちのほうがええか
http://www.ibm.com/developerworks/jp/java/library/j-jtp01274/

C/C++用のガベージコレクタライブラリなんてのもあるのな。

あの，友人が「プロトタイプベースの言語最高」とか
叫んでいたんですが，それってクロージャで代用
できたりしませんか？

C++の次の規格でにラムダ式とクロージャが使えるように
なったら，「C++最高」って叫んでもいいですか？

それって何ていう、「C++ってCで代用できたりしませんか？」


できません。

boostのラムダは苦しすぎるしうまいこと言語に入れてもらいたいもんだね

プロトタイプ・ツール作成用にLL、本格アプリ用C++の２つマスターすればよいでFA？

>>696
それだけでいいって言われたら、あなたは満足してそれだけで学ぶことをやめてしまう
だろうから、「それだけでは不十分」といってあげる。俺って、なんて優しいのだろう！

皆はやっぱBASICからはじめたんだよね。もちろん。

>>696
C++ の代わりにその LL の実装言語 or 拡張言語をやっておくと良いよ
ま、大抵は C だけど

>>696
それなりの経験があると、C++のノウハウが高いのでプロトタイプ作るのに
言語変える方がめんどくさいんだよな。
えーっとPerlでBase64はどうするんだったっけな・・CPANのなんかだっけ・・
より、OreBase64 b64(buf); b4.Decode();とか、えーっとRubyでソケットは
Socket.new(・・第一引数はSocket::AF_INETだっけ・・・あれ？selectとか
使えたんるんだっけRubyは？、えーっとよりOreSocket s; s.Connect("google");
とかになっちまうんだよな。
さらにプロトならGUIつけることも多いから困るんだよな。PerlでGUIか・・
VBの方がいいかな・・っつーとやっぱ、よいしょOreWindow w; w.Show();
ってやるんだよなあ。

昔、ノウハウとかライブラリが貧弱だったころはスクリプトよく使ってたん
だけど、最近はプロト作る用途でもほとんど必要なくなっちまったよ。
まあ俺みたいな10年選手のおっさんにはこういうやつ結構いるんだがさ。

「プロトタイプベースの言語」という言葉を理解しているレスが
一つしかない。気がする。

と693が言ってるぞ

ざっくりプロト作るぜ、のプロトじゃねーよ。
おっさんだから仕方ないとは思うけど。

察するにJavascriptの話だろ、693は。

よく読めよ・・696はざっくりプロトの方なわけだが

おっさんごめん

だてに禿げてねーんだぞ

>>696のプロトの話は>>693のプロトの話と関係ないよね。

>>700のおっさんの言ってることは分かるなあ。
昔はよくC++と俺ライブラリで何でもやってた。
最近はC#と.NETで事足りてるから俺ライブラリ使わないけど、
.NET禁止環境に配布するときだけは引っ張りだすこともある。

そういう高機能な俺ライブラリにかわるようなもので
一般的な奴ってあるの？

ATL/WTL
MFC

gladeはどう?
mm版もあるようだが、わざわざmm版使うくらいならqtでいいような気もするけどw

そういやトロールテックどっかに買収されたな。

qtっていくらすんの？

[KDE/Qt]Qtについての疑問を教えあうスレ 3
http://pc11.2ch.net/test/read.cgi/tech/1194158506/

>676
>>正直言って、weak_ptrだけで十分
shared_ptr使わないでweak_ptrだけ使うって・・・
boostのそれを指しているのならば意味が分からん。

誰か解説ヨロ。

shared_ptrなんてバグの温床だから使うなよ。


shared_ptrは悪くないだ、俺が悪いんだ、、、

>>714
weak_ptrに汎用的な機能を持たせるって意味だろ

代入しようとすると deep copy してくれる scoped_ptr ってないの？
自分で作ったの使ってるけど，標準的なのがあれば
そっち使おうと思って．

optionalでどうよ

>>1
良くネーよ、複雑になりすぎてまともに使える人間が居ない
挙句、オブジェクト指向がわかって無いからできないとか抜かすアホまで現れ始める始末だし。
そんな使い方したらC++はJava以下じゃねーかとか思いながら、そんなタコが現れるのも無理も無いと思うので
C#なりJavaなりにとっとと移行すべきだと思うのである。

>>717
どうやって作ったの？
代入演算子がアレなC++では無理があると思って諦めていた、ちょっと教えてくれ

>>676
組み合わせて使う事を前提にした weak_ptr のみで一体何をしようというのだ、使い道つーか使い方ワカンネーよ
設定すら出来ないポインタに存在価値はあるのかwww

だから全部weak_ptrにして汎用的にするんだろ

>>721
悪い事は言わないからもっともっと使いこなしてみろ、使い方次第ではガベコレ方式より遥かに強力な shared_ptr/weak_ptr だ
その能力は、単なる生存管理にとどまらないという事を知るべきだ。
お前みたいなタコが増えてくるから、もうJavaでいいよなんて事になるんだよ。

RAD使わなきゃdelphiが一番難しいんだろ？

DelphiからRADを取っちゃったら何も残らないじゃないか

pascalコンパイラとしては使えるだろう。

>721
>>だから全部weak_ptrにして汎用的にするんだろ
意味がわからん。
weak_ptrはshared_ptrと対になって、尚且つ使い分ける事に
意味があるのに。もっと馬鹿にも分かるように説明してくれ。

>>726
基本的にインスタンスは全部自動変数で、参照はweak_ptrで渡せば、
スコープで寿命が来ても参照が残らない。

>>721じゃないけど、shared_ptrも何もかも、ポインタが全て
weak_ptrに統一されて、Javaが実装している参照のような
弱い参照を用いた実装になるってことじゃないかな

Javaの参照だって4種類もあるよ。

>>717
特定のクラスのサブクラスしか格納できないboost::anyみたいなもの？
需要あると思うけど、ネーミングをするのが一番難しいと思う。
名前さえ決まれば、boostに追加されそうな気がしないでもない。

>>719
代入演算子じゃなくて、テンプレートコンストラクタでどうにか汁。

>727
「汎用的にする」の一例という解釈でOK？
「全部weak_ptrにして」のほうも解説よろ。
特に「全部」が何をさしているのか。

>728
Javaの弱参照は通常参照と区別して使用することに意義があるんじゃないの？
それが正しければshared_ptrと使い分けできない（統一された）weak_ptrに存在意義は
ないとおもわれ。

なんか電波がピピっときて理解できた気がする。
C++の生ポインタが全部weak_ptrになっちゃって、あるweak_ptrをdeleteしたり、
参照してた自動変数がスコープアウトで消え去ったりした場合、
同じオブジェクトを参照してるweak_ptrがみんな０になるとちょい便利かも
みたいなはなしじゃないのかひょっとすると。

>>732
正解
電波のスキルがうｐしたねｗ

>>732
どんだけランタイム情報が充実してんだよｗｗｗ

自動変数がスコープアウトで消え去ったのを weak_ptr で捕捉するのは
そのままでは無理では？捕捉される側のオブジェクトのデストラクタなりで
何らかの notification を行わないと

>>735
そうだね。
被参照オブジェクトの側でweak_ptrのリストを持っていて、
デストラクタでweak_ptrに通知するしかないね。

だったら言語仕様かえて、型なんてなくしちゃえよ

>>737
ぶっちゃけ俺言語にでも走った方が楽しいかなと思うときもある。
でもそういうのは仕事で使えないからなー。

weak_ptrとかshare_ptrとか見ると
namespace pointer
{
　class werk;
　class share;
}
の様にアンダースコアで区切られ微妙な名前になるより、
長くても名前空間で区切られる方が有り難いと思うのは、俺だけ？

>>739
uint8_tとかwchar_tとかと同じ類

>>740
クラスと単純な型では違う気ガス。
基本的な型は、どこのスコープからでも見えた方がよいからね。

>>741
作った人は、そういう基本的な型と同じカテゴリーだと考えていたのだろう。
好みの問題だから、どちらが正しいという論争に答えはないよ。

全部 shared_ptr で循環参照に対して対策を施すというのならまだ話がわかるが、全部weak_ptrって、、訳わからんな。
脳みそばらして中身覗かせてくれよ

どっちも同じに見えるのは気のせいか
違いを解説してくれ

>>744
理解しているとはとても信じられないが、仮に理解しているとして、だ
まず、weakとsharedの意味を辞書で引いてどちらがふさわしいか考えてみろと

>>745
ただのポインタ(char*など)　＋　weak_ptrで循環参照が解決すると思ってたんだ
俺が間違ってたのか？

>>746
少なくともboostのweak_ptrは、boost::shared_ptrに格納されているものにしか機能しない。

コピーは自由にできるが一つでも消えたら全部道連れということかね。
それって便利か？

auto_ptr以下だなw

単にdeleteしたりスコープから外れたりして、
使えなくなったオブジェクトを扱おうとすることを弾けるというだけだな。
デバッグ時には無条件に便利かも。

コンテナにauto_ptrすら入れられない
ライブラリが標準名乗ってるのがそもそもの間違い。

確かに、なんでshared_ptrが最初から入らなかったのか不思議。

>>752
templateに対する理解が進んだのはSTLがでてからそこそこ経った後だから仕方なかろう。
ATLの時代ですら、不十分な理解のまま巨大ライブラリを作って、あの有様だし。

コンパイラ製作者であるハゲの人の意図すら超える内容があった template は今後も重要な概念になると思いますよ。
破滅的になってきたC++が維持できるかどうかは別として

>>753
そう言われると、あの時代にSTLが作られたということが奇跡的に思えてくる。
アロケータとかアレなところはあるけど。

書籍で読んだ限りではSTLは作られたんじゃなくて別の言語から移植された物なんだよ、どこかに歴史がかかれていないかな？
元々はオブジェクト指向ベースのクラスライブラリになる予定だった。
さらにSTLで納得できない人たちが集まって作ったのが boost
templateの驚愕の事実はLokiライブラリの作成と、そこでのメーリングリストのやり取りより始まる。
それにしても不思議、不思議だな、僅かな規則を決めたら、そこから知らない事実が次々とでてくるというのは。
言語やライブラリというものは、人間の作ったものだけけど、
このテンプレートと来たら、まるで元々そこにあって、自分たちはそれを掘り出しているような気分になる。
彫刻家が仏像を彫るときに、仏像は木の中にいる、自分はそれを掘り出しているだけだという
なんとなくその気持ちがわかる。

>>756
STLはAdaから移植された物らしいね。
それはあまりに巨大な物だったのでC++の言語仕様に取り入れる
時にバッサリコンパクト化した。

wikipedia見たけど、メタプログラミングやりたかった奴が実現できる環境がAdaしかなかったのでそっちで初めたけどC++に鞍替えしたという感じじゃん。
どっちも同一人物が作ってるし。

Cという言語があったその昔、std::vectorみたいに育つ配列作ったら、上司に思いっきり笑われたのを今でも思い出す。

ttp://up2.viploader.net/upphp/src/vlphp139808.jpg

Cにvectorはいらない。

仕事で人のCのコードを見ると必ず自前のvectorが使われている。
一度メモリリークしているものも見たことがある。
指摘したら客からクレームはないとスルーされた。

そこで始まる前から終わってしまったC99の出番ですよ

C99によりC++とCの互換性が無くなってしまった。
そりゃ終わるだろ。

レベル１：　育つ配列として使える構造体（vector）を作る
レベル２：　vectorをポインタで受け渡しする
レベル３：　vectorに関数ポインタを持たせる
レベル４：　確保したメモリ領域を管理し、使用量をデバッグできるようにする
レベル５：　安全に、全ての確保メモリを解放できる
レベル６：　様々なアルゴリズムに特化したvectorを作る
レベル７：　あれ？ もしかしてコレC++使えばよくね？ と思い始める

>>764
C++0xでまた互換性がある程度は復活するんじゃね？

最初からC勉強しても結構無駄骨折るよな？

ツェーペーペー

自分は今仕事ではC#とかJavaです。C++はお勉強は少しだけしたことがありますが、
自力でアプリ組むのはできないと思います。

自分のようなC++素人から感じるのは、

-----------------
・危険度が高い

ハードに近い部分にアクセス可能なので、とんでもない惨事をもたらすコードが書けてしまう。

・規則に例外が多い

こうも書ける、ああも書ける。そしてこう書くと実はこういう動きをする。〜には実はこんな意味がある
とか規則がスッキリしていない。

シンプルな基本ルールから演繹してソースコードを書くというよりも、上記のような事例を沢山記憶して
いないとアプリが作れない。
-----------------

ってことなんですが、実際どうなんでしょうか。C#やJavaは上の2つについては不十分かも知れませんが
前進していると思います。一定のパフォーマンスや自由度が犠牲にしてますが。

>>769
規則に例外が多いとは感じたことないな。vector<bool>くらいか
実装に依存する差異はJavaやC#に比べて多いとおもう

危険度もまともなOSで動かす分には変わらない。
変なことをしようとするとOSに止められる。
それはC#やJavaだとVMが担っている役割だな。

もちろんやろうと思えば危ないこともできるけど、
それはプログラマが意図的にそういうプログラムを書かないとやれるわけがない。
ウィルスとかワームとかがそう。

規則に例外が多いってのは、どの言語でもそうだと思う。
JavaやC#だとEqualsと==演算子とか最初何あれって思ったよ。
慣れればなんてことないんだけど。

なるほど、C++知らない人間が想像で怖がってるだけなのかも知れませんね。

どうも自分は、統一感があるのがC#やJavaで、C++ってのは今までの経緯というか
文脈というか、言語の細かい「事情｣に通じてないと使えないという印象を持ってました。

あとメモリ管理を意識するというのも大変そうだなぁと。ソースコードが何をやって
いるのか、ではなくて、マシンのメモリ上のどの部分をいじってるのか、ということを
意識するというのは、実際に工数が膨らんでしまう＆大きな不具合が生じる可能性が
高まるんじゃないか、と思うのです。

メモリ管理を意識ってのはほとんど寿命の問題。
普通にやってるぶんにはマシン上のメモリ配置など意識する必要はない。
触りもせず杞憂もほどほどにしとけ。

スマートポインタ使っとけ

C++使いの私からすれば、一々newしないといけないJavaの方が面倒だと思う。
データ構造はSTLのコンテナを使えば済むし、オブジェクトは普通にローカル変数で済むからね。

>>775
Javaでもローカル変数ぐらいはあるが、
C#でいうところの値型（struct）がないのが面倒ってこと？

GCのほうか余計に気を使う。

自分も>>769と同意見で、C++は注意することが多すぎると思う。
メモリ管理、スライシング、仮想関数テーブル、多重継承、Cスタイルとの混同、ヘッダの衝突etc...
STLも、さらにBoostも覚えて使えとか、うちではMFC使ってますとか、
組み合わせて使うときにはまた注意事項が増えて・・・。
Javaや.NETではほとんど意識しないことばかりだから、ストレスが溜まるよ。

そうかのう。
必要に応じて取捨選択すればいいだけ。
むしろ、俺はJAVAでGUIどうやって書けば良いのかわかんね。
EclipseにGUIエディタとか入れてるはずなのに出てこねーし。
まあ、作れてもJudeみたいに糞遅いプログラムじゃ悲しいけどね。

自分の基本的なプログラムに対する考えは、「富豪プログラミング」的なものです。

つまり、分かりやすい、間違えにくいというのが最優先であって、実行効率やそのための
裏技的な知識は2次的なもの、という考えですね。

富豪的でも「難解」なコードはあり得るでしょう。アルゴリズムのようなものです。しかし、
C++が難解なのはそういう意味ではなくて、>>778に書いていただいたような、文脈を
色々知らないとコードが書けないってことなのです。

>>779
ちょっとお聞きしたいのですが、C++っていうと、WinのGUIアプリっていうつながりが
やはり定番なんでしょうか？逆にそれ以外の用途って、どんなものがありますでしょうか。

C++の言語の仕様が詰め込み杉ってのを否定する奴はまずいないだろうね

>>780
普通にシミュレーション系のプログラムを書く分にはGUIなんて要らないし、
C++でも>780の言うところの富豪プログラミングができると思うけどねぇ。

ライブラリの仕様が延々書いてあるから多く見えるだけのような…
個人的にはいらない機能もあるけどね

Windowsに関していえば、
GUIなどは.NET、速度を要求するところだけC++のハイブリッドが望ましい。
部分的にアセンブラを使うような感覚で。

文化なのか何なのか知らんが、Windows プログラマが C++ を使うような場面で
Unix や Linux のプログラマは C (含 gcc 拡張) を使うケースが多いよね。

>>780のように言語自体が難しいのはアレだろという意見は昔からあるわけで、
C が使える環境でも Fortran だの COBOL だのを好んで使う人も昔からいた。
perl で短く書けるものを sh や awk で長く書く人とかも同類か。

>>785
短く書けるからと言って、awkで読み易く書けるものをperlでわざわざ読み難く書くこともなかろう。

awkは知ってるが、perlは知らん。
awkで不足するようならC++に飛んじゃう。

>>780
いんや、GUIなんて殆ど作りません。
JAVAやC#は覚えることが少いとか言う人がいるんで、
C++でやってきた人間にはJAVAも覚えることだらけだよと言いたかっただけです。

Cで多態とかやろうとするよりはC++でやったほうがシンプルに書けるとかもあるんで
Cだから簡単だとは一概には言えないよ
それと、全部やるなら覚えることが多いのは確かだけど
使わないでいいならクラスもテンプレートも覚える必要ないし

慣れた言語が一番使いやすいから、ある用途で優れてる言語と分かっていても、
自分にとっては慣れてないせいで結構細かい言語仕様、ライブラリを調べないと
何も書けないというのもある。

C++が目指した道も「分かりやすい、間違えにくい」ということだったはずなんだけど、
結果は、そこに至るまでの道がかなり長い方になってしまった、と自分は思っている。

C++だってわざと難しくなるようにできているわけじゃなし、少なくともプログラム言語ひとつ捕まえて、複雑だの何だの言って怖がってるうちは一山いくらのアルバイト程度のプログラマであることを自覚した方がいい。

Java の人には、きっとプログラマじゃない人（実装することの専門家を目指してない人）も結構いるんじゃない？

C++は全用途向け言語ってことを忘れてる奴が多すぎる
安全性を理由にプログラマが実行可能なことを減らしてはならない
邪悪なハッキングだって時には必要な事だから禁止されてはいないのだ

JavaやC#よりも面倒なのは俺も思う。
それに、IDEの補完機能の賢さやコンパイルの速さでは本当にC#やJavaが羨ましい。

C++は標準の例外がクソ過ぎる。

と俺は思っています。

標準ライブラリ全般がくそで貧弱です。
TR1では到底足りません。Boost全部入れたって足りるようなものではありません。

>>788
そうですか。現状のC++の用途というとWinGUIアプリが中心なのかな、と思ってました。

あと、C++ができる人にとって、JavaやC#は楽勝であるというのは事実でしょ？自由度が
Java/C#よりも大きいのですから。

>>792
問題は、C++が知識量を必要とするということなんですね。ちょっと極端な例かも知れませんが、
Schemeのように実に単純な文法から森羅万象を生成するというのではなく、覚えておくべき
知識を要求してくるのがC++じゃあないかと。

JavaやC#はその辺Scheme程ではないですが、シンプルです。変数の扱い、スコープ、基本的な
構文、クラス関連の表記方法と意味が分かればよい。あとは、いかに無駄無く綺麗に書けるかに
なってくるわけで、これは知識とはちょっと違います。

>>798
というか君は、CもC++もロクに使ったことが無いんだろう。
ちょっと触れたぐらいで多くを語るなｗ

Schemeとまではいかないまでも、LLから勉強してある程度
プログラミング覚えてからCやC++やったほうがいいと思うんだけど…

C++→C#と入ったが、楽勝ではなかったぞ。
あの大量のライブラリ、初めは適切なキーワードもわからずググれない。
それ以外の言語を始めるのと大してハードルは変わらなかったと思う。

一通り使えるようになった今だから言えることだけど。

楽勝だなんてC#にもC++にも失礼だ。

ライブラリの学習コストはどの言語でも大変。
.netはそれを統一してくれた。

一人でプログラム作るんならC++を使うけど、
数人でプログラム作るんならCやJavaを使う。

>>798
Java は Java で標準添付のクラスの量に初心者はびっくりするよ。
どれをどう組み合わせて使えば良いのか判らない。
そういう意味では情報量は必要だよ。

>>797
そうか、きみの使っている言語は準標準レベルで
マルチスレッドと構文解析機とシリアライズと非同期通信とグラフ理論と行列計算
をサポートしているというのか。それはすごい。

キレのある皮肉のつもりなんだろうな〜、きっと。

つーか、matlabがかなり近い?

一度C#をやろうとしたとき、ヘルプを見ても欲しい情報がなかなか見つからなかったのがつらかったな
C++は十年以上かけて覚えたけど、どんどん仕様が変わっていったのがつらかった

>>799
> ちょっと触れたぐらいで多くを語るなｗ

あはは。いや、お勉強ならしたことあるんですがが、C++の実際の実装ではそんなのあまり
役に立たないと感じたわけです。結局、低レベルの、OSだったりメモリ管理だったり
の知識が必要となるんじゃないですか。

>>802>>804>>808

ライブラリの学習って言いますが、あれは覚えるものではなくて辞書の引き方を知るだけで
よいのです。大きな本屋へ行って、目当ての本を探す際に書店の分類を参考にしてその書棚へ
向かうのと同じですよ。検索エンジン使うのとも似てます。

>>809
> 結局、低レベルの、OSだったりメモリ管理だったり
> の知識が必要となるんじゃないですか。

なる場面もあるしならない場面もある。
デバドラ書くならOSの知識は必要だけど単純なファイル操作だけとかならほとんどいらない。
スクラッチでメモリ管理を書く必要があるなら知識は必要だけど、
アプリで使う程度のメモリ管理ならコンテナとスマートポインタで簡単にできる。
C++は両方の局面で使えるってことだね。

>>809
＞結局、低レベルの、OSだったりメモリ管理だったり
Win32APIとかそのへんの話か？
そこらへんだったら言語の問題とはベクトルが違うぞ。
言語と環境を一緒くたにするな。

でもC++のコンテナとかでトラブルが起きると
デバッガでマシン語眺めないと原因がわからないことが多いような。
.NETとかだと〜Exceptionの意味を調べれば終わりだけど。

なんでやねん

>>809
その辺りは考え方の違いで、
・C/C++ はメジャーなので多くのプラットフォームがネイティブでC/C++から呼べるAPIを
　用意している。のでC/C++で何か書く場合には、それを使えるし使うことが多い。
・Java は OS 側からのサポートが超貧弱。代わりにライブラリを用意。
　それで出来ないことについてはJNI 等に頼らざるを得ない。
という見方もできる。

いずれにせよ、ライブラリの問題なら言語仕様とは関係ないし、ライブラリを除外して考えるなら、
Java で簡単にできることはそのほとんどが C++ でも同様に簡単（かつ難解でなく）できると思う。

>>809
趣味なら構わんが仕事なら役立たずPGの烙印押されるよ。
よくC++10年使ってましたというPGがMFCやATLが理解できなくて
テスターにしか使えないとかよくある。あるいは、
1時間でできるコーディングを調べながらやって1週間かけるPGとかいる。
コーディングスピードはできる人とできない人で100倍以上の差があるなんてのはよくある。

tteいうか、JavaでもC#でもちょちょっと調べてさらっと書ける人なら
Symbian だろうが Win32 だろうが C++ でコード書くくらい楽勝だよなぁ・・・
DI等のマイナーなくせにお約束だらけの世界も少ないし。

生産性において MATLAB と比べられたらさすがに分が悪いけど。

std::vector<std::auto_ptr<hoge>> kusolib;

>>814
JavaにOS側のサポートが多かったら、Javaの理念に合わないんじゃないのか?

>>815
C++を10年使っている事と、MFCやATLが判らない事は何の関係も無いと思うんだ

815の言う「MFCやATLが理解できない」というのは、
いま現在知っているかどうかだけでなく、「今は知らないが必要ならすぐ使えるようになるレベル」
も含めた、広い枠組みでの有能・無能の話だと思うよ。

ATLはCOMが手軽に扱えて便利だったがMFCの存在価値はまったく理解できない

ただ、MFCを作ったプログラムという資産は山ほどあるわけで。

MFCよりWTLがいい

オブジェクト指向言語でライブラリを理解するということは
フレームワークのお作法を理解するということで、理解するにはやはり時間がかかる。
特にMFCみたいにマクロだらけのものは。まぁ便利だけど。

>>816
Javaは基本的に公式ドキュメントあれば事足りるから
調べ物にはあんまり困らないよ。
突っ込んだ仕様は調べる必要あるけど。

C++は何故か必要な情報になかなかたどり着けねえ…。

Javaは学習しやすいけどランタイムの信頼性が低いのがネック

>>824
どういう情報にたどりつけないのだ？
C++の仕様として読み込まれていることならC++の仕様を見るだけでわかるだろ。
MFCだったらC++の仕様じゃないんだから、MFCの仕様を探せば良いわけでな。
本来、OSや環境サイドで決めるものの仕様まで言語仕様に読みこんでるものはすかん。

>>824
>Javaは基本的に公式ドキュメントあれば事足りるから

いくらなんでもこれはないだろう。
トイ・プログラム程度しか書いたことないんじゃ・・・

基本的だから別にいいんじゃね？仕事的にはアウトだけど。
どんな言語やライブラリ、処理系だってバグがないものなんてないから、嵌るときは嵌る。

僕は神になる為に駅前ギャンブル場に行った
そしてトイレにこもり続け、 店員に注意された----

僕「店長を呼んでくれないか」
賭博主が何事かと、のこのこやってきた

僕はロープ、ベルトをもっている

僕「お前のせいで借金地獄だ　自殺しようと思う
暴力団に殺されるより楽にしにたい」
賭博主「え!?　そんなことしたら、営業妨害で訴えますよ？」
僕「それがどうした　これから死のうってのに
警察呼ぶか？　出てきたら店の真ん中で死ぬ」
賭博主「それは困るッ・・・どうすれば？」
僕「借金は１０００・・・万近く・・・あるのだが」

死神「こんな場所が日本に１万以上あるのか　うめ〜」

これを繰り返し、僕は神となった！（大富豪になった）

C++って好きなんだけど洗練されてないと思うぜ。
かといってJavaはやりすぎだしC#はイっちゃってる。
結局戻る所はC++だわ。

でも洗練されてるC++って見てみたいなぁ。
言語仕様見て感動したい。

洗練か…そこんとこDはどうなの？
弄ったことないからD使いの人宣伝してくれ

VerilogでASICとか作ってたんですが、今回はSystemCをやると言い出す人がいて
先週からUMLとC++のコード書いてます。
UMLは好きになりましたが、まだあまりC++が好きになれません。
昨日は演算子のオーバーロードを考えた人を絞め殺したくなりました。
こんな俺をC++大好きっ子にするコメントお願いします。

>>832
C++として使うから嫌いになるんじゃね。C＋便利機能（クラスとか
STLとか）くらいで使えばきっと好きになると思う。

SystemCだからといっても、無理やりC++機能をフル活用しようと
思わずに、ベタベタにCでかいてもいいし、クラスとか必要な
とこだけC++の機能使えばいいんじゃないかなぁ。

>>832
string jangdonggun = string("あなたのことが") + string("好きだから");

>>832
> 昨日は演算子のオーバーロードを考えた人を絞め殺したくなりました。
誰か他の人が書いたトンデモ・オーバーロードに振り回されたのかな。
だとしたら、気持ちはわかるけど、それはその書いた奴が悪いｗ
まともな奴は心得た使い方をしているし、その範疇の中で語るなら、
演算子オーバーロードが無かったら逆に困るんだよね。色々と。

基本的にC++は、初心者（機能を知らない）を支えたり、身の程知らず（後先考えず機能を使いまくる）を
窘めたり、といった努力を一切放棄した言語。
「上手く扱える奴が得られる幅と力」重視で設計されていて、初心者とか、職場に身の程知らずが居るとか、
そういう人には厳しいと思う。

行列計算とかは演算子オーバーロードがないときついな。

数学側で演算子がどんどんオーバーロードされるのに、
プログラミング言語側でサポートされないと読みにくいコードになるしな。

演算子オーバーロードは何でもありだから、プログラムを書いたやつのセンスが問われるな。
そもそも、演算子オーバーロードの代表格、iostreamの演算子なんて、考えようによってはひどすぐる。
cout << a;
なんて、代入系演算子でもないのにcoutを書き換えちゃうしな。
副作用のある処理は副作用があると明示的にわかる演算子を使うべきのような。

C++標準のiostreamなんて、使おうとして一瞬で捨てたぜ！
クソスギデショ。

シェルの追記リダイレクトがヒントだったのかね。逆だけど。

>>838
数学世界では、破廉恥なオーバーロードがすでにまかり通っていますからね。

>>840
STL誕生前のライブラリだけあって、他からひどく浮いてるしな。

>>1-843
要するにC最高ってことだな？

代入が演算子ってのがものすごく気持ち悪くなってきた。
数学的な演算子って言うのはあくまで1つ以上の値や関数等を演算した結果を返すものだよね。
関与したオブジェクトそのものを変更したりはしないはず。
関数f(x)を積分したところで、それは積分した関数を返す演算であって、f(x)自体を変更するものではない。

Cは平気で++や=などの副作用のある演算子が出てくる。
C++に至っては、オーバーロードで+などの一見副作用のない演算子に副作用を込められる。
キショイ。
つーか、演算とはオブジェクトも値も関係無く適用されるべきものであるのに、副作用型演算子はオブジェクトにしか使えないし。
そもそも参照渡しが関数や演算子の定義を見ないと渡したオブジェクトが変更される可能性があるのかどうかわからん時点でキショイな。
こういうことを考えると関数型言語とやらに興味が出てくるのだろうか。

演算子を定義できるようにするとかどうよ
さらにホワイトスペースのオーバーロードも出来ます

申し訳ないが、>845は「参照渡し」や「演算子オーバーロード」を理解できないで挫折した香具師が、
精一杯虚勢を張っているようにしか見えない。

「包丁で人が殺せるから料理ってキショい」とか言われても同意できないよな
殺さなきゃいいんだよ

言いたいことはわからなくもないが、今更どうでもいいって感じ。
演算子オーバーロードってC++だけの機能じゃないしな。
Javaはできなかったっけ？

> 副作用型演算子はオブジェクトにしか使えない
これは、もしoperator =や[]などがクラスのメンバとしてしか
定義できないということであれば、0xから解消され、
非メンバとして定義できるようになる。

>>847
すまんが、並列計算数値解析プログラムをCやC++で書いてるのだが。
C/C++の最適化効率の悪さが念頭にあって、副作用のある演算子もその大部分を占めてるなと思ったわけだが。

>>851
だからね、その実績が>845で台無しになっているってことよ。
# 尤も、その実績のどこに「参照渡し」や「演算子オーバーロード」が関係しているのか判らないけれど。

それは言語の仕様じゃなくてコンパイラの性能だろ

>>852
まあ、ふと立ち止まって考えたときに、「演算子」というもののありかたがどうなのかと。
Cは「高級」言語じゃないからしかたないが。
>>848のように殺せる道具を殺さないように使えば良いわけだし。

>>853
コード以上の文脈を読みとるのはコンパイラにとって大変だろ。
同じ振舞いをするコードでも、プログラマの意図したことがわかればより最適化できるケース(エイリアス問題など)があるしね。

だからそれはコンパイラの性能だろ。仕様のせいにするなよ。

>>856
仕様のせいだよ。
エイリアス問題なんてまさに仕様のせい。

そう思うならC++以外の言語使えよ

要するに参照透明性でしょ。Haskell あたり使えばいいんじゃない？

__declspec(noalias)に__attribute__((const))とか
C++標準とは別に、統一を図る場があってもいいとは思う。

>>845
君は、きっと関数型言語もきしょいと思うようになるだろうから
演算子の存在しない言語を利用した方が良いと思うんだ
アセンブラでも演算子は出てくるから、ここは一つ、バイナリで直接プログラムを書く人になるんだ
まあ、CPUが変わると命令が変わるが、そんな細かいことは気にするな
きしょい演算子と永遠に縁を切れることを考えたら安い投資だ

>>858
C++の仕様に問題があると、なにか問題があるの？

>>845
それだと、
関数型言語でも代入はメチャクチャ使いまくるから結局キショいと思うと思うよ。

schemeのset-car!とかset-cdr!とか、call/ccで継続を変数に代入する所とか。

>>863
代入が悪いのではなく、代入が演算子になっているのが悪いのでは？
func(a=b)とか出来る所とか。

mov a,b って書きたいってことか。

:= がほしいとか？違うか

Hoge hoge = GetHoge();

の = のところで何が起きるかここだけ見て分からないのはかなり嫌かも。

・GetHoge() が Hoge& を返していた場合
・Hoge に変換できる全く別の型を返していた場合
・Hoge のコンストラクタが受け取る全く別の型を返していた場合
・代入演算子がオーバーロードされていた場合

こうやって見てみると
auto hoge = GetHoge();
は型変換を伴うような変な副作用が無くていいのかな。

余計なことを考えず、「= と ++ と -- は特別」って覚えておけばいいのでは。

プログラムを書くことを諦めるってのも一つの方法だぜ？

>>845
君、Haskell がオイデオイデしてるよ。

>>863
let や再帰を駆使すりゃある程度は…。

>>868
そういうレベルじゃなくて、理解した上でのそもそも論でしょ。

他人の作った言語なんだから、いつまで使っても馴染まない部分てのは
多かれ少なかれどの言語にもあるかもなぁ。
そんな時、PG的には自分で俺言語を作るべきなんじゃないのかｗ

>>871
そうすると、この話題は「物事に例外が存在するのはキショイ」というだけのもので、
ディテールにはまったく意味が無いと思う。論ですらないよ。

>>873
このスレ的にはC++は良いって意見ばっかじゃないという意見が出たらダメということか。

演算子オーバーロードの害悪の話が出てきて、
その害悪とは元来の意味とは異なるオーバーロードが可能ということと、
さらには元来副作用をもたらさない演算子に副作用を仕込めるという話になって、
そもそもCの演算子からして副作用を持つ演算子というのは数学的で言う演算子からかけはなれている、
という流れだろ。

おとなしく使えとかそういう話じゃないはずだがw

>>874
どういう電波を受信すると、そうなるんだ？
相手が「馬鹿なことを言ってる」ことにしたくてたまらない
二十歳前後の自称論客みたいな話の運び方すんなよなｗ

C++って言語仕様だけが一人歩きしちゃっててかわいい。

演算子の一般的な意味とかけ離れた定義が可能なことで、それが糞仕様にはならんと思うよ。
関数名だって自由にデタラメな名前つけれるし。
納品済みのコードでtest1()とかaaaa()とか見たことあるし。

演算子は元々言語仕様で意味が決まってるのに、オーバーロードで勝手にそこから踏み出すわけだ。
関数名は元々言語使用で勝手につけてよいと決まっているので、演算子の場合と一緒にすべきではないな。

aaaaという関数名はもともとC/C++に存在しない単語だけどoperatorはそうではないという違いはあるけどね。
文字列の連結がoperator-だったり、行列の積がoperator[]だったりしたら発狂しそうだｗ

>>880
やってみれば判るが、実は文字列の連結にoperator-()を使うのは意外に収まりがいい。
寧ろ、Basicを真似てoperator&()なんかにされたら泣ける。

>>879
漏れが設計して漏れが実装してるクラスにおける「代入」や「大小関係の比較」の実装は
漏れができるようになってないと使い物にならないじゃん・・・

Java だって equals に「引数をファイルに出力する」とかいう実装を与えられるわけだし。

表記の一般的な意味とは異なる実装するから困るって話じゃないの？
Add()関数作って実際は引き算の処理されるのと
文字列の連結がoperator-するのと問題は同じと思うが。

VBAをちょこっと触ってる自分はoperator&のほうがまだしっくりくるわ・・・

<<よりはまだ&のほうがいいような

>>885
それなんてboost::archive

MFCもそんなのあったな。

>>881
"ABCDBC" - "BC"
この結果は、
"ADBC"だと納得行くが

"ABCDBCBC"なら、「なんでやねん!!!」と思うよ

寧ろ、"ABCDBC-BC"になってくれたら何かと便利。

便利じゃないよｗ

>>888の状態で16進演算してくるなら便利。でもstringの仕事じゃないよな。

>>891
stringの仕事じゃないね
16進演算なんて普通に
int i = 0x0a - 0xf0;
で出来るんじゃね?

>>892
ファイルから文字列として読み込んだときとかの話ねｗ

そうだとして"90" - "1" が"8F"とかありえないでそ（ｗ

weirdString foo = "-" + "|";
assert(foo == "+");

kidsString foo = "1" + "1";
assert(foo == "田");

オペレータでどうにかするんじゃなくて
STL的にはイテレータでどうにかすべき問題ではないの？

Cだと
int main()
{
printf("%d", 1);
}

c++だと
int main()
{
std::cout << 1;
}

で、最近のコンパイラは使ってない関数は出力ファイルに入らないように削除してくれるらしい。
これをリンク時ガベージコレクションって言うんだっけ？

それで、上記プログラムだとCの場合にprintf全体をリンクする(doubleを文字列化する処理も含まれる)が
c++だとstd::cout::operator << (int)をリンクするだけでOKだ。

後はc++のほうを例外処理無し、RTTI無しのオプションを付けてコンパイルすればCのプログラムより小さくなると思う。

気が向いたら実験してみる。

そんなわけなかろうｗ

>>898
ostreamの実装がprintfの実装より小さくなれる気がしないんだが…
とりあえず結果報告キボン

>>900
フォーマット文字列の解析が要らないから小さくなるかもなぁ。

ヒント:淫乱

インリンじゃないの？

Cだからってprintfのパーサの実装が綺麗だと思うなよ!

>>898
の実験結果を発表します(ｼﾞｬｼﾞｬｰﾝ)

実験環境
OS:windowsVista
gcc ver3.4.4 @cygwin

cs.cとcs.cppの内容は>>898に#includeを追加したのと同じ内容です。

gcc cs.c
a.exeの大きさは8873byte
gcc -Os cs.c
8683
gcc -O cs.c
8873
gcc -O3 cs.c
8873

g++ cs.cpp
477682
g++ -Os cs.cpp
477014
g++ -O cs.cpp
477577
g++ -O3 cs.cpp
477014

>>905
勝負になっていないように見えるが？

visual studio2005 sp1のcl.exe

cl cs.c
53,248
cl /Os cs.c
53,248
cl /Ot cs.c
53,248
cl /Ox cs.c
53,248
cl /Ox /Oi /Ob1 /GL /Oy cs.c
53,248

cl cs.cpp
135,168
cl /Os cs.cpp
131,072
cl /Ot cs.cpp
135,168
cl /Ox cs.cpp
131,072
cl /Ox /Oi /Ob1 /GL /Oy cs.cpp
131,072

今回の実験ではc言語で書いたプログラムのほうが小さくなった。
でも十分大きなプログラムではこの差はほぼ無視できるレベルになるのではないだろうか。
気が向いたら実験してみる。

VCなら/MDを付ければいいんだよ。

vc9 /Os /MD
cs.c: 7,168
cs.cpp: 7,680

vc9 /Os /MT
cs.c: 53,248
cs.cpp: 129,024

gcc(4.1.2) -Os
cs.c: 8,330
cs.cpp: 8,827

gcc(4.1.2) -Os -static
cs.c: 615,580
cs.cpp: 1,306,095

-----

サイズの最適化しかやってないけどこんな感じだった

ためしにC#版もやってみた、オプティマイズなし
class App {
　static void Main() {
　　System.Console.WriteLine( "{0}" , 1 ) ;
　}
}
csc cs.cs : 3,072
ildasm で調べたら Main() のコードサイズは17バイト
コンストラクター 7 バイト、あわせて 24 バイト
その他の容量は、動作しない環境で実行したときのエラーメッセージ用実行コードその他
サイズが気になるなら、マネージド系が圧倒的に有利です

ランタイムが別なんだからそりゃそうだ

ランタイム別としても17バイトはすごいと思うよ
C だと、スタックフレームの構築だけであっさり17バイト突破するよ

ランタイム(VM)に丸投げなだけだろ禿

だからその丸投げの度合いがすっげえなって話だろ？
とっくに折り込み済みのことを突っ込みの手段に使うのって馬鹿丸出しだよ。

17Byte中に文字列 "{0}" = 8byte も込みだったりするのがまた恐ろしい。

>>913
マイクロソフトC++ V14.0でO1で最適化するとCでも14

>>913
マイクロソフトC++ V14.00でO1で最適化するとCでもmainのコードサイズは17バイトだ
スタックフレームは必要ない
最適化なしのスタックフレーム付でも22バイトにしかならん
コードサイズだけ比較しても意味ないがね

コードサイズを小さくしようという話の流れじゃないのかwww

初学者はとりあえずＣやっとけ
極めなくてもいいからやってればC++なりJAVAなりいくらでも替えがきく

Cは勉強用／拡張用には良いかも知れんが、やりたいことを実現するまでが長いのがなあ。
俺はあんまり勧められない。

確かにCじゃ画面に線一本引くのでも苦労するが、
本格的な学習の前の基礎知識を学ぶという点では良いね。

でもCの前にASMをほんのちょっとで良いから勉強してみるのも良いかも。

>確かにCじゃ画面に線一本引くのでも苦労するが、

苦労も何もCにそんな機能はない。

楽勝
putchar('-');

と思ったが標準出力が画面に出力される保証は無いんだった

C言語と追加機能を使って線を書くの略だろう

追加機能がOKならinclude1つと関数呼び出し一回で線を引ける処理系だってあるし

だから逆に言えば簡単に描けない処理系もあるわけで

標準ではかけない

FreeBSDのSSCLIでも簡単には線を引けないしCに限った話ではないな

画面のある任意の処理系に簡単に書ける言語ってあるの？

処理系に書く、ってどういう意味だろう。

グラフィックが簡単にできる言語があるかという質問では?

画面上に線が簡単に書ける言語といえばLOGOだな

グラフィックが簡単な言語というならFlash/ActionScriptだな
時点は xaml、ドキュメントとデザイナがもう少しまともになれば間違いなくコレかと。

N88

旧VBもフォームに一行書くだけで線引けるよ。

X1turbo BASIC

<hr>

>>939 ﾌｲﾀｗｗｗ

>>923
ガキの頃、Quick Cを使ってグラフィックライブラリでビデオメモリに線を引いたりしてたんだが、
あの頃はCの標準ライブラリと非標準ライブラリの違いなんぞ知る由もなかった
PC98シリーズでいかに高速な描画をやるかって、インラインでアセンブリを書きまくるとか
アーキテクチャニュートラルなコーディングなんか微塵も考えてなかった

その頃にアーキテクチャニュートラルなグラフィックのコーディングを
しようとしたら、なんだろ。X-WindowとかMotifとかかな

当時は毎回全コードを捨て去って新規に作っても十分いけるし、コードの品質も毎回向上したからね
実際、非互換の方が高速な上にすばやく作れて、となれば互換性など考える理由は無かったかと。
正しいソフトウェアは時代次第でどんどん変化する訳だ。

>>943
それだ！
だいたい、当時のPCは性能が今と比較するととんでもなく低かったんだよな
intel系は640KBのメモリとEMSメモリ、ビデオメモリの余りやらを駆使してているソフトなんかがよくあった
互換性よりも動作速度のほうが重要だったのかも
いや、移植先なんてなかったんだ、当時のPC98のシェアは日本国内の90%を越えていたしｗ

それが今じゃなんだ、ランゲージニュートラルでアーキテクチャニュートラルでUML駆動モデルで
ロバストネス分析→設計モデル。リソースは無限であるという前提ときたもんだ
下回り(デバドラやハード制御)を知らないのも困りもんだが…

Javaやってるとクローン作らないで参照戻すくせに
カプセル化がどうの言うの奴とかいるのよ
始めにCとかC++やってればそのへん安心

>>945
malloc() の返り値を呼び元でfree() してもらうのは、だめですか..........。

>>946
後処理用の関数を用意してあげるのが親切かも

JAVAやらドトネトとかRuby、Python、Perl、PHPなんかを最初の言語に選んでしまうとC/C++は
ハンパじゃなく分かりづらい言語になりそうだな

C/C++を最初の言語に選んでしまった場合は？

C/C++を選んだからといって、他の言語の学習が楽になるわけではない。

>>949
>>950の言うとおりなのだろうかと
だけど、C/C++を最初にやってると、そうでないよりはC/C++学習が楽かも
そんな俺はx86アセンブラ→Turbo Pascal→Quick Cだった

学習が楽かどうかは言語仕様よりもIDEのサポートが重要な気がする。

そりゃまあ、昔はmakeとemacsだけでなんでもやってた気がするけどサ。

漏れなんか今でも linux や Solaris では vi だなあ・・・

>>952
いまでも仕事の大半は、makeとVimで済ませてるな。デバッガもよっぽどの
ことがないと使わない。ファンクショントレースとcoreファイル開いてバックトレース
すればバグの9割以上は1瞬で解決するし。1瞬で解決しない場合は、
２，３のprint文入れればそれで解決する。

システムテストやらででてくる再現性の低い不具合とか、ハード起因の
不具合とかでは、デバッガ重宝するけど。

IDEサポートって本当にそんなに重要か？インテリセンス（笑）なんてVimだって
備えてるぜ？Unitテストなんて、Rubyでは言語のライブラリとして豊富な機能が
提供されてるぜ？VSSよりSVNのほうが便利だぜ？メトリクスツールは、
もはやフリーでも転がってるぜ？

IDEのメリットって何だ？

環境の構築が容易

>>954
VisuaｌStudioとかのC++BuilderのIDEは使うけど、ほかのIDEはエディタがいまいちなのが多くてmake作成用にしか使わない感じ。

>>955
環境の構築の容易さにアドバンテージがあるとしても、IDEを習得するための
労力と時間、一社のIDEに依存してしまうリスク、汎用性の喪失、費用などを
考えると、俺にはIDEの方がいいなんて、現時点では到底思えないな。

Eclipseも数時間で捨てた。VisualEditorだけは使うけど。
VC++使う羽目になりそうだったので、Glade+Rubyで押し切ったわ。

まあ、makeでビルド出来る時点で、変人だからねぇ

変人の普通が、普通の人の普通かって話だよなぁ...

つーかさ、makeでビルド出来るなら、VC++使っててもいいんでないの?
MFCやATL使わなきゃ環境依存なんて無いでしょ

>>959
GUI作ることになった（といっても、社内ツールだが）。VC++使ってくださいと
言われたのだけど、そのツールLinuxでも使うことが想定されたから、
「今後他プラットフォームに移植することを想定するなら、最初からそれを
考慮したほうがいいですよ」といって、Ruby+Gladeで落ち着いた。

横から「Pythonは？Pythonでいきましょうよ！」っていうPython厨がいて
驚いたが、華麗に無視

＞Python厨
ソイツは大事にしとけｗ

インテリセンス（笑）なんてVimだって備えてるぜ？

VCのインテリなら単語補完に毛が生えた程度じゃない？

>>960
> 横から
> 華麗に無視
比較的まともであると言われるPython使いの「横から目線」に、
横柄・傲慢で知られるRuby使い特有の「上から目線」で対応したわけですね？

「結果」は現場の力関係に依存するからともかくとして、
Python使いとRuby使いが登場する「人物描写」としては、実にお約束だと思いました。

ここでPython対Rubyをやるなよ…。
やるならLLバトルロワイヤルでどうぞ。

個人的に軽い社内のツールでVC++とRuby、Pythonなら
Python＞VC++＞Rubyだなぁ。

特に若い人がPython使いたいって言うなら、自分の趣味は切り捨てて
そっちを優先させるし、特にないならマルチプラットフォームでお手軽(?)なJava
選択するけど。

>>963
何を言っとる。
最近のインテリセンスはコーディング中にプリプロセス走らせるぞ。
おかげでビルドターゲットの切り替えが重い重い…。切りたくても
切れないし。

>>967
マイクロソフトからすれば、ハードウェアの進化に即した
ソフトウェアを提供しなければ、バージョンアップしてもらえ
なくなるかも、他OSに乗り換えられてしまうかも、という恐怖
が付きまとっているのだから仕方がない。

ソフトはユーザエクスペリエンスを無視して、「重い処理」を
作りこまなければ意味がない。デスクトップアプリ全盛は
それでもよかった。

Web全盛の時代、ユーザは「よりよいエクスペリエンス」が別の
ところにあると気づいてしまったのだな。そして「それで満足」
してしまいそうになっている。

まぁこれからはMSもおもてなしに移行せざるを得ないだろう。

そしてIEの改良に注力せずに、他ブラウザの追従を許してしまったことは
致命傷になるかもしれない。シルバーライトを声高に叫んだところで、
さんざんFUDで痛い目を見てきた開発者達はAIRを選択することは
目に見えている。

MS終焉の序章ですな。

頼みの綱は、WMPlayerによるDRM動画流通のしくみが豊富なとこくらいか。
はてさてDRM頼みがいつまで持つことやら。

>>968
「おもてなし」を使うということは中島さん？

つかMSの方針とかどうでもいいし
このスレで許されるMSの話題はVisual C++だけだ

vimでも〜とか言ってるやつはC#のインテリ使ったことないだけだろ

>>973
C# は確かに凄い。ここまで補完が優秀だと、片手でプログラミング出来る程だな。
仕事で VC++ 使ってると、C# が羨ましくてしょうがない。
「インテリセンスを更新しています･･･」が表示されて、激重な時は特に。

>>974
C#楽なんだけどさ、propertyとかいう変なの使ってgetter/setterするのはどうも…
ついでに、インデクサって悪の枢軸じゃなかろうか？
ってか、.NET Frameworkそのものが業務アプリ作るには不十分な希ガス
.NETでGUI作って、処理部はネイティブ言語でAPIコールが生産コスト安そうだ
あとは、俺が古い考えなだけなんだが、ガーベージコレクションの恩恵を受けると、C++に戻った
ときに危うくdeleteするのを忘れそうなんだがｗ

>>975
明示的にdeleteしているならC++を使えていないと言うことだ。
auto_ptrやsmart_ptrを使うか、さもなくばデストラクタでdeleteすればいいのだから。

基本に従ってればdeleteは完璧に抹殺できるよな

VB6、VB.NETのインテリもまともなんだが
なんでVCだけタコなんだ

>>975
ttp://journal.mycom.co.jp/articles/2007/05/16/java7/

ぱくりぱくられだな