トップページ⇒tech
193コメント51KB

C++を滅ぼそう

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
C++は難しいので、こんな言語いらないです。
どのようにしたらC++を滅ぼせるでしょうか。

という事を話しあうスレです。ﾄ-ﾞｿﾞ
0002デフォルトの名無しさんNGNG
C#が出たら滅びるでしょう。
少なくともWindows上では。
0003参考までにNGNG
MacOS Xでは Javaと Objective-Cが標準。CPPは要りません。
0004デフォルトの名無しさんNGNG
それはココアだけでそ。
カーボンってのもあるとｵﾓﾜﾚよ。
0005デフォルトの名無しさんNGNG
Carbonは既存アプリの延命措置です。新規開発にあんな物を使う理由が
ありません。そんなことをするデベロッパーは CPPと同じ運命を辿るで
しょう。

toolboxがダメダメなのは有名だけど、ホントに使い勝手が全然違うんだって。

UNIXではまだまだ CPPが使われていくのかな？　KDEとか。
0006デフォルトの名無しさんNGNG
>>5
あらそう。

じゃ、クラシックってのは何よ？

カーボンはアドビがアプリ移植に手間かかるのいやだから
作らせてたってのはホント?

JEDITの作者はカーボンに文句いってるんだっけか？
0007デフォルトの名無しさんNGNG
別に CPPに恨みはないのであしからず。

Carbon, Cocoa, Classicは開発フレームワークであると同時に各々
別の実行環境と考えても（正確ではないけど）間違ってないと思う。

Carbonは現行 Mac標準の APIである Toolboxを OS X用に焼き直した
物で、OS Xネイティブで動く。
主な用途は現行アプリのアップデートなど、従来の Macベンダーが
過去の資産を活かすために使う。

Cocoaは OS X標準のアプリケーションフレームワーク。Java2と Objective-C
に独自の APIを追加した物。OS X技術の恩恵を完全に享受できる。
アプリの新規開発するなら、このフレームワークを使うのが妥当。
従来の Macベンダーにとっては全く新しい物。

Classicはユーザが今までのソフトウェア資産を無駄にしなくていい
ように用意されたもの。エミュレータのような実行環境で、いわゆる
Toolbox APIで作られたソフトが動く。
OS Xネイティブでは動かないのでこのフレームワーク向けに新しい
アプリケーションがリリースされることは考えにくい。
Toolboxは肥大化し過ぎて評判はよいものではありません。

あとは良く知りません。
ただ MacOS Xで CPP使いたいっていう人は少数なんじゃないかな。
Cocoaから呼び出すには手続きが必要だし、Java, Objective-Cが使い
にくいわけじゃないし。

手許の半端な知識で書いたので、詳しくは Appleのサイトにある情報
を見て下さい。
0008デフォルトの名無しさんNGNG
CPPって何？
#defineとか処理するアレか？
0009デフォルトの名無しさんNGNG
C Plus Plus
きっと、C++言語のことでしょ。
0010デフォルトの名無しさんNGNG
そうです。昔はやった言語だからわからなかった？
0011デフォルトの名無しさんNGNG
CocoaはNextStep系のフレームワークなんですよね。
マクーOSXは正当なNEXTの後継者ってわけだ。

マクーではC++は滅びるって事か。
それではWinでも滅びてもらうことにしよう。
0012デフォルトの名無しさんNGNG
そんなでC++が滅びるならとっくに滅びてるはず
0013デフォルトの名無しさんNGNG
開発用の言語としてアセンブラー、C がたどった道をたどるでしょう。
完全に消滅することはありえないが、主流ではなくなると。
ただ、アセンブラー、Cの知識は、ハードウェアに密着して、
どうしても必要になることがあるが、、C++は中途半端。
Cobol/Fortran みたいに、一度は一世を風靡したが、現在では
知らなくてすめばそれでもよしという時代が来るはず。
0014デフォルトの名無しさんNGNG
んー、Java,ObjectiveC,C#じゃまだ力不足な感じ。
STLが登場してしまった以上。
0015デフォルトの名無しさんNGNG
MacのAPIになったぐらいじゃきついね。
0016デフォルトの名無しさんNGNG
Cocoaでの新規開発にリソース割ける企業がどれだけあるかな。
今となっては特別に革新的なわけでもなし。
ふつーPureJavaに行くよなあ。
0017デフォルトの名無しさんNGNG
CocoaではJAVAでネイティブコード動くってことかしら？
0018デフォルトの名無しさんNGNG
C系のくせにで実行速度を犠牲にした Objective C の方が C++よりも中途半端です
0019デフォルトの名無しさんNGNG
高速化の手段は、低速でもいいのでプログラムが動いてから。

