1 ：
仕様書無しさん：
以上
宿題がんばれよ。
いい加減、言語叩きは飽きたよ。
5 ：
仕様書無しさん：04/09/06 13:34
>>3 C++できますといって本当はCしかできないウンコが必死(w
あちらこちらで奇妙な書き込みをして・・・
なんだか可哀想になってきたよ。
お大事にね
Java出来ますとか言ってよ、BASICみたいな組み方しか出来ない奴も居そうだな。
8 ：
仕様書無しさん：04/09/06 13:45
C++を使えると豪語する者＝本当はＣしかできない低脳
モノホンさんでつね
一連の事件はこの発言した人しかないでしょうw
↓
関係ありませんが、ある有名なるJava厨さんによると
Javaは TCP/IPの上にあるHTTPで動作するそうです。
何で？
15 ：
仕様書無しさん：04/09/06 15:45
main()に処理を全部書くJava使い
16 ：
仕様書無しさん：04/09/06 15:51
Java厨隔離板欲しいなぁ
17 ：
仕様書無しさん：04/09/06 15:53
ほんとうだよね。なんか美人な(C/C++)に鼻もひっかれられなかった
腹いせをしているもてないJAVA厨といった感じ
たちの悪いストーカーみたいだよ
できたところで変わるとは思えないけどな。
>Java厨
頼むから、C++ができるようになってから言え。
ああ、漏れは両方できるから言うんだけどな（ｗ
最後の (w がバカっぽいんだよなぁ
>19
そうかくと
C++ができるという椰子こそ危ないとか
ワンパターンなJAVA厨は言う
JAVA厨と遊ぶときのお約束
Javaは TCP/IPの上にあるHTTPで動作する仕様である事を心する
Javaと書かないでJAVAと書くこと
あまり難しい事を言うと言い返せなくなって暫くだんまりするから
ほどほどにする事。
>>20 漏れは結構ヴァカだが、JAVA厨の藻前は漏れより遥かに上級（のバカ）
>>20 藻前、2chの全板でその発言してみろ（ｗ
>>23 ああ、俺も一応、仕事で C++ も Java もやるよ。Perl 厨だけど。
両方できるのは結構なんだけど、(w があると何か嘘っぽく見える。
まあ、どっちでも良いけどな。
>>24 まあ、2ch なんてアホばかりだろ。
>>25 > 仕事で C++ も Java もやるよ。Perl 厨だけど。
( ´,_ゝ`)
JAVA厨怒れ！
さすがにPERL厨にコケにされる事はないだろう
それは酷いな。では、Lisp 厨と言っておくよ。
JAVA厨もなめられたものだ・・・・
bash >>>>>> DOSバッチ >>>>>> D$2コマンドセンターSQLアシスタント >>>> JAVA
ひまわり > NotesScript > ｷﾞｺﾍﾞｰｼｯｸ > しぃ言語 > JAVA
( ´､_ゝ`) ﾌﾞﾌﾞｰ
ﾌｧﾐﾘｰﾍﾞｰｼｯｸが抜けてますよ
ひまわり > NotesScript > ｷﾞｺﾍﾞｰｼｯｸ > しぃ言語 > ﾌｧﾐﾘｰﾍﾞｰｼｯｸ > JAVA
( ´､_ゝ`) ﾌﾞﾌﾞﾌﾞｰ
>>32 おい、FAMILY-BASICは、ｷﾞｺﾍﾞｰｼｯｸよりゃ上だろ。
Z80ニーモニック > JAVA
( ´,_ゝ`) =3
( ´,_ゝ`) ==３ ﾑｯﾊｰ
その口で"ﾑｯﾊｰ"はいかがなものかと。
これでいいか?
( ´∀`) =3 ﾑｯﾊｰ
39 ：
仕様書無しさん：04/09/08 04:03
とりあえず動くものをつくって稼ぐ人と、その後を面倒見るひとがいれば
みんな幸せなのではないかと思います。
なんつったって、お金があっての職業じゃないですか。
ヨーロッパだとしっかり設計してたりしますが、日本文化で稟議を通すための
説得力がないＳＥにもまた問題があると思うんです。
だから専門教育をうけていない人や、経験不足のひとがかせげてしまうのでは
ないのでしょうか。ヒューマンスキルとマニアを兼ね備えたC++使いをみたことありますが
結局いいスキルの持ち主は被害ばかりこうむってしまいモチベーションが低下しますよね。
どうしましょうか。
40 ：
仕様書無しさん：04/09/08 04:11
そもそも稟議書にハンコ押すやつがドタコで
金額ばかりに目がいっちゃうんだから
まともなものなんかできんよ（泣
42 ：
仕様書無しさん：04/09/08 15:43
>>41 まさか・・・野村部長でつか？
(;ﾟ_ﾟ)
プログラムとは無縁の部長がマ板をチェックしてるとは・・・
L(・o・)」オーマイガ！
まあ、Javaは言語そのものよりも
ライブラリが豊富なのがうらやましいよ
44 ：
仕様書無しさん：04/09/11 18:28:22
>>25 口先だけで実際にやらせてみるとなにもできなさそうな香具師だなw
45 ：
仕様書無しさん：04/09/11 18:30:01
>>43 いまどきライブラリなんて言葉をやたらと使う奴って、
それこそ時代遅れ。
これだからC++厨は(ry
って言われるんだよ。
APIとかフレームワークといったほうが説得力があるってのに
釣りだよな？
47 ：
仕様書無しさん：04/09/11 18:55:06
>>45 ライブラリってＡＰＩやフレームワークで置換できる概念なのか
こら、バカをかまうんじゃありませんっ。
時代遅れ(´･ω･`)(´･ω･`)(´･ω･`)
説得力(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)(´･ω･`)
>>52 どっちのスレもウルトラ級のバカという点では一致している
54 ：
仕様書無しさん：04/11/14 01:56:42
C厨＝ライブラリ厨
55 ：
仕様書無しさん：04/12/16 20:09:42
c++がいちばん実用的です。速いし簡単
56 ：
仕様書無しさん：04/12/16 20:10:38
c++は速い、簡単、覚えることが極端に少なくて済む、何でも作れる
57 ：
仕様書無しさん：04/12/16 20:13:08
c++もできねえくせに、なんでてめえみたいなﾁﾝｶｽ係長になれるんだよてめーはよ ｸｿｶﾞｷが。
あっ社長の息子だからか あーーーーーーっはっはっぐぎゃひゃはははぁぁあ
58 ：
仕様書無しさん：04/12/16 20:19:37
>簡単、覚えることが極端に少なくて済む
プログラミング言語C++第3版とか、ごっつ分厚いんですが？
Modern C++ Designとか内容が鬼なんですが？
59 ：
仕様書無しさん：04/12/16 22:06:29
そんなの読む意味なし
先に言語覚えれ
バ～カ。
61 ：
仕様書無しさん：04/12/17 18:44:02
ひいっヤンキー係長 ｗ
62 ：
仕様書無しさん：04/12/17 19:15:14
>>58 あの程度で厚い？ﾊｧ？あの程度で内容が鬼？ﾊｧ？お前PGに向いて
ないんじゃね？田舎カエレや。
>>62 もってないのかよ・・・。
アマゾンで売ってるから、とっとと買ってこいや、ハゲ
64 ：
仕様書無しさん：04/12/18 00:51:55
>>63 あんなもん辞書だろ。分からんことがあったらそこの説明だけ見る、みたいな。
65 ：
仕様書無しさん：04/12/18 00:58:15
>>64 いや、普通に読めるよ。
つか、あのぐらいの厚さの本は普通にあるからな。
66 ：
仕様書無しさん：04/12/18 00:58:58
まあ、はじめは重要な部分とそうでない部分が見えてないから
ちょっと時間かかるだけだろ。
普通には読めん
何故なら、文章が下手だから
C++第三版は、全部読めて理解できてれば、そりゃ相当な理解度だ罠
長いこと使ってるんでわりとボロボロになってきてるが、いまでもたまに「へー」と
勘違いだのうっかり間違いだのを（本に）指摘されて欝になる。
同時に、この本のサンプルや記述の全部を鵜呑みにしても意味がないところもある。
「こんな最適化は期待できんなあ」みたいな。
でもまあ、とりあえず一度は通して読んどけ。
69 ：
仕様書無しさん：04/12/22 22:37:04
あんな本読まなくても良い。難しい。さっぱり読む気が起こらない
なんか
>>22が壮絶に勘違いしてるというか馬鹿なのに誰も突っ込まんのか
72 ：
仕様書無しさん：04/12/24 21:59:35
シーバルスバルス！
73 ：
仕様書無しさん：04/12/24 22:00:14
74 ：
仕様書無しさん：04/12/24 23:12:33
しかし、C++の標準ライブラリ（STLなど）を代替できるシステムは、他言語ではまだ出来て
いない。それが出来たときには、C++は死ぬかも。
>>69 おれも、テキトーな入門書とEffectiveC++だけでいいかなと思う。
そんで使いながら、STLやBoost等のおいしい所をつまめばいいかなあ。
77 ：
仕様書無しさん：04/12/24 23:57:04
>>74 どこが馬鹿なのだ？。Java等で、C++の標準コンテナ・標準アルゴリズムと同じようなことができる
ライブラリはあるのか？。
確かに、標準ライブラリ+Boostの魅力があるからC++を捨てられんのだよなあ
79 ：
仕様書無しさん：04/12/25 00:06:29
Java,C#などと比較してC++は遥かに複雑な言語なんだけど、標準ライブラリやBoost
は、その複雑な言語構造を使って実現している。
Java,C#のように、単純な言語でC++標準ライブラリの機能を実現できるなら、C++の
メリットは大変に小さくなる。でも、それは難しいと思う。というか無理かもしれない。
Java,C#で、標準ライブラリのようなものを定義できるように言語を拡張すると、C++並み
に複雑な言語になってしまうかも。
一時期Genericsの付いたJavaやC#になびいたこともあるけど、
Modern C++ Design読んだら一気にC++に引き戻されたからな。
JavaやC#にはこの、ある意味変態じみた楽しさが無い。
Boost C++
82 ：
仕様書無しさん：04/12/25 00:16:33
c++だのjavaだの人が作った部品をかき集めて
結合してるだけなんじゃないの?
そんなんでいいきになってんじゃねぇよ
アルゴリズムを勉強しろよ・・・たとえばFFTとかね
DHDLとか極めて自分でCPUの論理回路設計してみろよ
ボケども
>>82 FFTとかできないと思うほうがおかしい。
ついでに一般的なプログラマがDHDL極める必要がどこにあるかワカランのだが、オレは昔やってた。
つーかプログラマならちょっと勉強すれば論理回路とかできて当たり前。
アホかお前。
84 ：
仕様書無しさん：04/12/25 00:22:41
>>83 まぁもちろんまともなプログラマなら論理回路とかできて当たり前だな
お前以外のヴォケどもに言っている
FFTみたいな数値解析アルゴリズムは、天才に任せた方がいいんじゃない。
86 ：
仕様書無しさん：04/12/25 01:38:52
使えるのが普通。
作るのが天才だろ。
まあ、そりゃ使うだけなら。
つーかお願いだから凡人でもC++を正しく使える様、とっととC++の規格を上げてくれ。
Boostの中でもarrayとか変態的でない素直な連中は、とっとと標準ライブラリに組み込んでくれ。
頼むよほんと。
高級言語でこれだけの性能出せる変態言語は他にないんだから、
あと一押し天才の皆様にご助力願いタイのココロ。
>>82 の知能では、FFT と DHDL が精一杯だったということか。
>>83 >凡人でもC++を正しく使える様、とっととC++の規格を上げてくれ。
莫迦でなければ現行の仕様で問題なく使えますが。
つか、「規格を上げる」とは？
>高級言語で
ひとつ、大きな認識不足がありますね。
>>89 正しく使えるに決まってるが、Javaあたりが当たり前に持ってる機能がC++に居ても邪魔にならんだろ。
配列のサイズ取出しとか、未だにsizeof(ARRAY)/sizeof(ARRAY[0])とかしなきゃならんのだから。
配列なんてそのままデータ構造なんだから、静的に求まってるサイズはその場で取り出せて当然だ。
この辺をコンパイル時に解決してくれるだけでも、負担は大分減る。
boost::arrayとか使えばその辺は簡単に解決するが、それだってboostを入れなきゃならんという
事には変わらないわけで、普通に#include <array> とかすれば簡単に使える様になってくれると嬉しいとか、
配列なら暗黙のうちに#size()メソッドが追加される（これは既存コードとの互換性の面から難しいだろうが）とか、
そういう努力はお願いしたいなと、そういうこと。
それにC++は充分高級言語だよ。
Cやそれ未満のレベルの理解が伴ってこそ本来の性能を発揮できるのは当然だけど、
同じ処理内容、同じ性能のコード書くのに必要な打鍵量の少なさ考えれば、あれが低級言語だなんて
到底言えないってばさってばさ。
…なんかsizeofに括弧つけてる奴が何言ってやがるとかそういうレベルでも
あれこれ言われそうな疑心暗鬼に捕らわれてしまって欝ですよ。
sizeofは演算子だから括弧いりませんねそーですねフンだ。
ぬるぽ。
>>90 >配列なんてそのままデータ構造なんだから
ちげーよ。阿呆か。
>>92 構造だよ、冗談でなく。データの単位と、連続性と、連続量が定義されてる。
その辺揚げ足取りたければなんとしてくれてもいいが、
静的に解決可能な配列サイズくらい、静的に「かつ簡単に」解決する手段が
なぜ今まで用意されなかったかが不思議でしょうがない。
いや、boostは置いといて。
この中で配列境界踏み越えての参照だの書き込みだので
バグなんか出したことありませんが何か？て人は、冗談抜きで
神かパラノイアか嘘つきだと思う。
規格策定当時は「時代はvectorだー！」だったのかもしれんが、
その程度ちょちょいと組み込んでもらえるだけでも随分違ったのに。
たとえばマクロの出番が減る。
テンプレートの方言が減る。
boostは…使う奴は使うが、ビルド可能なソースの納品にあたって結構気を使う。
バージョンが違えば何が起きるかは神のみぞ知る結果になりかねないし、
使ってない環境にに「入れてね♪」とはおいそれと言えないことだってあるだろうし。
vector<bool>とかみたいに中途半端で放置されてる標準とか、
イテレータ類の異常な書きづらさ、書かなきゃならんコード量、
生きてるんだか死んでるんだかよくわからんコンテナ用の自前Allocator仕様、
結局コンパイラ任せになってて安心して使って良いのかどうなのかわからんRVO、
おなじく（これも下位互換性が足引っ張ってるんだろうが）引数の評価順の不定性等、
いくらでも手を入れられそうな場所は一杯あるんだが、全部放置されてる希ガス。
そもそもboostて次期C++仕様への組み込みを目指す機能セットの構築を発端にしてるのに
その成果が完全にboostで固定してしまって、C++本家に還元されないのはなんでやねん、と。
結局この手の言語の大掛かりな改変つーと、C++後継となる新言語に任せるしかないって話なのか？
Dか？Dなのか？
大手ベンダがサポートしてくれるってんなら、それはそれで一向構わないんだけどさ。
別に現状のC++でも、普通に使えてるのは間違いないんだし。
>>93 C++の規格改訂は５年おきだからね
shared_ptr, bind, mem_fn, ref, function regex, tuple, type_traits
辺りは次期標準に入るらしいよ。
>sizeof(ARRAY)/sizeof(ARRAY[0])
Javaの配列は配列じゃないんだよ。
C++ならvector使えや。素人さん。
>>96 boost::array程度なら自前で実装してもたいした手間じゃないと思うが
つか、sizeof(ARRAY)/sizeof(ARRAY[0])だけなら、
template<class T>
inline const unsigned int lengthof(const T& array){
return sizeof(array) / sizeof(array[0]);
}
・・・
int a[100];
std::cout << lengthof(a) << std::endl;
なんかで。
>>90 >未だにsizeof(ARRAY)/sizeof(ARRAY[0])とかしなきゃならんのだから。
それで済むのなら、
なぜ新たに構文を追加しなくてはいけないの？
>>90 >配列なんてそのままデータ構造なんだから、静的に求まってるサイズはその場で取り出せて当然だ。
しかも、ちゃんと「その場で取り出せて」いるし(w
102 ：
90：04/12/28 03:08:38
そのバカの90がこんな時間にご光臨ですよ。
結局のところ、boost::array程度の実装は難しくないし、
俺も自前で書いたテンプレートを使ってる。
普通誰でもやるだろう。
ていうか、boost::array自体誰が書いてもあんな感じって実装だよな。
100行少々のコードでしかないんだし。
だからこそ、その程度はとっとと標準にして欲しいってだけ。
簡単だからって放置されたら、方言が増えるだけやんけ。
boostが出した成果の還元が遅すぎるって思うってだけのことなの。
>>94 tupleが入るのは少し驚いた。
あれ、めちゃめちゃ力技の実装するしかないよね？
そりゃあればそれなりに便利だけどさあ。
あと
>>98、それ、恐ろしいことに sizeof(array)がポインタのサイズ返す処理系に遭遇した記憶がある。
Tのリファレンスを受けてる時点でTが判明してるんだから、静的に解決してもよさそうなものなのに
T&のサイズ（すなわち隠蔽されたポインタのサイズ）を返すんですよ。おっかねえ！
昔の記憶だから脳内コンパイラの出力かもしらんが。
だったらすまん。
103 ：
仕様書無しさん：05/01/09 13:39:39
c++はシンプルで速度も速く、極めて実用的だから、これから先生きのこると思います。
言語Dはまだテンプレートの仕様に混乱がありそうだ。そのうち、Visual D++ .NET (仮称) が出てきたりして
それならそれで一向構わないな。
言語は仕様が練れてるにこしたこたないのは勿論だが、
やっぱり統一された標準の看板があってこそだし、
それで使う人間が一気に増えるならお釣りが来るくらいだ。
VCのテンプレートは何か不幸な訴訟問題で随分長いこと
アホーな仕様のままだったけど、現行のものは良い出来だし。
106 ：
仕様書無しさん：05/02/22 11:40:40
>>39 されど、一度動いてしまったものを
拡張、改造、機能追加、引き継ぎするのが
大変なんだよ。
で、最初から新しい言語で作り直す手間を強いられる。
酷い顧客は以前のソースコードも仕様書もまったくこちらによこさずに
作れと言い出すからなあ。
107 ：
仕様書無しさん：05/02/22 11:41:56
>>55 Ｃより遅いじゃん。
STL使ったらさらに遅くなるっていうし
108 ：
仕様書無しさん：05/02/22 11:43:51
>>73 いやお前はC++が無くなっても死なない。
なぜなら
D 言 語 が あ る か ら
109 ：
仕様書無しさん：05/02/22 11:46:29
>>74 > しかし、C++の標準ライブラリ（STLなど）を代替できるシステムは、他言語ではまだ出来て
> いない。それが出来たときには、C++は死ぬかも。
それだったらもうすでにC++は死んでいるんでは？
Java. C#, D言語がある程度代替しているし。
110 ：
仕様書無しさん：05/02/22 11:47:12
111 ：
仕様書無しさん：05/02/22 11:48:36
>>87 すべて一から作るのは天才的な要素があるが
FFTならそこらへんのサイトの情報を拾ってくれば
誰でも簡単に作れるぞ。数値解析、数値計算にしてもな
112 ：
仕様書無しさん：05/02/22 11:50:00
>>90が求めているC++言語ってのはD言語のことだろうな
113 ：
仕様書無しさん：05/02/22 11:52:15
>>95 実際にvectorを使わない素人どもがC++玄人を名乗ってウザイんだけど。
キモイコード書きまくって自分が凄いと勘違いしてウザイ
なんでもかんでもvectorに突っ込んで俺ｓｔｌ玄人って感じで、
他のコンテナ知らないの？って人いるよねー
vectorとlistはよく使う
dequeは滅多に出てこないがさりげなく使う
setは設計時に存在を忘れている
使いそうで意外と使ってないのがmap 連想配列はphp/perlでは使うのにな
>>107 よく知らないのなら
迂闊な事は言わない方がいいですよ。
117 ：
仕様書無しさん：05/02/23 01:38:49
>>115 MapはJavaではもっとよく使う
とくにServlet + DBでは重宝する。
VectorやHashtable, Enumerationはレガシーなので使用禁止だw
足りない分はJakarta Commons Collectionsで補う
JavaってMSのおかげでwinネイティブの世界でもうまくいきそうだったのに
サンが余計なことして使いどころが狭まっちゃったんだよね。
>>115 俺がmapをよく使うのは、PerlからC++に来たからだろうか。
120 ：
仕様書無しさん：05/03/13 00:03:31
>>118 使いどころが狭まった？
そう感じたことは全然ないが。
Javaでモノをろくに作ったことがない人間には
そういうイメージだけ先行してJavaの最新動向がよくみえていなさそうだね。
ライブドアの堀江がイメージだけで先行して凄そうだからライブドアの株でも買おうかなと
思って買ったが株価はまったく上がらず下がる一方で大損をする馬鹿にそっくりだよな
>>118って
121 ：
仕様書無しさん：05/03/13 00:08:33
C++ の標準の map は Tree Map だからなあ。
hash_map は処理系依存だし。
なんでﾎﾘｴﾓﾝが出てくるんだｗ
123 ：
仕様書無しさん：2005/05/02(月) 12:45:33
>>107 Ｃ＋＋はＣを包含しているので、速度が足りなければＣ構造を使えばいい。
それから、ＳＴＬは使い分ければいい。実行速度が必要なところは配列などを使い、
それ以外は、ＳＴＬを使うとか。
125 ：
123：2005/05/02(月) 15:07:25
>>124 ほとんどの場合それが正解だと思う。
ただ、たま～にコンテナを避けたい場合があるんだよね。
C++嫌いを大量発生させたのはVC++/MFCだね。
BCBすればVBなんかよりもずっとポトペタ開発なのにね。
何このC++ﾏﾝｾｰなスレ
VBはﾎﾟﾄﾍﾟﾀと馬鹿にし、BCBはﾎﾟﾄﾍﾟﾀとﾏﾝｾｰする。
コンパイラの最適化能力には目をつぶる。
これがボーランドクオリティ。
>VBはﾎﾟﾄﾍﾟﾀと馬鹿にし、
これ、ちが。
VBはﾎﾟﾄﾍﾟﾀしようとすると、コントロールが少な杉というか、じぇんじぇん無いじゃん。
>コンパイラの最適化能力には目をつぶる。
これもちがくない？
ﾌﾞﾋﾞはオソ杉で画面の描画が見えちゃうﾖ。
131 ：
仕様書無しさん：2005/05/02(月) 22:29:17
C++なんだから、VC++やGCC、watocomとの比較に決まってるじゃん
133 ：
仕様書無しさん：2005/05/03(火) 08:48:43
Borland C++ Builderはﾌﾞﾋﾞがライバル
134 ：
仕様書無しさん：2005/05/03(火) 09:05:06
VBで充分
135 ：
仕様書無しさん：2005/05/03(火) 10:43:20
LinuxでC++開発している人の開発環境ってなんなんだろ？
Emacsは無しで。
kdevelopは趣味の域をでれないとおもうし。
136 ：
脳内PG：2005/05/03(火) 11:29:07
時代遅れだろうが、習得しておいた方がいいのは確かだよね・・
じゃあ、俺はsedで
139 ：
仕様書無しさん：2005/05/03(火) 15:29:53
>>134 BCBは十分だが、VBは不十分。
個人に言えば、
BCB > VC++ >>>>>>>>>>>>>>>>VB
だな。
BCBよりVBの方が親切だよ。
141 ：
仕様書無しさん：2005/05/03(火) 16:42:22
>>135 g++ + autoconf + automake + emacs + gdb
これだけそろえれば、GUI の IDE とできることは
大して変わらなくなる。
142 ：
仕様書無しさん：2005/05/03(火) 16:45:51
DelphiがあるからBCBなんて使う機会ないよ
つかC++おぼえときゃ、他の言語のいろはも最初からわかってしまう仕組み
ﾃﾝﾌﾟﾚｰﾄｸﾗｽもっと普及しろ
>>141 Eclipseが次世代emacsなんじゃないの？
146 ：
仕様書無しさん：2005/05/03(火) 19:18:37
>>146 入力補完のせいで砂時計が出るのは。。。
脳内補完汁
(；ﾟДﾟ) ＜ 汁！？
脳内おかん汁
>>146 「入力補完がない。仕事じゃ使えない」とかほざく。
仕事じゃ使えない。
153 ：
仕様書無しさん：2005/05/23(月) 09:36:35
最近のC++は人気がなさすぎですな
>>153 C++の設計と進化がものすごい売れ行きみたいですが、何か？
155 ：
仕様書無しさん：2005/05/23(月) 12:56:40
C++は進化が止まってしまってる。
CはlinuxやBSDのおかげでまだ使われている。
ObjCはmacのおかげで進化し続けてる（TIGERの新しいフレームワークは興味深い）
JavaはSUNにコントロールされてるから進化はしてるが進歩はして無い。
C＃は話にならない、単なるJavaもどき。
だから今更C＋＋使っても将来は無い。STLいいのにね、もったいない。
使用されてるかどうかと、進化のあるなしを
混同してるのは故意か天然か。
Java = C++
- プリプロセッサ
- テンプレート
- ポインタ演算
- 多重継承
- 非ヒープ上オブジェクト
- 演算子オーバーロード
- 名前空間
・
・
・
+ カベージコレクション
>>157 プリプロセッサは言語とは関係ないし、名前空間もパッケージを使えば
同様のことが出来るだろ。
>>154 それがC++の人気に繋がるかといえば、
そうでも無いなあ。
勉強するにはいいけどC++の案件を増やす要因には
なりにくいな
160 ：
仕様書無しさん：2005/05/23(月) 14:21:12
>>155 Javaはフレームワークだけ大幅に進化している。
Genericsによる進化、コンカレント工学技術の導入
といった進化は大きい。
進化が遅く見える部分は外部の者が提供している。
それはApache Jakarta Project, IBM, Eclipse Communityだ。
ほかにもJBossグループ、BEA, Spring Fraework, Seasor2
といったものがあり、さらに
Apache Incubator から次々とあたら曽於者が生み出され
Javaを取り巻く環境は激しく進化している。
C#はWinFXによる進化が期待されている。
>>157 > Java = C++
> - プリプロセッサ - テンプレート(ただしGenericsは覗く) - ポインタ演算
- 実装多重継承 - 非ヒープ上オブジェクト - typedef
> - 演算子オーバーロード - グローバル変数 - グローバル関数 - 構造体
> ・
> ・
> ・
+ カベージコレクション
+ VM
+ 強く型付けられた言語
+ 動的コンパイル JITコンパイラ、Hotspot
+ PreJITコンパイラ
+ インターフェース実装
+ リフレクション
+ 厳格なセキュリティ
+ サンドボックス、署名
+ 国際化プログラミング
+ ネットワーキング
+ すべてのクラスのスーパークラスObject
なにこの現行のアプリ全否定スレ
163 ：
仕様書無しさん：2005/05/23(月) 17:27:20
JAVA信者がC♯に必死なのが笑える
きっと言語仕様が遙かに優れているの解ってて
恐怖しているんだなw
164 ：
仕様書無しさん：2005/05/23(月) 20:45:53
結局そこへいきつくのかw
せっかくJavaを覚えたオジサンたちにとって、「なんかちょっと違う」C#を覚えるのは
逆にかなり苦痛らしいよ。
JavaからC#への移行は言語自体の機能がどうこうよりクラスライブラリを
覚えなおすのがﾏﾝﾄﾞｸｻ('A`)
167 ：
仕様書無しさん：2005/05/24(火) 02:24:44
>>166 Visual Studioってインテリセンスとかついてて勝手に一覧でてくるから
覚える必要まったくないじゃん。適当に最初の文字タイプして
矢印で見ていけば。俺はＪａｖａから学んだけどどっちも苦にならなかったよ。
C++で常駐プロセス作っても何も言われないが、
Javaで常駐プロセス作ろうとするとみんな眉をひそめるよ。
*ﾊﾝﾏｰで殴る
javaで常駐プロセスはVM共有化がないと話にならない
まあ、C#がある現在、Javaなんぞをやるのはマゾ行為でしかないわけで。。。
172 ：
仕様書無しさん：2005/05/27(金) 16:56:28
とはいえ、プロも歳をとれば油断する。
大事故になりかねない。
若い奴でも調子に乗ればとんでもない殺人を犯すことになる。
プロでも酒を飲めば3人の高校生の命を奪ってしまう最近の交通事故のように
なることもありうるのだ。
JR西日本のような列車事故は焦ったために起きたことだ。
焦りに焦ってバグで人を殺すようなプログラミングをすることは許されない。
私はC++を医療器や航空機に使うことは反対だ。
C++は使い方を誤ると誤って患者や旅客の命を奪いかねない言語だからだ。
だから人の命を奪う恐れが高いC++は普及させないほうがいいと思っている。
時間とかければいいとはいえ、顧客は容赦しない、
「他の言語でやすくできるならなぜC++では安くできないのか？」
と問いつめてくるのだ。そうなると大抵の企業はものを「お客様は絶対的な神様だ」と称して
ものを速く完成させようとすると。すると徹夜残業が増える。徹夜残業しても間に合わないので
C++にしかできないとんでもないスパゲティコードが生まれる。
そしてC++のコードが世に増えれば増えるほど無駄に徹夜する時間が増えてしまう。
C++のコードを貰い受け、引き継ぎ、苦労する後継者が増える。
そして焦りが人の命を奪う。
だから、私はC++だけで作られた自動操縦システムを開発することに反対する。
JR西日本のような列車事故を二度と起こさないためにも。
少なくともC++に厳重なルールとC++の規格が統一されるまでは
C++は普及させないほうがいいだろう。人々の命を救うためにも。
>>172 >ニャホニャホタマクロー辞任にあたり
まで読んだ。
コピペにその返しは痛い。
実在し得ない相手の地団駄を一所懸命想像してニヤついてそう。
176 ：
仕様書無しさん：2005/05/28(土) 23:06:36
コピペの奴って、最初自分ではいいこと言ってると思ったんだろうね。
賛同の嵐がやってくるなんて妄想しちゃって。
しかし反応が悪く、自分がバカみたいに見えてきたんで、今度は「荒し」のフリしてるんだ。
でも、君は、恥ずかしいよ。
これはコピペのうちに入れたくネーよ、芸術性の欠片も無いがな
178 ：
Warrior：2005/05/28(土) 23:45:33
とはいえ、プロも歳をとれば油断する。
大事故になりかねない。
若い奴でも調子に乗ればとんでもない殺人を犯すことになる。
プロでも酒を飲めば3人の高校生の命を奪ってしまう最近の交通事故のように
なることもありうるのだ。
JR西日本のような列車事故は焦ったために起きたことだ。
焦りに焦ってバグで人を殺すようなプログラミングをすることは許されない。
私はC++を医療器や航空機に使うことは反対だ。
C++は使い方を誤ると誤って患者や旅客の命を奪いかねない言語だからだ。
だから人の命を奪う恐れが高いC++は普及させないほうがいいと思っている。
時間とかければいいとはいえ、顧客は容赦しない、
「他の言語でやすくできるならなぜC++では安くできないのか？」
と問いつめてくるのだ。そうなると大抵の企業はものを「お客様は絶対的な神様だ」と称して
ものを速く完成させようとすると。すると徹夜残業が増える。徹夜残業しても間に合わないので
C++にしかできないとんでもないスパゲティコードが生まれる。
そしてC++のコードが世に増えれば増えるほど無駄に徹夜する時間が増えてしまう。
C++のコードを貰い受け、引き継ぎ、苦労する後継者が増える。
そして焦りが人の命を奪う。
だから、私はC++だけで作られた自動操縦システムを開発することに反対する。
JR西日本のような列車事故を二度と起こさないためにも。
少なくともC++に厳重なルールとC++の規格が統一されるまでは
C++は普及させないほうがいいだろう。人々の命を救うためにも。
179 ：
仕様書無しさん：2005/05/29(日) 00:59:44
コピペにマジレスして突っ込まれてマジ切れ
マジかっこ悪い
181 ：
SuperWarrior：2005/05/29(日) 17:51:25
とはいえ、プロも歳をとれば油断する。
大事故になりかねない。
若い奴でも調子に乗ればとんでもない殺人を犯すことになる。
プロでも酒を飲めば3人の高校生の命を奪ってしまう最近の交通事故のように
なることもありうるのだ。
JR西日本のような列車事故は焦ったために起きたことだ。
焦りに焦ってバグで人を殺すようなプログラミングをすることは許されない。
私はC++を医療器や航空機に使うことは反対だ。
C++は使い方を誤ると誤って患者や旅客の命を奪いかねない言語だからだ。
だから人の命を奪う恐れが高いC++は普及させないほうがいいと思っている。
時間とかければいいとはいえ、顧客は容赦しない、
「他の言語でやすくできるならなぜC++では安くできないのか？」
と問いつめてくるのだ。そうなると大抵の企業はものを「お客様は絶対的な神様だ」と称して
ものを速く完成させようとすると。すると徹夜残業が増える。徹夜残業しても間に合わないので
C++にしかできないとんでもないスパゲティコードが生まれる。
そしてC++のコードが世に増えれば増えるほど無駄に徹夜する時間が増えてしまう。
C++のコードを貰い受け、引き継ぎ、苦労する後継者が増える。
そして焦りが人の命を奪う。
だから、私はC++だけで作られた自動操縦システムを開発することに反対する。
JR西日本のような列車事故を二度と起こさないためにも。
少なくともC++に厳重なルールとC++の規格が統一されるまでは
C++は普及させないほうがいいだろう。人々の命を救うためにも。
>>181よ
C++はその意味では人を殺せよう。
しかし殺せない言語に出来ることは制限されることを忘れては居まいか？
少なくともC++には「人を殺せるだけの自由度とポテンシャル」がある。
ソレこそがC++を使う理由なのだよ。
その分扱いが難しくなっても…だ。
いうなれば鋭いナイフだ…汎用性があり、自由が効く反面で危険だ。
それとも君はペーパーナイフにすがって生きていくと言うのかい？
>>182 自己書き換えコードを駆使したアセンブラでも使ってればぁ？
切れ味の悪い包丁は、よく切れる包丁より危険だ。
185 ：
仕様書無しさん：2005/05/31(火) 22:49:21
炭素、酸素、窒素、水素など有機化合物に最低限必要な
少ない元素の組み合わせでより多くの物質を生み出せる自然との調和を取りやすい言語がJavaだとしたら
数多くの元素、しかも生命にとっては無駄どころかほとんど危険な不要な放射性同位体
までをも平気で使ってしまう諸刃の剣がC++
もうひとつのたとえとして、
英語のようにたった26文字という少ないアルファベットの組み合わせだけで
言語を表現できわかりやすいのがJavaだとしたら
C++は、中国語や日本語のように無駄に複雑で漢字というアルファベットが
トリビアのように膨大な言語だ。
しかも中国人たち彼らはそれが凄い、素晴らしいことだと豪語している。
それはただの文化であって仕事の能率では関係がないどころか能率を下げる可能性もあるのに。
アンチJavaなC++信者にはそういう傾向があるのではないかという気がしてくる。
186 ：
仕様書無しさん：2005/05/31(火) 23:05:31
単純な事だと思う。
Javaは、確かに少ない元素の組み合わせで物質を生み出す。
しかし
C++は、微粒子のレベルから新しい元素をも作り出し、物質とする。
どっちが良いか悪いかは別として。
C++が不要なわけではないな。
187 ：
仕様書無しさん：2005/05/31(火) 23:15:36
別にC++は言語としての設計思想が時代遅れだとは思わないが、
効率よくプログラミングできる言語ではないよな
C++はパッケージ管理やクラスの概念等、コーディングレベルでの
言語としてのサポートが貧弱すぎ
もうちょっとJavaを見習って欲しい
188 ：
仕様書無しさん：2005/05/31(火) 23:30:43
189 ：
仕様書無しさん：2005/05/31(火) 23:31:30
>>187 Cと互換性があり、古い開発ツールが使え、Cと同等の実行効率、という基本方針があって、
それがC++が生きながらえている最大の根拠だからね。
それらと相容れない仕組みは期待してもしょうがない。
>>190 それを目指した言語は幾つもあった。
Objective-Cとか、えぇと、他名前忘れたけど、３つ並べられてた。
その中C++が一歩前に出たのは言語名が優れてただけな気がする。
>>191 Objective-C は、「表記の仕方があまりにも C からかけ離れてて
馴染み難い」ってのと、「実行効率を犠牲にしてる」ってのが。
193 ：
仕様書無しさん：2005/06/03(金) 14:10:11
>>186 > C++は、微粒子のレベルから新しい元素をも作り出し、物質とする。
おいおい、作ったら10のマイナス何乗秒後かには消えてしまう
ろくな物質がないじゃないかw
ウンウンなんとかニウムみたいなものつくって
何が楽しいんだw
そんな不安定な元素を組み合わせて人間に役立つ物質でも
作れると思ってるのかw
194 ：
仕様書無しさん：2005/06/03(金) 14:11:23
>>190 おまえ、D言語をしらんのか？？
D言語が普及したらC++なんて糞くらえだぞw
>>193 そういう状況から偉大な発明者が現れて、その発明無しでは生きていけない
数年後のお前が「ぬるぽ」と書き込みをする。
いや、そもそもおまえの発言そのものが濡ルポだよ
197 ：
仕様書無しさん：2005/06/03(金) 14:28:38
北朝鮮の科学者が核兵器作って人殺して偉大な発明だあ？
アフォか
無理矢理C++を叩こうとするもんだから
すっかりトンデモなレスばっかになっちゃってるね（微笑）
「C++の設計の多くの部分が、強制に対する私の嫌悪に根ざしている。
人類の歴史の最悪惨事は、"これは良いことだからこれをやれ!"という
理想主義者の強制から生じている。
理想主義は多くの罪なき犠牲者を作りだすだけでなく、
権力を揮う理想主義者たちを妄想と腐敗に導く。
理想主義者たちは経験を無視し、
また彼らのドクマや理論を否定する現実を無視する。」
『C++の設計と進化』 Bjarne Stroustrup著
より引用
>>201,202乙
おいらはC++厨ですが何か?
厨房なんで嬉しくって、いろんなとこに貼りますたよ。で、何か?
ﾌﾞﾋﾞ厨はあなたでしょ。Java厨にもなれないのね(^∀^)ﾌﾟｹﾞﾗ
>>203 >で、何か?
ガードレールの金属片に頭ぶつけて氏ね。
>>204 すいません。あなたVBすらまともにできないのですね。
そんな程度の低い煽りでは、まともにプログラムは書けませんよ。
新明解国語辞典を精読されることをオススメします。
あぼーん
209 ：
”削除”依頼板転載人＠星猫：2005/06/03(金) 18:46:59
>>209 山田ウィルスの変種かとｵﾓﾀら、違うのか。
>>205 > そんな程度の低い煽りでは、まともにプログラムは書けませんよ。
煽りとプログラムの関係を述べるよう求めたりしたら
やっぱ答えられずにヒステリー状態になっちゃうんでしょうか？
>>200 それでプログラマが個別に「C++を安全に使う方法」を生み出さなければならないと。
一種の職務怠慢だよな。クサレ言語設計者が。
いい加減、新人にEffective C++系の本の内容一通り叩き込むの面倒くさいんですけど。
>>212 文句言うくらいなら使わなきゃいいじゃない。
>>212 怠慢のおかげでコンパイルタイムチューリング完全。
無能はいつだって恩恵が見えない。
216 ：
仕様書無しさん：2005/07/13(水) 14:27:26
どうしてC++は死滅してしまったのか？
おお、情けないC++
↑な～に言ってんだか…
この速度ならぬるぽ
219 ：
仕様書無しさん：2005/07/16(土) 14:51:54
すでに死滅してるさC++は
この人気のなさが死滅の原因
莫迦には使えない言語ですから。
>>212 で、結局｢安全に使うための定石｣を強制されるんだよな。
222 ：
仕様書無しさん：2005/08/26(金) 16:49:27
13 名前：デフォルトの名無しさん 投稿日：04/04/17 14:17
>>9 C++の開発者ってSTLみたいな変なところにだけ拘って、
実際の需要と離れていってるんじゃないかなぁ。
MSもC++は放置して、C#とかVBみたいな独自言語で
ユーザーの囲い込みに走っている感じ。
C++は割と好きなのだけどライブラリが貧弱なので
C#とJavaに移行予定です。
14 名前：デフォルトの名無しさん 投稿日：04/04/17 14:19
>>13 ライブラリが一番多い言語だと思うけど･･･
お金払うのは嫌だって意味で？
25 名前：デフォルトの名無しさん 本日のレス 投稿日：2005/08/26(金) 16:44:07
>>14 フレームワークとして使えれば
最高のライブラリだが
数が多いだけでは軍人数が多いだけの中国軍と同じ。
アメリカ軍は中国軍よりも人数が少ないが
軍隊としての質は非常に高く、軍事力も絶大強大で世界最強だ！
総ライブラリ力、総フレームワーク力ではC++軍(中国)は
強大な軍事力を誇るJava軍(アメリカ軍)、C#軍(イスラエル軍)陣営に劣る！！！！！
223 ：
仕様書無しさん：2005/08/27(土) 01:56:49
C#ってちょっとやってみたことあるけど苦痛でした。
というかＭＳとＳｕｎが和解した今、使い道ってありますかね？
Javaでいいんじゃない？っていう時流だと感じる今日この頃（というか案件ででてきたことないC#）
224 ：
仕様書無しさん：2005/10/23(日) 14:18:38
ｸﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｫ！
225 ：
仕様書無しさん：2005/10/24(月) 01:40:35
すみません真面目に相談なんですが・・・
今までVB（６まで）とCOBOLしかやったことが無かったのですが
いきなりVC++をやれと言われました。
さっそく仕事が入ってきてソースをながめまして、修正したところ
ちょっと直しただけで色んな所に影響が出るのと、Classのつながりなどが
全くわかりません。命令もわからないし・・・
もう自分には全く手を付けられません。
来週末までにある程度修正しなければいけないのですが、どうしたら
いいですか？諦めるわけにはいかないんです。私以外にやる人が居ない
し、もし諦めたら多大な被害が出ます。
助けてください。
>>225 なるほど糞プログラムというのはこういった具合に生み出されるものなのだな。
あなたも気づいている通り、それは｢どう考えても無理｣です。
あなたの責任は、明らかに不可能なスケジュールを立てたバカの責任とともに、
今後のデスマのどさくさでうやむやになると思うのであまり深刻に考えなくてもいいと思います。
いざとなったら逃げてもいいわけですし。
227 ：
仕様書無しさん：2005/10/24(月) 03:34:17
>>225 「父が倒れ、家業を継ぐことになった。」
今の君には、どんな言葉よりもすばらしい響きだろう。
なーに。
多大な被害ったって、
>>225が被るわけじゃないし。
失業保険もらいながら、VC++の勉強したら？マジで。
そんな準備期間設けない会社なんか、つぶれてもかまわん。
ってか、この世から抹殺しろ。
228 ：
仕様書無しさん：2005/11/05(土) 00:03:24
C++が時代遅れになるとき、
それはまさにD言語がはやるときだね。
D言語が流行るのはMSがVisual Dを発売してからじゃないかね。
でも.net作ったから、しばらくはDはやらんだろうなぁ。
230 ：
仕様書無しさん：2005/11/05(土) 14:14:13
そしたらM$はC#かC++.NETを推そうとしそうだな。
D言語の本や雑誌も出ているので
密かに流行出すかもな。
まずはFedora Coreのパッケージに標準搭載されれば(ry
231 ：
仕様書無しさん：2005/11/23(水) 17:18:49
ま、VS.NET 2005 Express が無料になったから
いいでしょ
232 ：
仕様書無しさん：2005/12/04(日) 00:44:28
>230
やるならC++/CLIだろ。
233 ：
仕様書無しさん：2005/12/04(日) 02:01:43
>>232 M$系言語に依存してもまたM$に利用され捨てられるだけだぞ
ＶＢ厨やC#厨、COMに騙された昔のVC++厨のように
234 ：
仕様書無しさん：2005/12/04(日) 03:15:07
やっぱJ#が最高だろ
235 ：
仕様書無しさん：2005/12/04(日) 10:39:10
時代はS言語だぞ
てめーら遅れすぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
言語の自由度が高い分、使いこなすまでの敷居も高いのかも知れんが、
これ使いこなせると本当の意味でプログラマって感じがするな。
かっこいいじゃん。
Javaとか、誰でも使えちゃう言語って仕事向きかも知れないけど、
それだけじゃ面白くねーよ。
仕事ではあんま触りたくないけど。
237 ：
仕様書無しさん：2005/12/04(日) 10:55:54
C++は時代遅れではなくて
単に設計思想が間違っている言語。
ライブラリもクズの寄せ集めで
趣味の域を過ぎない言語。
238 ：
仕様書無しさん：2006/01/08(日) 02:09:40
>D言語が流行るのはMSがVisual Dを発売してからじゃないかね。
>でも.net作ったから、しばらくはDはやらんだろうなぁ。
いやVisual D.NETを発表する。
当然、D/CLI も発表する(w
とりあえず、Perl.NETで我慢する
240 ：
仕様書無しさん：2006/01/08(日) 02:24:11
とりあえず COBOL.NETかFORTRAN.NETかLISP.NETかPASCAL.NETかAWK.NET か
出てくれ（ｗ
MASM.NETきぼんぬ
242 ：
仕様書無しさん：2006/01/08(日) 02:45:02
MASM/CLIが必要になるでしょうね。
MSILと混合して記述できないと困るし。
Python .NET が有力だな
>>237 もしそうだとしたら、その割にはめちゃくちゃ普及したと思うが。
>>225 はその後どうなったんだろう・・・
すげー気になる・・・
>>246 Scriptじゃねーの？
だとしたらヴァカ丸出しだが。
248 ：
仕様書無しさん：2006/02/10(金) 11:24:01
250 ：
仕様書無しさん：2006/02/10(金) 12:08:11
C++は時代遅れの糞言語だが、C++出来る人は神。
>>242 成る程と思ったが、よく考えると意味ねーじゃん。
252 ：
仕様書無しさん：2006/02/12(日) 13:40:28
>>250 神とかいうな。
C++しかできない馬鹿が増えるだろ。
今C++の仕事なんてろくにナインだしな。
金も稼げない奴を神とは呼びたくないしな。
253 ：
仕様書無しさん：2006/02/12(日) 18:51:34
単に、言語仕様が複雑なだけで、仕事で使わなければ
覚える必要はないと思う。
目的が金なら他の職業探したほうが楽なんじゃないか？
255 ：
仕様書無しさん：2006/03/23(木) 16:17:05
自社開発では他じゃなくてもいい
256 ：
仕様書無しさん：2006/03/23(木) 16:24:15
頭やられて今ニート
ﾌﾟﾌﾟ
>>726は現実を知らないようだな。
>>723が意図していることの
意味も知らず。
# Slashdot での大論争。これは今までで一番愉快な
Java 対 C++ の議論に違いありません。
C++ 愛好家は必死に「不公平だ、こっちはメモリ管理を
手動でやらなきゃいけないのに」と主張しています。
公平を期するための彼らの提案は - System.gc() の
呼び出しを山ほど突っ込んで Java 側を遅くするというも
のでした（お気づきでない方のために。Java は System.gc()
を呼び出さなくてもメモリを回収します。 System.gc() の呼び
出しを追加してもメモリ回収の速度が遅くなるだけです）。
続く抗議もすべて、このベンチマークが Java をひいきしてい
るという一点に集中しているようでした。しかし奇妙なことに、
３年前までは当時の JVM をテストしても C++ の方が速いとい
う結果が出たものです。このノイズの山を掘り返せば、有意義
なコメントが見付かるかも知れません
# さらに続く議論。この事件から生じた騒動（または余分なキャラ）
で大儲けできた人がいるかも知れませんね
# Java と .NET のガベージコレクションに関する調査
# WebSphere は自動的に負荷分散の最適化を行うことで、ハードウェア要件の低減をねらいます
#
# Java 1.5 は 20% 高速化した模様
http://www.javanews.jp/javap/newsletter043.html >>257 随分前にその話は終わったんだが。
今頃ノコノコ出てきてそれか。
259 ：
仕様書無しさん：2006/03/31(金) 11:59:29
C++厨が終わったことにしておきがたってるだけなんだが。
今頃その逃げ台詞か
>>259 >C++厨が終わったことにしておきがたってるだけなんだが。
ごめん、何言ってるかよく解らない。
ん？「終わったことにしたがってる」か？
いや、検討はした。どこのｽﾚだか忘れたが。
(個人的には、メモリ管理を云々する莫迦は放置すべしと思うが)
どっちにしろ、今更そんなコピペを持って来ても
何が変わるわけじゃない。
少しは自分の言葉で語れ。
ささ、もう一度
はい！
C++厨がC++が負けているという話を
終わったことにしておきがたってるだけなんだが。
今頃その逃げ台詞か
ごめん、
>少しは自分の言葉で語れ。
なんて無理だったようだ。
ごめん、一体どんな煽りをしてるのか
質問に答えさせるなんて無理だったようだ。
265 ：
仕様書無しさん：2006/03/31(金) 23:01:57
大規模開発君!!
>>264 そもそも、日本語が不自由なのに
こんな所で話し相手探すのは無理。
本国へ帰れ。
はいはいそれは自分の姿を鏡にうつしてから言ってみようね
>>266君
最近特にC++の重要性を感じてきた
こいつを攻略せずに開発者といえるか？
270 ：
仕様書無しさん：2006/05/03(水) 04:45:07
キャリア系のソフトは、全部C++じゃないのか？
Javaは遅いからC++で、っていわれて、
C++で書いてるよ。
271 ：
仕様書無しさん：2006/05/03(水) 09:47:25
今更だけどC++勉強しなおしたい
すればいいじゃないの。世の中で一番楽しい言語は
C/C++だ！！
全てはポインタの基礎を理解すればできるはず。
(非配列編)
char *p; //アドレスの入れ物、初期化または代入しないと使ってはいけない
char c=100; //8bit値の入れ物にDECの100を代入
p = &c; //8bit値の入れ物のアドレスをセット
printf(*p); //8bit値の入れ物のアドレスの中身の値を出力
まとめ
宣言時のポインタ変数の * と利用時の*の意味が違う
ポインタ変数も入れ物である。ただしアドレスをセットする専用の入れ物。
間接参照するために利用する。
【問題】
間違いをつっこんでくれ。
ポインタを理解してもテンプレートメタプログラミングを理解するのには役立たない。
275 ：
仕様書無しさん：2006/05/07(日) 15:27:39
ポインタの全てを網羅してるかは別として
サンプルコードとコメントの部分は間違ってないよ
276 ：
275：2006/05/07(日) 15:30:11
あ、失礼
printf(*p);
これが間違っていた。
277 ：
仕様書無しさん：2006/05/07(日) 15:37:41
俺、日本語できるよ
278 ：
275：2006/05/07(日) 15:40:22
正しくは
printf("%d",*p);
出力結果
100
279 ：
仕様書無しさん：2006/05/07(日) 15:47:50
280 ：
仕様書無しさん：2006/05/07(日) 15:51:58
例題で10進使うのにわざわざ「charのポインタ」を使う理由が不明。
素直に実値のintを使え。
281 ：
仕様書無しさん：2006/05/07(日) 15:55:24
>>280 charはサイズが小さい数値型。という認識。
別にcharでもlongでも同じ。
こんなので迷うならばCは無理。
282 ：
仕様書無しさん：2006/05/07(日) 16:02:15
C++は趣味でやりなさい、趣味で。
複雑な言語仕様が
さぞかし自尊心を満足させてくれるだろうから。
単に古い遺産が捨てられなくてあんな肥大化しただけなんだが。。
うむ、
>>282が正論を言っている。
板ではこの正論が解らないC言語厨がよく暴れているようだが
285 ：
仕様書無しさん：2006/05/07(日) 16:57:26
趣味でやれってのは同意。苦労してマスターしても報われ度は低いかも。
IT屋さんとしての仕事も少ないしね。
ただ、今後のプログラマ人生の中で何かしらの礎にはなってくれると思う。
だけど、＞複雑な言語仕様ってのはおかしい。
理解しづらい仕様かもしれないが、構造的なものは至ってシンプルだと思う。
僕が理解出来ないものはふくざつ
287 ：
仕様書無しさん：2006/05/07(日) 19:18:56
C++は確かにANSI Cよりは複雑だが
言語仕様の機能を必要以上に使わなければ良い。
・クラスのボディとANSI Cのスタイルの組み合わせで結構。
・クラス&STL C++の組み合わせでも結構。
・参照、オペレータ演算を使わないも結構。
ようはいかにシンプルに統一されたコードで高性能な実現ができるかだけだ。
馬鹿な椰子ほど全部の機能仕様を使わないとC++を理解した事にならないと
脅迫観念を持っているようだ。
C++が複雑とかどこの年寄りだよ
いや、java小僧だろ
290 ：
仕様書無しさん：2006/05/07(日) 19:48:46
C++擁護してる奴はなんで擁護してるのかさっぱりわからん
時間をかけて習得する割に本当に得るものが少ない。
俺は仕事でやる必要なければ一切いじりたくないよ
そういうわけにもいかないのが現状だが
あの程度のものに時間かけるのか？
292 ：
仕様書無しさん：2006/05/07(日) 20:38:31
いや、もう既に習得してるから「得るものが少ない」とかいう考えはないが、
習得してもいない奴が「複雑」とか「使えない」とか語るのはおかしい
>>292 >習得してもいない奴が「複雑」とか「使えない」とか語るのは
「挫折した」の歪曲表現。
294 ：
仕様書無しさん：2006/05/07(日) 20:56:02
>>290みたいのは、
一般的にJavaで飯が食えるようになった頃にPGデビューしたいわゆるJava世代だろ。
そう言う奴は、C/C++なんて通ってこなかっただろうし、今更習得しても
今後、その苦労に見合った見返りがあるか疑問ってのも解る。
現に俺だってC/C++で仕事するってことはあんまり無くてJavaやC#メインで使ってるし。
現世代でも「C/C++は難しい」っていう風潮があって、Java世代においても
C/C++が出来ないことがイメージ的にPGとしてのLvをはかられてしまうっていう局面が
言い伝え的にあったりするから、ある種のコンプレックスみたいなもんだろ。
んで、チャレンジしてみたはいいが「なにこれ？」って理解に苦しみ、あげく果てに
「使えない」等のC/C++叩きに発展と。
295 ：
仕様書無しさん：2006/05/07(日) 21:02:14
296 ：
仕様書無しさん：2006/05/07(日) 21:04:21
馬鹿には似合わない
それがC/C++
297 ：
仕様書無しさん：2006/05/07(日) 21:06:31
>時間をかけて習得する割に本当に得るものが少ない
習得できてないから得るものがマイナスになっただけだろ
298 ：
仕様書無しさん：2006/05/07(日) 21:26:08
得るものが無ければやらなきゃいいだけの話。
自分が理解できねーのを言語のせいにしてんじゃねーよ。
299 ：
仕様書無しさん：2006/05/07(日) 21:27:06
Java僧≒シャバ僧
300 ：
仕様書無しさん：2006/05/07(日) 23:52:45
【問2】
出力結果を答えよ
#include <stdio.h>
int main()
{
//配列編
long larr[] = {1,2,3,4,5,0};
long *pl;
pl = larr;
while(*pl++)
putchar((int)*pl + 0x30);
}
> long larr[] = {1,2,3,4,5,0};
> long *pl;
>・・・
> while(*pl++)
> putchar((int)*pl + 0x30);
int larr[] = {1,2,3,4,5,0};
int *pl;
・・・
while(*pl)
putchar(*pl++ + '0');
あ、間違い探しじゃないのか
302 ：
仕様書無しさん：2006/05/09(火) 19:15:25
だからテスト問題や間違い探しのような問題は意味がないって話だよ。
ポインタが必要と言う意味を理解しているのか？
ポインタに対して特定の演算子使えるの知らないのか？
勉強しなおして来い
>>304 そーゆー意味じゃなかろう。
副作用の話でしょ。
putcharのことか
つーか、セキュリティを考えると、
いずれクライアントPCではネイティブアプリ動かせなくなりそうだがどうよ。
なかなか歴史を感じさせるスレですね
>>307 別に俺はネイティブにしたいからC++を使っているわけではないので、なんとも思わない。
Boostが使えればそれでいい。今のC++/CLIではまだアンマネージドでないと無理のようだが。
310 ：
珍米大使：2006/07/02(日) 05:03:56
C++を馬鹿にする奴はとりあえずWindowsとLinuxとUNIXと
プレステ２とプレステとスーパーファミコンとファミコンと
XBoxとXBox360の使用を中止すべきだな。
ちなみに俺は携帯の使用を中止しない
なぜなら俺はJavaを馬鹿にしている訳ではないからｗ
311 ：
仕様書無しさん：2006/07/02(日) 21:47:00
312 ：
仕様書無しさん：2006/09/11(月) 22:46:36
そっすね
C言語は後数十年は無くならないだろうなぁ。
今度出るWindows VistaでもドライバはほぼC言語だし。アプリはC++かな。
ドライバ屋さんはしんどいですよ。ドライバではC++は危険だし、boostなんか使えないし。
314 ：
仕様書無しさん：2006/09/12(火) 04:02:16
C++/CLIの文法がすごい。というかキモイ
MSはC#3.0でも文法追加するしすごいな
VB.netに触れる機会があったが
VBゆえの曖昧さが.net対応強制で緩和されてて
以前のアレよりは結構マシに見えた
ほぼコンパチブルらしいC#ってのはそんなにやばいの？
316 ：
仕様書無しさん：2006/09/13(水) 01:05:50
>>313 おそらく C と Lisp だけは 100 年後も現役で使われてるだろうな。
>>314 まなげどよりはずっと素直な構文になったと思うけど・・・
318 ：
仕様書無しさん：2006/09/13(水) 17:23:56
>>310 携帯Javaなんか使ってるバカいるの？あ、お前か
319 ：
仕様書無しさん：2006/09/13(水) 18:54:17
携帯JAVAってよくないの？
auだからわからんな。BREWもあまりいいとは言えないが。
携帯ってよくないの？
>>318 お前ほどじゃないんじゃね？
>>319 どうせゲーム程度にしか使われないんだから
あんなもんでおｋ。
>>320 BREW は仕様が論外なのと、au が莫迦。
携帯Javaの仕事ってやった事ないから知らんけど、納期が極度に短くて、単価が極度に安いんだろうな。
C++に依存しているBREWはもっとひどいよ
325 ：
仕様書無しさん：2006/10/27(金) 17:01:40
auが場かってのも歩けど
クアルコムも馬鹿
326 ：
仕様書無しさん：2006/10/27(金) 17:10:03
携帯屋さん。余計な機能付けなくて良いから、辞書機能ちゃんとしてよ。
広辞苑とかさ。
メールやってて変換出来ない文字おおすぎ
>>326 変換してて突然リセットかからなければいいんですよ。
解析系のクライアントアプリ作ってるC++厨です。
javaとか興味あんだけど、いまいち乗り切れないんだよね。
理由↓
１．ホントに速いの？ -小数の行列演算とかどうよ
２．起動は速いの？
３．VMは信頼できるの？ -VMがハングしたりとかしないの？
４．既存の資源は活用できるの？ -買い漁ったのライブラリ(.libとか)が必須なんだけど
５．最適化は出来るの？効くの？ CならPGOとかprofilerとかあるが
どうよ？
４は望み薄だけど、他の心配事に良い答えがあるようなら、乗り換えるよ。
>>328 たぶん、科学屋さんだろうけど俺の意見はこんなところ
主のJBOSSなどのAS使ったりした案件でJAVA使って
キャリアとか鯖向けのアプリはC/C++でやってます。
1 速いか？計算量による問題とアルゴリズムの良さを除いて計算回数が１０万回程度なら誤差の範囲
2 起動は100％JAVAは遅い（VMの内部でC++のnewを使って最低でも64MBのメモリを確保している）
3 VMは桃源郷みたいなもの（メモリが逼迫するとすぐ落ちます）なのでよくフェイルオーバを考えないといけない
4 libはJNIで呼び出せるがオーバヘッドが許容できるのかを調査しないといけないからその分のコストを吸収できるか
解らないならお勧めしない。
5 Profilerが標準、商標でもあるのでコーディングレベルから最適化はできる。でもマシンに合わせた最適化不可能
あくまでアルゴリズムと設計の最適化にしか使えない。