C++の将来性。。。

。。。使われなくなってきてることありません？？

いや、Delphi6 と JBuilder6 が発売されたのに
C++Builder6 が発売されないので、ちと不安になってきた次第。

STL無くって移植しにくくてパスカルだしの Delphi も、とろくさそうな Java もヤル気しないし・・・
C++でできんことは無いだろにな〜。

んー、愛しのC++がFORTRANみたく情報処理試験から削除されたり、
コボラーみたく揶揄されたり、の世界が待ち受けてるんかなぁ。

C++使いの人は自信満々な人が多そうなので、こんなこと思う人は
おらんのやろな・・・とは思いますが、布団にもぐってふと思ったので、書き込みしてみました。

C++の近未来ってどんな感じでしょ？？

ボチボチじゃない？

&Heart;

C++の将来は君たちの肩にかかっているのだ。がんばってくれたまえ。

Javaの方が危ぶまれている模様。
すまんが実戦のパスカルを見たこと無し。

情報処理試験にC++なんてあったか?

♥

ぼちぼちすか。。。オブジェクト指向を分かってるつもりで設計していざ実装が進むと、んーって程度のヘボですんで、
理論にハマるよか、違う言語の文法でもかじったほうがいいのかなぁ。。。と。

VBを破綻しない範囲で使いこなす。これ最強。

>>6
ないっす、すんませんす。

巨大ファイル or 速度重視のファイル入力以外では 何も考えずにTStringList->LordFromFile() とか
やっちゃってます...いまじゃ２種受からないかも

♥
♤
♣
♢

>>9
昨年度に初めてVB使いました。
継承の仕方がわからんかったので
コレクションのメンバ？にコレクション（クラスだっけか）をじゃんじゃん入れ子しました。
多重継承はいらんのですが、せめて継承させてほしい。

でもコンパイルは速い（しなくてもいい？）VBは意外と使いやすいす。

。。。C++以上にVBやばいのでは？

ஹஸஷவழளலறரஐஒஔகஅஇஇஉஈஊஞிாௌொெ௯௭௪

&rlo;なぜ荒れてるんだ？

C++は複雑だけどいい言語だよ
OOがいつまで持つかわからないけど

あ

こんなスレもあります。
&rlo;http://pc.2ch.net/test/read.cgi/tech/1008349566/

残ります・・・が、専門性の高い分野になるでしょう。
現在のハードウェア産業のような位置づけになると思います。

ＶＢは消えます。新規にこれを使う理由が何もない。