複雑怪奇でプログラムが実行する所まで
たどり着かないC++は必要ないです。
0020デフォルトの名無しさんNGNG
Winが進化していって
ネイティブコードより.NETの方が高速動作するようになったら...

それは無理でも

Windows自体のカーネルが変更されて
既存のWinカーネルが死亡して
非常に安定したWindowsが登場し、
それは.NETアプリしか動作しないなんて事になった日には

ようやくC++はC#に置き換わるようになるのだろう。
0021デフォルトの名無しさんNGNG
>>20
.NET勘違いしてない？
0022デフォルトの名無しさんNGNG
>>21
してないよ
0023デフォルトの名無しさんNGNG
C#に、unsafeでCがつかえるように、C++も…てわけにはいかないんだよね。
なにせC++だから。
0024デフォルトの名無しさんNGNG
>>20
そうなったら、カーネルとかデバドラとかのAPIよりも下のレイヤ
と関係ないアプリケーションプログラマは、C/C++を知らなくてもOK
になりますか？
0025デフォルトの名無しさんNGNG
Cocoaにおいて Javaの扱いは２通りあると聞いています。僕自信は Objective-C
を勉強中で、Javaは試してないのですが。

その１.Pure Java
Pure Javaを意図して作られたコードは JavaVM上で動きます。これは他の OSと
全く同じです。原理上は他の OS上でも動く物が作れます。

その２.Java→ Objective-C変換
Cocoaフレームワーク向けを意図して作られた Javaコードはコンパイル時に
Objective-Cコードに変換されるそうです。
この場合はネイティブコードとして動き、他の OSでは動かないと思います。
利点としては OS Xの APIがフルに呼び出せる、Interface Builderという GUI
構築ツールで効率的にアプリケーションが作れることがあげられます。

それと OS Xの Objective-Cは、純粋な Objective-Cに NeXT, Appleがクラス
ライブラリを大幅に追加した物です。他のプラットホームでも Objective-C
が流行るということは考えにくいです。

>>18
OO言語の癖に Cとの互換性にこだわってぐちゃぐちゃになった CPPはよっぽど
中途半端です。って言ったら言語の一側面しか見てないことになりますよね。

おおまかには >>13に賛成。
CPPが滅びるとは思わないし、これからもどんどん使われていくと思いますが、
CPPを使う必然性は薄れていくと思います。
0026デフォルトの名無しさんNGNG
>>25
誤爆か？
002725NGNG
ごめんなさい。ageるつもりじゃなかったんだけど。
しつれいしました。
0028デフォルトの名無しさんNGNG
ちゅか、c++ を cpp って言うのわやめれ。
なんとなく。
0029デフォルトの名無しさんNGNG
そうだな。バカっぽい。
0030デフォルトの名無しさんNGNG
つーかバカ
0031（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰNGNG
じゃあ、今後このスレでは
Cﾌﾟﾌﾟﾌﾟｯ
でお願いしまｓ。 　（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0032（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰNGNG
>>24 OKになるよ。

現状、汎用機でもLinux&JAVAの組み合わせで
プログラム組めるし。

