07/04/20 18:25:00
毎日の様に言語のリファレンスを漁るのが馬鹿らしくなってプログラマー止めた俺か思うんだが。
JAVAは広範囲なプラットフォームでも同じソースで稼働させるのが楽というか標準てライブラリが備わっているのがメリットで、
C++は標準搭載はしていないが代用のライブラリがいろいろあってコーディングは出きるけどかなり開発に時間(コスト)がかかるけど熟練次第で何でも作成可能ぢゃないんかい？
JAVAの特性としてプラットフォームとソース間をVMが補完して動作してるから現状では根本的に早く動作出来ないのでないんかな～とか？ちげぇ？
262:仕様書無しさん
07/04/20 19:56:43
速度速度って五月蝿いなぁ。
263:仕様書無しさん
07/04/24 11:52:26
Visual C++ for JVM & Linux
264:仕様書無しさん
07/05/13 16:21:23
>>261
普通にVMレベルで突っ込みどころ満載でした。
複数プラットホームの弊害の吸収をVMでしているだけです。
ありがとうございました。
265:仕様書無しさん
07/08/22 03:52:50
アセンブラ
266:仕様書無しさん
07/08/22 23:00:04
職はどっちの方が多い？
優れてても使えないなら意味がないんだし。
267:仕様書無しさん
07/08/23 18:46:13
Javaは実に優れた言語だと思うが
C++を使いこなす人の方が憧れる
268:仕様書無しさん
07/08/24 09:49:46
いまだにC言語一本の俺が来ましたよっと
269:仕様書無しさん
07/08/24 18:26:08
C++ は、効率とかぬきにして、プログラマを夢中にさせる何かがあるよね。趣味で使うには最高の言語だと思う。
言語全体に一貫性があり、シンプルでありながら、無限の可能性を持つ言語。
Javaは便利だけど好きになれない。
270:仕様書無しさん
07/08/24 19:40:18
>>269
職人技が生かせる余地があるようね。
271:仕様書無しさん
07/08/24 22:46:23
Javaって制約が多い気がする。
何でもクラスとか印譜理面子にしないとダメだし。
272:仕様書無しさん
07/08/25 07:52:16
印譜理面子で2秒なやんだ。
273:仕様書無しさん
07/08/27 15:57:32
Webシステム以外での使い道を見出せなければ、Javaは衰退していくだろうねぇ
274:仕様書無しさん
07/08/27 16:00:14
あらゆるものがWebシステム化するので問題ない
275:仕様書無しさん
07/08/27 16:47:57
ゆるゆるものがWebシステム化するとは思えない。
276:仕様書無しさん
07/08/27 18:14:41
あゆやゆもじゃわわ
277:仕様書無しさん
07/08/27 19:32:48
>>273
何も知らないべーベーちゃんか？
278:仕様書無しさん
07/08/27 21:48:59
いいかげん、Java=Webって考えは止めてほしいよなぁ・・・いつまで大昔のこといっているんやら・・・
279:仕様書無しさん
07/08/27 23:06:01
>>269
＞言語全体に一貫性があり、シンプルでありながら、
どう考えてもC++はこれとは真逆の言語だろ
280:仕様書無しさん
07/08/28 00:08:34
C++はtemplateがすごすぎる。
これのためならJavaに劣るC++のすべての部分に目を瞑ってもいい。
281:仕様書無しさん
07/08/28 00:25:38
ｼｺｼｺ
282:仕様書無しさん
07/08/28 00:32:09
>>280
テンプレを使うのは素人。
プロはdefineでテンプレを実装する。
283:仕様書無しさん
07/08/28 01:32:22
精鋭？が10年かけてJavaでつくったOS -> JNode
URLﾘﾝｸ(www.jnode.org)
ほぼ素人クンだった ひげぽんがC++でわずか数年でつくったでOS -> Mona
URLﾘﾝｸ(wiki.monaos.org)
どっちを選ぶ？
284:仕様書無しさん
07/08/28 01:55:12
仕事で使うなら絶対Java
修正に修正を加えたC++のスパゲッティコードに潜む
メモリリークバグは極悪って言うか失踪したくなる
285:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/08/28 01:57:24
Javaのほうがいいな
C++だとおそろしくてnew使えない。
286:仕様書無しさん
07/08/28 02:02:04
JAVAでOSが動くってこととC++でOSが動くってのはぜんぜん意味の違うことだと思うが
287:仕様書無しさん
07/08/28 02:03:52
donut作った人がライブラリで使ってる関数オブジェクトをPOD化するテクニックに感動している俺は素人
288:仕様書無しさん
07/08/28 02:13:43
>>282
やめんかバカモン
そんな事をしたらコンパイルは遅くなるし、エラーチェックもまともにできないじゃないか
マクロとテンプレート両方使える局面ならtemplate使えーー
289:仕様書無しさん
07/08/28 02:23:46
プリプロセッサを使った可変引数テンプレート、オーバーロード関数の定義とか物凄く便利だぜ
templateとマクロを併用してクロージャ作る事もできるらしいし両方を使ってこそのC++といえよう
仕事の上での実用性はともかく皆が言ってるほど(禿のジョークインタビューとか)悪い言語じゃないと思うけどなぁ
290:仕様書無しさん
07/08/28 03:21:40
テンプレートを使えない局面ならマクロを使うしかないが、わざわざせっかくの型安全捨ててマクロ使う必要はないってだけ
C++の悪いのは、仕様が不必要なまでに複雑になりすぎているという一点だけで、コンセプトは悪くないのは認める。
ついてこれない初心者と、分かったつもり知ったかC++プログラマが多いので、現実問題として非常に使いにくい。
知ったかが職場の半数を超えると、もう悪夢としか言いようの無い状態になる。
C++の仕様を全て整理すれば、かなりの人間を取り込めると思うが・・・、もう流れはJava/C#へと向かっているので、素直にそちらに行くのが吉かと。
というか現状のC++でJava以上の開発効率を上げるのに必要な要素は揃っているが、現実問題としてそれを可能にする人間をそろえるのは絶望的だよ。
最近C#はHaskell等の最先端の考え方を取り込んでき始めている上、データベース向けの実用機能も充実し始めているので、かなり期待している。
それに素人でも半年仕込めば、ほぼ使いこなせるレベルまで引き上げられるしね。
これがC++では一年やってもモノになるかどうか怪しくなる。
291:仕様書無しさん
07/08/28 08:09:33
というか記述の自由度が高すぎるのが開発現場じゃ悪い方向に
作用することが多い
Javaみたいに制約が多いほうがいい
逆に、趣味でやるときはCやC++の方が面白い
292:仕様書無しさん
07/08/28 08:49:07
C++使いはハズレが少ない気がする
293:仕様書無しさん
07/08/28 09:07:28
>>292
C++使いの方が長年プログラマやっている可能性が高いからなぁ・・・
294:仕様書無しさん
07/08/28 09:16:38
ハズレた時はすごいことになるがなｗ
295:仕様書無しさん
07/08/28 10:30:45
両方覚えるとかいう荒技は可能ですか？
296:仕様書無しさん
07/08/28 11:09:57
>>295
C++やってからJavaやった方が歴史を感じられる。
297:仕様書無しさん
07/08/28 11:30:01
C++の何が問題かJavaの閉塞が何処にあるのか良く分かるから
可能なら両方やるべし
298:仕様書無しさん
07/08/28 11:51:44
C++は常に新たな可能性を模索する言語
そんなプロトタイプみたいな言語、仕事には使えん
好きだけど
299:仕様書無しさん
07/08/28 11:57:37
>>295
例え使わないとしても
C++は教養として学ぶべき
Javaは使えて当然
300:仕様書無しさん
07/08/28 14:20:15
>>278
Windowsターゲットのクライアントアプリ以外はJavaでいけるね。
AWTとSwingの出来がもう少しよければ、開発現場はJava一色になっていたと思う。
JavaでGUI組まされるのだけは絶対嫌。
301:仕様書無しさん
07/08/28 14:51:52
>>300
Swingの問題ってどんな感じですか？クリティカルな問題？それとも見た目？
302:仕様書無しさん
07/08/28 20:25:32
ちょっと気の利いたアプリケーションって
概ねC++というのはン年前から変わっていない。
気軽に組んで、気軽にPCにつめるのはいまだに
言語的にヘビーなC++がメインというんはどうなのよ。
結局、環境も含めて考えるとJavaってヘビー超えて
肥満体なのよ。
そのこと克服しない限り、結局"Webだろ"でおしまいの言語だと
思う。
303:仕様書無しさん
07/08/28 20:51:37
webもrubyやphp6のせいで危ないと思いますがね
304:仕様書無しさん
07/08/28 21:21:31
webは、AJAXの登場で、言語ではなくて、
以下にJavaScriptとかXMLをうまく扱うかに重点が移った
気がする。
305:仕様書無しさん
07/08/28 23:58:28
JavaScriptをコネクリまわすのって結構イヤンな感じなんだが。
つかWebのIEやらFireFoxやらの対応とかが本質的でないなぁ、って感じてします。
SwingとかはEclipseにマトモ(?)なプラグイン入れてなんとかって一昔まえの
VBに追いつくって感があるよな。
306:仕様書無しさん
07/08/29 01:45:16
環境が無償で手に入るので、教育用としては抜群に適している。
307:仕様書無しさん
07/08/29 11:26:35
>>306
済まんが何の話か解らん。
308:仕様書無しさん
07/08/29 14:59:42
Javaのような「WEB時代のCOBOL」とC++を比較する神経がワシには理解できん。
309:仕様書無しさん
07/08/29 15:10:52
>>308
「言語なんてひとつあればいい」と思っちゃう、素人特有の神経。
310:仕様書無しさん
07/08/29 15:23:53
やっぱ言語は色々使いたいよね
それを使って何を作るとかは頭悪いからあまり興味が持てないけど
311:仕様書無しさん
07/08/29 15:59:38
学生さんとかが勉強する言語を１つだけに絞りたいとかなのかな？
312:仕様書無しさん
07/08/29 16:05:11
>>308
WEB時代のCOBOLって、NetCOBOLやんか。
313:仕様書無しさん
07/08/29 16:07:01
パソコンショップ完全リンク
URLﾘﾝｸ(search.yahoo.co.jp)
314:仕様書無しさん
07/08/29 16:55:44
Visual C(OBOL).NET
315:仕様書無しさん
07/08/29 18:24:37
COBOL屋さんの移行先がJavaしかないという悲しい現実。
316:仕様書無しさん
07/08/29 20:49:35
>>315
そして、なんちゃってで作って悲しいプロジェクトになっちゃう現実。
だから、JAVAにさらに制約の強いフレームワークを重ねてプロジェクトを回す事を検討しなければならないわけだな。
317:仕様書無しさん
07/08/29 21:13:36
Javaのtry～catchは便利だよね。
C++にもあるけど、あまり使えない。
なんか「Javaのtry～は裏で色々処理をやっているので低速」
みたいな解説してるホームページがあったんですが・・・。
かくいう自分は、C++。
318:仕様書無しさん
07/08/29 21:23:25
でもさ、お前ら例外時の処理ってなんかやってるか？
319:仕様書無しさん
07/08/29 21:26:53
>>317
ちゃんとやんないと、あの例外エラーのダイアログ出ちゃうじゃんか。
それが気持ち悪いんだよ、だからtry～catchするんだ。
320:仕様書無しさん
07/08/29 23:12:58
ぬるぽ
321:仕様書無しさん
07/08/30 14:48:15
javaでGUIの実装するときってSWINGとアプレットがいいの？
322:仕様書無しさん
07/08/30 15:06:42
Javaアプリを素人に配布するのに説明が面倒な気がする
323:仕様書無しさん
07/08/30 15:13:50
JavaアプリってEXE化できるんでしょ？
324:仕様書無しさん
07/08/30 16:30:55
これだから説明が面倒なんだよ。
325:仕様書無しさん
07/08/31 00:19:59
Ｃ＋＋はＣ言語知らないとできないっしょ。
よく切れる職人さんのカンナと一緒、コンパイルするのが怖い怖い。
326:仕様書無しさん
07/09/01 12:46:02
コンパイルするのは別に怖くないだろう
お前はおじゃばか
実行するのが怖いだけだ
327:仕様書無しさん
07/09/01 13:50:34
実行すんのだって怖かねーだろ。
納品すんのが怖いだけだ。
328:仕様書無しさん
07/09/01 15:40:01
Cで納品したってcoreはかねーか心配になったりするけどな
329:仕様書無しさん
07/09/01 22:02:18
俺はtemplateで記述した部分が俺の意図した通りにコンパイルされてるのかの方が心配だけどな。
おっとModern C++ Design 読んでない人はレスしなくていいよ。
330:仕様書無しさん
07/09/01 22:27:44
そういう心配しないといけないのがC++クオリティ
331:仕様書無しさん
07/09/02 21:02:26
自分のイメージだと
C・・・・・・魚類
C++・・・・・両生類
JAVA・・・・爬虫類
という感じかな。
C++は陸に上がる進化（＝オブジェクト指向）の
つなぎの言語のような気がする。
爬虫類が誕生しても魚類や両生類が絶滅したわけではなく
ただニッチ(生態的地位)が違うだけ。
だからどちらが優れているとはいえないのでは？
332:仕様書無しさん
07/09/02 22:15:03
>>331
すごくわかりやすくて感心した
333:仕様書無しさん
07/09/02 22:17:44
うん、優れているじゃなくてだめなだけ、
別にJavaに限らず流行にそった言語は
環境に適応できず全滅していく。
肥大化した言語は特にそう。
まあ、C、C++も生き残るだろうけど、
ニッチ分野が縮小するだろうけな。
334:仕様書無しさん
07/09/02 22:22:32
>肥大化した言語は特にそう。
C/C++/C#の事か。
335:仕様書無しさん
07/09/03 01:02:47
肥大化しないのがすばらしいのなら、マクロ無しアセンブラが一番エラいって事かな。
C++にしてもjavaにしても昔に比べて用途が増えたんだもの。
大きくなってもしょうがないんじゃないかな。
336:仕様書無しさん
07/09/03 04:01:39
C++派の人はMFCもバリバリできるの？
337:仕様書無しさん
07/09/03 08:18:33
そもそも、素で作れるC++と
基礎からベッタリのJavaとでは肥大化の意味合いが違う。
いつでもスタート地点に戻れるC++と、
肥大化した環境で永遠に悩めるJava。
その辺の差考えてみた事ある？
338:仕様書無しさん
07/09/03 19:48:57
別にJavaでも素で作れるし、戻れるだろ。
こんにちは世界程度なら。
それに肥大化具合を言い出すとC++の方が凄くて、
素に戻るのは困難だろ。
339:仕様書無しさん
07/09/03 21:01:36
STLなんてわけわかんない
340:仕様書無しさん
07/09/03 21:49:28
Java厨だとかC++厨だとか言ってるけど
プログラムなんて高校で基礎の基礎かじった程度の自分からしたらなんてLVの高い厨なんだ
なんて思ってしまうわ。
341:仕様書無しさん
07/09/04 05:36:53
俺遊び的にC++を勉強中なのだが
Cから学ばないとわかりづらい事とかありますか？
そういうレスが以前あったのでしつもんー
342:仕様書無しさん
07/09/04 05:55:46
javaやvbからやった方がわかりやすい
343:仕様書無しさん
07/09/04 06:48:49
どっちなんだー
344:仕様書無しさん
07/09/04 07:50:34
C++はCとの互換性を保つためにぐだぐだになってる
345:仕様書無しさん
07/09/04 08:07:49
>>344
具体的にどこがぐだぐだか言ってみ？言えないでしょ
346:仕様書無しさん
07/09/04 10:06:03
C++ は言語自体に魅力がある、ありすぎる
そのせいで仕事が進まなくて本末転倒
ぶっちゃけ Java にしとけと言いたい
347:仕様書無しさん
07/09/04 10:53:17
メモ帳でコード書くのならCから始めろ
348:仕様書無しさん
07/09/04 13:44:59
らじゃー
根本から作っていくと言うのは好きなんだよね
挫折するかもしれないががんばりまーす
349:仕様書無しさん
07/09/04 18:39:45
>>341
javaやらvbからはじめるとC++を勉強しにくくなる
C++をすこし勉強してからjavaかvbを勉強してそのありがたさを知るべき
俺みたいなC++ができない人間にはなるな
350:仕様書無しさん
07/09/04 21:15:02
>>349
うむ。蛇場しかできんと「おじゃば」のようにしかなれないからな
351:仕様書無しさん
07/09/04 21:54:46
>>349
ありがとう
とりあえずC++保留してCやってみるか
352:仕様書無しさん
07/09/05 09:14:38
Cでも構造体と関数ポインタを駆使すれば
C++になる オーバライドとオーバロードはできんけど
継承系はあほのための仕様だからつかわんでもよし
353:仕様書無しさん
07/09/05 09:18:37
>>352
お前にはC++は複雑すぎる
354:仕様書無しさん
07/09/05 11:50:49
>>352
C++になるかどうかは別として、
オーバーライドはできるぞ。
355:仕様書無しさん
07/09/06 05:28:40
>>352
電波を受信しました
356:仕様書無しさん
07/09/06 07:55:29
>>352
クラスを構造体がわりに使うのやめてください
357:仕様書無しさん
07/09/06 18:57:49
>>352 の言動は継承したくないな
358:仕様書無しさん
07/09/08 13:00:30
>>319
でもそれだと、本来予期しないエラーがあればそれに対する対処をしなくちゃ
ならないのに、それを知らずに動かし続けることになるよ。
359:仕様書無しさん
07/09/08 17:19:12
>>358
それは、例外クラスが特定できない場合じゃないのかな。
try {} catch(...) {} の ... で全部片付ける手抜き野郎の話だよね。
例外のスーパークラスがしっかりしていれば、問題ないよ。
何の例外型だか把握できる機構がしっかりしていればの話だけどさ。
360:仕様書無しさん
07/09/12 02:29:21
Javaプログラマのほうが給料が高い！これホント。
おれはC++ばっかりやってきたけど、Javaに転向しようかと思ってる
361:仕様書無しさん
07/09/17 16:24:51
フォートラン開発者、ジョン・バッカス氏が死去
URLﾘﾝｸ(www.iza.ne.jp)
ジョン・バッカス氏（コンピューター言語の開発者）ＡＰ通信が２０日伝えたところによると１７日、オレゴン州アシュランドで死去。８２歳。
362:仕様書無しさん
07/09/17 19:14:21
Ｃ＃かJAVAやれば、Ｃ＋＋理解しやすいよ。
勉強する順番のお勧め。
Ｃ言語→Ｃ＃→終了。(やりたければＣ＋＋)
363:仕様書無しさん
07/09/17 20:29:19
>>362
おいおい。いい加減なこと言ってんなよ。学生か？
364:仕様書無しさん
07/09/17 20:45:12
学生ではありません。
信心ですが･･･
実際、今、勢力をもっているのは.NETとＪＡＶＡです。
仕事も多いです。
Ｃ＋＋の時代は終わりました。
365:仕様書無しさん
07/09/17 20:46:31
信心→新人
366:仕様書無しさん
07/09/17 20:47:41
C++/MFCでもっと頑張れやオマイラ
367:仕様書無しさん
07/09/17 20:48:34
ＭＦＣの時代も終わりました。
もうマイクロソフトはＭＦＣのサポートを終了します。
これからは、.NETです。
368:仕様書無しさん
07/09/17 20:59:08
サポートはともかく
いずれMFC製プログラムが動かなくなったら暴動起きるっす
369:仕様書無しさん
07/09/17 21:08:13
MFCは大掛かりな更新がひかえてるらしいじゃないか
370:仕様書無しさん
07/09/17 21:17:24
.NETのクラスライブラリに追い付くのかしら
371:仕様書無しさん
07/09/17 21:28:27
俺的にはプログラムがどういう風に動いていて、
どういうと子が不利で、どういうとこが有利か
わかっていれば、どの言語も同じだと思うが
372:仕様書無しさん
07/09/17 21:36:01
C++が優れていればJavaは存在しません。
Javaが優れていればC++は生存しません。
そしてJavaは技術者数が最も多い言語です。
373:仕様書無しさん
07/09/17 21:39:27
＞そしてJavaは技術者数が最も多い言語です。
C言語じゃねぇの
374:仕様書無しさん
07/09/17 21:41:03
URLﾘﾝｸ(www.tiobe.com)
Cも多いが1位ではなかったり。
375:仕様書無しさん
07/09/17 21:44:01
COBOLやろうぜ！
376:仕様書無しさん
07/09/17 21:58:57
C言語はいろんな言語のサプリメントとして今後も生き残る。
D言語がサポートしてたのを確認して確信した。
377:仕様書無しさん
07/09/17 22:28:44
Ｃ言語は消えないでしょう。
378:仕様書無しさん
07/09/17 22:31:22
むちゃくちゃな新人現る。
.NETは死ぬでしょ。C#はJ#と同じ道を歩みそう。
379:仕様書無しさん
07/09/17 22:36:32
VBがが生き残ったようにC#も行き続ける
380:仕様書無しさん
07/09/17 22:46:34
VisualBasicは中身.netとすり替えられててもう死んでる
381:仕様書無しさん
07/09/17 22:52:02
JAVAが死ぬか.NETが死ぬか。
.NETは死なないでしょう。
.NETはＯＳへと進化しますから。
Microsoftのwindowsを使い続けるなら、避けられません。
382:仕様書無しさん
07/09/17 22:54:47
>>374
C++は沈没中だな、もうゲーム以外では殆ど使われていないからしかたないが。
383:仕様書無しさん
07/09/17 22:57:48
win16→win32→.NETへと進化していくのです。
Windows VistaではAPIがWin32 APIから.NET Framework 3.0へ変更される予定であったが、
Win32 API主体のまま出荷となっている。
ＪＡＶＡが生き残るか、.NETが生き残るか。
384:仕様書無しさん
07/09/17 22:59:57
どうみても.NETです。ありがとうございました。
385:仕様書無しさん
07/09/17 22:59:59
D言語の伸びとC++の減りが同じであることが怖い。
GCがゲーム用途に弱いってのが克服されたら一気に持ってかれそう。
386:仕様書無しさん
07/09/17 23:01:59
DBやCADがJavaを支持してる限りJavaは死にようが無い。
C#はWindowsが存在している以上、死にようが無い。
機能的にもろかぶりでも採用する側は綺麗に分かれてるからどっちも死なない。
387:仕様書無しさん
07/09/17 23:17:36
C言語で書いてるプログラムってC++で書けばいいのに
なんで未だにCなんだろ
388:仕様書無しさん
07/09/17 23:17:54
みんな言語がどうだとかプラットホームがどうだとか、そんなにカリカリするなよ。
全てのものは、死へ臨む存在なのだから。
389:仕様書無しさん
07/09/17 23:18:55
保守的な人ばっかだね
390:仕様書無しさん
07/09/17 23:22:26
>>385
たまたまだろw
phpのような web系は強いね、実際問題としてウェブサービスとMSオフィスとの連携が容易な開発環境は切望する。
C# / VB.NETに使える、薄いComラッパなんかじゃない.Netネイティブ実装をして欲しいな
ことごとく object 型の内容不明のインターフェイスは使いにくくてかなわん。
インストーラーももっともっと練って欲しいClickOnceは便利そうだが実際にはバグっぽくてトラブルが多くて使いにくい。
ウェブサービスももっと簡単にできそうな気がする、ネットの向こうのマシンのclassをインスタンス化して使えるのは大幅な作業効率化に繋がるが、まだまだやれるだろ。
とどめはXNAと連動してXBox360や、携帯端末とのやり取りが・・・できたならなんか面白いもの作りたいな
マイクロソフトまんせー
391:仕様書無しさん
07/09/17 23:22:40
>>387
ヒント：extern "C"
392:仕様書無しさん
07/09/17 23:26:17
Windowsオンリーなら迷わず.NET。
マルチプラットフォームならJavaだろうね。
Oracleなんかは.NETに重きを置いてないか？
DBサーバーはUNIXでWebサーバーやクライアントは.NETみたいな。
基幹業務でこの組み合わせは最強。
393:仕様書無しさん
07/09/17 23:27:49
エンタープライズ製品はコントロールパネルがJavaなことが多いからなぁ。
死にようがないんじゃない？
394:仕様書無しさん
07/09/17 23:34:09
＞Oracleなんかは.NETに重きを置いてないか？
どう考えてもJavaです。
395:仕様書無しさん
07/09/18 00:20:17
.Netは明らかに技術者不足。
ついでに言えば、ネーミングの失敗が大きすぎる。
Javaは、「Java」という言葉が携帯アプリ等で一般に浸透しているぐらい、市民権を得てるが、
.Netは技術者からさえ、何それ？という反応が少なくない。
396:仕様書無しさん
07/09/18 00:31:45
確かに。
調べなきゃ知らなかった。
397:仕様書無しさん
07/09/18 21:43:22
NO MORE C/C++ !
URLﾘﾝｸ(java.sun.com)
398:仕様書無しさん
07/09/18 21:45:25
これからはルビーの時代
399:仕様書無しさん
07/09/18 22:15:18
すれ違い
400:仕様書無しさん
07/09/19 18:34:32
こちらもよろしくです
Webプログラマに転向したい人のスレ
ｽﾚﾘﾝｸ(prog板)
401:仕様書無しさん
07/09/22 19:00:56
あげ
402:仕様書無しさん
07/11/05 08:45:38
ネタ切れ？
403:仕様書無しさん
07/11/05 17:17:24
しかし、VBより先にC++の方が沈没しようとは、１５年前、誰が予想し得たろう？
404:仕様書無しさん
07/11/05 18:12:23
>>395
.com（ドットコム）みたいな耳心地だからな。
下手すると.com（ドットコム）と混同されて古臭い単語と思われるかもね。
405:仕様書無しさん
07/11/05 23:05:52
>>403
VB.netをVBと呼ぶなら
C#をC++/MFCと呼べよw
406:仕様書無しさん
07/11/06 11:11:33
MFC/ATL沈没→C++沈没という印象だな
C++そのものが沈没原因になったようには思えない
407:仕様書無しさん
07/11/06 12:59:48
CLIは？
408:仕様書無しさん
07/11/06 15:13:36
>>407
.NET は Side by side 等のバージョンアップを障害なく行うための仕込みが沢山入っているから
そう簡単には沈没しないんじゃないかと予想
しかしまぁ、C++沈没の最大の理由はMicrosoftの動向そのものであって
1.Microsoft が Java に移行しようとした
2.Sunと喧嘩
3..Net Frameworkを独自に起こす
という一連の中で若干寿命が延びてC++中心の世界が広がって予想しにくくなっていたんだろうな。
つかいい加減沈没して良し。
409:仕様書無しさん
07/11/07 00:25:19
MFCとかManaged C++とか、Microsoft主導の変なものが溢れなければ、
というか、もう少し標準規格のライブラリ（せめてJavaのCommonsみたいなの）が
広まっていれば、もう少し長生きできたんではないかと思う
410:仕様書無しさん
07/11/07 02:00:56
VC++関連のライブラリの類は新しくなる度に扱うのが難しく成りすぎたのが原因だな。
VFW → DirectShowとか
411:仕様書無しさん
07/11/07 02:52:34
C++終了の方向なのかな？かな？
Javaがネイティブコードを吐けない以上、C++に絶対に勝てない分野があるんだが
PGの負担が軽いのは圧倒的にJavaだろうけどね
412:仕様書無しさん
07/11/07 09:22:15
C♯あればCぷらぷらはイラネ
413:仕様書無しさん
07/11/07 09:55:50
コンパイラとかosとかvmとかはc++
414:仕様書無しさん
07/11/07 20:21:33
>>410
C++はそういう低水準なライブラリも扱える言語だというだけのこと。
本当の問題は、それをラップした（他言語並の）高水準なライブラリに恵まれないということ。
415:仕様書無しさん
07/11/07 22:31:38
C++でライブラリだけ作って、後は簡易な言語でコールみたいな用途であれば
十分に生きていけるとは思うけど、なんか勿体無いよなぁ
悪い言語じゃないんだけど
416:仕様書無しさん
07/11/07 22:53:13
こっそりと「おぶじぇくてぃぶしー」と言って恥ずかしくなって帰ろう
417:仕様書無しさん
07/11/08 01:09:13
ＶＣ＋＋６．０までは使ってたんだが
もうwindowsでコード書いてなくて、もっぱらlinuxなので教えて。
.NETってぶっちゃけなんですか？
418:仕様書無しさん
07/11/08 01:19:49
>>417
COMの未来系
419:仕様書無しさん
07/11/08 02:00:08
ＣＯＭでしたか。
ほとんど使わなかったな。
ＶＢとかからでも呼び出したりできるものですよね。
より役に立つ部品化が進んでるということ？
420:仕様書無しさん
07/11/08 14:37:23
C++とJavaを並べて比較したってしょうがないだろ。
C++のJavaに対する関係は、ハードウエアとソフトウエアの
関係みたいなものだから。
421:仕様書無しさん
07/11/08 16:00:15
JAVAがJAVAXに改名するかも？
URLﾘﾝｸ(www.youtube.com)
422:仕様書無しさん
07/11/08 23:45:55
C++の辛い点はATLの登場がちょっと早すぎた感があるところかな
もう少しtemplateのノウハウや技術が安定してから登場すればかなりのレベルになったんだろうけど
急ぎすぎてライブラリを泥沼にしてしまった感あり、今あるBoostの機能などを活用したら物凄いレベルになったと思ふ
まぁあっちゃら方面は.NETに向かう事になりそうですが、つか.NETは新型のCOMみたいな物になっているし。
423:仕様書無しさん
07/11/08 23:56:24
>>419
.NETはCOMと相性のいいJavaのデッドコピー
もともとMSはJavaを採用するつもりだったらしいが、SUNとは喧嘩別れ
424:仕様書無しさん
07/11/09 23:49:24
昔はVBなど覚えても先が無いからC++覚えろ、みたいな常識があったが、
ｱﾚを真に受けてC++に行った人って…。
425:仕様書無しさん
07/11/10 01:41:12
.NETになってもネイティブコードが吐ける言語は必要でしょ。
.NET Frameworkも一皮向けばすぐP/Invokeか
RCWでネイティブにInvokeしてるみたいだし。
クライアント周り →.NET
カリカリチューニング → C++
っていう流れなんだろな。
C++にfinallyがあってとRTTIの実装がはじめからあればと悔やまれる。
426:仕様書無しさん
07/11/10 01:42:33
フン、ひけらかし、つまんね
427:仕様書無しさん
07/11/10 01:47:05
>>424
C++自体に先はなかったけど、C++学んだ経験のある人間なら、
JavaでもC#でも簡単に移動できるだろうし、VBよりはマシだと思ふよ
428:仕様書無しさん
07/11/10 10:35:08
＞JavaでもC#でも簡単に移動できるだろうし
希望的憶測が入ってるな。
429:仕様書無しさん
07/11/10 10:35:10
JavaからC++に移行中で悩んでることがあるんだけど、
純粋仮想関数の存在意義ってなんだろう？
あれがあるとクラスをインスタンス可できないから、
Javaのインターフェースと同様に考えてると
オブジェクト指向としてはやりづらいことこの上ない。
俺がアホなの？
430:仕様書無しさん
07/11/10 10:44:19
>>428
似すぎ故に混乱しそうにはなるが、難しさはないよ、逆方向の移動も簡単
>>429
最近は実際そんな流れになっているよ、可能な限りインターフェイスを使った実装が正しい実装でしょう。
将来また新しいアイディア手法があらわれて純粋仮想が重要になるケースもでるかも試練ですが・・・
431:仕様書無しさん
07/11/10 10:50:30
>>430 にちょっと修正
C++からJava/C#への移行はまったく新規に憶える言語として考えたほうがいいかもしれない。
逆もほぼ同様、ただしJava/C#は学習期間が短くてすむのでこっちの方が楽。
432:仕様書無しさん
07/11/10 10:57:28
>>429
Javaのインターフェイスの概念は、C++の virtual 継承において実装のない純粋仮想関数のみのクラスが使えるという事実にもとづいて実装されたものらしいよ。
C++では、上記同様にして使えば、Javaと完全に同一とはいかないものの大体似たスタイルの実装ができるよ。
433:仕様書無しさん
07/11/10 11:17:41
>>430, 432
サンクス。
つまり、現時点でC++でJavaのインターフェースと同様の
ポリモーフィズムを実現するには、クラスには純粋仮想関数を使わずに、
空のvirtual関数を定義するということでOK？
434:仕様書無しさん
07/11/10 12:17:21
関数のほうだけでなく継承クラスの指定のところにも仮想を指定するんだよ
435:仕様書無しさん
07/11/10 13:32:10
言語仕様やOOPあたりは基礎知識としてある程度互換するけど
C++とJava/C#は根本的に勉強しなきゃいけない方向性が真逆だからな
436:仕様書無しさん
07/11/10 13:46:04
C++はいらんけど、Java/C#な人たちにもCは知っていて欲しい
それだけでコード書く時のメモリへの意識が良くなる気がするので
437:仕様書無しさん
07/11/10 18:11:30
ま、結局極めるべきはアセンブリ言語なんだけどね。
438:仕様書無しさん
07/11/10 23:09:01
C++とかまだあるんだね。
風向きが読めないPGはかわいそうだね。
まぁ、読めないからPGのままなんだろうけどねｗ
439:仕様書無しさん
07/11/10 23:22:26
>>438
PGという職種自体が風向きを（ｒｙ
440:仕様書無しさん
07/11/11 02:49:40
ここの書き込みを見るだけで何かを読めてないのは感じる
441:仕様書無しさん
07/11/11 11:37:57
むしろマ板は風向きが読めてない人間が来るところだと思ってる
442:仕様書無しさん
07/11/13 15:22:12
>>433
いや、純粋仮想関数使えよ。
443:仕様書無しさん
07/11/13 18:51:49
>>433
純粋仮想関数だけのクラスがJavaのインターフェース相当だよ。
444:仕様書無しさん
07/11/14 15:00:16
あたかも業界標準の話が続いているように見える錯覚
445:仕様書無しさん
07/11/15 10:24:37
>>443
それだけだとキャスト時の挙動が若干違ってしまう
class InterfaceA
{
virtual void f() = 0 ;
} ;
class InterfaceB
{
virtual void g() = 0 ;
} ;
class InterfaceC : public virtual InterfaceA , public virtual InterfaceB {}
class SuperClass {}
class MyClass : public SuperClass , public virtual InterfaceC
{
} ;
446:仕様書無しさん
07/11/15 10:30:42
445 に忘れ物、デストラクタにも virtual を付けて空の関数としておくこと。
447:仕様書無しさん
07/11/18 17:59:43
そういう基本の本に載ってること以外の特記事項が多いよな、C++は。
448:仕様書無しさん
07/11/21 23:26:12
Cを大体理解したんで、C++に行こうと思うんですが、
独学でOOPやるにはなんかいい方法ありますか？
449:仕様書無しさん
07/11/22 01:03:32
Animalクラスを継承したDogクラスとCatクラスを作る
450:仕様書無しさん
07/11/23 02:17:30
>>447
仕方がないよ、C++のclassは本来のクラスではなくて拡張構造体だからね
Cのstructの仕様と違いが出てしまわないようにするには、どうしても理解できないような例外的内容が必要になる。
451:仕様書無しさん
07/11/24 15:11:45
>>445
でも、それで純粋仮想関数ではなく
空のvirtual関数にすればJavaと同じ挙動になるとでも言うのか？
452:7si
07/12/21 01:07:19
sage
453:仕様書無しさん
08/01/01 00:22:08
あけましておめでとう！！
ちなみに俺はC+++派！！
454:仕様書無しさん
08/01/01 01:52:53
どちらもそこそこ極めたい。
C++にもSUN認定資格みたいなのがあればいいのにな。
サーティファイにC++専用のもあれば、絶対受ける。
455:仕様書無しさん
08/01/01 11:02:36
>>453
が時代の最先端を語ってる件
456:仕様書無しさん
08/01/03 19:22:45
>>455
すげぇなｗｗｗC++の上位言語ですかｗ
457:仕様書無しさん
08/01/04 05:22:43
C++0xのことだろうか？
いや、違うな。さらにその先を見据えた言語なのだろう。
458:仕様書無しさん
08/01/15 00:21:31
Windowsアプリを作りたいのでC++を勉強しようと
してるんですけど、間違ってる？
今まではWebアプリばかりやっていたのでずっとJavaの
お世話になっていました。
459:仕様書無しさん
08/01/15 00:23:06
>>458
間違ってないけどC#か、そのままJavaでも良いんじゃないの？
460:458
08/01/15 00:49:10
C#はよくわかりませんが、JavaってWindowsアプリをつくるイメージが
あんまりないんですよね。
というか巷にあふれているWindowsアプリが何の言語で作られているか
よく知らないんですけど。何の言語で作られていることが多いんでしょう？
461:仕様書無しさん
08/01/15 00:51:20
javaなんてこの世から
無くなれば良いんだよ。
462:仕様書無しさん
08/01/15 02:03:21
>>460
>巷にあふれているWindowsアプリ
「今」ならC++、VB、(Delphi)位じゃないかな。
IDEが無料になったし、そのうち.NETアプリ増えてくんじゃないか？
javaやってたらC#は違和感無いと思うよ、VBからVB.NETやるよりも
463:仕様書無しさん
08/01/17 00:17:39
実力的には
Javaの上位層＞＞c++の上位層＞＞＞＞＞c++の下位層＞＞＞＞＞javaの下位層
だろ。c++でちゃんとＯＯ設計できる奴に会ったことがない。javaにはいるけど。
javaは言語が単純なだけあってすそ野も広いから下位層だとc++＞＞＞＞java。
464:仕様書無しさん
08/01/17 01:26:54
おまえらちんこなこと言ってないで実用性考えろよ。
お前らが今見てるデスクトップの99%のアプリはC/C++。
465:仕様書無しさん
08/01/18 01:12:18
つっても、サーバアプリの方が数は圧倒的に多いし
466:仕様書無しさん
08/01/18 14:26:17
今2chを見るのに使っている専ブラはDelphiなワケだが
数の論理で言うならJavaが一番プログラマ多いらしいな。
467:仕様書無しさん
08/01/19 11:29:54
>>463
むしろ
c++の上位層＞Javaの上位層＞javaの下位層＞c++の下位層
ばらつきが多いのはc++プログラマのほうだよ
上の方は、オブジェクト指向はもちろん、ジェネリックスプログラミングやメタプログラミング、それを極めるのに関数型言語と
この世にありそうな概念の殆どを把握している上に、ハードが解り、アセンブラまで使える。
逆に下位は // コメントを使ってC++のつもり程度のレベルまで。
Javaプログラマに技術力にばらつきが少ないというのは、一見した感想。
468:仕様書無しさん
08/01/19 12:51:37
C++はできない人には永遠にできないが
JAVAは多くの人が使えるって差はあるな
でもだれでも使えるって点ならVBに軍配が上がるんで
JAVAは少し立ち位置が微妙
469:仕様書無しさん
08/01/19 20:15:38
>>468
VB触ったこともVB厨のコードも見たことないだろ。
470:仕様書無しさん
08/01/19 21:09:40
>>469
むしろ５年ほどVB厨として生きてきたよ
471:仕様書無しさん
08/01/21 17:43:23
コボルアイシテル
472:仕様書無しさん
08/01/24 01:41:35
LOGOてプログラム組めるの？
てっきり絵を描くなにかだと思ってた
473:仕様書無しさん
08/01/24 01:58:14
あげてみちゃう。
474:仕様書無しさん
08/01/24 01:59:57
っていうかなんでおめーらはどの言語がいいとかでﾓﾒてんだよ。
自分がやってる言語に誇りをもってやってりゃあいいだけの話し。なさけねぇ。
じゃあねおやすみなさい。１０００００年後にまたあいましょうねグルさん達。
475:仕様書無しさん
08/01/24 07:03:37
だまってObjective-Cつかっとけ
476:仕様書無しさん
08/01/24 21:30:31
今日学校でVB.NETの本読んでたら現社の先生が「へ～、今でもヴィジュアルベーシックやってる人いるんですね。」って言われた。
477:仕様書無しさん
08/01/24 23:20:20
>>470
じゃあ自覚しろよ、VB厨は使ってるとは言わない
478:仕様書無しさん
08/01/27 16:58:06
Java VMがC/C++で書かれている時点で議論終了
479:仕様書無しさん
08/01/28 22:16:38
今度rubyの本でもわざと広げてみろ
480:仕様書無しさん
08/01/28 22:43:31
ごつごつした野蛮な低級言語に慣れると
VBのような高度に抽象化された高級言語使用者を妬むようになるらしい。
481:仕様書無しさん
08/01/28 22:49:21
2つ、覚えれば
482:仕様書無しさん
08/01/29 00:27:20
日本語すら読めないのか・・・
483:仕様書無しさん
08/01/29 15:38:02
＞VBのような高度に抽象化された
抽象なら良いんだけど高度にというか大幅に機能が減ってるんだよな。
484:69式フリーPG ◆hND3Lufios
08/01/30 22:18:21
Javaはうざい
485:仕様書無しさん
08/01/30 22:21:29
Javaは名前が変
486:仕様書無しさん
08/01/31 02:57:36
C++はポインターを使えばある意味フルアクセスで隠蔽も糞もないからな。
487:仕様書無しさん
08/02/01 09:19:29
リフレクションのある言語にも似たようなことは言えるわけで
488:仕様書無しさん
08/02/01 19:01:20
Java = ロブスタ
C++ = アラビカ
489:仕様書無しさん
08/02/01 19:37:10
>>486
バカ！
そこが良いんじゃないか。
プログラムなんて元来シンプルなものなのに
小難しい概念を取り込んでくるから訳わからなくなる。
今ではプログラミング談義は可哀想な人認定を受けてしまうようになった。
490:仕様書無しさん
08/02/02 08:43:15
単独で実装可能な範囲：C++ > Java
マのレベルの差がでないことによる優位性：Java>C++
動作速度：C++>Java
技術者に求められる知能：C++>Java
仕事の量：Java>C++
当該言語を使えるマの数：Java>C++
挫折率：C++>Java
ハッカー級レベルをもつ技術者の比率：C++(C)>>>∞>>>Java (Javaだけのハッカーはまずいない）
俺の状況毎おすすめ言語
マじゃないけど、デキル奴として仕事がこなせればいい：VB、Excel VBA
プログラマになりたい：Java、C#（というより流行っている言語）
技術者としての成長したい：C、C++
かな
491:仕様書無しさん
08/02/02 10:25:31
>>490
俺の状況毎おすすめ言語
GUI 中心のエンドユーザーの案件で、要望に迅速かつ最小限の工数で仕上げたい。：VB、Excel VBA
WEBアプリケーション開発をしたい。後方互換性や開発環境の互換性を維持したい。：Java、C#、PHP
組み込み系、自社アプリケーション開発等、ソースが膨大になっても、移植性や様々な開発環境など幅広い範囲をフォローしたい。メモリー管理など細部まで自分で操作したい。：C、C++
かな
492:仕様書無しさん
08/02/02 11:00:30
オフショアでJAVAorC++使ってるとこある？
VBはオフショアにしてるけどC++はいつまでも俺が書いてるんだよな・・・
正直もう書くのめんどいんだよｗ
493:仕様書無しさん
08/02/02 11:07:30
> オフショアでJAVAorC++使ってるとこある？
C++はともかく、Javaは普通にあるんじゃね？
494:仕様書無しさん
08/02/02 13:59:12
オフショアって安価に人海戦術をやれるってことに価値があるわけで、
高レベルの部分は、海外に出したところで高い。
495:仕様書無しさん
08/02/02 15:29:50
高尚な理論は全然判らんが、
JAVAは超越関数が全部 Math のメソッドになってるのが腹立たしい
数式が見にくいじゃないか
496:仕様書無しさん
08/02/02 16:31:31
C++のSTLをさらに強化して、10進数演算小数点以下８桁くらいまでを普通にできるようにしてくれたら最高
497:仕様書無しさん
08/02/02 17:58:37
DOSでのC開発くらいしかスキルなくてC++やってると、VBが恋しくなる。
楽だから。
勉強する時間がなければC++なんて無理
498:仕様書無しさん
08/02/02 18:48:50
>>497
C++->Javaとやってきたが、うちの新人にはJavaを勉強することを奨めている。
JavaがわかってからC++を知った方がいいと思った。
499:仕様書無しさん
08/02/02 20:01:22
オブジェクト指向がいいとおもうなら、Java→C++でよか。
だが、現実はオブジェクト指向なんて、なんちゃってだし
500:仕様書無しさん
08/02/02 20:09:10
アセンブリ → C → C++ → Java/C# → Perl/Ruby...
と進むのがエリートコースなんだが。
最初に楽しちゃうとろくなもんにならんゾ
501:仕様書無しさん
08/02/02 20:47:30
アセンブリ必要な奴はCを知らないと辛いけど、Java/C#が必要な奴は
アセンブリなんて一生お目にかからなくても別に困らんぞ
502:仕様書無しさん
08/02/02 20:53:57
アセンブリ言語で苦労するのはクソ設計の石触るときだけの気がする。
86系の石とかさ。
503:仕様書無しさん
08/02/02 20:55:20
それはアセンブリの知識があれば解決できていた問題に気づいていないだけ。
504:葉猫 ◆Jz.SaKuRaM
08/02/02 21:05:33
最新の16ビットの高性能マイコンの方が安いんでつから古い石＆アセンブラなんて
いつまでもやってないで Cでいいでちょ('A`)
505:仕様書無しさん
08/02/02 21:06:04
コンパイラの最適化で対応できない新しい石の機能を使いたい時はアセンブラしかない。
まぁそういうのはライブラリ開発組に任せて大半はその恩恵に預かるだけだがな。
506:仕様書無しさん
08/02/02 22:02:30
>>500-505
組み込み系のプログラミングとデスクトップアプリケーションをごっちゃにするな。
507:仕様書無しさん
08/02/02 22:05:06
>>500
アセンブリ → C →VBと来たら楽で戻れなくなった
チーム開発するようになってからは管理もしやすくてなおさら
Cはたまに呪文みたいなコード書く人居るから大変
508:仕様書無しさん
08/02/02 22:48:04
>>490
C++使いとJava使いじゃ追いかけてるものが違う。
C++プログラマにとってのステータスは組み込みとかゲームとか
割合マシンよりのプログラミング技術だけど、Javaプログラマはサービスとか
システム連携とかもっとhigherな（機械から離れてる）とこを目指してる。
509:仕様書無しさん
08/02/02 22:50:54
目指してんのか？
510:仕様書無しさん
08/02/02 22:56:16
目指さない奴もいるけど目指す奴は目指すだろ
C++でもJavaでもモチベーション低い奴高い奴いろいろいるだろ
511:仕様書無しさん
08/02/02 23:02:12
俺は両方目指してる。
512:仕様書無しさん
08/02/02 23:20:35
>>510
Javaのみしか使えないやつで、モチベーションの高い奴なんてみたことないぞ。
かつてのVBerと同程度の志しかないように見える。とりあえず、うごけば・・・・ってね。
あとプログラマの目指すサービスって顧客の求めるものとは方向が全然違ったりするし。
たとえば、
プログラマが良いと思っているサービス：Webアプリにすれば管理が楽です！
顧客が求める良いサービス：とにかくExcelと連携がとれていて、反応が早くて使いやすい。
とかね。
513:仕様書無しさん
08/02/02 23:26:06
>>512
そだね、客の求めるものがいいものだと思う
現実的な工数で見た目のいい物ってなるとJAVAのほうがよかったりする？
教えて両方使ってる人
514:仕様書無しさん
08/02/02 23:27:22
>>512
>>508のいう「サービス」はWebサービスとかＳＯＡとかそういうヤツだと思われ
515:仕様書無しさん
08/02/02 23:35:42
>>513 男なら見た目より中身で勝負しろ
516:仕様書無しさん
08/02/02 23:42:27
>>514
いや、その視点がプログラマの視点ではないかと。
俺は社内SE兼事務員だから、基本ユーザーサイドにいる。
多くのユーザーは、EXCELがアプリケーションの基本であり、
・EXCELと連携が取れて当然。
・EXCELでできることは、当然その他のアプリケーションもできる。
・ユーザーインターフェースもEXCELのようなものである。
と考えている。
2000万かけて発注してつくったWebアプリより、
規模が小さかった頃に作った6年前のEXCELのマクロ&VB4.0によるシステムのほうが評価が高い。
もちろん技術者的視点だと今のシステムのほうがいいんだが、ユーザーの視点だとこういう評価。
517:仕様書無しさん
08/02/02 23:42:55
マが「見た目のいい物」って言い方するか？
518:仕様書無しさん
08/02/02 23:44:44
>>517
画面設計とかで顧客レビューしないの？
519:仕様書無しさん
08/02/02 23:46:43
>>516
社内の情シスが要求定義出来てないだけだろ。
要求定義まで発注してるならSIのミスだけど。
520:仕様書無しさん
08/02/03 00:01:45
>>518
「見た目」はデザイナのタスクでしょ。
B2C以外で「見た目」ってレベルの話も早々無いし。
マの画面設計は機能的な表現の確認。
521:仕様書無しさん
08/02/03 00:05:34
クライアントサイドのプログラムは絶対にMS製開発環境で作れ。
サーバーサイドはどうでもいい。
これ、客に喜んでもらえる最低条件。
522:仕様書無しさん
08/02/03 00:10:50
デスクトップアプリとクラサバとWebアプリの違いや用途を説明しきれてない
だけなんじゃないの。エクセルだけで情報共有やコラボは厳しいでしょ。
523:仕様書無しさん
08/02/03 00:26:13
>>521
うちクライアントPCがLinuxになっちゃったんで、折角作ってもらっても動かないんですが...
524:仕様書無しさん
08/02/03 01:31:10
>>520
そっか、概要からやってるマって少ないのか？
普通に画面設計（何も無いところからの提案）からやってるけど
525:仕様書無しさん
08/02/03 02:02:00
>>524
おまえのなかでは概要=見た目なのか？
ほんとに開発経験あるの？
526:仕様書無しさん
08/02/03 02:03:34
>>525
いやｗ当然見た目だけじゃないよ？
開発は１０年以上してるけどなぁ
527:仕様書無しさん
08/02/03 02:11:36
>>526
１０年以上・・・
画面にどの項目が必要かは機能に依存する、それはデザイナにはわからない。
ベースになる画面=画面設計はマの仕事。
「見た目」って言うのはそのベースに肉付けするタスク、これはマよりデザイナのタスク。
画面設計（マ）→見た目（デザイナ）→反映（マ）
スレチだしコレで終わりな・・・
528:仕様書無しさん
08/02/03 02:40:03
>>527
>>513の
＞現実的な工数で見た目のいい物ってなるとJAVAのほうがよかったりする？
もスレチかな？
デザイナが独立してる業務はやった事が無いからな
分業してるところがあるってのも理解できる
手法が違うんだろうな
ウチはこんな感じ
・顧客と要件確認
↓
・機能概要設計（開発者から提示）→顧客と機能確認
・画面設計（開発者から複数提示）→顧客と使い勝手と見た目の好みを協議
↓
・詳細設計～MAKE～TEST
で、聞きたいのは一番上のやつね
マとデザイナが分業じゃ無い人の意見聞いてみたいな
529:仕様書無しさん
08/02/03 04:44:59
>>528
> ＞現実的な工数で見た目のいい物ってなるとJAVAのほうがよかったりする？
> もスレチかな？
エスパー募集にした方がいいよ。
530:仕様書無しさん
08/02/03 09:02:44
JAVAって文字コードの変換とかしょぼくね？
531:仕様書無しさん
08/02/03 13:17:23
Webアプリだとデザインは分業が多いよね。逆にVBとかで作るWinアプリだとあまり聞かない。
その前提がズレてんじゃね？ まぁ、SE/プログラマにデザインやらせるもんぢゃないよ。
532:仕様書無しさん
08/02/03 14:03:39
SE/プログラマにデザインやらせた結果の産物→Windows
デザインとプログラム分業の結果の産物→Mac OSX
533:仕様書無しさん
08/02/03 14:12:34
どっちもどっちだな
534:仕様書無しさん
08/02/03 15:16:52
学者と大手技術者にやらせた結果→Tron
535:仕様書無しさん
08/02/03 15:23:01
自動改札くらいしか使ってるの知らないな
536:仕様書無しさん
08/02/03 15:36:16
2chネラーにやらせた結果の産物→MonaOS
537:仕様書無しさん
08/02/03 17:09:08
ひろゆきにやらせた結果→このざま
538:仕様書無しさん
08/02/16 00:30:40
JAVAとかC++とか関係無い
俺が１人で優れている
539:仕様書無しさん
08/02/16 00:53:49
おじゃばじゃないんだからｗ
540:仕様書無しさん
08/02/16 09:13:29
インタプリタな言語から来た人なのか？
コメントが全く入っていないコードの書き方。
541:仕様書無しさん
08/02/22 21:59:41
やっぱJava->C++と進んだ方がいいのか。
俺C言語とPerl同時にやってる・・・。
で、3月から就職活動です。
542:仕様書無しさん
08/02/23 09:33:22
>>541
スレ的にはなんだが学生ならC++もJAVAもイラネ
Cだけのほうが変に染まって無くていいよ
でもCで変に染まってるのは簡便な
ソフトウェア工学とかコンピューター工学をおさらいしてたほうが良いんじゃないか？
543:仕様書無しさん
08/03/22 20:19:06
どっちが優れてるかって、Javaに決まっているだろ。
Javaの方がバージョンアップとかされてるし、
機能もどんどん豊富になっているのに。
JavaとC++それぞれで、同じ仕様のソフトを作らされたとしても、
断然Javaの方が早く仕上げることが出来るよ。
しかもバグ無しでね。
544:葉猫 ◆Jz.SaKuRaM
08/03/23 14:48:10
C++は日進月歩が激ちいから、ちょっと勉強を怠るとまったく別言語のように感じられまつね。。。。。。
545:仕様書無しさん
08/03/23 15:17:34
C++の日進月歩が激しい！？
マジ？Javaの間違いだろ。
546:仕様書無しさん
08/03/28 11:13:52
Boostのことだろ、jk。
547:仕様書無しさん
08/03/28 23:19:32
jk＝女子高生的に考えて？
548:仕様書無しさん
08/05/23 18:18:55
const がない言語は使いたくない。
const がない言語は private や protected がないのとたいして変わらない。
549:仕様書無しさん
08/05/27 01:04:34
OK、ベンチマークテストで決着だ。
じゃ、C++派のオレからね。
----
#include <iostream>
template <int N>
struct Fib{
enum{ value = Fib<N - 1>::value + Fib<N - 2>::value };
};
template <>
struct Fib<2>{
enum{ value = 1 };
};
template <>
struct Fib<1>{
public:
enum{ value = 1 };
};
int main(){
std::cout << Fib<32>::value << std::endl;
}
----
計算時間：０秒
550:仕様書無しさん
08/05/27 21:32:03
>>546
言っている意味が分からん
551:仕様書無しさん
08/05/30 13:58:41
どこの専門学校でも最初に学ぶのは
C言語だよ
まあJavaは業界標準になったけど
でもJavaはデスクトップアプリって言うイメージがあんまりない
Win以外では違うけどね
それとアルゴリズムとか何かに特化した解説書にはC/C++が多い
まあ自分はWin以外ではJava
WinではC++見たいな感じで使い分けているよ
開発環境に頼るプログラマーも増えてきているよね。
プログラマーの質が落ちてきているのかな？
イメージ的に
C++・・・中・上級者が多い
Java・・・様々
みたいな感じだね
かく言う自分もろくなプログラマーじゃないけどね
最終的にどっちかと言われたらC++だろうね
自分の能力をしっかりと反映してくれる鏡みたいなもんだね
でもSunの製品も好きだよ
552:仕様書無しさん
08/05/30 19:03:09
どう考えてもアプリ作るんならjavaが開発速いだろ。
なんでわざわざc++を選ぶ？
553:仕様書無しさん
08/05/30 20:04:35
Java で作った Word や Excel の動作を見てみたい。
554:仕様書無しさん
08/06/01 21:06:04
Javaでは、出来ないことがある。また、速度も遅いし。
native使うと保守性の問題がでる。Java+他の言語をシステムレベルで，構築できるエンジニアは少ないから。
555:仕様書無しさん
08/06/01 21:21:48
Javaでしか出来ないことの方が圧倒的に多いだろ…
てか、C++なんてもう流行らないだろ。
556:仕様書無しさん
08/06/01 22:32:50
使いこなせる言語が
C/C++
VB
Web-Scr系
Java
.NET
SQL
ASM
環境もマイコンからWebまで、ゲーム系から業務、組込みまで一通り開発してきた
俺 様 が 優 れ て い る
道具の優劣なんざ使う人間の質で変わるさ。
557:仕様書無しさん
08/06/01 22:34:58
asm以外使えるけど
使える言語の多さで優劣は測れないだろ
558:仕様書無しさん
08/06/01 22:35:38
一つの言語をハッカーと呼ばれるレベルまで極めてみろよ
559:仕様書無しさん
08/06/01 22:49:15
>>555
>Javaでしか出来ないこと
具体的にどういうこと?
560:仕様書無しさん
08/06/01 22:51:25
>>558
特定の言語を極めたところでハッカーとは呼べない。
ハッカーってのは、そもそも言語を極めた奴のこと
ではない。
561:仕様書無しさん
08/06/01 22:53:49
>>560
ではどういった人間をハッカーと呼ぶの？
562:仕様書無しさん
08/06/01 22:55:10
>>561
ググレカス
563:仕様書無しさん
08/06/01 22:57:09
プログラマーがハッカーと呼ぶ場合
その技術の高さから尊敬されるプログラマーのことを指す
例：Perlのハッカー
と認識しているが。
564:仕様書無しさん
08/06/01 22:58:32
>>563
ググレカス
565:仕様書無しさん
08/06/01 22:59:47
一般人がハッカーと呼ぶ場合
セキュリティを破ってコンピュータに侵入する人間のことを指す
ただしどちらの意味でも共通して言える事は
コンピュータにやらせたいことをさせる事が出来る人間ということ
566:仕様書無しさん
08/06/01 23:00:50
>>564
結局よくしらないんですね
聞いた僕が馬鹿でした
567:仕様書無しさん
08/06/01 23:03:52
>>566
565が言うのが概ね正しい。
よって、Perlの～とか、Javaの～というのはあり得ない。
568:仕様書無しさん
08/06/01 23:07:21
>>567
なぜあり得ないのか
ハッカーは自分の出身の言語によって考えるそうだが。
569:仕様書無しさん
08/06/01 23:10:45
>>568
言語毎を極めることは、コンピュータにやらせたいこと
をさせる事が出来る人間のそれと同じではないから。
Perlは所詮、Perl。 Javaは所詮、Java。
出来ることは予め決まっている。
570:仕様書無しさん
08/06/01 23:14:40
わかった
571:仕様書無しさん
08/06/01 23:37:14
>>559
APIの豊富さ・使い勝手のよさ。
開発ツールの豊富さでもJavaの方が上。
572:仕様書無しさん
08/06/01 23:53:39
>>571
それが Java にしかできなきことですか？ そうですか。
573:仕様書無しさん
08/06/01 23:55:43
リバースエンジニアリングもJavaがやりやすいし、
リファクタリングもJavaの方が楽。
クラス構成の変更とかもJavaがやりやすい。
保守性を考えたら圧倒的にJava。
C++なんて昔のシステムの保守くらいだろ。
スピードだって今はハードの性能上がってるしな。
そこまでC++だからという恩恵は受けられない。
574:仕様書無しさん
08/06/01 23:58:07
>>572
C++は開発をする上で柔軟性がないんだよ。
例えば手戻りが発生したら、Javaよりも多くの工数を必要とするの。
てか、ここでC++なんて勧めてるやつ、業務経験あるの？
学校で習ったことくらいしかないんじゃないのか？
575:仕様書無しさん
08/06/02 00:19:46
いちいち2次元ベクトル new したくないし、まだC#の方がまし。
576:仕様書無しさん
08/06/02 00:32:37
いまどきの学習言語はJavaじゃないの?
577:仕様書無しさん
08/06/02 11:25:03
>>573と>>574が言ってることはダウト
これだから知恵の無い奴らは…ITゆとり世代?
まじでこの手の無能を使ってる時が一番心労がたまる…。
ちなみにこの手の無能の36歳の男と仕事してて疲弊したから俺は今日有給wwww
578:仕様書無しさん
08/06/02 13:28:43
まじでC++プログラマの皆さんにはJavaの勉強をお薦めします。
そしてJavaのプログラムを作ってみてください。
C++の良さを再認識し、もっと良いプログラムを作れるようになるでしょう。
579:仕様書無しさん
08/06/02 16:45:16
javaにはプリプロがないよね。
定数を定義するとき、みんなどうしてるの？
580:仕様書無しさん
08/06/02 20:11:12
定数より条件コンパイルしたいときに困った。
昔、無理やりCのプロプロ通してからjavaコンパイルしている同僚がいた。
581:仕様書無しさん
08/06/02 23:42:42
>>577
俺は事実を言ったまで。
時代について来れないC++厨は一生疲弊してな。
582:仕様書無しさん
08/06/03 17:25:24
Java アプリは GUI がカッコ悪いうえにもっさり感があってストレスが溜まる。
CPU が速くなっても C/C++ アプリのサクサク感と比較されるからずっともっさり
感がなくならない。
583:仕様書無しさん
08/06/03 18:00:02
>>582
swingのこと？
JavaのGUIはswingだけじゃないよ。
584:仕様書無しさん
08/06/03 18:19:18
Swingいったん氏に体になったけど、復活してデファクトになったんじゃなかったっけ？
585:仕様書無しさん
08/06/03 20:16:00
>>583
何を使っているのか分からないがカッコ悪いのが多い。
文字や線もアンチエイリアスがかかっていないのが多くて醜い。
586:仕様書無しさん
08/06/03 21:03:41
Javaってモッサリ言語だよね。
587:仕様書無しさん
08/06/03 21:42:25
つーか、かっこ悪いかカッコいいかなんて
定量化できない主観的な意見だなｗ
そんなので言語の優劣をつけてるやつの方が
激しくかっこ悪い。
588:仕様書無しさん
08/06/04 00:26:44
かっこいいかどうかはともかく、
OS標準のUIと見た目が違うのはが気になる。
それはまだいいが、操作性が異なるのはストレスたまる。
Javaが、というつもりはない。
C++だってクロスプラットホームという奴は大体そう。
おとなしく標準のコントロールを使ってくれ。
589:仕様書無しさん
08/06/04 00:28:11
Javaで組んであると一目でわかるように
してるんぢゃね？ 糞でも出来ますよ、
この位ｗ って暗にアピールしてるような
ものだがなｗ
590:仕様書無しさん
08/06/04 01:16:28
"Write once, run anywhere" を守るためならしょぼくなっても仕方ない。
591:仕様書無しさん
08/06/04 13:28:55
Javaアプリだけ遅くなるのはいいけどリソース食いすぎで他のアプリにまで迷惑かけるなよ。
ノートPCだとまるでディスクキャッシュが無効の状態だよ。
小さいテキストファイルを開くたびに待たされてイライラする。
592:仕様書無しさん
08/06/04 19:06:33
>>590
GUI周りをそれでやる必要はなかったな
593:仕様書無しさん
08/06/04 19:33:24
>>588
クロスプラットフォームの意味が分かってれば
そんなバカなレスはしないはずなんだがな。
OS標準のコントロール使ってる時点でクロスプラットフォームじゃねぇだろ。
>>591
それはプログラマがしょぼいせい。
594:仕様書無しさん
08/06/05 01:15:58
きっと Java にはしょぼいプログラマを惹きつける何かがあるんだよ。
595:仕様書無しさん
08/06/05 09:27:19
片方しか使えない人間にこのスレに参加する資格はない
596:仕様書無しさん
08/06/05 12:00:46
昔みんなが Java Java 騒ぐから一時 Java を使ってみたが、結局 Java の良さが
理解できなくて C++ に戻った。
597:仕様書無しさん
08/06/05 23:22:42
>>594 >>596みたいな事言うやつってさ、
昔磨いた技術が捨てがたくて、
新しい技術を受け入れづらくなってるんだろうね。
時代についていけなくて悔しいから、
自分のプライドを守るために
粗探しに必死なんだろうよ。きっと。
>>595
全く。
598:仕様書無しさん
08/06/06 05:04:26
JavaなんてどうせLinux専用みたいなもんだからc++でいい。
599:仕様書無しさん
08/06/06 19:32:38
> JavaなんてどうせLinux専用みたいなもんだから
は？ｗ
600:仕様書無しさん
08/06/06 22:14:35
LinuxってそんなにJava使われていたっけ?
自分が管理しているLinuxサーバー2台にぜんぜんJava入っていないけど。
601:仕様書無しさん
08/06/06 22:24:43
Windowsで使われないJava。
Linuxで使われないJava。
やっぱりどこいってもCとC++なんだな。
602:仕様書無しさん
08/06/06 22:46:11
情けないねえ
別の言語を使うなんて格ゲーのキャラ変えるようなもんだろ
何をそんなに拘ってるんだか
603:仕様書無しさん
08/06/06 23:27:18
JavaとC++の両方を高く評価しているやつなんて皆無だろ。
604:仕様書無しさん
08/06/07 03:04:21
本題からはズレるが、言語の優劣なんてプログラマには関係ない。
JAVAやC++を使うような連中は自分の意思で言語を決定できないからな。
どちらも四年制大学を卒業したプログラマが使う技術だ。
こういう連中は国家資格を取得し、メーカや独立系の企業で仕事をする。
自分が配属された部署がC++やってるなら、他に選択肢などない。
あと、現実的なこと言うと比較できるほどやってる人はいない。
CとC++が使えるPG、CとJAVAが使えるPGはけっこういる。
しかし、C++とJAVAを使い分ける人には会った事がない。
わざわざ2種類のオブジェクト指向言語を覚えるメリットは少ない。
あとはVBやRubyを触ったら熱が冷める。
その頃には、プロジェクト管理や契約書に関心がいくようになる。
605:仕様書無しさん
08/06/07 06:41:54
>>601
>やっぱりどこいってもCとC++なんだな。
10年前の話？
>>604
VBやRubyに変わられる事はありえないだろ。
606:仕様書無しさん
08/06/07 07:42:58
>>604
俺はVBを触っていたけど、今はJavaが好き。
.NETは高級言語過ぎて内部で何が起こっているのかわかりづらいからなぁ。
トラブルが起きた時にはまる時間が長くなりがちな気がする。
Rubyってインタプリタだからそれこそ遅いんじゃないの？
607:仕様書無しさん
08/06/07 10:56:51
>>604
おまいと一緒にすんなよｗ
608:仕様書無しさん
08/06/07 11:00:03
俺は.NETが割とお気に入り
JAVAと違って学ぶことが多くあるからな
C++はジェネリックスがJAVAにも.NETにも搭載された時点で
存在価値が薄れた気がする
いまさらAPI叩く必要もないしな
609:仕様書無しさん
08/06/07 11:02:28
あとVBは業務アプリ専用の糞言語とだけ言っておく
610:仕様書無しさん
08/06/07 12:10:08
>>607
.NETはあんまり知らんけど、
Javaでサーブレットしてた方が自分で設定すべきことが多くて
学ぶことあるんじゃないのか？
Visual Studioとか使ってると、
何も知らなくても勝手にやってくれる部分が多いからなぁ。
>>609
確かに、
VBはExcelVBA以外はあえて使う事もないんじゃないかね。
>>604のVBを使ってJavaの熱が冷めた理由が本気でわからんｗ
611:仕様書無しさん
08/06/07 12:19:57
>>610
.NETはあまり判ってなくても何となく組めるから勘違いされる
612:仕様書無しさん
08/06/07 12:42:33
VBができると事務のお姉ちゃんにモテモテだからな。
たぶん。
613:仕様書無しさん
08/06/07 13:00:01
ここでC++が、JAVAが良く判らなかったとか言ってる奴は
自分はアホですって告白してるようなもんだ
614:仕様書無しさん
08/06/07 13:05:12
判らないのはJAVAではなくJAVAの良さ
615:仕様書無しさん
08/06/07 13:14:29
>>614
同じことだと思う。
616:仕様書無しさん
08/06/07 13:39:39
>>614
自分でメモリ管理することの利点欠点と
それがイベント駆動型アプリケーションにもたらす影響を教えて
617:仕様書無しさん
08/06/07 14:54:37
>>614
詳細設計しかやったことない新人プログラマがいる現場なら必要。
新人にメモリ管理はちょっと重荷かも。
今は開発者のレベル差が激しいから言語仕様で保障されてるほうが良い。
あとは、自分でロジック書けば開発コストも増える。
知識ついてくれば自分でもできることは増えるけど
言語やミドルウェアに頼った方が開発コストは減る。
618:仕様書無しさん
08/06/07 18:10:23
>>616
> 自分でメモリ管理すること利点欠点
これはJavaのメモリ管理に対してのC++のメモリ管理のことか?
利点
- 必要なくなったオブジェクトを即座に削除できるのでメモリの無駄が減る。
- デストラクタによって局所変数を即座に後処理することができる。
この仕組によりメモリ以外の一般リソースの後処理もできる。
これはオブジェクトの外で finally するより簡単である。
- new や delete のオーバーライドによってメモリ管理を簡単に変更できる。
- プールやスマートポインタなどによってオブジェクトの寿命を細かく制御できる。
また小さなオブジェクトのメモリ効率を良くすることができる。
- 基本型以外の型でも、必ずしも new する必要がない。
- GC のように不意に実行が中断されることがない。
- オブジェクトはある程度レイアウトを制御できるので他言語とリンクしやすい。
- 配置構文 new によって共有メモリや特殊なハードウェアを扱いやすい。
- ポインタ自体がオブジェクトなので Swap などの細かい操作が簡単である。
欠点
- new したら明示的に delete しなければならないことがある。
- ヒープメモリの実装によってメモリの断片化が起きやすい。
- オブジェクト所有権を意識していないプログラマはメモリリークを起こしやすい。
- オブジェクトの参照が入り組んでいるとダングリング参照を起こしやすい。
- ライブラリなどはオブジェクト所有権を明記していないと間違いを起こしやすい。
- 一般的なスマートポインタだと循環参照の扱いが難しい。
メモリリークの概念によっては GC を持つ言語でメモリーリークはある。
またオブジェクトが削除されないことが必ずしもメモリリークとは限らない。
> それがイベント駆動型アプリケーションにもたらす影響を教えて
これは知らない。
C++メモリ管理とイベント駆動の関係で嬉しかったことも困ったことも記憶にない。
619:仕様書無しさん
08/06/07 19:11:41
>言語やミドルウェアに頼った方が開発コストは減る。
つまりこういうこと。
C++はメモリ管理やロジックを自分でやる必要があるから、
JavaよりC++のプログラマの方が優れているなんていうやついるけど、
実はそんなものはちょっと教えれば大抵のJavaプログラマはすぐ習得する。
お勉強にちょっとC++をいじるのは良いかもしれないが、
開発コストを考えればJavaに軍配が上がるのは明らか。
620:仕様書無しさん
08/06/07 20:00:56
JAVAで作られたプログラムとC++で作られたプログラム
どっちが高性能なの？
621:仕様書無しさん
08/06/07 20:02:59
モノによる
はい、次。
622:仕様書無しさん
08/06/07 20:17:10
同じだけの時間をかけたものであればJava
同じだけの機能を持ったものならC++
だが、保守を考えるとやっぱJavaだろうな。
623:仕様書無しさん
08/06/07 20:38:23
javaだろ
624:仕様書無しさん
08/06/07 21:04:05
>>620
JAVAの性能に関する話題はタブーですよ。
625:仕様書無しさん
08/06/07 22:27:38
世界中で使われてるような評価の高いソフトウェアって
JAVAとC++どっちで作られてることが多いの？
626:仕様書無しさん
08/06/07 22:54:37
>>625
Javaは新しいから、
昔からあるような評価の高いソフトでは
そんなに多くは使われてないんじゃない？
でも、オラクルは確かJavaとC両方使われてたんだっけな
627:仕様書無しさん
08/06/07 23:17:07
世界中で使われてるといったら
Word, Excel, PowerPoint, Photshop とかかな。
何で開発されているんだろうね。
628:仕様書無しさん
08/06/08 09:32:42
本業は別業界なんで、余裕の時間にバイトでプログラマーでもしようかと思うんですが、
どの言語を勉強すればいいでつか？
629:葉猫 ◆Jz.SaKuRaM
08/06/08 11:11:09
VBAだな。 エクセルでマクロの記録をやったのを少ちずつ改良つればいいでつち。
630:仕様書無しさん
08/06/08 12:06:14
キチガイコテはさっさと氏ねと
631:仕様書無しさん
08/06/08 17:50:59
途中、めんどくなって読んでないけど
簡単にまとめると、敷居が低いのがJavaで
使い込んでくると使いやすいのがC++って結論でおｋ？
632:仕様書無しさん
08/06/08 22:15:33
敷居とかではなく、ハードウェアに対する近さが違う。
それに実際にアプリ作るなら、どんな環境で開発するかも考えるべき。
C++はC言語をオブジェクト指向言語にしようという事で開発された言語。
ベースになってるC言語と同様に、OSやコンパイラだって記述可能。
Windowsで何か凝ったもん作るならVC++。
携帯電話やゲーム分野など、大抵の分野でC/C++の処理系が存在します。
Javaは「完全なオブジェクト指向言語」なので
C++みたいに構造化言語みたいな使い方はできない。
あと、ハードウェアをあまり意識しないで良い。
難点はインタプリタ言語なんで重い。これでOSは書きたくない。
Webアプリを作るならミドルウェアも、マニュアルも豊富だし有力候補。
あと、両者とも決して敷居が低い言語ではないと思う。
どちらも構造化言語で必要になる知識(変数、文法、ライブラリ)のほかに
以下のような知識がないと仕事では使えないと思う。
・オブジェクト指向の知識
・プラットフォームの知識(WindowsでVC++ならMFCや.NET、JavaならJavaVM)
・システム化する対象の知識(ワープロや表計算、金融や流通などの業務知識)
・ソースコードのマネジメント知識(バグ管理やコーディング規約、バージョン管理など)
あとはコミニュケーション能力が大事。
画面設計書、テーブル定義書には記述できないことが多いし
大規模開発になりやすい。
少しのコミニュケーションギャップがプロジェクトに大ダメージを与える。
633:仕様書無しさん
08/06/08 22:28:53
C++の利点
- 高速で細かいところまで制御しやすい
C++の欠点
- 学習が難しく機能が誤用される可能性が高い
Javaの利点
- C++の欠点の反対
C++の欠点
- C++の利点の反対
634:仕様書無しさん
08/06/08 23:45:28
>>632-633
ありがと。
特に 632の解説はわかりやすかった。
635:仕様書無しさん
08/06/09 01:12:56
>>632
> あと、ハードウェアをあまり意識しないで良い。
これは嘘じゃないか？
思いっきり動作環境を意識しないとコード書けないと思うが。
636:仕様書無しさん
08/06/09 02:15:55
JAVAのが初心者にはいいんだ
637:仕様書無しさん
08/06/09 02:23:54
C++のSTLは洗練されてない
アルゴリズム関数とかダサい
638:仕様書無しさん
08/06/09 11:58:32
>>637 もっと論理的に説明してください。
639:仕様書無しさん
08/06/09 23:09:00
俺もC++やっていたけど、STLはひどすぎたよ
Javaの方が何倍も効率いいし、やっていて楽しい
640:仕様書無しさん
08/06/09 23:48:07
>>632
Javaはインタプリタといっても、
よく言われてるほど速度遅いやつじゃないぞ。
641:仕様書無しさん
08/06/09 23:56:47
GC邪魔
642:仕様書無しさん
08/06/10 00:22:17
>>641
…別に？
643:仕様書無しさん
08/06/10 16:13:39
Java で 60fps を死守しなければならないアプリケーションの作り方って難しくない?
必要なオブジェクトを予め new しておいて後は一切 new しない方法しか思いつかないけど。
new のタイミング以外で GC が起きないという前提で。
644:仕様書無しさん
08/06/10 20:47:38
>>637
その気持ち分かる気がする。
アルゴリズムの関数はいろいろあるけど、
copyとfind、for_eachとか使う頻度が高い関数は極少数。
もう少しよく使うものがあってもいいんじゃないかと思う。
具体的に何？と言われると考え込むけど。
645:仕様書無しさん
08/06/11 16:53:40
STL はデータ構造とアルゴリズムが綺麗に分離されているのが凄いよね。
あれを考えた人は天才としか思えない。
646:仕様書無しさん
08/06/11 17:32:02
＞データ構造とアルゴリズムが綺麗に分離されているのが
いや、それってSTLを考えた人じゃなくて、template構文を考えた人。
647:仕様書無しさん
08/06/11 19:47:58
STLってなに？
648:仕様書無しさん
08/06/11 19:53:44
OTL
649:仕様書無しさん
08/06/11 20:10:01
>>646
コンテナとアルゴリズムを分離してコンテナ以外に対してもアルゴリズムを
適用する方法は template の概念だけではなかなか思いつかないよ。
Stroustrup もこれに衝撃を受けて標準化を遅らせてでも STL を標準に入れた。
650:仕様書無しさん
08/06/12 15:02:38
C++は言語仕様が汚く、複雑すぎるんだよな。
ソフトウェアに必要な「短くまとめるセンス」がない。
「簡潔さ」「スマートさ」「覚えやすさ」が無視されてる。
構造化言語ならC言語、オブジェクト指向言語ならJavaは
うまくまとまってるが、C++はどっちつかずで使いづらい。
Unixのテキスト処理やファイル、OracleのSQLや
GoogleMapsのインタフェースも「スマートさ」がある。
iPodやiPhoneも「スマートさ」「潔さ」がある。
651:仕様書無しさん
08/06/12 21:29:23
Javaのどこがうまくまとまってるんだ？
混沌そのものじゃないか。
652:仕様書無しさん
08/06/13 08:08:43
>>651
Javaを使って混沌になるってのは、
自分の腕がしょぼいといっているようなもんだぞ…
653:仕様書無しさん
08/06/13 14:13:40
Javaは基本型とクラス型の機能が非対称すぎる。
- 基本型は参照を使えない
- 基本型は Object のメソッドが使えない
- それぞれメモリ管理の方法が違う
- それぞれ型変換の方法が違う
- クラス型はほとんどの演算子が使えない (なぜか String には加算演算子がある)
654:仕様書無しさん
08/06/14 10:01:16
Simulaで基本型とクラス型の違いに不便を感じて
どっちでも同じ扱いができるようにしたC++。
655:仕様書無しさん
08/06/14 11:28:25
>>653
>Javaは基本型とクラス型の機能が非対称すぎる。
>- 基本型は参照を使えない
>- 基本型は Object のメソッドが使えない
お前もう少しJava勉強してから出直してきた方が良いよ。
656:仕様書無しさん
08/06/14 11:59:51
>655
えーと、intとIntegerを混同してたりしない?
653はその辺の話をしてるんだと思うが。
漏れもintをコンテナに突っ込む為にIntegerにしたり、
逆に計算するためintに戻すといった操作を必須とする
仕様はイケてないと思った。
657:葉猫 ◆Jz.SaKuRaM
08/06/14 12:07:12
全てをおっぱいおっぱいにちないで処理スピードのために型を残ちたJava、ﾀﾞｻ
658:仕様書無しさん
08/06/14 13:03:24
>>656
してない。
てか、653と656はオートボクシング知ってるの？
659:仕様書無しさん
08/06/14 13:21:37
てか、>>653は、文面から察するに、オートボクシング型どころか、
Integer型やDouble型の存在すら知ってるかどうか危ういんだが…。
660:仕様書無しさん
08/06/14 13:23:58
間違えた、オートボクシングのあとに
なぜか「型」がついてるのは気にしないでくれ。
661:仕様書無しさん
08/06/14 13:33:40
>658
ほう、こんなものが追加されたのか。
4.0までしか使ってなかったから知らんかった。
でも↓は酷すぎ…
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
662:仕様書無しさん
08/06/14 14:15:18
>>659 Autoboxing は最近知ったがな。
基本型のラッパーを使っていも、同じオブジェクトから作った2つのラッパーが
同じオブジェクトになるわけではないし。
しかも Integer は -128 から 127 は特別扱いされてややこしい。
Autoboxing は単にラッパーオブジェクトへの変換を自動化しているだけで
面倒な部分を隠しているだけ。ラッパーではなく基本型のオブジェクトで
なければ混乱するだけ。
それに 5.hashCode() みたいな事ができるのか? できたとしてもいちいち
Integer オブジェクトに変換されていたら重くてしょうがないが。
言語が特別扱いするクラスも増えて Java はどんどん複雑になっている。
663:仕様書無しさん
08/06/14 14:50:52
> -128 から 127 は特別扱いされて
これは知らなかったが、だがこんなものは開発標準で規約を決めれば良いだけの話。
Javaのコードの簡潔性や、開発速度等のメリットから見たら小さな話。
5.hashCode()これは出来ないし、C++でも出来ないだろ。
C#なら出来るか？
だが、それがどうしたというのか…。
664:仕様書無しさん
08/06/14 15:07:39
>>663
> 5.hashCode()これは出来ないし、C++でも出来ないだろ。
> C#なら出来るか？
> だが、それがどうしたというのか…。
基本型だけ Object を継承していないのが非対称ということ?
C++ はもともと共通のベースクラスを持っていないので
できなくても不自然ではない。
5.hashCode() みたいな書き方は Ruby ならできる。
C# は知らないが結構オブジェクト指向っぽくなっている
ようなことは聞いたことがある。
665:仕様書無しさん
08/06/14 15:42:40
>663
全然小さな話じゃないよ。
規約決めた所で、徹底不足だったら意味ないし、
知識として知っててもミスしないと言い切れない代物。
レビューでも注意深く見ないと気付けないだろうし、
動作テストでも検出できない恐れが十分あり得る。
これがIntegrなんてごく基本的なクラスに存在するのは
かなり致命的だと思うが。
666:仕様書無しさん
08/06/14 15:45:24
>663,664
URLﾘﾝｸ(www.ne.jp)
C#はこれを克服し、基本型をなくしてしまった。
全ての型はクラスであるとしたのである。
intはSystem.Int32のエイリアス。
stringはSystem.Stringのエイリアス、そして配列までも
System.Arrayのエイリアスだとしている。
667:仕様書無しさん
08/06/14 15:57:06
>>665
>規約決めた所で、徹底不足だったら意味ないし、
C++だったらnewしたらdeleteしなきゃメモリリーク起こすの知ってるよな？
それだって対策が徹底不足だったら意味ないし、当然ミスもありうる。
それに比べたら別にIntegerの問題くらい大した事はないだろう。
てか、>>661のページは面白おかしく書いてるだけであって、
実際の実務でそんなIntegerの使い方はありえない。
>>666
C#なんてJavaほどマニュアルも揃ってないし、微妙極まりないだろ。
Rubyなんてインタプリタだし却下。
668:仕様書無しさん
08/06/14 15:59:23
>>665
>動作テストでも検出できない恐れが十分あり得る。
そんなのどんなバグでも検出できない恐れは十分にある。
>これがIntegrなんてごく基本的なクラスに存在するのは
Integerは実はそれほど頻出するクラスでもないよ。
>かなり致命的だと思うが。
全然。
669:仕様書無しさん
08/06/14 16:04:33
>667
メモリリークはツールなりデバッグ関数なりで、
動作テスト1回で簡単に検出できる。
何が最悪かって動作テストをきっちりやっても
防止できない所なんだよ。
そこが最悪か否かの境界線。
あとC#のマニュアルはMSDNで十分過ぎる。
Javaに倣ってソースからドキュメントを生成する仕組みもあったはず。
670:仕様書無しさん
08/06/14 16:09:46
>>668
> Integerは実はそれほど頻出するクラスでもないよ。
Autoboxing 導入されたら知らないうちに頻出するよ。
671:仕様書無しさん
08/06/14 16:12:29
C#は結構まとも
悪くないよ
一般的には.net依存なのが最大の難点になるけど
672:仕様書無しさん
08/06/14 16:16:05
>>669
メモリリークがIntegerのそれより簡単に検出出来るなんて、どこにそんな根拠が？
そもそもIntegerで==を使って比較なんてして、最後まで気づかないなんてありえない。
てか、Integerをそんな頻繁に使っていること自体ありえない。
悪いけど、うちでそんなソース書いてたら、すぐ直させるよ。
MapやListに使う事はあるが、外に出す時は必ずintに直すべき。
C#はマニュアル、開発環境ともにJavaに劣るよ。
673:仕様書無しさん
08/06/14 16:21:25
>>670
Listとかに挿入する時に知らないうちにオートボクシング行われている。
…といいたいのか？
オートボクシングが採用されたバージョンでは、同時にジェネリクスも採用されてる。
つまり実際にはList<Integer>などと宣言することがほとんどで、
知らないうちなんてありえない。
674:仕様書無しさん
08/06/14 16:28:46
>672
メモリリーク検出用のツールとか関数というのがきちんとある。知らんの?
※適切なタイミングでメモリの仕様状態を確認するだけで分かる。
675:仕様書無しさん
08/06/14 16:36:09
>672
>MapやListに使う事はあるが、外に出す時は必ずintに直すべき。
そうすると
>653
>Javaは基本型とクラス型の機能が非対称すぎる。
>- 基本型は参照を使えない
>- 基本型は Object のメソッドが使えない
に戻ってくるわけで。
676:仕様書無しさん
08/06/14 16:40:47
>>674
デバッグツールはcoreを解析する時くらいしか使ったことないな…
>>675
だからそのデメリットが分からないのよ。
基本型とクラス型の二つがあったらなぜいけないのか。
C#やRubyに慣れすぎてて、Javaに違和感を感じてるだけなんじゃないの？
677:仕様書無しさん
08/06/14 16:50:12
>>673
変数宣言の場所と変数を使う場所が離れているときは型チェックがあると助かるんだよ。
List<Integer>に int を突っ込むときはエラーを出してくれると助かるんだけどね。
678:仕様書無しさん
08/06/14 17:01:53
>676
>C#やRubyに慣れすぎてて、Javaに違和感を感じてるだけなんじゃないの？
逆にJavaに慣れすぎてしまってるんじゃ…
例えばList<Integer>の各要素に+1するのに、わざわざ変換するのは面倒だろ?
だからこそAutoboxingが導入されたんだろうが、>661の問題が発生するから
>672の言うような運用でカバーせざるを得なくなり、Autoboxingのメリットは無くなる。
更にAutoboxingに頼らないのなら、>677の言うように暗黙の変換は無い方が
規約を遵守させるのには便利だ。
要するに>662の言うように
>言語が特別扱いするクラスも増えて Java はどんどん複雑になっている。
679:仕様書無しさん
08/06/14 17:15:39
>>678
俺はC#, C++, Javaどれも実務で使ったことある上で
比較をしてるんだが…
まぁJavaが特別扱いするクラスが増えてるってのは認めるよ。
Stringの+=と、StringBufferのappendのメモリの扱いの違いとかもあるだろうし。
しかし、そのおかげで使用する側は簡潔なソースを素早く書けるようになっている事も事実。
うちではシステムはどんどんJavaに移行してるよ。
C#なんかはVisual Studioとかで使うとシステムが高級すぎて
逆に融通が利かなくなる事も多い。
リファクタリングとか環境に依存したりとかでね。
680:仕様書無しさん
08/06/14 18:21:42
>>661
この仕様がどうこう、と言うより、こういう一貫性を失うような仕様を
安易に取り入れるような、美学を持たない人たちが言語仕様を作っている
こと自体が嫌だなぁ。
もっとも、C++のauto_ptrの代入で、右辺値にも副作用がある、という
点でも、同種の嫌悪感を覚えたが。
(auto_ptrの場合は、無理に代入演算子をoverrideせず、明示的な名前の
クラス関数にすればよかったと思う)
まぁ美学だけじゃ食っていけないこともまた事実ですけど。
681:仕様書無しさん
08/06/14 19:40:59
Integerはもともと==で比較することを想定していないからね。
つまり、equalsを使わなかった方が悪いという事。
127までとそれ以降の挙動の違いは、
普通にパフォーマンスの都合でしょう。
確かソートのアルゴリズムも、内部で要素の数に応じて
バブルソートとクイックソートを使い分けていたと思う。
だから、その仕様を持ってJavaを悪く言うのは筋違いだと思う。
682:仕様書無しさん
08/06/14 21:48:17
速度だけの違いで済むならいいんだけどね。
Integer の場合、数値の比較なら equals() でもダメじゃないか?
Long と比較したら常に false になるから。
683:仕様書無しさん
08/06/14 22:08:47
>>682
だから基本型に直せって。
てか、ここでIntegerネタで粘着してるやつって何なんだ？
からくり分かってるんなら気をつけてコーディングすりゃいいだけの話だろ。
-128～127の件も、無駄なインスタンスが増えないように
工夫されて作られてるだけだろ。
Integer型と基本型が両方用意されているのも、
パフォーマンスの都合で基本型が残されているだけだろ。
Mapとかに入れる時用にラッパークラスも用意されているわけで。
こんな簡単なものの使い分けもできない馬鹿が、
これほどまでに多いのか？
こりゃ日本のプログラマの扱いがひどくなるのも当然だよ。
684:仕様書無しさん
08/06/14 22:11:16
>>680
一貫性がないって、
パフォーマンスのために、状況に応じて処理を変えるのは当然じゃないのか。
むしろ美学があると思えないようじゃ、あんさんの腕もたかが知れてるぞ。
685:684
08/06/14 22:27:05
なんか腹が立ってきたな…
686:仕様書無しさん
08/06/14 22:36:49
>>684
> むしろ美学があると思えないようじゃ、あんさんの腕もたかが知れてるぞ。
君は C++ に美学を感じているのかい?
687:684
08/06/14 23:13:54
>>686
なんだと！？
そりゃどういう意味だ。
688:仕様書無しさん
08/06/14 23:27:57
C++は作者自身がs いやなんでもない
689:仕様書無しさん
08/06/15 12:51:08
>>687
C++ の設計に美学を感じているのか、それとも美学を感じてないかという疑問。
俺も >>680 のように Java の設計には美学を感じていない。
Java と C++ の設計思想は間逆なので両方の設計に美学を感じることはないと思うが。
690:仕様書無しさん
08/06/15 14:41:01
なんかわかりやすい自演がいますね
691:仕様書無しさん
08/06/15 14:47:27
漏れは極力makeの時点で不具合を検出できるか、
極力短い時間で書る（テストにより多く時間を割ける）のが
美学だと思うんだが。
その点Javaは中途半端だと感じた。
692:仕様書無しさん
08/06/15 15:22:15
>>689
間逆ぅ？どこが？
同じオブジェクト指向だろ、いみわかんね。
>>691
中途半端どころか、
Javaは開発環境もテスト環境もかなり整っている言語なんだが。
693:仕様書無しさん
08/06/15 15:23:39
てか、C++がmakeの時点で不具合を検出できるのなら、
Javaのeclipseの場合はコーディングしたそばから不具合検出できるがな。
694:仕様書無しさん
08/06/15 15:38:52
「eclipseが優れている」だったらJavaに拘らなくても良い気ガス
695:仕様書無しさん
08/06/15 15:47:21
＞間逆ぅ？どこが？
＞同じオブジェクト指向だろ、いみわかんね。
レクサスとダイハツは設計思想が間逆ぅ？どこが？
同じ四輪自家用自動車だろ、いみわかんね。
・・・と同じくらい、あなたの発言は滑稽ですが。
696:仕様書無しさん
08/06/15 16:00:34
eclipseでJavaしか使ったことがない新人なんですよ。
JVMすら分かってないような厨房です
697:仕様書無しさん
08/06/15 16:14:57
>>694
確かにほかの言語でもeclipseは使えるが、
Javaほどはどれもしっかりしてない。
>>695-696
はいはい、根拠を言えないで煽ることしかできない馬鹿は黙っててくださいね。
698:仕様書無しさん
08/06/15 16:22:09
>>694
俺はC++のmakeの利点に対して、
Javaのeclipseの利点を出しただけなんだがな。
何でそれが「Javaの利点 = eclipseが優れている」になっちゃうのよ。
お前の論理回路大丈夫か？
699:仕様書無しさん
08/06/15 17:12:29
ところでeclipseはIntegerを==で比較したら警告してくれるの?
700:仕様書無しさん
08/06/15 17:26:18
どうだっけ？
FindBugs (プラグイン)で String の == は警告してくれた記憶あるけど
701:仕様書無しさん
08/06/15 17:39:15
どうでもいいけどInteger厨は消えろｸｽﾞ
702:仕様書無しさん
08/06/15 18:16:15
>>697
Java と C++ の設計思想の違いが知りたければ '94 年ぐらいに書かれた
D&E の 4章「C++ 言語の設計ルール」あたりを読んでみなよ。
面白いくらいに Java と反対だから。
第一 Java は C++ を批判する形で出てきただろ。
703:仕様書無しさん
08/06/15 18:34:41
>>701
同意
Integerではまるような低レベルはさっさと消えろよ。
つーか、まだいたのかよ。
704:仕様書無しさん
08/06/15 18:38:33
>>690
自作自演呼ばわりかよ。
ちなみに俺も Integer 厨だぞ。
705:仕様書無しさん
08/06/15 21:06:42
>>704
消えろ。
706:699
08/06/15 21:29:25
とりあえず反応を見る限りでは指摘してくれないんだろうねw
では消えます。
707:仕様書無しさん
08/06/15 23:44:09
Javaってデストラクタないんだっけ？
708:仕様書無しさん
08/06/16 00:47:43
>>707
URLﾘﾝｸ(www.bohyoh.com)
709:仕様書無しさん
08/06/16 01:08:19
おいおいw
ファイルとかスレッドとか、コンストラクタ/デストラクタで管理したいリソースは
他にもあるだろうに。
710:仕様書無しさん
08/06/16 01:39:16
IDisposable って持ってなかったっけ?
711:仕様書無しさん
08/06/16 07:49:33
>>710
それはドットネット。
Javaだとファイナライザがあるけど、すぐ呼ばれる保証は無い。
712:仕様書無しさん
08/06/16 12:43:43
確かJava(JVM)のファイナライザは最終的に呼ばれる保証もなかったんじゃない?
713:仕様書無しさん
08/06/16 21:02:14
ここで「デストラクタが無くてもなんとかなる」と反論が来そうだな。
714:仕様書無しさん
08/06/16 21:30:41
>>713
いや、総合的にはJavaが優れていると思うが、
C++のデストラクタは確かに便利だ。
715:仕様書無しさん
08/06/16 23:55:25
C++だけじゃなくてC#、PHP、Python辺りにもあるよ。
Rubyは無いけど代わりにクロージャブロックというものがある。
参考：
URLﾘﾝｸ(ja.wikipedia.org)
716:仕様書無しさん
08/06/17 00:06:31
C#でファイナライザは滅多に使わないだろ
むしろオブジェクトの生滅を制御できない言語で
ファイナライザに依存する処理を書くほうがアホ
717:仕様書無しさん
08/06/17 01:13:53
リソースの所有権を持っているオブジェクトがそのリソースの後処理をするべきで
try-finally でクライアント側がリソースの後処理をしなければいけないというのは
オブジェクト指向言語とは思えないね。
718:仕様書無しさん
08/06/17 01:31:24
道具に振り回されてる厨房はもっとたくさんの言語に触れて見聞を広めなさい
719:仕様書無しさん
08/06/17 16:36:22
まぁ、デストラクタなくても代用手段はいくらでもあるし、
困ったことはないけどね。
720:仕様書無しさん
08/06/18 01:33:00
Javaって const ないんだっけ？
721:仕様書無しさん
08/06/18 02:20:42
static final
722:仕様書無しさん
08/06/18 07:42:07
オブジェクトの寿命を管理する必要があるシビアな処理にはC++
業務系などの比較的緩い処理にはJAVA
特にイベント駆動アプリの場合
処理が走るタイミングがユーザーの操作時に局所化されるため
ガベージコレクションによる遅延も問題ではなくなる
723:仕様書無しさん
08/06/18 13:25:23
>>721
final は変数の初期化後にその変数への代入操作を禁止するだけじゃないか?
>>722
マウスドラッグ操作のときはカクッと止まってイラッとする。
基本的にアニメーション系は同じ問題が起きる。
724:使用書無しさん
08/06/21 22:17:16
javaで帳票設計ツール(URLﾘﾝｸ(jdrafter.sakura.ne.jp))を作ったんだが、結構使える。開発には4ヶ月ほどかかったが、javaの豊富なAPIとガベージコレクターのおかげで割りとスムーズに開発できた。
これをC++で作ろうとすると、細かい部分について一から作らなければならないし、あとメモリーリークやオブジェクトの管理やら貧乏くさい作業が増えるため、何年かかるかわからん。
どっちが優れているかは好みの問題だけど、２者択一なら俺は間違いなくJavawを選ぶな。
725:仕様書無しさん
08/06/22 04:19:06
>>724
なかなかよさそうじゃないですか
726:仕様書無しさん
08/06/22 12:33:27
今の Java のジェネリクスはこの時よりまともになっているかな?
「Java Generics ～ C++ template との比較 ～」
URLﾘﾝｸ(www.mamezou.net)
727:仕様書無しさん
08/06/22 13:50:23
Java・・・優れた言語
C++・・・優れた人が使う言語
728:使用書無しさん
08/06/22 18:36:16
>>725
よかったら使ってね。
729:仕様書無しさん
08/06/22 20:12:13
初心者から中級者ってどこで判断するんだ
開発経験年数？
730:仕様書無しさん
08/06/22 22:10:57
ガベージは無いだろガベージは
garbageなんだから
731:仕様書無しさん
08/06/23 14:08:03
ガルバゲと読めと？
732:仕様書無しさん
08/06/23 21:05:28
発音はこちらでﾄﾞｿﾞｰ
URLﾘﾝｸ(dictionary.goo.ne.jp)
733:使用書無しさん
08/06/23 23:07:00
ぼんくらjavafreekのみなさん
くやしかったら URLﾘﾝｸ(jdrafter.sakura.ne.jp)
に匹敵するプログラム作ってねばか
734:使用書無しさん
08/06/23 23:14:35
ぼんくらc++ふりーくのみなさん
くやしかったら URLﾘﾝｸ(jdrafter.sakura.ne.jp)
に匹敵するプログラム作ってねばか
735:仕様書無しさん
08/06/24 00:53:59
ねばか って何だ?
736:仕様書無しさん
08/06/25 00:48:49
C++って、教科書に載ってる以上の勉強がたくさん必要だよな。
独特の規約というか…
それを分かってなくて作る奴もいるのが頭痛い
737:仕様書無しさん
08/06/25 01:09:25
C++の時代はもうすぐ終わる
738:仕様書無しさん
08/06/25 01:27:10
最初から来ていない
739:仕様書無しさん
08/06/25 01:36:22
これから来る
740:仕様書無しさん
08/06/25 01:45:41
まぁようやくコンパイラがまともになってきた事だしね。
テンプレ駆使したライブラリもぼちぼち出揃ってきたし。
741:仕様書無しさん
08/06/25 02:06:35
>>736
お約束のような気がするけど、それはC++に限ったことじゃないぞ。
たしかに、C++は特にまともなコードを書くにあたっての要求が高いほうだとは思うけど。
742:仕様書無しさん
08/06/27 00:41:39
Java書くようになったらもうC++書くのが面倒くさいよ。
状況が書くことを求められる時にだけC++も使う気でいたいと。
743:仕様書無しさん
08/06/27 02:16:19
やる夫で学ぶJRuby最適化
URLﾘﾝｸ(recompile.net)
どうあがいてもJavaに任せられん部分もあると思うんだ。
744:使用書無しさん
08/06/27 21:03:09
>>743 やる夫 やられる妻