C++ nanka ni mirai ha nai(w
ha ha ha

Ruby ga saikou.
http://www.ruby-lang.org/ja/compar.html
C++
いろいろと有名なオブジェクト指向言語であるC++とRubyを比較すると:


C++なぞ問題外．^^;;;

omaera ni taisuru keibetu no nen ha hukai zo

>>19
信者ウザイ！！

Rubyなどと比較してもらえればC++の将来は安泰です。

>>1
おれはDelphi6が出ていてもDelphiのほうがよっぽど心配だが。
ってか、なんでC++Builder待ってるんだ？

Stanley Lippmanの『C# Primer』
http://www.dotnetbooks.com/listings/bookdetails.asp?isbn=0201729555

Charles Petzoldの『Programming Microsoft Windows with C#』
http://www.microsoft.com/mspress/books/5188.asp

この２冊だけ見てもC/C++の将来なんて明らかでしょ？

>>24
ペゾルト本までC#。(;´Д`)
WinAPIを直接使う時代は本当に終わりなんだな。

飯前に仕事がヒトくぎり付いたので、覗きに来ました。

>>23
FORTRANにいそしんでいた頃ですが...
Delphi1を発売日に購入し、パスカル（や馴染みのないWindows環境）に1日で
挫折し、Cの本を買ってきてC++Builderにかけることを決意したのでする。

Delphi vs C++Builder
○Delphi用のVCLは作れませんが、Delphiのユニット使えます
○#include <vcl.h> を削除して、atoi()とかpowl()とか使わずに堪え忍んで
　コーディングしてれば、他のOSへの移植もほぼ大丈夫
●Delphiのコンパイルは速いっすね。インクルードぐるぐるな私のC++プロジェクトは
　最悪な遅さです。

C#ってね、C++とJAVAとVBのイイトコどりしたような感じだなぁ、と昨年度の
VBプロジェクトで感じました。MSでなければ飛びつきます。

というか、C＃（ドットネット）って
DOS->Win16->Win32 みたいに、下位は継承して新しい環境作るぜって事ではないの？

>>26
> MSでなければ飛びつきます。

（　´,_ゝ`）ﾌﾟｯ

&rlo; http://pc.2ch.net/test/read.cgi/tech/1010414590/l50

１よ　こんな板違いのクソスレたてるヒマあんならDelphiくらい覚えろよ
　　今なら半日でつかえるようになるだろうに

>>27
すんまそん、C#勉強不足なんす。

昨年のVBプロジェクトでは、VBは.netになるとIntegerとかの型の
大きさが変わってあとが大変そうなので〜って客に懇願したのですが、
deleteされちゃいました。微妙に環境の継承に支障もあるかな〜と。
その点JAVAはint=32でしたっけ、いさぎよいと思うし、
環境に任せる C, C++ はもっとステキだとも思いますが...笑。

VBの余談ですが、this の同義語？が Me なのは笑っちゃいました。

>>31
VB8ではthisの同義はXPになります。

>>24
すぐに反応できませんが、読んでみます。

>>26
反応ありがとうございます(w

VBにしてもC#にしても秀作ではあると思います。
MSだから嫌いというのはあるのですが、
MSならなんとか普及させるだろ、ってのも考えます。

・BCBから寄り道してDelphi(そりゃ一番に考えます>>30)
・MS嫌いだし合理的な文法だからJAVA(でも、SunもMS同様鼻につく)
・なんだかんだ要ってもMSの世の中だしC#(MS倒産しないかな...)

んー第２言語の選択に悩んでるんだね俺（と気づいた）

>>32
VB8のエディタは自動的にXpにしてくれます、多分。（おもしろくない...）

さて、仕事します。。。

>>30
何が板違いだかサパーリわからん

道具話しはプログラマ板でという事だったからね>>34

まあ時に連れて世の中なんて変わるもんだけど、
　冬厨のおかげで今の惨状という事もお忘れなく。

板違いといちいち書かれなかったのは
冬休み中は書いても荒れるだけだという事でご理解下さい

>>35
冬休みは終わったはずでは･･･

C系が消えることはまずないでしょ
とりあえずJAVAは消えてくれ

>>1
房ランド = RAD
C++ != RAD
ってだけだ。

JAVAはC系じゃなかったのか・・・

>>39
JAVA言語としては良いかもしれんが
まわりの環境が糞

SUNが死ねば.NET天下になってPGは楽だな
恐怖政治と引き換えだがね

そう言う漏れはObjectiveで遊びちぅ（へらへら

>>40
やっぱマシンバイナリ吐けないってのはやばいと思うよね

C++は大丈夫さ。

>>18
日経エレクトロニクスとかの広告記事で、C++でLSI設計するのが活気的、てなことが
よく書いてあります。私はLSIのeもわからんですが、これから主流になっていくんでしょね。

>>35
板ちがいすんまそん、です。

>>41
MSが死んでもSunの恐怖政治始まっちゃいそうす。
悪人ヅラのMSと偽善チックなSunとで丁度よさげです。

>>42
マシンバイナリ吐けるJAVAコンパイラ？みたいなのはSunに怒られちゃうのでしょか。
OS替えの予定なしにJAVAでサーバアプリ作ってるケースでは、喜ばれそうですが。

む板ってことで...今簡単なGISもどき作ってて、こんなことしてます。
・多角形の三角形分割
・三角形の面積計算
・交差や包含の判定
・スプライン
・レイヤ処理
なんでこんな低レベルからせんといかんのだろって感じです。（幾何音痴の泣き言）
楽しいですが...いいジオ系？ライブラリないですかね〜

ハードが高性能化してVMでも問題なくなるとか言ってるけど
ほかの言語だってもっと速くなってるんだよね

>>45
んーWin3.1とTurboC（の頃）では、生Ｃのコンパイルも結構時間食ってましたが、
今では（小さいソースだと）秒殺ですからね...５年後ならJAVA-VMもＯＫかと。

>>38
RAD環境とは無関係だけど、親切なエディタだな〜とか思いません？

C++とはあまり関係ありませんが

>>44
昨年後半はGISの同じようなプログラムを作っていました。

・三角形(ポリゴン)の面積計算
は非常に簡単ですが

・交差や包含の判定
は極めて難しかった。辺の交差情報だけからは判定できな
いからね。

・スプライン
見た目の美しいスプラインにするのが大変でした。

・レイヤ処理
ラスタレイヤがあったり、データがメモリに載らないと大変。

当方も幾何学など忘れはてていたので、座標系変換やクリッ
ピングなど、ややこしいことばかりでした。ポリゴンの数も
半端じゃないので、高速化の工夫も必要だし。

参考書だけで20万円は買ったかな？

>>47
湯上りでほこほこっす〜男ですが。

・三角形の面積計算
　ヘロンの公式をそのまんまで実装し、テストもせず放置。
　底辺10000高さ1みたいな三角の面積ちゃんと出るんかな〜みたいな。

・交差や包含の判定
　有向線分２本の交差判定のセンで頑張ってみましたが、
　線分端点が他方の線分に乗るときdouble型の値で判定するのが
　気持ち悪いのと、凹多角形での判定ロジックがつめれなかったので、
　多角形を正規化して三角に分けて、その三角と点との包含判定で
　乗り切ろうかと模索中です。

・スプライン
　Cによるスプライン関数、って本の実装しなおしで勉強中。
　周期パラメトリックスプラインってやつでコンターを書く予定っす。
　コンターの等値領域の面積計算せんといかんのが、難関の予定っす。

・レイヤ処理
　class TLayers : TObjectList
class TLayer : TObjectList
class TMapObject : TObject
とつらつら書いてフォトショップの画面とにらめっこしてます。
　破錠回避の先読み...プログラムの面白い瞬間でもあります。

やっぱ、なにげにポリゴン多いですよね...面積計算とかの誤差膨れそうだし。

ま、こんなこと考えながらスレ立てたので、むいたなのです

>>40
なにこれ。

C++大好き。
ってか作り貯めた自作ライブラリなしでは何もできん･･･

>>49
まわりにJAVAできる人いないとか、
CPUが286とか...ってかどんな風に糞なんでしょ？？

>>50
言語うんぬんより、蓄積ですよね、ごもっとも。

＜凹多角形の包括判定
ラスタライズが前提なら、交差する辺の数で判定できるんだけどね。

VMは逝って良し！

>CPUが286とか

Wabaなどを使えば8...16bit CPU環境でも
いちおうjavaできるYO!
誰かMSXにWaba依嘱しろ。

というかjavaソースをネイティブコンパイルすればいいんだし。

むしろJAVAを持ち上げてる連中が気に入らん

>>1　はそもそもC＋＋というよりBCBのことをいっているのだと思うけれど
BCBは結局PASCALをコアに使っているわけだから半端だし
リンカが遅いからDELPHIのがよっぽどまし。

C++は別にベストではないけれどとりあえず機械からも人間からも
遠からずちかからずでいいんじゃないかな？

コンピューターに結果を求めるか
単にプログラミング言語遊びをするかで見方が変わってくると思う

JAVAやVBがプログラム全部に向いてなくてもCOM呼び出しとか
出来合いのもの使うのには向いていると思うし
C＋＋以外のものは基本クラスをチョコチョコ変えられて
根本的な互換性を無くす恐れがあるから(関数レベルは別として)
そういう意味でも”中間言語”としてC++ & Cは価値があると思う

C++とDelphi/VBを比べるのはおかしい。

C++と比べるのならPascal/Basicでしょ。
Delphi/VBの相手はVisual C++。

>>56
C++ の基本クラスって何よ？
C の基本関数&構造体群だったら まだわかるけど。

その通りだけど>>57

環境とアプリが複雑化して、言語だけでは比較出来ず、ツールでなければ比較出来ない時代だね。
C++がどうか、ではなくて、C++/STL or VCL or MFC、Delphi/VCL、C#/CLRはどうか、って感じ。
VBは生産性悪いので要りません。

！！！！！！！Luby最高！！！！！！！

なし。

*** 終了 ***

>>54
8ビットでもいけるんすか、すごいですなぁ。
ちなみに今前に座ってる人はJ2MEやってます、今の携帯電話は16ビットでしたっけ？
...浮動小数点がないけどそのうち含まれるんだろな。
ん、ネイティブコンパイルってマシンバイナリ（>>42）吐いちゃうってことですか？

>>59
そう思います。BCBもVCもC++をサポートしたC+++状態す。
C++にプロパティってない（んだっけか）し、プロジェクト構成なんてBCBのバージョン間でもバラバラですからねぇ。
VB、エディタはおりこうさんでしたよ〜RAD系ではBCBが最悪かも。

>>57
私は、>>33に書いてるようにVCへの引っ越しはハナから断念してます。
BCBはバグ取りの度にDelphi達人に近づいていきますし...多分。

>>56
C++には、ネットワーク機能やスレッドやGUIが無い代わりに、
それらの１個下の階層では標準化委員会さんが保証してくれる
ってことっすよね。上位機能はベンダー任せっていさぎよさは
環境依存や不定だらけのC, C++らしくていいかも。

>>58
んー、VBがドットネットになったら、Interger型が16から32になっちまう、
みたいな不安定さがないってことなんじゃないでしょうか。JAVAも10年後には
intが64になっちゃったりして...ずっと32って言ったじゃん！みたいな...。

飯行きます。

>>52
ラスタライズ前提ってのは、どういうことですか？
行政区領域とコンター等値領域の重なり部分面積とか
を精度を明示して出力し、どっかよその研究所に提出
って感じなんで、できるだけベクトルデータで計算したいのですが。。。

んー逆にいうと、ベクトルデータでは交差判定できないってことかなぁと思いまして。

Rubyは作者が逝ったら扱ける

>>63
基本クラスって 基本データ型とか組み込み型の事か…
ても、C/C++ のintって処理系依存だよね？

言ってる交差判定は　例えば、ここでいう
http://www.infoeddy.ne.jp/~tensyo/prog/linealgo.htm

「線分が交わるか」ってタイトルの話しと同じか？
ここには内包も２種類解説があるぞ

>>63
ある点が多角形の中にあるかどうかは、その点から多角形の外に引いた線分が、
多角形の辺と交差する回数が奇数か偶数かで判定できるのはいいですよね？
で、この方法は凹多角形でも、穴のあいた多角形でも使えるんですが、どーでしょう？

あら、かぶってるかも。
>>66の内包の２種類ってのは、穴のあいた多角形の穴を内部と見るか外部と見るかの２種類でしょうか？
って、見に行けばいいんですよね。

穴があるという事は２つの多角形に別けられるんだから

２つに別けてからそれぞれ内外判定すればいいんじゃないの？

もしかしてデータ構造として　輪郭ベクトルが並んでるだけか？

どんなにハードが高性能化しても結局仕事ではマシンの限界までカリカリに叩いちゃうので、
CやC++がなるというのは考えにくいなぁ〜
オレはゲーム系だが、仮にPS3のスペックが単純に今のPS2の十倍だとしても、
とことんまでマシンの限界まで挑戦させられそうな気がする・・・
デザイナの要求とか聞いてると。
JavaとかC#がいけるのは比較的規模が小さく、マシンにゆとりが環境だけなんちゃう？

C++だっていけてるライブラリさえあれば、ネットワーク系だろうがなんだろうが、
素人にでも十分開発できるからね。

むしろヤバいのはC#とかだと思う

>>69
２つに分けたあとの凹多角形の内包判定は、そのまま穴のある多角形の内包判定に使えますが、
わざわざ分ける理由とは？

>>71
　いやそりゃ判定は出来るけど　　合成されてしまうでしょ？
　どっちの多角形に含まれるか迄判らないんだからさ

　例えばドーナツで回転方向が同じなら
　交差判定法なら　外側に
　巻きつけ判定法なら内側になってしまう

それでいいなら使えるだろけど

何かJAVAがC++より硬牢だと抜かすバカが いるが、本気なの？
両方使った実感だが、JAVAとC++では猫に小判。
比較にならんし、する奴の気が知れない。
C++使ったらJAVAには戻れんよ。マジで。

Javaが猫でC++が小判??
つーか比べんなよあふぉかお前

>>73
> JAVAとC++では猫に小判。

C++で１バイトもリークさせない自信があるならね。

>>75
> C++で１バイトもリークさせない自信があるならね。
まともなlintを使っていないことを告白しなくともいいのに:)

そりゃぁ C++ のSTLは便利だからねえ・・・

でも便利すぎてアルゴリズム勉強しなくなる諸刃の剣　だから他の言語に移れない

>>73
> JAVAとC++では猫に小判。

あのー、「月とすっぽん」とかの間違いじゃないの？

>78　たぶんキミ正解　

いや、きっと
>>73 が猫で
JAVAとＣ++ が小判

JAVAには硬牢性のかけらもないと思う

>>73
痛い厨房だなぁ。日本語を先ず勉強しなさい。

76はlintでリーク防止できるのか。おめでてーな。

リークしてもプロセス殺せば消えるから
別にいいーだろ

>>84
アフォ氏ね。
C++で24時間動き続けるマルチスレッドアプリ作ってみろヴォケ。

Cで書いてたけど･･･
Java屋さんの一面が垣間見えました　　（苦笑）

exit()する前にfree()呼べばリークしても大丈夫だよ

>>87
そのネタ飽きた。

Rubyならなんでもおっけいです。

while(1){
exitする前のfreeは不要ですよ
}

Rubyはメモリリークだらけで使いモノにならん

func(char *x)
{
func(">>90 freeしないとメモリを回収しない処理系が有るんだよ！！");
}

void operator ()()
{
static_cast<T>(this)->func("そうだよ。ちゃんとdeleteしないと。")
}

>>85
自分が作れないからといって、それが普通だと思わないように。

↓exit前のfreeネタはここでしろ
http://1kai.dokkyomed.ac.jp/mammal/jp/species/homo_sapiens.html

>>94
だよね、何時もコードを駄目にするのは一握り(又は大部分)のダメな
PGなんだよ
でも85みたいな人でもそれなりの成果物を上げられると言う意味では
Javaは正しかった。
家の中でばかり遊んでると、お外で遊べなくなるのが心配だけど

ﾊｹﾞど
出来る出来ないと便利不便利は別次元
きっちりしたNative吐けない奴は何をやってもﾀﾞﾒ
箱庭引きこもりﾌﾟﾙｸﾞﾙﾏはあふぉぷ〜

>>97
ネイティブコードなんて今日び流行んねーんだよヴォケ。首吊れ。

JITが流行らないとでも？

JavaとかRubyてファミコンの「RPGツクール」みたいだよね
「そふとうぇあつくーる」　（^_^;;

C++分かる人はJava, C#すぐ分かると思う・・・

>>101
わかるがどちらも使いたくない

>>66,>>67
ご指導ありがとうございます。
交差数が奇数か偶数かで判定できて、凹だろうが穴んぽこがあろうが関係ない、
ってのはOKです。で、交差判定の時に、線分端点が他方の線分の端点に乗るとか線分に乗るとか、
線分が完全に乗っちますとか...の条件区分で頭がこんがらがってる状態っす。
落ち着いてよく考えてみます。
んと、>>66さんがくれたURLにあった巻きつけ判定？のDelphiソースはCに直して今日やってみました。
うまくいっとるゲではあります。（検証を進めます...）

>>69
ちなみに今やってるデータは、↓っす、ありがちですな〜。
http://www.gsi.go.jp/MAP/CD-ROM/gyo25000/indexgyo.htm
穴んぽこは、湖沼か飛び地っす。
外周ポリゴンの中で全部の穴んぽこの外ならOKって感じで作業してますよ。
ちなみにポリゴンの回転方向属性（外は左で中は右...かな）もあるので、外積使ってってのも
試しましたが、外積自体がよくわからんので断念っす（←根性なしですな）


>>75, >>76, >>83
メモリリークは得意す。lintって何すか？コードガードみたいなんかな
以前、常駐でなんとかのーてぃふぁいAPIでフォルダ監視して、逐次FTPでファイルを
キック転送するソフト作りましたが、メモリリークが原因で逐次立ち上げに変更させられました。
うな〜。>>84さんの言うこともごもっともかも。

>>97, >>98
私はBCBで作ったISAPIを置ける安いレンタルサーバがあれば満足す（←ない...）
BCB-Kylixが出てくれればなおOK、出なけりゃDelphi-Kylix乗り換え（←超高い）。
Perlは右小指が不自由でどの指も伸ばせない私にはムリ（←一応ケンジョウ者す）
BorlandがつぶれたらJavaしよかな...ん？JBuilderもなくなるなぁ。

...Brew と J2ME も C++ vs Java ですなぁ、あれは住み分けできそうですが。


>>70
ゲームなめてました。地図どころじゃなさそうですね、家族大事にしてください？？
ちなみにBCBのFTPライブラリ（NMFTPってコンポ）は世界イチ最悪っす。

↑長すぎはいかんですな>>103

>>101
幾何のURLを探すとよくアプレットによる実演？があります。
で、ソースコードもあるのですが、C++とよく似ているので
・分かった気になる
・微妙な違いがあるので、よくみるとわからない...
ってことになります。ま、実際に問い合わせあればJava書けます、と客には言ってます〜。

このスレはC++にポジティヴでよいな。
（Java使いもC++を敵視しなければ仲間なんだけどな。）

>>105
敵視してなんかないよ〜。
ただ、Java使ってると、ヒープ自分で完璧に管理するのが面倒くさく
なるので、C++をあまりやりたくなくなるというだけ。

>>106
誤：Java使い　正：一部のJava使い
Javaを敵視するC++屋もいるけどね。ごめんな。

でも、C++のメモリ管理は、ハンドルクラスとか書くとほんと気持ちいいよー。

JAVAはおもちゃっぽくてやだ

>>106
Java でもメモリ以外のリソースは、どのみち管理するのは自分の責任。C++ だとデストラクタにお任せできる
分だけ、用途によっては楽だと思うな。

（もちろん、用途によっては Java のが楽だが）

>>109
デストラクタ作らなくて良い立場の人だったら、かな？

デストラクタを作る作らないは関係ないのよ。
C++は、デストラクタを*適切なタイミング*で*自動的*に呼出してくれるから楽ってことよ。
例外発生した場合もスコープを抜けるタイミングで自動的に処理してくれるし。

Javaは、プログラマが*明示的*にリソース解放処理を呼出すか、
*制御不能なタイミング*でfinalizer(だっけ?)が呼出されるので辛いことがあるね。

>>110 ???
俺は、コンストラクタとデストラクタを書くときが一番萌え萌えなんだけど、
逝ってよしですか？

>>112
気持ちちょっとわかる。メモリ領域の神になった気分だよね。

Javaだと、VM大仏の手のひらで踊る孫悟空の気分。

>デストラクタ作らなくて良い立場の人だったら、かな？
毎回は作らないだろ。局所的なオブジェクト以外はフツー、
コンテナで包むから。
new/deleteはコンテナのを使う。
シビアな場合は独自のヒープを作る。
私は、ハードディスクのパーティション切るみたいに
自分でヒープ切って、その中でマイmalloc動かして、
不要になったらフォーマットするみたいに
まとめてあぼーん。ディスクの物理フォーマット
みたいにまとめて解決。

今時のまともなC++プログラマは、デストラクタに直接 delete を書く機会が少ないのよ。
STL、auto_ptr、shared_ptr を使うので、delete はテンプレート組み込みのデストラクタが
宜しくやってくれる、てな感じっす。

かなりの使い手と見た。
でも、mallocすか？allocatorでは？

>>116
ぐはっ。俺は、もう「今時のまともなC++プログラマ」ではないのか！鬱。

>>115-116
なるへそ、便利になったもんですね。
Generic Programming萌え。

>>117
C++ではコンテナに頼ってる。あんまりシビアな状況にはまってない。
ソースはmalloc関係(電子のお針箱センセイ)のスレで公開してるよ。

>>119
テンプレートプログラミングは萌えるな。(必要以上に)
ただ、C++コンパイラのテンプレート機能が不完全で萎えることはよくある。
gcc3.x と VC7 に期待中。

Java も JDK1.5 で Generic 導入とか。そうなったら Java へも復帰したい。

>>120
>ソースはmalloc関係(電子のお針箱センセイ)のスレで公開してるよ。
これってどこでしょう？検索しても見つからない；；）
教えてください。

今作業しているC++ソースで数えてみたが、
35000行中、new は50行、delete は10行だった。
ほとんどメモリ管理処理は手で書いてないね。

>>122
ヒーソリ公開
http://www.fuel.co.jp/rmalloc.html

>>123
私が書いてるコードだと、11000 行のコードに grep かけて

　new 66 行
　delete 3 行
　スマートポインタ (auto_ptr, shared_ptr, scoped_ptr, CComPtr) 82 行

だった。単純に grep しただけだから誤差があるけど、いずれにせよ C++ で生の delete を使う機会はほんとに
少ないよね。


ついでに、例外と return の使用頻度。

　例外を投げる　58 行
　catch で捕まえる 14 行
　return で返す　213 行

おはよです。（今朝は快速新快速全滅につき会社遅刻っす。）

>>105, >>106
JavaはC++派からみると、クチ先だけの大風呂敷を広げる小泉首相
C++はJava派からみると、過去の業績にアグラをかいてイジめる抵抗勢力
ってとこでしょうか。。。ま、インド人に負けないように頑張りましょう。

>>118
ぐはぐはっす。
auto_ptr、気にはなっていたんですが、隣のコボルプロ！さんには
auto_ptrを覚える（俺も一緒に勉強ですが...笑）よりも
deleteで明示的に殺すことをお勧めしておりました。
FORTRANの暗黙的型？とかVBのOption Explicit抜き？とかでバグ経験あるので、
迷った時は明示、の方針でしたが、auto_ptr使うようにしてみます。
明示って忘れる..鬱。

んー、上級者にお伺いを立てる時は緊張しますが、
初心者と共有することが解ってる時って、いろいろ気を使います。

じゃ仕事します。（今日は会社で毎週やってるVBA勉強会の資料作成っす...暴）

しかし、
> new 66 行
> delete 3 行
この差は何？別にいいけど。

俺もC++ソースでの、例外とretrunの使用頻度を追記〜

全ソース 35000行
throwする 203行
tryする 16行
catchする 23行
returnする 1100行

catch が少ないが、他は >>125 とほぼ同じ比率になっている。
こういう分析はけっこう面白いな。

auto_ptr<T> TClass( new T("init") )
こういう風に初期化するからでは？

☠ฺ

へえ針箱さんはfuel.co.jpの社員なの？

ふー資料作成終了。今からサービス残業で勉強会っす。
結局資料は数値地図25000行政界・海岸線っす。

わたし >>1 ですが、板違いどころかスレ違いなことばっか
書いてますが、独り祭りしてるわけでもないんでご勘弁を。

C++、まだまだ現役だなぁ...と、ちと安心しております。
100以降、ハイレベルなのか常識なのかどっちっすか？

「EffectiveC++レベル」を常識だろ！と煽れるようになりたい・・・

C++はまだまだ現役どころか普及段階かと

>>133
激しく同意

>>134
激しく同意

printf("%d\n",*((int *)0x0012FF88));

今、漏れ様のPCでこれをやると100がDOS窓に表示されるぜ

>>133
えーっ、このぐらいは常識では ?

　ISO/IEC 14882 Programming languages - C++
　プログラミング言語 C++
　ARM
　Inside the C++ Object Model
　Generic Programming - STL による汎用プログラミング
　Effective C++ 改訂二版
　More Effective C++
　Exceptional C++
　Modern C++ Design
　オブジェクト指向における再利用のためのデザインパターン
　リファクタリング

……と言うヤツがいたら、是非とも知り合いになっておきたい（ｗ

俺は規格書は斜め読みでお腹いっぱい、Generic Programming 関係とリファクタリングはざっと読んで実戦投入を
始めてるけど、まだまだ理解し切れてないって感じ。

>>138
一応、「STL による汎用プログラミング」を除いて全部持ってる。
「プログラミング言語 C++ 第3版」「Effective C++ 改訂二版」
「nside the C++ Object Model」(の訳書)は全部読んだ。
残りは、まあ斜め読みないし半分程度かなあ。
まだまだ修業が足りないと日々感じています。

>>138
わたしめも、「プログラミング言語 C++ 第3版」「Effective C++ 改訂二版」
の２冊は持ってます。アルゴリズムや言語をツクれる人ってえらいなぁ、
とか思います。
本にのめりこんで仕事してなかったりする...そのうち役に立つさ！笑。

>>134
安心っす。私への普及が済まないうちからお払い箱では困るっす。
Java方の方々からの反応もありそうですが...。

おれもなんか安心したな。

>>138
なぜか全部持ってます。
EffectiveC++とデザパタは、読んで理解した時結構うれしかったっす。
デザパタはまだ6割くらいをやっと使えてるくらいだけど。

MoreEffectiveC++は初めて読んだ時なんだか良く分からなくて、
ほったらかし。そうだ、そろそろ理解できるようになったかな？
読んでみよっと。

STL本は買っただけ…買ってすぐ、仕事がJava一本になっちゃって…

困ったときのARMなんで、ARM以降に追加された分で非常に困ってしまう。
改訂版でねーかなー

ここに書き込んでいる人は仕事がない！ああどうしよう！まわりは
忙しそうだし。。って人ばかりです。

>>138
一冊も持ってなひ・・・うりゅ〜。

>>1ですが、仕事タイムには書き込み少ないっす。夜中にも少ないんで
皆さん平和そうだなと安心しておりまする。

テスト前の読書みたく、かえって忙しい時に
こういうとこよくきちゃいません？（でも脳壊れますよね）

>>144
私は死ぬほど忙しいときは２ちゃんねるしてる暇はないんだが、適度に忙しいと現実逃避に書き込
みたくなる。そんなもんじゃない？

この不況のご時世だから忙しいのは悪かないんだが、あまり忙しすぎて勉強する暇がないのも困る。
年功序列で食ってける時代じゃないし、今日の食い扶持を稼ぎつつ、来年も通用する人材にならない
と、ねぇ。

おはです。

>>147
死ぬほど忙しかったあとに２ちゃんねるに来ます。んで、ダラダラしてたら
次忙しくなるときの準備ができなかったりする。

暇なとき、勉強ちっくなことはできるんだけど、過去案件の整理は苦手です、俺。

>138
をぉ!持ってる本の数だけ言ったら俺もかなりスゴいぞ!!
でも理解している割合はきっと消費税並みだな(鬱

んと、とりあえず２次細分１枚の描画してみました。
明日はViewport設定とか書いてみましょっと。
調べるだけの毎日から実装だけの毎日に移行...鬱になるんだろなぁ。

>>149
私も持ってる量だけは多いっす。2mちょいくらいかな。知識は10cm。。。か。

>>150
>2mちょいくらいかな。

これって、C++の本だけで?

俺の持ってるベーマガをつむと数十メートルになるよ

age

| へ へ 〃
| の の 　
| 　も 　 |
＼ へ ／
　￣￣
ニュー速板でおすみつきのAAです！
どうだ！

昔はＢＣＣとＭＳＣを買うと、マニュアルが２ｍくらいになったなぁ。

>>151
全部で2m...でした。

>>155
TurboC++forWin, Delphi1, BCB1, BCB3, BCB4, BCB5、と積み重ねても
2mいきません。昔はもっとすごかったんすか？

GISのほうは、Viewport関係のAPIを使うとTCanvas->Handleが破棄されちゃってるみたいで、
うな〜って感じっす。Linuxとかへの移植のときは、ViewportAPIの部分とかどうすんだろ...しーらないっと。

んじゃ仕事します。

static_cast<XXX>(xxx);こんなのがいっぱい

static_cast<T>(this)-> ﾃﾞｽｶ?

ついでに reinterpret_cast もイッパイ。

分割コンパイルの悪夢さえ忘れれば、C++ 最強

大量のヘッダーファイルをインクルードしなくて済むようになれば・・・

括弧好きの俺としては、C++ & Scheme 最強。
柔軟にリンクできない Scheme 処理系は逝ってよし。

キャスト連発のやつって、設計おかしいのとちゃう？
特にアップキャストが多発してるようなら明らかに設計ミスだと思うんだけど。

それにしても、本2Mって凄いなぁ。
他の言語も合わせても1M位しか無いよ俺。
結構買ってる方だと思ってたんだけど甘かった。

>>160
分割コンパイルの悪夢ってどういう事？

>>138
俺は最近不安なんだが、これ全部読んで、使いこなしてる奴のソースって、
周りの奴には理解不能になるだろ？　とくにテンプレートとSTL。
したら、足並みを乱す輩として、職場で孤立したりしないか？

周りのレベルにあわせて、非効率なコード書くのも
ストレスたまるだろうし。

俺が歴2年の派遣PGだからかもしれんが、
実際のとこ、スキルをそこまで上げてもいいのか？
あと、そこまでレベルの高い開発チームは日本に存在するのか？

漫画ならかるく2mは越える。

>>164
最近、転勤して知ったが、いるところにはいる。
ソース解析してるんだけど、わからないやら、楽しいやら

>>164
実際それが問題になってんだよなぁ。。。

レベルの低い方を基準にしても、進歩は望めない。

ま、プロジェクト全体のレベルが低くても、低いほうに合わせるのは、いくらでも出来るから、お勉強はしといたほうがいいぞ。
低いほうに合わせながら、たまぁに、平均的なモノを混ぜるのが楽しい。

一昨年にやった仕事で、クラスの仕様書に「このクラスはコピーコンストラクタ定義してないから、使うときは気をつけてね」って
かいたら、コピーコンストラクタについて、説明会をやらされたことがあって、そのときはちょっとイヤなかんじだったけど。

navi2ch初カキコ。

組み込み系のプログラムでC++を使うことってあるの？
おれはWindows上でしかC++（というよりVC++かｗ）やった
ことないからよく分からない。
どうなんでしょ。UMLなんかでも組み込み系やリアルタイム系の
本とか出てたりするけど。

>>169
学生で、プログラマになりたいと思ってるんだけど、2chの書き込みみてると、なんかあまりにレベルの低いDQN会社の話ばっかりで、なんかいやんな感じなんだけど・・・。
実際どうなの？まともな会社とDQN会社の比率は。

>>160
Bridge パターンを使って、実装を隠せ。メンバ変数やプライベートなメソッドが
増えても再コンパイルせずに済むようになる。

// ヘッダファイル
class Foo
{
　　struct Impl;
　　const auto_ptr<Impl> pImpl_;
public:
　　Foo();
　　~Foo();
　　void func1();
　　void func2();
};

// この先は Foo クラスの実装ファイルで定義　外には見せない
struct Foo::Impl
{
　　// メンバ変数いろいろ
　　void func1();
　　void func2();
};

Foo::Foo()
　　: pImpl_(new Impl)
{}

// デストラクタは Foo::Impl のデストラクタを参照する必要があるから、この
// ファイル中で明示的に実装すること。
Foo::~Foo()
{}

>>172
続き

void
Foo::func1()
{
　　pImpl_->func1();
}

void
Foo::func2()
{
　　pImpl_->func2();
}

// Exceptional C++ で詳しく解説してあったと思う

>>164
> あと、そこまでレベルの高い開発チームは日本に存在するのか？
いるところには、いる。

あと、仕事といっても業務系の大規模開発ばかりじゃないし。実際

　開発者数　プログラマは数人から、多くても十人（ただし精鋭ぞろい）
　開発期間　一年半ぐらい

というようなプロジェクトも割とあるよ。

>>159
static_cast で派生クラスへのキャストを乱用してたら、かなりヤバいソースコードだと
思うが、reinterpret_cast はそれほど危険な香りはしないけどな。

特に Win32 API のような「C 前提の API」を使ってプログラミングしてると、どうしても
必要になるし。e.g ウィンドウプロシージャの LPARAM, WPARAM の扱いとか、COM
のオブジェクトを作るときに CoCreateInstance の引数を LPVOID* にキャストすると
か alloca 使うときとか。

typedef struct {char year; char month; char day;} Date;

void hoge(int y, int m, int d)
{//引数y=1951〜2077 / m=1〜12 / d=1〜31保証
　　Date date; y -= 1950;
　　date.year = y;
　　date.month = m;
　　date.day = d;
}

１：date.year = y;
２：date.year = static_cast<char>(y);
３：date.year = (char)y;
４：date.year = char(y);

少し昔の事だけど、ｵｻｰﾝPGに君ならどうする？って聞かれた・・・
２って答えたら「３をえらばな〜この業界やって行かれへんよ」
っていわれた！！そうなのか・・・理由を聞くべきだった・・・

んな事言う奴は頃してイイよ！
Cｦﾀくさいね

Borland C++ Builder 6 age!

俺は char year; の方が気になる。

ところで、センター試験のＢＡＳＩＣて使う場があるのか

2000年問題があったのにchar year;ってなに？（w

＞３をえらばな〜この業界やって行かれへんよ

オレもおっさんだけど、そらなんやねん、とつっこみたい。
ロートルがみな(char)y;としているから、おまえもそうせい
という理由なら、そんな会社には将来はないから辞めたほうがいいで

>reinterpret_cast はそれほど危険な香りはしないけどな。

ネタだよね。ネタだと逝ってくれ（w

>>182
上で具体例あげてあるが、どれかやばそうなのはあるか?

（もちろん、やばい reinterpret_cast の使い方も存在はするけどさ）

>>175
＞static_cast で派生クラスへのキャスト
そんなこと、出来るの？？

>>184
ポインタや参照の話と思われ。

Ｃ言語はアセンブラを記述する代わり。生き延びる。
Ｃ＋＋なんて中途半端な意味論もった言語は消えてよし。
ＳＴＬも中途半端だし、OCamlのfunctor見習え。
Ｃ＋＋はOOへの橋渡しとしてちょっとＣを拡張してみただけ。
JavaでJITもいやならCGJとか使えばよい。
速さは実装の問題で言語とあんまり関係ないし。

すみません。間違えました。CGJじゃなくてGCJですね。
ひくつになります。

C++は教育用言語としての価値はあるから
いいんじゃない？C程のものじゃないけど。
それだけあればもう十分でしょ。
実際にあるコンパイラもこなれてきたし。
一番辞めて欲しいのはユーザー数が減っているときの
無意味な仕様拡張。これをやりだしたら
末期症状だね。

Ｃは言語からアセンブラへの変換の様子がわかるし、
意味論が皆無だから逆にいいと思うのですが、
Ｃ＋＋は下手に言語に意味をつけたために無意味なポインタへのキャストなどが
現れて教育用に適してない気がします。
char型と整数の足し算なんてできるから初心者は混乱するし。
工夫すればそういうのは回避できる問題。
ポインタと整数の足し算ができるから、ＧＣもうまく実装できなくてどうしてもゴミが残るし。

http://www.amazon.com/exec/obidos/ASIN/0521750334/
こんな本が出るらしいけど、実際に売れるんだろうか？
いや、売れて欲しいｗ。

>>189
> 無意味なポインタへのキャストなどが
たとえば?

>>189
＞char型と整数の足し算なんてできる
＞ポインタと整数の足し算ができる
Cでもそうだけど、なぜC++だと問題なのだろうか？

>>192
むしろ C++ だと STL に string, wstring ある分、文字列の扱いは明確になってると
思うけどね。

俺は C だとたまにバッファオーバーフローのバグを出すけど、C++ でその手のバグ
は滅多に出さん。STL さまさま。

>>192
俺も疑問に思ってるけど、>>189の「意味論が云々」という所ではないだろうか？
なんのことだかさっぱりわからないけど。

なぜ C のソースから出力されるアセンブラが想像できるのに、C++ だと想像
できないんだ?　最適化後のコードはともかく、最適化前の状態ならだいたい
予想つくだろ。

例外とか多重継承時の仮想関数呼び出しとか C++ 固有の話はいくつかある
けど、そんなに難しいことはしてないぞ。（自分で考え出せと言われたら、ちと
辛いが、既存のレポートなんかを読んで理解するのは、それほど難しくないと
思う）

いっぱい返事があってうれしい
>>191
例えば、浮動小数点のビットごとの内容を見るときに、ポインタとってintポインタにキャストして
中身見るとintとしてみることができますよね？アセンブラなら仕方ないけど、データの表現している
実装依存の内容を別の見方で見られるわけだから、こういうのはバグの原因になる。こういう変換は専用の
プリミティブ関数を用意すれば防げる。
>>192
文字とintを足すっていうのも実装依存の問題で言語的な意味をなしていない。Ｃ＋＋はＣよりも意味を
加えることで言語に制限を加えているから、中途半端なことせずにこういうのも制限すべきだと考えます。
Ｃはアセンブラの動きをもっとも直接的に記述できる言語だと思うから、必要性という面でよいと思います。

ＳＴＬは引数に型を指定できて便利だけど、バイナリを作るわけじゃなくてコンパイルごとにその型専用の
コードを生成するから分割コンパイルができない。記述力は劣るけど、Ｊａｖａのクラスはできるし、
Ocamlとかもできる。

>>196
ネタだったのか…

電波だろ。

「C++は、どうしてJavaじゃないのか？」って>>196の叫ぶ声が聞こえてくるようだ…

JAVA＝＝糞言語

ごくろうだったな　>>189にレスした奴ら

>>199
C -> C++ -> Java
-> C#
っていう流れでしょ？C#の実装見ればC++のどこが糞であったかがわかるな。
糞であったからこそC++で削られた部分が大きかったわけだ。
C#はMicrosoft版Javaだし。Javaよりは機能豊富だけど。200はFALSE。

>>202
200 が false なのはともかく

C -> C++ -> Java -> C#

ってのも false だ。目的としているところが微妙に違うから、C を C++ で全て置き換
えるのは無理だろうし、C++ を Java で置き換えるのも無理だ。

包含関係じゃなくて、言語が開発された順番だよ。言語の持つ機能をできなくする
ってのも重要なことってこと。Javaとかはセグフォルとかのバグを減らすために
ポインタの演算をなくしたんでしょ。
ＣはともかくC++,C#,Javaはソフトをなるべく作りやすくって意味で目的は
似てると思うけどな。

あとC#とJavaは並列に書きたかったけど失敗しました。

C++がダメだって言ってる奴って
今までなに作ってきたの？
VC++とかBCB使って業務アプリ？
まさかね〜ｗ

205のいっている意味がよくわかりません。

>>204
C, C++ に関してはハードウェアよりのソフトウェア開発も主要な用途の一つだから、
ほとんど生のメモリが見えるようなポインタの実装やポインタ演算は必要でしょ。単
に用途が違うんだよ。

>>207
189はそういった用途にC++を持ち込むなと言いたいらしい。

速さをあげることが重視されるような部分とかシステムに直に触る
ような部分部分はcrucialなバグを出さないためにもsoとかdllとして
できるだけ小さい関数で実装する。ライブラリがきちんと作ってあれば、
これらのライブラリを使ってソフトウエアを作る場合には重大なバグは
でにくい。

オブジェクト指向は速さよりも大きいソフトを作りやすいように設計してある
わけだから、むしろそういう低レベルな部分はライブラリに任せて全体を統括
する部分を担当するべき。
Ｃ＋＋はオブジェクト指向の過渡期にできたから必然の仕様だけど、
JavaとかC#ができたならそっちに移行すべきだといいたい。
僕もＣ＋＋は使ってきたけど。

次世代のスタイルは複数の言語を階層的にって感じかな

Javaや.NETが動かない環境の方が圧倒的に多いんですが。
WindowsやSolaris上でアプリ作るのに.NETやJavaが
いいというのは分かるんですが、そんな話を一般化して
どうするよ。

C++をオブジェクト指向のために使うのはあまりにももったいない。
そんなくだらないものに執着しなくてもよいように、いろんな機能が
テンコ盛りになっているんだから。

C++の方が生産性が高いと思うんだが、
それは俺がヘタレだから？
前に見たプログラミングコンテストなんかじゃ
Cの方が圧倒的に成績よかったぞ。

>>212
C＋＋ってそんな特殊な機能があるの？
>>213
C++は生産性をあげるために速さをちょっと犠牲にしてる。
速さならＣとかMLのほうが上。

>>209
> 速さをあげることが重視されるような部分とかシステムに直に触る
> ような部分部分はcrucialなバグを出さないためにもsoとかdllとして
> できるだけ小さい関数で実装する。
ネタは sage てな。

その共有ライブラリを扱う部分なんかを実装するために使われてるんだって。
いまどきの OS は便利な機能を当たり前のように提供してくれてるから感覚が
麻痺してるのかも知れんが。

>>214
ちょっと犠牲にしてるといっても、仮想関数呼び出しで this の間接参照が発生する
可能性がある（クラスが固定されてれば発生しない）とか、多重継承時にオフセット
演算が発生する、なんつーのは

　C でも同じ事をやろうとしたら、やっぱり発生するコスト

だから、関係ないよね。ソート処理なんかに関しては qsort() が関数ポインタを
引数に取るため関数呼び出し分だけのコストがかかるのに対して、STL だと簡
単な場合にはインライン展開可能になるから逆に速いし。

C++ でコストがかかる処理といったら、俺は例外周りぐらいしか思いつかないなぁ。
アレはスタックまき戻しをやるために細工が入るから、どうしてもコストがかかる。

>>216　テンプレートはアダバナかもしれないよ

インライン展開が早い時代はCPUの性能向上につれて終ってしまった。
関数呼び出しを使っても短く、出来るだけキャッシュがヒットする方が速い時代に

>>215
だから、ほんとにアセンブラレベルでやらなきゃいけないライブラリは
Ｃとかアセンブラで実装して、それを使うソフトウエアとか高レベルの
ライブラリは安全の保障されたＣ＃とかＪａｖａを使えっていってんの。
Ｃ＃もＪａｖａもＶＭはさんでそれを実現してる。
ＤＬＬは知らんけど、基本的なsoは全部アセンブラかＣで書かれてる。
共有ライブラリ＝低レベル　ではない。

>>217
> インライン展開が早い時代はCPUの性能向上につれて終ってしまった。
そんなことはない。文字列のソートとか、文字列をキーにした hash や木構造を
作るような場合（それって割とあるでしょ?）、インラインにするか strcmp 呼び出す
かで、かなりコストが違うぞ。

>>216
本当に速さが必要な部分ではクラスは使わないといいたかったんですよ。
あとＣ＋＋は基本的にtail call eliminationが実装されてないらしいし。
ペンティアムとか多段のパイプラインがあるＣＰＵだとjump系の命令は
オーバーヘッドが大きいし。これはＣでも同じかもしれないけど。

＞jump系の命令はオーバーヘッドが大きいし
C++だと、Cと同じ事するのに条件分岐が増えるように読めた私は、小一時間ですか？

>>218
何を主張したいのかイマイチ分からんのだけど

　従来 C, アセンブラでやってた部分は、そのまま C, アセンブラでやれ
　(そこに C++ の出番は無い)

　従来 C++ でやってた部分は Java, C# でやれ
　（そこにも C++ の出番は無い)

よって C++ 逝ってよし、と言いたいの？　想定している世界が両極端すぎっつー
気がするが。

>>220
> 本当に速さが必要な部分ではクラスは使わないといいたかったんですよ。
3D 処理のための行列／四元数演算とか画像処理でも、当たり前のようにクラス
ライブラリが使われてるけど。

テンプレートはタイプセーフなのも重要だと思うが。

>>222
そうそう。今はまだＣ＃が普及してないし、ライブラリもＣ＋＋を対象と
したものが多いから極端かもしれんけど、Ｃ＋＋の将来性の話だからありかなと。

>>223
画像処理の４次行列関連では表面的にはクラスとして提供されていても
その中ではＣＰＵのベクター命令が呼び出されてると思うけど。
僕が言ってるのはクラスの中身をアセンブラでってこと。

>>225
将来の話なら、従来 C やアセンブラでやってた領域に C++ っつーのも十分に
ありな話だと思うけどな。実際、組み込み用途でも C++ コンパイラが提供される
ケースが増えてるし。

>>226
> その中ではＣＰＵのベクター命令が呼び出されてると思うけど。
それだとむしろ、C# の managed なコードで実装したらコストがかかりすぎて実用
にならないし、unmaged で実装したら C++ から直に使うのと安全性が変わらない、
という具体例という気が。

>>227
そこもＣ＋＋でなくてはいけない理由はないのでは？
Ｃとアセンブラで書かれたライブラリがあって、ソフトウエアはＣ＃で
書いたほうが生産性も安全性も上のような気がしますが。

>>228
すいません。managedなコードが何か知らないのでなんとも返答できませんが、
例えばJavaだったら、Java3Dは３Ｄの画像処理用のクラスライブラリは提供
されているが、その実装はOpenGLによって速さ重視でされている。というようなことを
言いたかった。

>>209
＞ライブラリがきちんと作ってあれば
ここで、「速いけれど危険なコード」が「エラーチェックなどが十分された、頑丈な（でもオーバーヘッドのある）コード」
にすりかわっているという罠

>>229
組み込みで CLR は動きません、今のところ。

>>232
携帯電話だと Java は動くものが多いが、だから「安全」になったかというと、そう
でもないわけで。Java は良い線は行ってると思うが、銀の弾丸になるには程遠い
よ。ちと期待しすぎ。

>>231
言わんとすることがよくわかりませんが、
速く安全なコードを作るためにはできるだけ小さい関数にする方がよいから、
Ｃかアセンブラで。ってこと。罠はなんだったのかわからんですけど、
よかったらかかってみてください。

>>229
ここは将来性の話。
>>232
安全なライブラリがかかれていればＪａｖａは危険なコードはかけないけど、
C＋＋だと十分に危険なコードがかけてしまう。携帯電話は安全どころか
機種によってライブラリの動作が違うというなかなか弱った媒体ですね。
将来のことなんで期待させてください。

>>234
同一の機能を提供する場合、コードのサイズと安全性に正の相関があるの?　確か
にアセンブラできっちりチューニングして書けばコードのサイズは小さくなるけど、だ
から安全かというと何とも。

コアな部分は仕様を抑えてコンパクトに、っつー MicroKernel の思想は否定しない
が、それと言語を絡めるのは無理があると思われ。

>>235
209 が考える「危険なコード」の定義をはっきりさせた方が良いと思う。人によって
かなり認識に差があるので、話がバラバラの方向向いてるし。

「Ｃ＋＋は、絶対に将来無くなるよ！」
「いつごろ？」
「Ｃ＋＋の存在意義が無くなる頃さ！」

>>236
コードサイズが小さいとバグが出たときの危険個所の特定が容易ということ。

>>237
下手なこというといろいろ揚げ足とられそうですが、セグフォルを出すコードなど。
ＯＳが危険とみなしてインタラプトするわけだから。あとセグフォルにならずとも
書き換えるべきではないメモリ領域を書き換えてしまうものとか。
あとはなんですかね。バッファオーバーフローとか？
スタックがあふれてしまうのもそうかも。ＳｕｎのＪＶＭだとセグフォルになるけど
ＩＢＭのＪＶＭはちゃんと防いでくれる。だった気がする。

>>239
> 下手なこというといろいろ揚げ足とられそうですが
そんなことを気にしてたら２ちゃんねるで生きていけませんって。下らん突っ込みは
適当にあしらって、面白い議論だけ参加すれば OK。

セグフォル = segmentation fault で良いのね?

>>240
そんな暖かい言葉　２ちゃんねるではじめてかけられました。
妙に幸せな気分です。
セグメンテーションフォルトでよいです。

>>239
> コードサイズが小さいとバグが出たときの危険個所の特定が容易ということ。
なるほど。

1. C やアセンブラだと小さいコードが、C++ だと大きくなる
2. コードが小さいとバグが出たときの危険個所の特定が容易

よって C++ を使うべきじゃないって理屈なわけですな。

そもそも 1 が疑問で、手でカリカリにチューニングしたアセンブラコードは確かに
小さくなるけど、C, C++ でコードサイズに差が出ます?　C++ で pImpl イディオム
を使って内部実装を隠すようなコードを書く場合には C と比べて多少コードが大
きくなりますが、同一の仕様を実現するためのコードなら差はほとんど出ないで
しょう。（それに pImpl でバグの特定が難しくなることは無いし）

次に 2 が疑問で、サイズが小さいことと危険個所の特定が容易なことは、あまり
相関が無いんじゃないかと。特にアセンブラでチューニングしたコードだと、ソース
を見てもレジスタに格納されている値の「意味」は即座に読み取れないから、逆に
デバッグは面倒になりがちです。

ふむふむ、セグメンテーションフォルトを起こすコードは危険だけど、実行時にバッファオーバーランの例外を投げるコードは危険ではない。
と、ま、そういう基準ですか。

>>242
全体的に僕の言いたいことが伝わらなかったようで自分の相手に伝える能力の無さが
悔やまれます。
１ですが、小さいコードを書くべきといったので大きくなってしまうとはいってません。
Ｃ＋＋は大きいコードが書きやすいようにＣを拡張したので小さいコードならＣでよい。
むしろＣで書いてもＣ＋＋で書いても同じようなコードになるくらいの小さいコードに
なるように機能を分割しようといっているのです。クラスとかは使わないって意味。
２ですが、例えばセグメンテーションフォルトがおきた場合にJavaではそんなの起きる
わけがないのだから、それが使ってるライブラリが問題だとわかって、どの関数で起きている
かわかれば、その関数が小さいほうが特定しやすいというわけです。
Ｃ＋＋で書いたプログラムはプログラム全体がセグメンテーションフォルトを出す可能性を
秘めているという意味です。

>>243
null pointer 参照もあるかな。

確かに C, C++ ではバッファオーバーランと dangling pointer の問題は割と
面倒を引き起こすことは多い。特にバッファオーバーランは、現実にクラッキ
ングにも使われてる「人気者」なのは確か。

ただ、あれは固定長バッファを前提としたプログラムを組んでるから発生す
る問題で、C++ で STL コンテナを使い出すと滅多にお目にかからなくなる。
dangling pointer (or iterator) に関しても std::auto_ptr とか boost::shared_ptr
などのスマートポインタ、それから STL の inserter なんかを使うようになる
と激減する。

あと dangling pointer に関しては GC があれば発生しないことが保証される
わけだが、メモリストレージ以外のリソース、具体的には socket やファイル
の類は GC があっても自前で管理しなきゃならんから、それほど安全では
ないんだよね。

特に GC だとオブジェクト解体のタイミングを特定できない都合上、C++ の
ように「コンストラクタでリソース確保して、デストラクタで開放」という使い方
が出来ないし。

>>244
> Ｃ＋＋は大きいコードが書きやすいようにＣを拡張したので小さいコードならＣでよい。
ダウト

言いたい事が伝わらないんじゃなくて、言いたい事がまとまってない印象をうけるなぁ…

239=白痴
ほらさっさと首吊って。

>>246
違うんですかね？ＣをＣ＋＋に拡張した意図とはなんなのでしょう？
小さいコードならＣでよいってのがダウト？さっきも書いたけどクラス使う
必要ないって意味で。たしかにANSIのＣは細かいのでGCCでとおるようなＣ
ってことにしといてください。局所的な関数定義はいらんけど。
>>247
火曜日にプレゼンあるんですよね。弱ったなぁ。
>>248
すいません。下らん突っ込みは適当にあしらわせてもらいます。

>ふむふむ、セグメンテーションフォルトを起こすコードは危険だけど、実行時にバッファオーバーランの例外を投げるコードは危険ではない。
Windowsなら、アクセス違反もスタックオーバーフローも
みんな例外が飛びますが何か？

>249
＞ＣをＣ＋＋に拡張した意図とは
入門書読め

>>249
読んだ上で「大きいソフトウエアを作るのが容易になるように」
と自分で思ってたんですけど、どうやらダウトらしいです。
なんで拡張したんだろうなー？これにあてはまらないＣ＋＋の追加機能って
なんだろう。

>>252
相談室じゃないんだから愚痴は勘弁してくれ。どーしてもということなら sage で
頼む。

それと論理的な話だが

　大きいソフトウェアを作るのが容易になるように

拡張したら、結果的に

　小さいソフトウェアを作るのも便利になった

でも良いじゃん。

>>253
論理的な話ではなくて理論的な話ですね。
大きいソフトウエアが容易に開発できるような言語を設計するためには
低レベルな処理ができなくするのも大事な場合があるわけで。

>>252 CをC++に拡張した意図は、開発者に聞くのが一番。
Bjarne Stroustrup が昔慣れ親しんだ Simula67言語の
機能を C にも欲しいと思ったことがその動機だ。
詳しくはココを読め
http://www.research.att.com/~bs/bs_faq.html#why

>>254
思い込みで意見を言う前に、まずは事実を調べよう Yo!

いろんな機能を追加したかったと書いてあるけど、C with Classesということ
は一番入れたかったのはやっぱクラスってことね。
分散ＯＳ作るのにＯＯが適してたってことですか。
つまり簡単にUNIX作れるようにってこと？
基本的にはＣといっしょね。

なにからなにまで聞かなきゃ気が済まないのか？

>>257
これを読み飛ばさんでくれよ。
> The more general aim was to design a language in which I could write
> programs that were both efficient and elegant. Many languages force you
> to choose between those two alternatives.

> 分散ＯＳ作るのにＯＯが適してたってことですか。
> つまり簡単にUNIX作れるようにってこと？
> 基本的にはＣといっしょね。
UNIX は分散 OS じゃないんだけど。そもそも分散 OS や UNIX が何なのか、
名前ぐらいは知っていても理解してないでしょ?　タネンバウム先生に教えを
乞うて出直してきましょう。

なんでもできるのが欲しかったってことか！確かになんでもできるのは
Ｃ＋＋ぐらいですね。
OPERATING SYSTEM CONCEPTS読みましたがそんなんじゃ駄目？
確かにＵＮＩＸ自身は分散環境に対応できるように定義されてないかもしれないけど
分散ＯＳとして作られてるのはＵＮＩＸがベースなのでは？MACHとか。

>>260
Mach は UNIX ベースじゃないやん。

あー。ほんとだ。unixから派生しただけでunixベースというわけでは無いんですね。
全部メッセージパッシングで分散環境につよいわけですな。

>>250
例外と割り込みは別ですが何か？

>>263
つか、隣のバッファ壊したくらいじゃ、割り込み発生しないだろ。

386じゃ例外もアボートっていう割り込みで実装されてる
わけだけど。

仕事でＪａｖａやってるけど、ツール類は全部ＶＣ＋＋ですだ。
Ｊａｖａでツール作ると起動が重いから嫌。

バッファオーバーランってセグメントの境界を
超えない限りは検地されないの？

ページングでも出来るでしょう。

>>268
なるほどそうですか。

bound命令でも出来るけど、チェックするコード通らないと。
デバッグレジスタでも可能だけど、４つしか無いし…

ところで、>>265アボートって、何番の割り込み？？

09h

9か、３８６以降はハードでは発生しないから、それを使うわけか…
って、throwのたびに int 9 って、いったいなんの実装の話なんだろう…
スレの趣旨から言うとC++でって事になるけど…

言いたい事は、
既に現在業務アプリは VB　＋VC++　で作るのが主流になったように、
将来
　下層：Cやアセンブラな低レベル低抽象化言語
　中層：高機能安全なコンパイラ言語
　上層：スクリプト的な高機能、お気楽言語層
　のような多層構造で作られるようになるだろうという事かな？

今C++言語はこの３層を全て賄うような感じだけど、それでは全体の安全性が
結局保てないわけで、アプリの堅牢性の為には、言語そのものもをそれぞれの
層で別けてしまうという発想になるだろうという感じ？

>>273
言語を使い分けるのはもちろん正しい。
スレの趣旨としては、
「全てに使えるものは何の役にも立たない」
ということわざが示すような状況にC++が
追い込まれていることを確認することですｗ。
もちろんC++が大好きな人間が、です。

・自分が一番好きな言語
・もっとも守備範囲が広い
この二つの事実はなんの現実を変える力も持ち得ない。

個人的にはもうどうでもいいかなって思ってるけど。

実際に使われて役に立ってるものを、役に立たないとか言われても。

>>275
C++ を批判するなら良いんだが、C++ を理解せずに聞きかじった知識で
自分の脳内に作られた

　C++ の幻想

を批判してるヤツが多すぎ。具体的な話になると、とたんにボロが出る。

なんかここの書き込みみて思ったんだけど、
これからC++をやるとしたら、それがどういう
汗にコンパイルされるか分かる人じゃないと
だめなのかか？

俺みたいなヘタレはまず汗やってからにしろってことか。。。

C++の悪いところ。

・Cのコーディングを許してしまうのでアブノーマルになりがち
・言語への縛りが少なく厨房PGにはすぱげちぃ〜が書きやすい
・標準ライブラリ(STLも含む)が糞なケースが多い。
・世の中にライブラリが腐るほどあって勉強するのが大変

C++の良いところ
・実行速度が速い
・templateが使える
・世の中に良いライブラリがゴロゴロしている(H++,STLPort,boost等...
・Cのライブラリがそのまま使える

>>278
> ・言語への縛りが少なく厨房PGにはすぱげちぃ〜が書きやすい
厨房が書いてもスパゲティにならんプログラミング言語って何?

>>279
なり易度はC++がダントツだと思われ。
スパゲチーにはいくつかの段階があると思うけど、
Lv.1 関数内スパゲチー
とりあえず動けばヨシ。

Lv.2 関数レベルスパゲチー
構造化に失敗してる。インターフェイスさえしっかりしているなら大問題にはなりにくい。

Lv.3 クラス間スパゲチー
始末に終えない。クラスに分けている意味がまったくないどころか理解不能になることも。
多重継承なんかも絡むとすごいことになりそうな予感。

>>280
C だろうが VB だろうが、手に負えないのは

　グローバル変数を多用していて、どこで何をいじってるか分からない

プログラムだと思うが。if - else の深いネストとグローバル変数がミックスされると
お手上げ。

MLは比較的すぱげちーにならないようにできてると思われる。

>>281
どこで何をしてるかわからないのはスパゲチーの極意だね。

>281
グローバルじゃなくても、
巨大クラス内メンバ変数で同様の症例はあるよ（ｗ

>>280
Javaで酷いのをよくみかけます。氏んでほしい。

>>284
要するにスコープの広い変数が問題だ、と。

せっかくクラスを使ってスコープを狭くしても、無理な多重継承やグローバルな
インスタンスを作ってぶち壊すと元の木阿弥…。

>>286
javaにてSingletonと称したそのケースが多発しているんですが
この猿どもはどこで勉強しちゃったんでしょうね？

クラス内すぱげちークンに、一度、インターフェースを定義して、それを使うように指示した事あるんだが、
こんどは、いつまでたってもユニットテスト通らないクンになったよ…
もちろん、Javaで。

javaで継承しまくりクラス間スパゲチーの修整依頼よく来るんだが。。。
そのコードが動かないならまだしも、既に稼働中のシステムだったりすると
もう手の加えようがない(藁,涙,号泣

スパゲチーって何？

めん状のパスタをゆでたもの

>>291
（ToT)フ〜ンダ・・

おもに、デュラム小麦が原料。

（ToT)フ〜ンダ・・・・
スパゲチーって何のことか，誰かおせ〜て？

スパゲッティ

【(イタリア) spaghetti】
〔スパゲティとも〕
細長く，管状でないパスタ。

この板での意味を知りたいんだけど．．．

>294
さがせや！いくらでも出てくるじゃねーか！
こんなかんじで..........

１０分でできるスパゲチー各種
ttp://homepage2.nifty.com/blue_moon/cocking_pasta.htm#03

>>296
そろそろ、このネタも飽きたから答えを。

スパゲティというのは、ロジックとデータ構造が複雑に絡み合って、メンテナンス
不能な糞プログラムのこと。絡み合い具合をスパゲティに喩えてるわけ。

■［この板で］の大辞林第二版からの検索結果　 0件
--------------------------------------------------------
検索結果に該当するものが見当たりません。
キーワードを変更して再度検索をしてみてください。

＞＞２９６
ありがとうございました．
丁寧な説明でわかりやすいでした．

次のC++のバージョンで実装されるであろう機能が乗ってるHPってある？

将来実装されるであろう機能

これ以上、実装が増やせるのか、という根本的な疑問が。
もうかなりの肥満体でっせ。>C++

いっそのこと
templateのみにしたらどうか

>>303
ライブラリの方は、まだかなり増やす余地があると思うけど。とりあえず

Boost.org
http://www.boost.org/

ここにある shared_ptr, bind, ref あたりは標準で欲しいよ。

（正規表現とかスレッドも便利だ）

compose は必要!!

ハードウェアよりのプログラムに C++ を使うのも結構便利だよ。
でも僕はそういう用途で例外処理や実行時型情報は使わないけど。
C++ のメソッドをアセンブラで書くこともあります。

要はコンパイル時にすべて静的に解決できる機能だけ
使ってるってことです。

多分 cfront でも事足りる機能だけ。

そういう厳格にアクセス制限と型づけされた高級アセンブラとしての
C++ の使い方もあっていいと思います。

それとは逆にもうモロにオブジェクトマンセー的な使い方もあるわけで、
こっちのほうは Java でも C# でも好みに合わせて使えばOKかと。

個人的には C++ と Scheme を使うことが多いです。

>307
scheme何に使ってるの？

研究でシミューレーションするときに、シミュレーションシナリオ書くために。
単なるマクロ言語として。

>>307
コードでかくならん？
「ハードウェアより」って言葉がまた意味が広いんだが。

>>307
> そういう厳格にアクセス制限と型づけされた高級アセンブラとしての
> C++ の使い方もあっていいと思います。
イイコト言った！禿々しく同意。

>>307
標準 C++ から例外や何かを取り除いて、まっとーな OS を前提としない環境でも
実装しやすい Embedded C++ なんてのもあるしね。

>>310
なんで C よりも C++ の方がコードが大きくなると思う?

1. テンプレートをインスタンス化するときに、別々のコードが生成されるから
2. 例外時のスタックまき戻し処理のために、オブジェクトの寿命追跡コード
　（プログラムカウンタとスコープ内オブジェクトの対応表を用意したり）が必
　要になるから
3. ライブラリ関数がやたらでかいから　特に iostream 関係

これをザックリ捨てると C でも C++ でもコードのサイズが大きく変わる要因は
ないと思う。vtbl の初期化やら多重継承時のダウンキャスト (仮想デストラク
タ呼び出しとか) もちょっとコードサイズに寄与するけど、それほどじゃなし。

>312 がいろいろ言ってくれてるからそれで十分なんだけど、
C++ が「重い、遅い」と言ってる人は「例外処理だけ」とか
「仮想関数だけ」とかを使った小さなソースを書いて、
アセンブラのソースを吐き出させてみるといいと思う。

するとたとえば、例外処理だけでいかに例外処理関連のルーチンを
呼びまくり、それを解決するためにリンカがライブラリをリンクしまくってる
様子がよくわかります。

まぁ僕の立場としては >311 なんで、純粋にオブジェクト指向言語としての
美しさを求めるという立場からは「汚いなぁ」とすなおに思うけど
（だから Scheme とか Java とか使うけど）、それを理由に「C++ はダメだ」
という立場の人に対しては「あー、C++ 使いこなしてないなぁ、このヒトは」
と思うわけです。

↑これ日本語おかしくない？

>>314
別に。

tyr{}で囲む個所はなるべく小さくするのが基本ですか？
DQNなもんで処理全体を覆ったりしてるんですが・・・

>>313
> まぁ僕の立場としては >311 なんで、純粋にオブジェクト指向言語としての
>美しさを求めるという立場からは「汚いなぁ」とすなおに思うけど
>（だから Scheme とか Java とか使うけど）、それを理由に「C++ はダメだ」
>という立場の人に対しては「あー、C++ 使いこなしてないなぁ、このヒトは」
>と思うわけです。

十分すぎる理由ではないか。

>>307
>そういう厳格にアクセス制限と型づけされた高級アセンブラとしての

こういう君のような使い方をしない奴は使いこなしてないってか？

>>317
> こういう君のような使い方をしない奴は使いこなしてないってか？
そうは言ってないと思われ。

>176 char year;
何の為に年をchar型にしてるのか、
興味もあるし気になる所だけど、
>181 2000年問題があったのにchar year;ってなに？（w
これはもっと気になりました。
2000年問題と何か関係があるんですか？
>176のソースだと2078年問題が出るぞ！みたいな事？

typedef struct {
　　char year[2];
　　char month[2];
　　char day[2];
} Date;
ウチはこんな感じの日付型で2000年問題を経験したな〜

＞何の為に年をchar型にしてるのか、
資源の節約とか…。

将来も未来も。。。。。ない。。。。のか？
。。。。Cはキライだし。。。。C#しかないのかな。。。。
C++の勉強は楽しかったな。。。。はぁ。。。。

Ｃ＃、ＪａｖａはC++で出来てんだよ

C++はなくならんよ。

MSはC#を推奨し、SunはJavaを推奨するけど、どっちも自分とこでは「C++使い」
を確保しておくだろ。じゃなきゃ、ネーティブコードが作れんや。
要するに、C#やJava（やその発展形）使いは、VBA使いのようなマクロ屋さんと
いうことになると思うよ。
もう、いいかげんCの時代じゃないしな。（藁

>もう、いいかげんCの時代じゃないしな。（藁

この一言で324はＤＱＮ決定

>この一言で324はＤＱＮ決定
この一言で325は、現代のコボラー決定。
（メンテにしがみついて生きていくのって楽しいか？）

まあ、324のいうようにC++やっとけば潰しがきくよ。
標準仕様も策定されたし、しばらく安泰でしょ。
VBみたいにメーカーの一存で決まる言語にどっぷり浸かってると
今回のVB.NETみたいに泣く事になるよ。

高級PG：C++
中級PG：C#、JAVA
低級PG：VB

あくまで、その級までの言語を使いこなすということで。

JavaとC#は、コンポーネント指向＋オブジェクト指向

稼げるんなら、C++でもJavaでもどっちでもいいよ。

>>327 >>328
禿になるまで同意。
>>326
煽んな。

C++やってれば、JavaもC#もすぐわかるので、やって
そんわないよ。
C++のいいところは、ソースレベルだということだね。
中でどのように動いてるとか、設計されているとかを追跡できる。
逆にいえば、ライブラリの中までみないといけないことが。

組み込み系, オープンソース系カーネル, 新規案件も C だよ。
C++ はもうちっとコンパイラ間の互換性をなんとかしてくれ。
愛してるけど。

一晩明けてみて判定すると、スレを止めたのは君だ！！>>332

というかC++もマクロ屋さんでしょ。

>>334
言語がどう変換されるか完璧に理解してる人は
そんなに多くないと思う（俺も含めて）。
とくにVC++でMFCしかやってなかった人は
大体そうだと思う。

マクロ屋さんだとしても中身を知ってるマグロ屋に
ならなくては・・・鬱

というか、Cラーってコーダーでしょ。
フローチャート（って俺見たことないんだけど）をもくもくと
Cに落としてくだけの。

たしかにコーダーだのコボラーだのがPG名乗るのはやめてほしいな。
マクロ屋？コーダーよりレベルの低い連中か？給料もらえてるか？

C/C++からヘッダだけ無くした言語、
もしくはプログラミング環境作って欲しいな・・・

でも確かにＣ＋＋の活躍する場はなくなっていくだろうね

VC++ + MFCから入ると潰しが効かなくなっちゃうね。
ANSI/ISO C++ → Windows SDK → VC++ → MFCがいい。

というかフローチャートとかでてくるようなのは組み立て工場。

C++はC#になるので無くなります。

でも最初からJavaとかC#でプログラミングを
始めるのはどうかとおもうぞ。
Cの勉強の為に作ったプログラムをC++でもう一回
作り直すそんな勉強を今やってるとこ。
JavaやC#だけじゃ普通の奴はダメだっておもったからね。

俺の経歴
C++ -> Java -> C -> VB -> C#
どれもきらいじゃないし、良さがあると思うけど、C++が一番よかったな。
（これは、処女をささげたからか？）
STLもしっかりしてきたし、まあ、これからも使わせてもらうよ。
C++.NETは使いやすいかな。

Genericも忘れんな。

今現在 私の知っている言語の中では、Ruby が一番理想的な
環境を実現しています。

それまでは、C++ で STL を使ってがんばろうとしていたのですが、
Java や Ruby を知ってから、C++ が
"いかに分かりにくい(落とし穴の多い)言語か"
というのが身にしみて分かるようになり、あまり好んで使わなくなって
しまいました。(STL に関しては未だに魅力はありますが...)

私は、コンパイラや言語設計の勉強を全くしたことがなかったのですが、
Ruby を知ってから、"実は言語を設計するのって、結構面白いんだなぁ"
と思うようになりました。

GUI を使わないプログラミングに関しては、今はほぼ Ruby で不満なく
書けています。(不満なくというより、日々いろいろな発見しているので、
まだまだ潜在力があるかなと感じているところです。)

>今現在 私の知っている言語の中では、Ruby が一番理想的な
>環境を実現しています。
バグ対策は?
elseifの分岐と正規表現の辺りがヘンです。
それとも1.6.xがハズレなのですか?

ふむ。slashdot.jpよりのコピペか。

>それまでは、C++ で STL を使ってがんばろうとしていたのですが、
文面から想像がつくけど、C++をベターCくらいの気持ちで使おうと努力してたんだろうね。そりゃだめだよ。

ずう〜〜っと読んでたけど、結局C++はイイの？
今C++を学習中なんだけど・・・・激しく鬱です。
やっぱJAVAにしとけば・・・・。

>>350
C# にしとけ
Lippman も C# Primer を書く時代になったし

VC++やるつもりでC++の勉強始めるなら
C#やるのがいいだろうね。
これからC++やるにはシステムに近いところを
理解しながらやるプログラマじゃないと
使う意味がないかも。
OSやコンパイラの挙動を理解してる人が
使うものだよ。

>>352
一応、某でやっております。

システムに近いところとは、どういうことですか？

MFCの本を売るなら今でしょうか？

C++は普通のプログラミングでも言語設計に近いことをやってるような気がして楽しい。

>>354
もう遅いです。VB本並みの値段になってます。
ヤフオクの相場の話ね。

すまん。
話についていけん。
逝ってきます。

＞システムに近いところとは、どういうことですか？

徒歩１０以内

時々走って２分と１５秒以内

＞これからC++やるにはシステムに近いところを
＞理解しながらやるプログラマじゃないと
＞使う意味がないかも。
＞OSやコンパイラの挙動を理解してる人が
＞使うものだよ。

これはＣ言語の牙城を崩せないと思う。
それぐらいは現場にいれば解かるだろ？

C++作ったあの禿げのおじさんって
Lispになんかトラウマでもあるんでしょうか？
昔、Lispハカーに屈辱でも味わったとか。

age

C は高級アセンブラ。
C++ はオブジェクト指向高級アセンブラ。

cとｊａｖａは、どっちが習得早いと思う？？

>>364
Cだと、一応コードはかけるけど、アホなコード量産してとんでも
ない動作を引き起こして迷惑掛け捲る時期がかなり長いと思われ。

Javaだと、そもそもコードかけない時期が長いと思われ。
そのあと、一応まともに動くけどJava的にはあほなコードを死ぬ
まで書きつづける人間も多いと思われ。

どっちがイイのかな。

>>365
もとVBが大量にクソコード書き捲くってますが、何か？

>>363 禿げ銅。

C++は最高級アセンブラ！

キミ達アセンブラ知らないでしょ
Ｃ++がアセンブラ？ﾜﾗ

>>369
知らなかったのか？
高級アセンブラ (決して高級言語ではない) であるところの C に
“OO っぽい機能”を追加したのが C++。
これを機会に覚えておくといいよ。

Cハカーはマクロ言語としてCを使ってるのかも
しれないけど、C++ハカーもやっぱりそうなの？
考えただけでもすげーよな。

>369
たいていの C コンパイラや C++ コンパイラは
ターゲットCPUのアセンブラソースを吐き出すことができます。

レジスタ割付などのオプティマイズの結果を確認するために時々確認します。

引数のプッシュ順とかに気をつければ、アセンブラソースから作った
オブジェクトとリンクさせるのも簡単だと思います。
インラインアセンブラならレジスタ変数も正しいオペランドに解決してくれます。

組み込み言語やゲームプログラミングでは
ビットローテートとかはインラインアセンブラを使うことも結構あります。

なので機械語との親和性を重視して「オブジェクト指向高級アセンブラ」と
呼んだんですが……変だったかなぁ。

ヘンなのは>>369です

C使い：VBユーザー＝汗マニア：C++ユーザー

>374
先生!
operator:()
は一体どーゆー演算子ですか!!

>>372
君は正しい。
それに、これからネーティブ吐けない言語が増えるし。

>>164
> 実際のとこ、スキルをそこまで上げてもいいのか？

これは驚いた。開き直りかよ!

Cはアセンブラかもしれないけど、C++は違うと思うなあ。まあBetterCとして使う
のも悪くはないけど。基準？メモリモデルを常に頭において作るかどうかかな？

C++の上位言語を作らないで欲しい。

ｃ＋＋ですらいまだに解ったのか解ってないのか…。