いらないねC++

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0033デフォルトの名無しさんNGNG
Linux&JAVAだってよ
恥ずかしーな
（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0034（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰNGNG
IBM
（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0035デフォルトの名無しさんNGNG
厨房？>1
0036名無しさんi486NGNG
C++に比べるとJAVAのガベージコレクタは、便利だよな。
0037デフォルトの名無しさんNGNG
>>36
えらくまっとうな意見だな
0038デフォルトの名無しさんNGNG
わけわからんうちにメモリ沢山使ってるのがやだ。

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
いいな、これ。
0039デフォルトの名無しさんNGNG
かってにＧＣされると困るときもある。
画面がカクッってなる。
0040デフォルトの名無しさんNGNG
java -Xオプションに、gc戦略を多少コントロールできる
オプション有るよ｡インクリメンタルGCには使い道あるかもね｡
0041デフォルトの名無しさんNGNG
OS XにはObjective-C++はないのか?
0042（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰNGNG
>>38
（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0043（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ NGNG
ジャヴァだとメモリリークして困ったから
VB&VC++にしたという話が日経ソフトの今月号に

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0044デフォルトの名無しさんNGNG
Objective-C++ってどんな感じ？
0045デフォルトの名無しさんNGNG
>>43
いくよくるよ？(ｗ
0046デフォルトの名無しさんNGNG
も・り・な・が
http://www.big.or.jp/~crane/cocoa/index.shtml
（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ ?
0047デフォルトの名無しさんNGNG
CPPつったら普通、Cのプリプロセッサの事なんだけど・・・
だれも突っ込まないのが不思議
0048デフォルトの名無しさんNGNG
大文字の C を拡張子に使ってる人って実際にいるんだろうか。
0049（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰNGNG
VBユーザーの諸君
Cﾌﾟﾌﾟﾌﾟﾌﾟが無くなったらいいと思わない？
滅ぼそう。Cﾌﾟﾌﾟﾌﾟﾌﾟ

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0050＞４７NGNG
>>8 が遙か昔に既に突っ込んでおる。
0051デフォルトの名無しさんNGNG
CPP：
Center for Plutonium Production プルトニウム生産センター
Communist Party of the Philippines フィリピン共産党
Cambodian People's Party カンボジア人民党
0052デフォルトの名無しさんNGNG
Cソースと区別するためにどんな拡張子使う？
cpp/hpp
cxx/hxx

それとも区別せずマクロで切り分ける？
#ifndef __hogeh__
#define __hogeh__
#ifdef __cplusplus
extern "C" {
#endif
/*cの宣言...*/
#ifdef __cplusplus
}
#endif
/*c++の宣言...*/
#endif
0053デフォルトの名無しさんNGNG
そもそも「Ｃ＋＋は難しい」ってのが分からん。
そうは思えない俺は、選ばれた人間なのか？
0054デフォルトの名無しさんNGNG
>>53
マインドコントロールされています。悪いとは思わないよ。

C++で嫌なところと言えばヘッダファイルの
相互参照とかじゃないですか?(Cでもそうか。)
0055デフォルトの名無しさんNGNG
ヘッダファイルという仕組みがイヤだね俺は。
JAVAとかC#とかObject Pascalみたいな構造の方がすき。
0056デフォルトの名無しさんNGNG
なぜ？
0057デフォルトの名無しさんNGNG
たしかに構文上でプリプロセッサが分かれているのは実装する側からみても、使う側
からみてもメリットは少ないね。出来ることも貧弱だし。>PP
Cとの互換を取った為だろうけど。
0058デフォルトの名無しさんNGNG
大文字小文字を区別するところが糞ですわ。
0059デフォルトの名無しさんNGNG
STL なんか結局は PP だし、結構潜在的なものは大きいと思うんだけど…。

それよりも、OOA したものを素直に OOPL 出来ないのが C++ のツラい所かな。
STL がなければ C++ 絶対触ってなかったですね。
0060デフォルトの名無しさんNGNG
>>53
それはキミがC++の難しさを知らないからだ。
0061デフォルトの名無しさんNGNG
>>59
なんかあほさ漂う書き込みですね。
0062デフォルトの名無しさんNGNG
C++のどこか難しいんだ？
俺には君たちの脳の構造が良くわからないよ。

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0063デフォルトの名無しさんNGNG
好きとか嫌いとかの程度の低い批判が多いなここ。
駄目なところとか解らないところを詳しく上げてみてよ。＞撲滅派の人々

0064デフォルトの名無しさんNGNG
Delphiよりコンパイルが遅いことがダメです。
0065名無しさん＠お腹いっぱい。NGNG
つーか、いつか自然言語で開発できることをのぞmu...
0066デフォルトの名無しさんNGNG
#include <stdio.h>

int main()
{
　　printf("ども\n");
　　printf("こんちは\n");
　　return 0;
}
0067デフォルトの名無しさんNGNG
Sub Main()
　MsgBox "ども" & vbCrLf & "こんにちは"
End Sub
0068sageNGNG
10 WIDTH 80,25 : CONSOLE 0,25,1,1
20 PRINT "ども" + CHR$(10) + CHR$(13) + "こんち" : INPUT A$;
0069デフォルトの名無しさんNGNG
using System;
class itteyosi
{
　public static void Main()
　{
　　Console.WriteLine("僕の時代到来＾＾");
　}
}
0070デフォルトの名無しさんNGNG
68の言語のなんと働きのある文字列である事か、翻って69の言語の無意味な
饒舌さは理解しがたいことよ
0071デフォルトの名無しさんNGNG
#!/usr/bin/perl
print "Content-Type: text/plain\n\n";
print "itteyoshi!!";
exit;
0072デフォルトの名無しさんNGNG
どっかのスレにあったけど MIND でも使えば？
まだ存在してるとは思わなかったが
0073デフォルトの名無しさんNGNG
>66さん
#include <stdio.h>

int main()
{
　　printf(
　　　　"せっかくだから\n"
　　　　"こうやって書きましょうよ（^^;\n"
　　);
}
0074C++派の皆様へNGNG
C++というチーズはいずれ消えます。

消えたときに「チーズはどこに消えた！？」と言わないよう
今のうちによく考えておくのが良しです。
0075ドズル中将NGNG
やらせはせん、やらせはせんぞ!!
おまいたちにＣ++は!!
0076デフォルトの名無しさんNGNG
>>62
自分の脳の構造、詳しく知ってんだ？
あ、ねずみ程度だからね

（・ε・）ﾌﾟｯﾌﾟｸﾌﾟｰ
0077デフォルトの名無しさんNGNG
>>74
VBはもっと早く消え（以下略）
0078デフォルトの名無しさんNGNG
C#で(速度を要求する)ゲームの開発はつらいだろうなぁ。
やっぱりC++&asm
0079デフォルトの名無しさんNGNG
うむ。ガベージコレクタが存在する時点で脱落であろう。
かくしてC++は細々と生き残る、か？
0080デフォルトの名無しさんNGNG
>>79
誰に言ってるのかわからんが、
ガベコレも小さい領域に対して行なえば現実的な解だと思うけど？
0081デフォルトの名無しさんNGNG
プレステ２やXBOXとか、カーナビのソフトは
JavaやC#やDelphiじゃつくれません。
0082デフォルトの名無しさんNGNG
「自分の使ってる言語マンセー」、「他の言語逝ってよし」って感じの
人は、言語以前に基本的なデータ構造やアルゴリズムの知識が
欠けている傾向があります。よって、

------------------------- 終了-------------------------
0083デフォルトの名無しさんNGNG
そうだな。こんな糞スレは１と一緒に終了。

------------------------- 終了-------------------------
008479NGNG
>>80
78について言っておる。
たとえ10msでも予測不能な負荷かかったら致命的なゲームに
ガベコレが現実的な解もなにもないぞよ。
0085>>82NGNG
それ、C++派のこと？
008682NGNG
C++使いは他の言語も使える人が多いので、そうでもない。
どっちかっつーと、VB…ｹﾞﾎｯ､ｺﾞﾌｯ､ﾀﾞﾚﾀﾞ!
008782NGNG
訂正

× C++使いは他の言語も使える人が多いので、そうでもない。
○ C/C++使いはデータ構造やアルゴリズムの基礎知識が比較的ある。
0088デフォルトの名無しさんNGNG
プレステ２やXBOXで動くまともなC/C++以外のコンパイラはないんかｺﾞﾗｧ
Object Pascal 使わせろやｺﾞﾗｧ
0089デフォルトの名無しさんNGNG
> ○ C/C++使いはデータ構造やアルゴリズムの基礎知識が比較的ある。

思い込み。
C++が滅びてもそういう知識は別物。

> プレステ２やXBOXとか、カーナビのソフトは
> JavaやC#やDelphiじゃつくれません。

それ以外のプラットホームでC++使うヤツは馬鹿
特にWindowsでいまだにVisualC++を使ってるヤツは
開発が遅いので周りの迷惑。
0090デフォルトの名無しさんNGNG
>>89
Windows上でマルチスレッド/マルチプロセス処理が必要なソフトって
何で書いてんのさ？
0091デフォルトの名無しさんNGNG
一定のレベルに達していないプログラマはC++使うと生産性や安全性がが
た落ちします。
ひよこや蝿の子供にはJAVA使ってもらうほうが安心できるので俺としては
C++には引退してもらいたいです。
0092デフォルトの名無しさんNGNG
>>91
うむ、かなり正しい意見だ。
0093デフォルトの名無しさんNGNG
コンピュータサイエンス的難易度で並べると、

言語処理系開発者 - なんでもいいと思うがC/Java多し
カーネル開発者 - 歴史的にはC、最近ならC++もあり
データベース開発者 - C/C++
デバドラ/デーモンなんかの比較的低位レイヤ開発者 - C/C++
堅牢性や速度を要求されるサーバ/クライアント側アプリケーション開発者 - C++/Java？
業務システムクライアント側開発者&データベース利用者 - VB/SQL

ここから帰納するに、VB使いはアカデミックな知識がない人間が多いってことか？
009493NGNG
考え直すと、Javaで書かれてて産業レベルで使われてる言語って、あまりないな。
学生の演習だと最近はJavaで書いてそうだが。
0095デフォルトの名無しさんNGNG
需要がなければ勝手に滅びるのに、
１は何を熱くなっているのだろう．．．
0096名無しさん＠お腹いっぱい。NGNG
>>94
北見工業大学が授業でJavaだって

札幌市といい、稚内の大学といい
北海道はJavaが優勢なのだろうか
0097デフォルトの名無しさんNGNG
C++ユーザの皆様に、「チーズはどこへ消えた？」をお勧めします。
今ちょっと大きめの本屋にいけば、たくさんおいてあるハズです。

＃もちろんJava、VB、COBOL(ｗユーザにもお勧めすることは
＃言うまでもない。
0098デフォルトの名無しさんNGNG
>>97
C#ユーザーも読んだ方がいい本ですか？
0099デフォルトの名無しさんNGNG
そんな駄ボンすすめんな
0100デフォルトの名無しさんNGNG
↑ヘム発見
0101名無しさんNGNG
一般的に、JVMは何で書かれてますか？
やっぱJava?
もしＣやC++で書かれてたら爆笑だよね。
0102デフォルトの名無しさんNGNG
Javaにない機種依存の部分を補うのがJVMなのに
Javaでどうやって書くの？
0103デフォルトの名無しさんNGNG
101は無限再帰によるスタックオーバーフローでフリーズしました。
0104デフォルトの名無しさんNGNG
ネタだと思われ。
0105デフォルトの名無しさんNGNG
そもそも、C++って便利ですか？
考え方には共感できるけど、実装が面倒で嫌い
0106デフォルトの名無しさんNGNG
>101
JVMは大抵C++で書かれてます。つうか、Javaでもボトルネックのとこ
とかシステムコールとかをJNIでCライブラリコールするのは良くやるよ。
OnceWrite〜糞食らえ。
（プラットホームごとにJNIのアダプタモジュール作るんだけどね。）

なんか勘違いがあるみたいだけど、JVMってのは、ようするにJavaバイト
コードの、OS毎のドライバっすよ。Javaで書いてどーすんのよ。
0107デフォルトの名無しさんNGNG
ＪＶＭを作るための言語がJavaScriptだろうが！！
0108デフォルトの名無しさんNGNG
ある意味すごい主張だな>107
0109デフォルトの名無しさんNGNG
>>107
ネタならバナナで釘が打てるほど寒いし、本気なら敬して遠ざけたい。
0110デフォルトの名無しさんNGNG
>>107
CLRを作る為の言語がVBScriptだったら、おいらは絶対に
C#には手を出さないぞ。
0111C++ -CNGNG
C++のいらない部分であるC言語との互換性の部分をすっぱりカットした、
解りやすい言語作ってくれないかなぁ。


0112デフォルトの名無しさんNGNG
C#はちょっとだけ前進したけど、
中間コードになるのはいただけない。
0113デフォルトの名無しさんNGNG
>>112
重くて死にそうな処理をやるライブラリだけ、ネイティブのx86コードで
書くとかできると幸せかも。

Javaと違ってどうぜWindows環境でしか動かないので、仮想マシン化
する意味は薄いかも。

でも、C/C++になりガベージコレクタがあったり、VBでできないマルチ
スレッド処理ができたりとかの、これまでの弱点を補完してるのは
プログラマ的に幸せかも。
0114ＳＡＧＥNGNG
>>111
やぱり名前は ++ で決まりでしょーか。
0115デフォルトの名無しさんNGNG
>>109
>ネタならバナナで釘が打てるほど寒いし

お・じ・さ・ん♪
0116デフォルトの名無しさんNGNG
>>109
薔薇がバラバラになるほど寒いよ、おじさん。
0117デフォルトの名無しさんNGNG
>>114 ++
C++からCとっちゃったのか(w
0118デフォルトの名無しさんNGNG
>>113
ネイティブコードにコンバートするのも
技術的には十分可能なはずだから、
そういうの作って欲しいなぁ。

そしたらC++ともおさらばやね。
0119デフォルトの名無しさんNGNG
objective-Cが出てこないのはなぜ．．．
0120デフォルトの名無しさんNGNG
>>119
Objective-Cってどこで規格化されてますか？
ANSI?
JIS?
ISO?
IEEE?
0121デフォルトの名無しさんNGNG
規格化されていないと安心できないの？

AnsiがC++の足を引っ張っているのは目に見えていると思うが
0122デフォルトの名無しさんNGNG
規格化で安心する時代になってんだよ。
0123ななしNGNG
下の見て。MSが定義するとわけわかんない。
どれもCOMを識別する名前を指すんだけど。
ANSIだったら、ID/const ID &なんてスッキリ
使い分けて定義してくれると思うけど。

typedef GUID IID;
typedef IID *LPIID;
typedef GUID CLSID;
typedef CLSID *LPCLSID;
typedef GUID *REFGUID;
typedef IID *REFIID;
typedef CLSID *REFCLSID;
typedef FMTID *REFFMTID;
0124デフォルトの名無しさんNGNG
俺はホーだ
0125デフォルトの名無しさんNGNG
ホー(そう)ですか。　　　　　　　　　　　　さぶっ
0126デフォルトの名無しさんNGNG
このスレの人たちの頭はオーバーヘッドが発生しているよ。
0127デフォルトの名無しさんNGNG
>>123
前から思ってるんだけど、MSのそのパターンってなんなの？

暗号化の一種なのでしょうか？読む気が失せるという点で。(ﾏｼﾞ
0128デフォルトの名無しさんNGNG
厨房プログラマは暗号っぽいほうを好むからです。
0129デフォルトの名無しさんNGNG
>>125
バナナで釘が打てるくらい以下略
0130デフォルトの名無しさんNGNG
素人考えですまんが、GUIDがなんのtypedefかって知っている必要あるんでしょうか？
0131デフォルトの名無しさんNGNG
＞130
特にないと思う。
サイズくらいは知ってたほうがいいかも。
0132デフォルトの名無しさんNGNG
>>89
＞特にWindowsでいまだにVisualC++を使ってるヤツは
＞開発が遅いので周りの迷惑。

それはそいつのスキル（又はVC++）のせいであって、C++のせいではない。
だいたい、C++でしばらくシステム開発やってればほとんどの部分が
使いまわしで済むから早い。
そもそも、あんたのとこみたいに開発環境がばらばらなのがおかしい。
もしかしてみんなそれぞれ一から作ってんの？
0133デフォルトの名無しさんNGNG
C++を初めて見たとき（っていうかOOPを理解したとき）
夢を見ませんでしたか？これさえあれば、どれだけ
きれいなプログラムが書けるだろうと…
それなのに、嗚呼、なぜMFCなんてものがまだそこにあるのですか（涙
0134デフォルトの名無しさんNGNG
Ｃ＋＋を使ったとき余りの遅さに驚いた。
そんな俺はＣ/ＡＳＭ使い。
ゲームプログラマあがりッス
0135デフォルトの名無しさんNGNG
>>133
思った思った。
それから2年ほど、必死で覚えたさ。
インテリジェンスなプログラムが書けるだろうと・・・
それなのに、嗚呼、なぜこんなにも悩ませられるのですか（藁

時には快適なんだけどねー
0136デフォルトの名無しさんNGNG
ま、いまさらCにも戻れないので結局C++なんだよねー。消極的支持って感じぃ。
C#がモノになるならサクサク移行するぜ。
0137デフォルトの名無しさんNGNG
>127
ソースの互換性を低めてＶＣに固執せざるをえないようにするためです・・・
0138デフォルトの名無しさんNGNG
>>134
C++は遅くねぇよ。
コピーコンストラクタ呼びまくってるんじゃないのか？
コンパイルした結果をアセンブラで読んで、
研究してみろ。
仮想関数呼び出しが遅いというのなら、
それはオブジェクト指向がわかってない証拠。
フラグを設けてswitchで分岐するよりずっと速いぞ。
0139デフォルトの名無しさんNGNG
>>134
CプログラマはC++を使わないでください。
0140デフォルトの名無しさんNGNG
>>138
激しく同意。
ＣとＣ＋＋のスピードの違いを体感できる人間など存在しない。
ギャバンでも無理。
0141デフォルトの名無しさんNGNG
それかひっどいコンパイラ使わされてるかだな。
0142デフォルトの名無しさんNGNG
>>13 の人は
何となく、ライブラリーのせいだと思われ。
stlとかバリバリつかってるんじゃないのかなぁ。
0143デフォルトの名無しさんNGNG
vectorとかは下手な自作ライブラリよりよっぽど早いと思うけど、
stream系はC標準ライブラリだけで書いたものよりだいぶ遅いかもね。
0144デフォルトの名無しさんNGNG
>>138-140
確かにiostream系は遅いよ。
でも、その他は特に遅さを感じないんだけど・・・
何処がそんなに遅いの？
0145デフォルトの名無しさんNGNG
iostreamは内部でwchat_tに変換してるからじゃないかってのをどこかで聞いた。
0146デフォルトの名無しさんNGNG
C++勉強しはじめのころにVC6のiostreamの実装をデバッガで追いかけてみた
ことがあるけど、operator<<の実装ではsprintfを使っていて、しかもsprintfの
第二引数の文字列("%s%d"みたいなやつ)を動的に作っていたので、こりゃー
遅いだろうと思ったことはあるよ。
しばらく後にstd::mapとかの実装を追いかけたこともあるけど、こりゃー
まねできんとも思ったな。

で、134はなんで遅かったんだ? ただの煽りちゃんですか?
0147デフォルトの名無しさんNGNG
STLのvector,list,mapって凄いよね。
下手に作るよりずっと早くて簡単だし、
俺は重宝しているよ。
よってC++が消えて無くなると非常に困るな(藁
0148デフォルトの名無しさんNGNG
で結局 EmbeddedC++ はどうなった？
0149デフォルトの名無しさんNGNG
このスレはC++を絶賛するスレですか？
0150デフォルトの名無しさんNGNG
STLのバージョンアップって出来ないのかなぁ？
0151デフォルトの名無しさんNGNG
>>150
そう言う人は.h++へ走る(藁
http://www.roguewave.co.jp/
0152デフォルトの名無しさんNGNG
Tools.h++とかThreads.h++って実際使えます？
使わなければいけないときってどんな時？
0153>150NGNG
http://www.sgi.com/tech/stl/
SGI STLなら、VC++やgccでも使えるそうな。
hash_mapもついてくるで。
0154デフォルトの名無しさんNGNG
言語がこんなにコロコロ変わったら、コードの再利用はどーなるの？
0155デフォルトの名無しさんNGNG
>>154
コードの再利用なんて気休めだってば。
0156デフォルトの名無しさんNGNG
>>154
「VisualC++言語」にしとけ (ﾜﾗ
0157デフォルトの名無しさんNGNG
>>156
COMはどうよ？
0158デフォルトの名無しさんNGNG
Cライクな構造化言語ならどれでも大体一緒ってな感じがする。
オブジェクト指向は頭では理解できてもコーディングに完璧には
反映できないっす。C++はCのつもりでコーディングしてもOKだから良いっす。
0159デフォルトの名無しさんNGNG
C++が難解なんじゃなくて、C++の解説書が難解なんだよ。
0160名無NGNG
仕事がなくなっちゃうからやめて
0161デフォルトの名無しさんNGNG
「C++のからくり」は入門書としてはよいぞ
0162デフォルトの名無しさんNGNG
158はドキュソ
0163デフォルトの名無しさんNGNG
「Effective C++」もお勧め。
0164デフォルトの名無しさんNGNG
>162
言わなくてもわかる。
0165デフォルトの名無しさんNGNG
Ｃ＋＋ってデバッグしにくくねえ？
オーバーロードが入り組んでたりとか、コンストラクタの順番で起こるバグとか全然見つかんなくてかなりイヤ。
あと人のソースってＣ＋＋だと壊滅的に読めないのもイヤすぎ。
0166デフォルトの名無しさんNGNG
確かに人の作ったクラスを継承しようとすると結構苦しいなぁ。
0167is_Aよりhas_Aの方が簡単なのは火を見るより明らか。NGNG
クラスは極力継承しない！
これは複雑化を避けるための鉄則だよ。
0168デフォルトの名無しさんNGNG
C++なれると、Cが使かえなくなるのはアホですか？
全部開けっぴろげで、どうせ〜ちゅうの
0169デフォルトの名無しさんNGNG
C++は言語仕様が破綻している。
Objective-Cにしとけ。
0170デフォルトの名無しさんNGNG
>166
実装継承はね。インタフェース継承ならやるでしょ。
0171デフォルトの名無しさんNGNG
>>168
C++はCに比べると簡単すぎるのでしょうがないんじゃない。
C++しか知らない奴はﾄﾞｷｭｿっぽい。仕様分析からできる奴は別だと思うけど。
0172デフォルトの名無しさんNGNG
なんでほろぼさにゃいかんのだ。お前が滅べ。
0173デフォルトの名無しさんNGNG
>>171
どんな奴だ？C++で人のライブラリ使うだけで何かを作るのは
アホでもできることだが、それで「C++できる」といってしまう
ようなイタイ奴しか知らないんだね、あんた。

C++でのライブラリ作成は奥の深い世界だ。
0174デフォルトの名無しさんNGNG
>C++はCに比べると簡単すぎるのでしょうがないんじゃない。
>C++しか知らない奴はﾄﾞｷｭｿっぽい。

えっそうなの？ ヌルいC++プログラマは Cな人以下なのか
windows環境なので今時 Cに触れる機会ないんですよねぇ
0175格闘バルーンNGNG
>>173

使う側も含めて言語を評価しねーとただの変態コーディアンだぜ。
全員がライブラリ作ってて開発効率上がるかっつーの
0176172NGNG
>>173,174
C++だとしょぼいコードでも動いちゃうじゃん。
Cだとしょぼいコードを書くと速攻で自分の首しめちゃうから、
ある程度淘汰されているってことを言いたかった。
だから、きちんと分析して書いてるやつは別ってわけ。
0177デフォルトの名無しさんNGNG
「しょぼいコード」なるものでも動くのは結構なことでわ。
0178デフォルトの名無しさんNGNG
>言語がこんなにコロコロ変わったら、コードの再利用はどーなるの？

C++は最初の標準規格が制定されてからまだ一度も変更されたことが無いのでは？
規格の改訂があったというニュースは聞きません。
0179デフォルトの名無しさんNGNG
>>178
つーか策定されたのつい最近じゃん。
0180デフォルトの名無しさんNGNG
>>174
>windows環境なので今時 Cに触れる機会ないんですよねぇ

Windows APIはＣじゃん。
0181デフォルトの名無しさんNGNG
>>174
>windows環境なので今時 Cに触れる機会ないんですよねぇ

Windows APIはPASCALじゃん。
0182デフォルトの名無しさんNGNG
はあ？__stdcallだろ。
いつの時代だよPASCALって
0183デフォルトの名無しさんNGNG
stdcallは実体はpascalコールじゃなかったけ？
0184デフォルトの名無しさんNGNG
ちがいます。
0185183NGNG
>>184
あ、そうなの？

アセンブラで昔試しに書いたときに

push MB_OK
push OFFSET msgstring_a
push OFFSET msgstring_b
push 0
call MessageBoxA

で普通に動いてたけど・・・。どこらへんが
違うのかな？ retもret nを使ってるよね。
SPを戻してないし。

別のことを言ってるのかな？
0186かいNGNG
>>167

has-A支持派って言う人は
Smalltalkとかもやる人ですか？

is-A支持派の極みがEiffelなんですよね＞どなたか？
0187デフォルトの名無しさんNGNG
>> 183
関係ないが昔ヘッダの __pascal コール見て
Win は pascal で書かれているっていうバカが
大量に発生してたこと思い出した
0188デフォルトの名無しさんNGNG
>>186
Eiffelには詳しくないんだけれども……
多重継承を積極的に活用するという意味ではis-A支持派なんだろうけど、
has-Aで済むところをis-Aにしようというほど積極的にis-Aにするものではないでしょう。

クラスを積極的に継承しないという発言は、
ポリモーフィズムを利用しない（＝オブジェクト指向しない）
とも受け取れかねないのでやめたほうがいいと思います。

ところでEiffelの継承元クラスのメンバのリネーム機能、
C++にも欲しいんですけど……。

Eiffelは、多重継承、テンプレート（ジェネリックプログラミング）などの実装がいいけど、
あのPascalに似たスタイルがどうも馴染めなくて……。可読性も悪いと思うし……。
JavaやC#みたいにCをベースに拡張していくのが正解でしょう。
だけどこれらの後発の言語は、とっつきやすさを重視しすぎていて、
C++やEiffelと比べると中途半端なところは否めない。

そもそもオブジェクト指向が普及しているとは言えないこの状況で、
Java派の人たちがC++のことを理解した上で批判しているかどうか疑問。
型安全なコンテナクラスが無いことをもっと危機的に感じて欲しい。

それでも、Javaが普及して、UMLやデザインパターンが広まるのは素直に嬉しい。
これまでオブジェクト指向に対するネガティブなイメージがなかなか取れなかったけれど、
Javaがトレンディな言語というイメージがついたことで、
オブジェクト指向が広まるいいきっかけになった思います。
Javaが気に入ったら、UMLも覚えてね。>ALL
0189183NGNG
>>187
はぁ、そんなこともあったんですか。Pascalコールなんてのは
add sp,nが省けることで、少しは速い＆ちょっとコードが小さくなる
程度の利点ぐらいしかないとは思うけど。まぁ8086のころのようにCPUが
遅くてRAMも少ないころは大きな意味があったんでしょうけどね。
Winの場合はSpeedを少しでも稼ぐ方かな。

結局、なにが違うのかな？　ちょっと気になってgoogleとかで情報を
漁ってみたけど、みつけられなかったし・・・
pascalコールの定義が間違ってるのかな？　わたしは、引数逆順でス
タックに積んでret nで戻す呼び出しだと認識してるんですが・・・
0190190NGNG
>>181
呼び出し規約がPASCALだと
PASCALで書かれてるんですか？
0191デフォルトの名無しさんNGNG
>>190
二回繰返した方が良いかも（謎
0192デフォルトの名無しさんNGNG
>>189
x86 プロセッサだと、ユーザプロセスからコールゲートを介し
て OS のコードを呼び出したときに、自動的にユーザスタック
上の引数をカーネルスタックにコピーする機能があります。

この場合、OS のコードの最後で ret n する (PASCAL 呼び出
しにしておく) と、ユーザスタックとカーネルスタック両方か
ら引数を取り除ける。

Windows の API 呼び出しって、この機能を使って実装されて
たりしません？

# 最近の PC UNIX だと lcall 使わずに int 使うのが流行り
# だけど。
0193183NGNG
>>192
なるほど。そういう便利な使い方もあるんですね。久しぶりに
放置してあったプロテクトモードプログラミング本をひっぱり出して
みてみました（ｗ

でもAPIの場合はプロセス間をまたぐわけでもないので、これを目的と
して作っているのかは？のような気はしますが・・
内部的には使ってるかもしれないけど。むむ。
■ このスレッドは過去ログ倉庫に格納されています