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 やる夫 やられる妻
745:仕様書無しさん
08/06/28 07:03:13
C++で受けると泥臭い仕事ばかりな気がするよ
746:仕様書無しさん
08/06/28 07:12:44
個人で趣味で組んでるときはC++の方が楽しいよ
747:仕様書無しさん
08/07/03 23:21:10
エディターとコマンドプロンプトでJavaを修行してたころ、省略形が欲しいとよく思ってました。
つまり、mainメソッドをmain（default）とか、newの後のコンストラクタが同じ型なら（）だけ書いて終わらせるような省略。
今は家でもnetbeans使ってるため、もうそんな事は思わないけど。
その点C++って面倒でも書く理由は納得できたかな。
748:仕様書無しさん
08/07/04 00:28:41
>>747
俺はJavaのソース書くときにテキストエディタは使わないけど、お前の言ってるレベルのことは
省略文字列の登録だとか単語補完みたいなエディタの機能で十分カバーできるだろ。
749:仕様書無しさん
08/07/04 00:40:52
省略形は下手な使い方すると読みにくくなる要因にしかならないからなあ
750:使用書無しさん
08/07/05 16:29:33
>>747 テキストエディタ使わずにソース書けるのか? IDEだって
組み込みのテキストエディタだがな..
と突っ込んでみる。
751:仕様書無しさん
08/07/05 17:01:11
バイナリエディタでソース書いてます
752:仕様書無しさん
08/07/05 17:12:01
>>751
ソースの意味失点の過渡
753:仕様書無しさん
08/07/05 17:17:21
バイナリエディタでテキストファイルを作ればいいのでは？
754:使用書無しさん
08/07/05 17:35:23
>>751頭をわって、脳の中身をみてみたい。
755:仕様書無しさん
08/07/05 23:56:17
バイナリエディタならclassファイルやjarを作ってもいいんじゃない。
756:仕様書無しさん
08/07/28 02:03:08
全部！全部！
757:仕様書無しさん
08/11/11 11:22:09
Javaに決まってんだろ
758:仕様書無しさん
08/11/13 00:02:14
JavaかC++かどちらかが優れていると断言する奴よりはどっちの言語も優れている
759:仕様書無しさん
08/11/13 00:20:19
は？
760:仕様書無しさん
08/11/13 00:42:31
>>759
Java厨「Javaが優秀に決まってるだろ」
C++厨「C++が優秀に決まってるだろ」
>>758「どっちもお前らよりは優秀だよ」
普通のPG「いいからお前ら仕事しろよ」
761:仕様書無しさん
08/11/13 01:03:24
人間と言語を比べる意味がわからんわけだが
762:仕様書無しさん
08/11/13 20:42:18
俺にはそもそも別の言語を比べる意味からわからんがな。
用途が違うんだから比べる事に意味も答えも無いだろ。
763:仕様書無しさん
08/11/13 20:56:53
言語仕様としてはJavaが優れている。
それにC++はOOPLとしても消極的杉。
764:仕様書無しさん
08/11/13 22:06:12
Javaも色々欠点はあるが、CGで全て許せる。
765:仕様書無しさん
08/11/13 22:17:27
普通に業務用に使うならＪＡＶＡ、Ｃ＋＋はマニア向けと思う。
ポインタ操作はややこしくてめんどくさいけど、マニアなら外せない。
766:仕様書無しさん
08/11/18 21:49:28
ポインタを知らずに参照の仕組みやら何やらを理解する方が難しい希ガス。
767:仕様書無しさん
08/11/22 23:37:01
URLﾘﾝｸ(www.hotdocs.jp)
同等です
768:仕様書無しさん
08/11/23 00:13:35
OS のサービスはC言語で提供さることが多いので、できることが多いのは C++。
ネイティブコードを実行するので、実行速度がはC＋＋。
でもそういうことをしたかったら、開発者がお勉強しなきゃいかんし、
C++は仕様がグダグダなので学習効率は悪い。
本来の目的からそれてマニアックな仕様を楽しむ心がないとC＋＋はきつい。
769:仕様書無しさん
08/11/23 07:47:25
Javaのほうが需要が多いといわれるが、
市場規模のトップシェアが組み込みである以上、CかC++のほうが需要は多い。
ただ、メモリ要領の制限からそのレベルまで配慮できるエンジニアが減少している今、結局Java使いのほうが多いように見えてしまうだけ
770:仕様書無しさん
08/11/23 10:21:07
沖縄に外国人３０００万人受け入れ計画
URLﾘﾝｸ(life.bbs.thebbs.jp)
こんな法案が可決したら日本は破綻する
(ちなみに東京の人口は1280万人)
選挙権がある方は良く考えて投票してください
771:仕様書無しさん
08/11/23 22:21:18
言語は、優劣つけるものではない。問題は、それを使う者。
Javaしか使えない者は腐るほどたくさんいる。
C++しか使えない者はきわめて少ない。
772:仕様書無しさん
08/11/25 16:13:19
多倍長整数の素因数分解のプログラムをＣ＋＋で書いた。
Ｃ＋＋のオペレーターオーバーロードは便利。
計算に１週間以上かかった。Java で書いたら何ヶ月かかるのだろう。
773:仕様書無しさん
08/11/26 14:58:58
瞬時に計算するアプレットを見たことがあるぞｗ
774:仕様書無しさん
08/11/30 12:15:36
所詮はGMP由来のラッパーじゃねぇかPHPみたいに。
772は車輪の開発したけど学習的には凄い意味があったと思う。
俺も昔はtemplateの学習を兼ねてstd::vectorやらstd::listを再開発してみたクチ。
775:仕様書無しさん
08/11/30 15:52:24
論ずるまでもないJAVAほど美しいオブジェクト指向言語はない。C++は多重継承ぐらいしか長所ない
776:仕様書無しさん
08/11/30 16:03:36
多重継承が長所ｗ
777:仕様書無しさん
08/11/30 23:37:04
まったくの初心者は何から学ぶべきですか？
778:仕様書無しさん
08/11/30 23:40:50
何から学ぶべきか自分で調べることを学ぶべきです
779:仕様書無しさん
08/12/01 00:03:31
(´･ω･｀)頑張ります
780:仕様書無しさん
08/12/01 08:50:57
JAVAは一般業務向けというか、新卒私大文系エンジニアに任せて、
自分は専門的にソフトウェアを掘り下げていきたいのでＣ＋＋。
781:仕様書無しさん
08/12/01 21:58:31
>>777
初心者はC言語でしょ
機械語に近い言語だからメモリの気持ちを勉強しやすい
782:仕様書無しさん
08/12/01 22:58:38
メモリの気持ちだってﾌﾟﾌﾟ
これだからヲタってきんもーっ☆
783:仕様書無しさん
08/12/01 23:04:42
メモリたん(*´Д`)ﾊｧﾊｧ
784:仕様書無しさん
08/12/01 23:09:35
俺はそろそろ初心者にC言語をススメル時代じゃなくなりつつあると思う
しばらくは、Cのソースが読めたほうが良い事のほうが多いから
使わないにしても覚えとく価値は（まだ）あるけど、、
C以外をすすめれば、挫折する人数は、1/3くらいにはなるんじゃないかと。
と、数年後には正論になってるであろうレスをかましてやる
785:仕様書無しさん
08/12/01 23:24:51
と、Cで挫折した>>784が申しております。
786:仕様書無しさん
08/12/02 09:37:47
初心者は C++ （STL含む）でいいよ。Cから入るより入りやすい。
しかも実用的。C++ 全てを知る必要は無いから、とりあえず必要なものだけ。
787:仕様書無しさん
08/12/02 13:21:17
いやあ、まずCで構造化プログラミングを覚えさせた方が良い。
いきなりC++とか与えても一つのクラスに全てをぶち込んだようなものを作ってくれる。
788:仕様書無しさん
08/12/02 14:10:18
それ、逆。
デザインに関しては最初（というか、今知ってるもの）に覚えたものから考え始めるので、
そんなことしたらC++でC言語関数構造化プログラミングやってくれるよ。
はじめにC++のきれいなデザイン（←C++の場合余計な文法や古い文法がジャマになりがちだが）を見せれば、それを土台に考えてデザインしてく。
789:仕様書無しさん
08/12/02 14:31:47
じゃあ、Javaでいいんでないの？
790:仕様書無しさん
08/12/02 14:44:36
組み込みソフトの0$部分だとコールバック関数はC/C++言語しか許さなかったり、
やっぱ、避けれない部分もあるし。
ウェブ～JavaによるGUIでもおｋなアプリ限定ならJavaでも良いんだけどさあ。
791:仕様書無しさん
08/12/02 16:09:21
>>789
Java よりも C++ の方が C も実質含んでるし、後の事考えると進める方向が
多いように思うんだよね。C++ でも STL 使えば扱いやすいし。boost や
過去の遺産の素晴らしいライブラリも多い。
C++ で始める事の問題は C も含んでるから言語仕様が冗長で、全部始めから
しようとすると圧倒される。Java の良いところは標準で GUI をすぐに使える
ところと、強制的にOOP 的な coding をさせられるところかな。
両方使ってるけど、java は窮屈でお仕着せがましく感じる事が多い。
C++ の方が自由に発想できる。
792:仕様書無しさん
08/12/02 23:20:21
Javaでデスクトップの求人があるなら、いいけど、、皆無だもんな～。C+＋はVCがあるから一応な・・どっちもかわらねえか？
793:仕様書無しさん
08/12/03 00:15:54
東海地方在住者なら、
C/C++ > SQL > Java >>> 他の言語
794:仕様書無しさん
08/12/04 21:38:39
【サンタクロース、酒気帯びトナカイ運用罪での逮捕に、ﾏｼﾞ逆切れｗ（動画有り）】(ZDNet)
URLﾘﾝｸ(builder.japan.zdnet.com)
795:mild7070
08/12/05 06:41:55
javaを始めて思った
C++とかCを先にやっときゃよかったなーと
URLﾘﾝｸ(mild7070.livedoor.biz)
796:仕様書無しさん
08/12/07 10:06:34
C++とかCをやって、Ｊａｖａに移ったけど、
Ｃはなーーんにも覚えてない。
797:仕様書無しさん
08/12/07 18:16:30
>>788
そりゃ嘘だ。
消化不良おこして中途半端に使った挙げ句カオスになるのがオチ。
初心者にデザインパターンの選択なんかできるわけがない。
背景を持たないんだから。
798:仕様書無しさん
08/12/07 20:20:44
背景を持たないっての、なんとなくわかるな。
非OOPで必死こいてツライ思いして歯がゆい思いしてこそ、
OOPなりデザパタのうまみが分かるってもの。
799:仕様書無しさん
08/12/08 04:08:46
c++にデータグリッドビューが無かったと知った時の絶望感
800:仕様書無しさん
08/12/08 08:37:52
>>797
デザインパターンの話じゃねーだろ
早とちりしてんじゃねえよハゲ
801:仕様書無しさん
08/12/08 09:07:54
>初心者にデザインパターンの選択なんかできるわけがない。
良いデザインをできるようになるには、良いデザインを見ることじゃまいか。
良いプログラマであっても古いプログラマであるためデザパタ無視してる人も居るとオモ。
自分の作り出した我流パターンで事足りて、書いた本人には明確にどこの処理はどこの箇所と分かる、みたいな。
802:仕様書無しさん
08/12/08 13:14:01
意図がわかるだけ我流や詰め込みよりは遥かにマシ
803:仕様書無しさん
08/12/08 13:18:10
ちがうっちゅーに
我流・・・本人にのみ意図が分かる（間違ったデザインだったとしても、本人も他人も気付かず延々とそれが続けられる）
デザパタ・・・他人にも意図が分かる（間違ったパターンをあてがった場合にも、他人がそれに気づく）
804:仕様書無しさん
08/12/08 13:20:48
例えば複数インスタンスありえるものを間違えてシングルトンにした場合：
デザパタ→チェックする人「これシングルトンにしたら複数インスタンスにできないでしょ？直して」
我流→本人「いや、私のこの構造体は１つと決めてるんです。他の部分、これで動くように直して下さい」
805:仕様書無しさん
08/12/08 18:38:31
そういう展開、あるあるｗ
806:仕様書無しさん
08/12/08 21:49:29
javaとc++????
くらべるんならjavaとc#なんじゃないの？
807:仕様書無しさん
08/12/09 13:14:09
初心者は何が正解であるかを理解出来ない。
指摘されても何をどう直すべきかわからない。
808:仕様書無しさん
08/12/09 13:14:37
よって自分で消化できた分だけを我流でぶん回す事になる。
809:仕様書無しさん
08/12/09 13:25:35
初心者はコピペでぶん回す。我流ソースを初心者にいじらせたら最悪。
デザパタが見えるソースを初心者にいじらせて間違ったら間違いを指摘する。これ最強。
810:仕様書無しさん
08/12/09 13:28:16
デザパタに限らずクラスってのが良いんだよね。
このクラスにこのメソッド名、中の動作は正しい・間違いが見えるんだよね。
それが、経験長いだけのＣ言語魔の我流ソースって関数ｲﾊﾟｰｲある中に次に何足したら正しい・間違いが分かり難いんだよね。
クラス＆デザパタ適用ソースなら、次に何かを足したり引いたりしたとき、それが正しい・間違いが丸見えｗ
811:仕様書無しさん
08/12/09 22:55:58
>>810
Cだから見通しが悪いという事は無い。
812:仕様書無しさん
08/12/10 08:41:01
>>811
クラスが使えないコードは見通し悪い。
だから世の中クラスライブラリ一色になっちゃったｗｗｗ
813:仕様書無しさん
08/12/10 08:46:17
Javaプログラマには糞設計な糞コード書く奴が多すぎる。
そしてどんな糞コードでも動いてる以上、捨てることを躊躇させる。
間違いが見えることと、直せることは直結しないのだ。
814:仕様書無しさん
08/12/10 09:07:02
しかしながら、間違いが見えないことと、直せないことは直結するｗｗｗｗｗ
815:仕様書無しさん
08/12/10 10:47:04
なに草はやしてんの？
816:仕様書無しさん
08/12/10 11:06:46
名前空間は欲しいね
foo_bar_baz_hoge_fuga_moge_moga
みたいな非常に見難い識別子がいっぱいでてくるから
817:仕様書無しさん
08/12/10 11:58:23
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ | .＿＿ いらないＣ言語を
| | | | |＼＿＼ 窓から
| | ∧＿∧ | | | |.◎.｜ 投げ捨てろ
| |（ ´∀｀）つ ミ | | |.： ｜
| |/ ⊃ ﾉ | | .＼|.≡.｜
￣￣￣￣'￣￣￣￣ | ￣
818:仕様書無しさん
08/12/10 16:41:59
ちょｗおまｗｗそれパソコンｗ
819:仕様書無しさん
08/12/11 20:16:00
>>817
そういるルールだからです。
「ぬーやる」バーガーはしっていますか？
820:仕様書無しさん
08/12/18 02:01:46
しかしC++はリンカやローダが追いついてないのがなんとも。
低レベルな部分に関わりたくない香具師には.NETかJavaをお勧めするなァ。
逆にその辺にwktkするようなMな香具師にはC++がお勧め。
821:仕様書無しさん
08/12/18 17:11:55
プログラミングの思想については、
Cで組まれたプログラムを修正（特に構造化プログラミングが叫ばれる前の）
↓
gotoで涙目になる。
↓
プログラミング診断室のような最低限のマナー本を読む。納得する。
↓
新規、修正等、最低限のマナーに気をつけて組みようにする。古いプログラムの修正では愚痴るようになるｗ
↓
C++にステップアップする。クラスの概念がうまれた理由が肌でわかる。
という風にステップを踏んだやつは、結局どんな言語でも綺麗に組む。
822:仕様書無しさん
08/12/18 17:46:24
ダウト！
＞という風にステップを踏んだやつは
これが少なくて、C++を”ベターC”として使うヤシが大多数という結果ｗ
823:仕様書無しさん
08/12/18 18:22:53
はぁ？何言ってんのお前？
824:仕様書無しさん
08/12/18 18:43:36
BASICでもんどりうつ。
Cで清清しい気持ちになる。
Javaで優しい気持ちになる。
C++で清清しい気持ちになる。
C#でイラッとする。
825:仕様書無しさん
08/12/18 22:46:16
Javaはエコじゃないから。
826:仕様書無しさん
08/12/19 16:16:55
>>824
C#はインデクサとかdelegateとか使い込むと、
Javaより痒いところに手が届く感があって悪くないよ
827:仕様書無しさん
08/12/21 04:38:08
Javaは標準APIと仕様を覚えるのが一苦労だぜ・・・
Javaに限らずプログラミング言語の仕様って何か作らないと絶対覚えないんだが、
何か作るには仕様を覚えないと無理という「鶏が先か卵が先か」的な問題で頭がイタイ。
828:仕様書無しさん
08/12/21 15:59:07
>>827
道具として使うのなら別に何使ってもいいんじゃないかな
言語はプログラマの力の源ですよ
829:仕様書無しさん
08/12/21 17:09:31
プログラマの力の源はコーヒー。
830:仕様書無しさん
08/12/22 02:14:35
>829
力の源って言うより、燃費向上グッズ。
タバコやガム、タブレットもこの類かと。
831:仕様書無しさん
08/12/23 21:24:56
大学での課題を実装するならどっちが良いですか？
832:仕様書無しさん
08/12/23 21:55:10
自分の苦手とする方で。
833:仕様書無しさん
08/12/24 01:54:23
ホントどうでもいいスレたてんなよヴォケ
Javaしか使えないプログラマは現場で役立たないけど
C++しか使えないプログラマなら、現場で使える。
（もちろんboostでマルチパラダイムしろとは言わないがSTLってなんですかとか言わないレベルね。）
ただ何故あなたはC++しか使えないのですかと問い詰めておく必要はある
834:仕様書無しさん
08/12/24 16:49:58
大したことないのに偉そうな奴ばっかり
835:仕様書無しさん
08/12/24 16:53:07
ヒント： お前も
836:仕様書無しさん
08/12/24 16:59:32
両方やりゃいいじゃん
片方マスターしたら死ぬわけじゃないんだし。C++の方が簡単ならそっちから入ればいいし
837:仕様書無しさん
08/12/24 18:02:04
仕事の種類によってどちらが優れているかは変化する。
両方半端に知ってるより、かたっぽをめちゃめちゃ知ってる人のほうが優れている。
と書いたら終了になるのかな？
>>833
現場ってどこですか？
>>836
ヒント：時間は有限 お前の若さも有限
838:仕様書無しさん
08/12/24 18:15:59
ヒント： C++だけで事足りるｗ
839:仕様書無しさん
08/12/24 18:40:51
javaを極めよう
俺２ちゃんねら嫌いだし
840:仕様書無しさん
08/12/25 09:28:59
OOPを学びたいのならJava。
OOPに消極的でいいのならC++。
841:仕様書無しさん
08/12/25 09:41:18
OOP的には、JavaもC++もクラスベースOOPで等価。
842:仕様書無しさん
08/12/27 15:07:04
OOPは組み方の流儀の一つに過ぎない
843:仕様書無しさん
08/12/30 00:24:52
そびえ立つ糞を眺めるならC++
そびえ立つ糞になるならJava
844:仕様書無しさん
08/12/30 16:21:36
NullPointerException
845:仕様書無しさん
08/12/31 01:35:38
ところでJavaの（別にJavaに限らないけど）クロスプラットフォームのメリットってあるの？
846:仕様書無しさん
09/01/01 14:00:22
>>845
昔やった案件では、そこそこメリットはあったけどね
確かに開発はwindows上で出来るし、楽は楽だったけど
でも環境による微妙な挙動の違いで、実働環境で原因がよく解らないバグが出たりして、
面倒は面倒だったな
847:仕様書無しさん
09/01/01 19:03:16
Java＝AOPが主流なのを知らんのはC系の人間だろうけど、
DIコンテナ？何それ？なJavaプログラマ＝糞 というのが正解なのですよ。
848:仕様書無しさん
09/01/01 20:27:05
DIコンテナは何使うんだろうね
849:仕様書無しさん
09/01/01 20:42:42
>>847
オブジェクト指向？？
なにそれ？なC++プログラマのほうが数倍クソだと思う。
C++も一応オブジェクト指向言語だが、
いまいち分かってないC++プログラマが多すぎる印象がある。
850:仕様書無しさん
09/01/01 21:14:27
C++のダイアモンド継承使ったデザインパターンってあるん？
もれはGoFのデザインパターンとかJ2EEパターンとかしかしらんけど
仮想関数とか二重継承使うと設計難しいそうだと感じるのよ。
本当にC++の仕様で設計できるやつっているん？教えて、C++の達人さん。
851:仕様書無しさん
09/01/01 21:35:02
てかさ、いまどきC++にメリットなんてあるか？
Javaのクロスプラットフォームみたいに、
Windows上で開発・テストして、その後Linux, Unixで運用するとか出来ないだろ。
一回Javaで開発してみなよ。もうC++には戻れないから。
852:仕様書無しさん
09/01/01 21:38:07
クラスプラットフォームなんてのは幻想だ。
まともに動きやしねえ。
853:仕様書無しさん
09/01/01 22:51:43
>>852
具体的には？
うちでは普通に使っているけど、
なんら問題なく運用回ってるよ。
Windows上でうまく行ってLinuxで不可能なことって何だ？
854:仕様書無しさん
09/01/01 23:03:32
そのうちまともに動くようになるんじゃないの。
855:仕様書無しさん
09/01/02 11:07:07
Java製ソフト作るとき、逆コンパイル対策とかやってますか？
856:仕様書無しさん
09/01/02 11:45:52
逆コンパイルしても読む気が失せるくらい汚いコード書くようにしてる
857:仕様書無しさん
09/01/02 14:28:56
ms-officeすら綺麗にパクれないjavaは糞
858:仕様書無しさん
09/01/02 15:00:36
ms-officeってN88BASICで作ってるんだよね
859:仕様書無しさん
09/01/02 17:39:25
>>856
さすがにそれじゃ自分の首しめるぞｗ
Javaは難読化ツールがあったはず。試したこと無いけど。
860:仕様書無しさん
09/01/02 18:11:46
>>851
ぎゃくにJavaの必要性あるか？
リソースをふんだんに使えるならRubyやらPythonとかのOOPLで十分だし、
早さが必要なら依然C++。JITをメリットに掲げたところでLLVMや.Netの出現で
最早Javaの特権ではなくなったわけだし。
そういや、遂にC++で回路を動作合成できるようになったな。
マルチプラットフォームを謳うJavaがこの地に足をつける日はいつになるのやら。
861:仕様書無しさん
09/01/02 18:33:17
こういう信者ホイホイみたいなスレは
ダラダラと伸びるね
862:仕様書無しさん
09/01/02 18:41:34
>>860
HibernateやiBatisなどのO/Rマッピングフレームワーク、
strutsやSpring、seaser2などのフレームワークなど新米PGが開発しても
そこそこまともなアプリになる。
Java関連の入門書、専門書は他言語に比べて圧倒的に多く独学でも勉強しやすい。
C++みたいに難解な言語ではない。
これだけでも十分必要な開発言語でしょｗ
そりゃ極めりゃC++のほうが実行速度が速いしいいのかもしれんが
頭のいいやつにしかできん言語なんぞ廃れるのは火を見るより明らかなのは当然です。
863:仕様書無しさん
09/01/02 22:12:34
>>851
仕事は、環境もセットで納品するからJavaでも良いんだよな
趣味ソフトは、Javaは配布すると環境の問題で動きませんとかうざいので
どうしても展開すれば即起動可能に出来るC/C++になるかな
.netも人によってはフレームワーク入ってないとかあるし
スクリプトも結局インタプリタ入れさせないといかんし
864:仕様書無しさん
09/01/02 23:36:13
>>851
unixしらねーｱﾎは黙ってれば？
unixでc++ならソースレベルでクロスプラットフォームだっつーの
865:仕様書無しさん
09/01/03 00:12:27
>>864
unixとwindowsじゃ開発スピードが全然違うよ。
>>860
Javaもそんなに遅くは無いぞ。
速さが必要だったとしても、C++の開発の非効率性から考えると、
割が合わないことが多い。
866:仕様書無しさん
09/01/03 00:16:33
>>863
趣味ソフトのほうがむしろJavaでは？
仕事の場合どうしてもパフォーマンス云々でC++を余儀なくされることはあるが、
趣味であれば容易に保守がしやすいJavaを選ぶのが賢明。
それに、環境の問題ごとき、適切なread me 入れれば特に問題は無いだろ。
>>855
してない。
というか、むしろ俺の場合オープンソースで配布してるからな。ｗ
難読化とか、そんな小細工しなくても、
著作権法という法律面で守られているから、特に神経質になる必要はないと思うけど。
867:仕様書無しさん
09/01/03 00:23:10
>>862
そういうことだね。
Javaはオープンで用意されているライブラリや、
設計やリバースエンジニアリングのツールとかが豊富なんだよな。
あとPGが学習するための資料や環境も十分にある。
こういった取っ付きやすさもJavaの強みだ。
868:仕様書無しさん
09/01/03 00:25:56
しかし趣味でもJavaやC++なんか書きたくないわー
869:仕様書無しさん
09/01/03 23:34:07
一番とっつきやすいのはVB.NET
870:仕様書無しさん
09/01/04 02:28:53
>866
著名なアプリを見る限りでは、個人製作のは圧倒的にC/C++が多いんだが。
Java製のはEclipseみたいに企業がバックについてるの以外ほぼ見かけない。
日本のWindows界隈に限った話だけど。
871:仕様書無しさん
09/01/04 15:35:42
>>862
だから速度いらねーならスクリプトでいいじゃん。
携帯電話とかは別としてスクリプトならマルチプラットフォームだし。
>>865
効率とはライブラリのことかな？まともに書いたコードのこしておけば大差さないだろ。
int main(void)
{
Model model;
Form view(model);
view.Visible(true);
}
872:８７１
09/01/04 15:41:58
間違えて書いてる最中に送信押してしまったOTL
>>865
効率とはライブラリのことかな？まともに書いたコードのこしておけば大差さないだろ。
int main(void)
{
Model model;
Form<Controler> view(model);
view.Visible(true);
return 0;
}
一回ライブラリ化してしまえばC++でGUI表示させるのもこんなもんだし。
特に分数とか超倍整数なんてJavaのほうがよっぽど効率悪いと思うが？
typedef Fraction<int> f;
f a=f(5,2)+f(10,3);
873:仕様書無しさん
09/01/04 17:43:09
>>871
JavaぐらいAPIが用意されてて統合開発環境が充実しているスクリプト言語教えてくれ。
速度いらない＝スクリプト の考え方はレベルが低いですよ。
874:仕様書無しさん
09/01/04 18:42:35
>>873
CPANとか触れたことあるか？
Shell Scriptは？#まぁ、こっちは状況で制限を喰らうことはあるが
あと、スクリプト系でIDEのありがたみを感じたことはない。
必要なところは言語機能が補完してくれるからね。
OO系ならRubyとか型いらずでめっさ楽。それでいて本当のポリモーフィズムが行える。
875:仕様書無しさん
09/01/04 19:00:28
本当のポリモーフィズム？
じゃあ、本当じゃないポリモーフィズムとは一体？
JavaぐらいAPIが用意されてて統合開発環境が充実しているスクリプトマダー？
876:仕様書無しさん
09/01/04 19:15:06
>>870
俺んとこの/usr/binをほじくったら、開発ツール以外でjavaはoperaだけだった。
ただし、シェルスクリプトとかとミックスしてるけどね。
あと、名前を聞いただけだがLimeWireってのもJava製らしいねぇ。
やっぱり個人レベルの有名どころは無いな。
877:仕様書無しさん
09/01/04 19:26:59
>>875
だからCPANとかあるだろうが。
そうでなくとも、PhytonとかRuby、Perlといった
メジャー言語はリポジトリを覗けばGUIからネットワークまで
操作できるライブラリが準備されてるってのに。
プラットフォームがUNIX系ならすべてのコマンドが関数と同じだし。
(関係ないがJavaのAPIって表現おかしくね？)
本当ポリモーフィズムじゃないってのはインターフェース等で
束縛されたポリモーフィズム。C++から続く型安全は保証されるかわりに
柔軟性が無い。もし似たような事をするなら1メソッドのインターフェース
を大量に作りそれを実装させるしかない。それでも記憶効率なんかは
言語機能として搭載されているものに比べ下がるけど
878:仕様書無しさん
09/01/04 20:03:40
> 本当ポリモーフィズムじゃないってのはインターフェース等で
> 束縛されたポリモーフィズム。
では、インターフェース等で束縛（？）されないポリモーフィズムが、
本当のポリモーフィズムだと？
ひょっとして、ダックタイピングと強い型付けの話をしてない？
それはポリモーフィズムじゃなく、単に型についての議論では？
本当のとそうでないのとのポリモーフィズムについての議論、
なんかどっかにソースある？ Smalltalk界隈とか？
ポリモーフィズムはどこまで行っても単にポリモーフィズムでは？
879:仕様書無しさん
09/01/04 21:11:39
議論に参加しようと思ったけど
ポリモーフィズムをまともに論じようと思えば圏論の知識が要るらしいから
勉強してからにします
880:仕様書無しさん
09/01/04 21:35:27
>>878
いい反応だねぇ。もっと具体的に言えばメッセージング。まぁ、
これを言うとRubyなんかも若干中途半端な言語ということになるけど。
感覚として完全なポリモーフィズムと言うと
Smalltalk>Objective-C、Javascript>Ruby、Python他OO系LL>>>>Java>C++
こんなかんじかな。C++もダックタイプはできるけど配列なんかじゃ生かせない。
Javaはライブラリを使えば近いことはできるけど言語機能であるのとは訳が違う
(それが有りならC++も有りだ
Objective-Cはメッセージングとしてかなりいい線を行っているがメッセージその物を
オブジェクトとしては扱えない。
881:865
09/01/05 20:13:34
>>871 >>872
それは趣味でプログラム書きたいときの話？
それだったら別に好きなほうで書けばいいじゃない。
俺が言ったのは、会社などの組織で使う場合の話ね。
>まともに書いたコードのこしておけば大差さないだろ。
>一回ライブラリ化してしまえばC++でGUI表示させるのもこんなもんだし。
オブジェクト指向なんだから一度モジュール化してしまえば使えるのは当然。
しかし、大規模なシステムになってくると、
そういうモジュールも属人的な部分が目立ち始めて保守性も悪くなる。
その点Javaであれば標準として備わっているものが多い。
例えば新しい人を雇った場合には、
前の同じようなフレームワークやライブラリを使った経験があれば、
すぐにその技術を活かしてもらうことができる。
882:仕様書無しさん
09/01/06 02:27:09
>873
クロスプラットホームの縛りが無いようなので、C#でも挙げとこうかw
ちなみ.NETはM$製であるせいかウケが悪いが、（漏れも眼中に無かった）
Javaの利点に加えてgccのように多言語対応、パフォーマンスもVB並(?)なんで
個人的には期待してる。
好みの言語で作ったライブラリを、対応言語・対応プラットホーム全てで共有できるというのは、
M$発祥であることを考慮しても、もっと評価されて良いと思うんだが。
883:仕様書無しさん
09/01/06 10:48:15
>>881
デファクトスタンダードなライブラリならC++の方が多いんだよチミ。
そもそも、標準ライブラリは最小限にして他で補うのがC++の指針だからね。
もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
ならご愁傷様としか言いようは無いけどねぇ。
あと、新規にライブラリ構築するならJavaだろうがC++だろうが他の言語だろうが
状況は変わらないだろ。優秀なアーキティクトやライブラリアン居るかいないかって
だけの事。
#とは言っても日本にゃ居なそうだけどナァ
884:仕様書無しさん
09/01/06 19:44:51
>>883
>もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
>ならご愁傷様としか言いようは無いけどねぇ。
まぁそういうこと。
システムには当然信頼性が求められるわけだが、
それにはサポートがきっちりされているかどうかも大切な一要素とされる。
もっとも俺はC++にJavaを超えるほどの良質なライブラリがあって、
Javaよりも手早くシステムの作成が可能だなんて思えないが。
仮に百歩譲ってそうだったとしても、
どうしても利益を求める組織は、
標準で用意されている機能が豊富なJavaを使いたがるだろうな。
885:仕様書無しさん
09/01/06 19:56:04
標準で、っていうところがポイントで、
Javadocで作られたあのびっしりとしたAPI 仕様、
あれが標準で用意されているのもでかいと思う。
886:仕様書無しさん
09/01/06 21:16:52
>>884
よくある経営者の流行り乗り。
金がある奴は何かうまくと聞くと
知りもしないのによく飛びつくw
ウチの取引先の管理職なんて
オブジェクト指向はGUIの様な
もんだと思ってる。
そりゃ、社員も青ざめるわな。
887:仕様書無しさん
09/01/06 21:37:59
>>886
？？？
全然違う話をしているな？？
俺はリスクの観点で話してるんだが。
要はシステムに不具合が発生したとき、
標準のを使っていると原因を特定しやすいし、責任とかもしっかりしてるだろ。
888:仕様書無しさん
09/01/06 22:00:01
あと、有名ライブラリよりも、
標準で用意されていたほうが、
スキルをどこでも活かせるというメリットがある。
標準で用意されていないと、
現場によって使っているライブラリ違ったら、
また学習しなおしだから、それだけ人件費がかかるということ。
889:仕様書無しさん
09/01/07 08:22:31
馬鹿が多い現場ではJAVAがいい
890:仕様書無しさん
09/01/07 17:48:48
>>889
Javaが良いって言うか…
まぁC++をバカに触らせるよりは、確かに問題は減るかもなｗ
891:仕様書無しさん
09/01/07 19:22:36
結論：どっちも優れている。状況に応じて使い分ければいい
892:仕様書無しさん
09/01/07 20:18:36
>>889
そういうこと。
バカが多い現場でJavaを使えば問題が減る。
優秀なやつが多い現場でJavaを使えばより開発がスムーズに行く。
どちらにせよJavaを使えば間違いなし。終了。
893:仕様書無しさん
09/01/07 20:22:57
でも、止めちゃイケナイものが入れ替え後に問題起こして止まってしまうのは
いつもJavaを採用したもの。
894:仕様書無しさん
09/01/07 20:52:33
>>893
意味が分からんｗ
たまたまだろ。
895:仕様書無しさん
09/01/08 07:02:53
去年トラブった某J○Bの基幹系システムってたしかJavaだったよね。
896:仕様書無しさん
09/01/08 11:33:50
>>893
その理論は無理があるｗ
C++で作ったって、止まるときゃ止まるｗ
897:仕様書無しさん
09/01/08 12:25:29
むしろC++のほうが（ｒｙ
898:仕様書無しさん
09/01/08 12:32:12
889に戻る
899:仕様書無しさん
09/01/08 17:04:39
Javaなら低コストかつ安全です＾＾v
ってJava厨がしつこいから入れ替えてみたらトラブル多発とか。
900:仕様書無しさん
09/01/08 17:15:05
IBMとスルガ銀行のやつがJAVAだっけ？
901:仕様書無しさん
09/01/08 23:34:36
Javaは軟派なイメージ
C++は硬派なイメージ
902:仕様書無しさん
09/01/09 01:58:28
>>899
>Javaなら低コストかつ安全です＾＾v
そりゃうそだ。Javaの開発は決して安くはない。
903:仕様書無しさん
09/01/09 03:34:38
Ｃ＋＋が先にできて．．だから、その改良型だよＪＡＶＡは。
Ｃ＋＋がＦ１カーとすれば、ＪＡＶＡは日産ＧＴ－Ｒのようなもの。
プロの君は、どっちを使う？ もう分かったよね？
904:仕様書無しさん
09/01/09 07:26:07
なら例えばC#はさらに改良されたと言えるのではないかい？
あるいはDだってあるぞ。
905:仕様書無しさん
09/01/09 21:50:38
C/C++はドライバや中小規模のアプリを作成するのには向いているが、
大規模なアプリやサービス構築するのには不向き。
Javaは逆に大～中規模のアプリやサービスには向いてるが、
小規模なアプリやドライバとかには向かない。
例えるなら戦術に長けるC/C++、戦略に長けるJavaと言った所。
906:仕様書無しさん
09/01/09 22:18:22
>>905
君の知る大規模とは何だい？
まさか、銀行システム程度の規模じゃないよね。
各種ミドルウェアは何で構成されているか知ってるかい？
DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。
どれもCかC++。
アプリケーションレベルでもExcel、Word、統合開発環境。
本当に大規模なプログラムは大抵CかC++になるんだよ。
2000年からリリースされて早9年。なんで、JavaでEclipseや
Opera、OOoぐらいしか著名アプリが作成されていないか解るかい？
Javaの謳い文句が現場のメリットとして形を成してないんだよ。
907:仕様書無しさん
09/01/09 22:21:06
このスレ意味なくね？
908:仕様書無しさん
09/01/09 22:44:55
本当に優秀なのはどっちも使えるプログラマってことだよな
909:仕様書無しさん
09/01/09 22:52:50
>>906
ムキになってるところすまんが、規模って案件の規模のことじゃね？
銀行の基幹系みたいに何百人が開発に関わるような規模だと
使える技術者を集めやすいかとか、低コスト短期間でそれなりの
クオリティのものを出せるかで使える言語も変わってくるだろ。
そりゃコストに制限がなければ優秀なC++プログラマでも集めて
好きなだけオーバーエンジニアリングしてりゃいいけどさ。
910:仕様書無しさん
09/01/09 23:10:29
>>906
>>905じゃないけどよ、
>2000年からリリースされて早9年。
>著名アプリが作成されていないか解るかい？
そりゃ古い有名アプリはC/C++が主流の頃作られたんだから、
Java使われてなくて当たり前だろｗ
分かってないのお前だけじゃないのか？ｗ
Javaはほとんどの場合の現場において、C/C++よりも効率的な事は事実。
もっとも俺は、小規模でもJavaが向かない理由は無いと思うがね。
main関数一つで出来たような、本当に小さい規模なら別かもだがｗ
911:仕様書無しさん
09/01/09 23:12:14
てか、
>DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。
低次元の事をやりたいんならC/C++が向いてるに決まっているだろｗ
だが、そんな低次元のコーディングが求められる事は、
ほとんどのシステム開発においてないよ。
912:仕様書無しさん
09/01/09 23:43:13
コマンドプロンプトで、コンパイルするとclはバッチ ファイルとして認識されていませんとなるのですが、どうしてか教えてください＞＜
プログラミング初心者です。
913:仕様書無しさん
09/01/10 00:00:25
使えないなら無理して使わなくていいと思う
914:仕様書無しさん
09/01/10 00:55:02
>>910
一応著名なアプリOOoは破綻気味ですが
なんでだろうね？
>>911
JRuby、Jythonなどある訳ですが？
別にJavaで、できない程低水準な訳じゃない。
ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
915:仕様書無しさん
09/01/10 04:37:47
なんでそんなに低水準を基準にして考えるのでしょうか？
業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。
言語として優れてるかどうかなんてプログラムが好きな人間が考えること。
企業は将来的に保守に金かからない言語とるのは当然だし、だからJavaが
今でも新規開発で使われてると思ふ。
一昔前のJavaならCチックなコーディングもかなりあるけど新規で開発してる
Javaに関してはかなりきちんとしたオブジェクト指向のソースですよ。
なので業務という点でいえばJavaのほうが優れている。
言語としてはしらん。
916:仕様書無しさん
09/01/10 07:20:16
>906,911
ドライバ開発とか組み込みを忘れて内科医。
Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。
>915
>業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。
COBOLやVBと同じで、「質より量」的運用ができるからだと思うけど。
実際、業務で競合する言語はC/C++じゃなくてそっちでしょ。
917:仕様書無しさん
09/01/10 11:32:34
>>915
その水準ならグルー系言語で十分だよ。
暫くしたらJavaも取って代わられるよ。
早さはミドルウェアに任せれば良いし、
POSIXコマンドや、CPANの様にJava
ライブラリとは比較に成らない規模の
ライブラリがある。
918:仕様書無しさん
09/01/10 13:39:20
結局2ｃｈ並みに大量に処理する必要があるなら
必然的にメモリ単位で処理を設計できる
Ｃ＋＋が圧勝だろ
919:仕様書無しさん
09/01/10 17:01:35
結局は適材適所ということか
920:仕様書無しさん
09/01/10 18:04:11
適材適所なんて、少なくとも >>20 で答えが出てる訳で
921:仕様書無しさん
09/01/10 18:13:47
>>914
正直言っている意味がわからねぇｗ
>別にJavaで、できない程低水準な訳じゃない。
>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
この二つの行で既に言っている事が矛盾しているわけだがｗ
>>918
大量の処理をするのにメモリ単位で処理を設計？
何年前の話だｗ
今はそんなのを意識しなくても済むようなハードウェア性能があるんだよ。
むしろ、そんなプログラム作られた日にゃ保守が困るからやめて欲しいだろう。
>>917
Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか？
>>916
組み込みの話なんて誰がしたの？
大規模なシステムっていったら基幹システムとか、
日々の業務処理を行っている重要な部分のことだろ。
922:仕様書無しさん
09/01/10 18:37:45
で、ナルトとルフィはどっちが強いんだ？
923:仕様書無しさん
09/01/10 18:54:01
>>922
ナルト=C++ ルフィ=Java という認識でよろしいか意識あわせしましょう。
924:仕様書無しさん
09/01/10 21:00:58
>921
「組み込み」とは誰も書いてないけどけど、>905に
c/c++ … ドライバや中～小規模アプリ向き
Java … 大～中規模アプリ向き
って書いてあるのを良く見てね。（’ドライバ’に注目）
あと基幹システムとかにはJava’の方’が向いてるのは否定してないから。
ただしJava’だけ’が向いてるとは思わないけどね。
925:仕様書無しさん
09/01/10 21:32:51
>>921
>>別にJavaで、できない程低水準な訳じゃない。
>>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
>この二つの行で既に言っている事が矛盾しているわけだがｗ
矛盾か？一行目は「組み込みレベルでは実質Javaを使うのは無理だが
ミドルウェアレベルならAPI直叩きする必要は無いから実装は可能。」
ということだと思うが？で二行目は、ライブラリに無いアルゴリズムや
テクの比率が多い場合言語機能で凌ぐしかないって事だろ。
>Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか
Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの？
着色とソースコードを飛び回るぐらいならemacsやvi、幾らでもある。
使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
926:仕様書無しさん
09/01/10 21:38:34
ところで、特に意味もなくC/C++と表記するのは何故？
機能規模が全然違うんだからC++だったらC++と書けば？
C++で開発経験が無いのに書き込んでる様に見える。
927:仕様書無しさん
09/01/10 23:46:00
>>926
C++がCと同じ使われ方しかしてないからそう表記するんじゃね？
Java/Javascriptとはかかんでそ？
928:仕様書無しさん
09/01/11 00:14:01
>>927
世間一般の表記の事を言ってる？
そういうことじゃなくて、このスレの中の話でCとC++を
ごっちゃにしてるのはどうよと言う話。
CとC++じゃ機能や移植性が異なるから開発する
世界かなりが違う。単に早さやCの仕様内の話ならC/C++
で構わんだろうがテンプレートなどを含めた話ならC++と
書かないとあんまり仕様を知らないように見える。
昔かし、C/C++が使えますと言って入ってきた新人が
全然C++を知らなかった事があって個人的どうしてもそう見える。
(学校でVC++を触ったことがあってそう言ったらしい)
929:仕様書無しさん
09/01/11 00:32:52
課題だして確かめなかったのが悪いのさ。
930:仕様書無しさん
09/01/11 00:56:37
ではVBよりVC++使うことがあるということは
C++には何らかの利点があるということか
931:仕様書無しさん
09/01/11 01:32:10
>>924
>「組み込み」とは誰も書いてないけど
はぁ？
>>916
>ドライバ開発とか組み込みを忘れて内科医。
>Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。
書いてんじゃん。
だめだ。お前はもう話にならない。
>>925
>Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの？
保守的な人はこれだから…（笑）
非効率な事を一生懸命やって、評価される時代は終わったのｗ
これからの時代は、利用できるものは利用して、
仕事を効率的に進めた人の勝ちなの。ｗ
お前が言っているのは「自分はviを使いこなせる」とか、
「リファクタリングツールが無くてもまともな開発ができる」と自慢をしているだけで、
Javaより優れた言語であるか？という問いに関してはまるで答えになっていない。
まぁ、お前は必死に 統合開発環境vi(笑)つかってプログラミングしててくださいよ。
932:仕様書無しさん
09/01/11 01:39:31
>926
組み込み分野だと、ハードに近い部分ほとC的、遠くなるにつれてC++的になる傾向があり
C++をベターC的に使うことが多いんで、CでもC++でもなくC/C++。
>930
ライブラリやフレームワークの類が、ヘッダとlib/dllしか無いってのは割とあるから、
MFCが扱える程度のC++の知識/技術があれば、VC++使った方が手っ取り早い。
ただCOMとかはVBの方が扱いやすい。（VBじゃなくても良いけど）
933:仕様書無しさん
09/01/11 01:54:10
>931
えーと。
>921が>916に対して「誰が組み込みと言った」とツッコミ入れたのに対し、
>924は>916は>905を受けて書いてるから…と返している。
要するに>924は>916へのフォロー。
それに対して「>916が書いてるだろ」って…
「バカと言う奴がバカ」に対し、「今言った」と返すようなもんだぞ?
934:仕様書無しさん
09/01/11 02:06:26
>931
Java使いが他を「保守的」と言うのは違和感があるな…
emacs、viは安全性より利便性を追求する傾向にあるから、
保守的とは言わんと思うんだが。（C++も同様）
古臭いとか、時代遅れというならまだ分かるんだが…
933の件もそうだけど、よく国語力が無いとか言われない?
935:仕様書無しさん
09/01/11 02:44:54
>>933 >>934
そういう揚げ足はもういいよ。
面倒くさい。
本題と関係ないし。
話をすりかえるな。
936:仕様書無しさん
09/01/11 02:54:02
933はむしろ意味不明な揚げ足取りへの反論。
937:仕様書無しさん
09/01/11 03:20:11
Java = 凡人
C++ = 職人気取り
C = 原住民
VB = 新成人
VC++ = 五月病
こんな感じだな
938:仕様書無しさん
09/01/11 12:44:59
>>914
> ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。
ライブラリに依存しすぎて、の意味が分からない。
誰か分かるやついる？
939:仕様書無しさん
09/01/11 12:50:41
>>914
ついでにこれも意味が分からない。
>一応著名なアプリOOoは破綻気味ですが
なにがどう破綻してるのか。
>>934
>emacs、viは安全性より利便性を追求する傾向にあるから、
viが利便性追求？？
あのー。何年前の話してるんでしょうかｗ
>よく国語力が無いとか言われない?
国語ではなく、Java言語、C++言語の話をしています。
>>936
反論？？
どう見ても苦し紛れのいいわけだろｗ
なんだよ、あの日本語はｗ論理にもなってねぇ
940:925
09/01/11 13:00:24
>>931
>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
俺が強調したいのはこっちなんだが。
レスするならこっちにレスしてくれ。
941:仕様書無しさん
09/01/11 13:04:59
【オープンソース】開発者24人のOpenOffice.は「極めて病んでいる」「停滞している」(2008/12/30)
ｽﾚﾘﾝｸ(pcnews板)
942:仕様書無しさん
09/01/11 13:15:53
>>938はもしかしたらライブラリと自前のコードが1:9になるような
開発をした事が無いんじゃなかろうか？
943:仕様書無しさん
09/01/11 13:25:43
>>942
1:9って言われても、ねえｗ
>>914の言ってること、分かる人？
944:仕様書無しさん
09/01/11 13:30:10
>>942
> >>938はもしかしたらライブラリと自前のコードが1:9になるような
ライブラリと自前のコードが1:9になる、の意味が分からない。
誰か分かるやついる？
945:仕様書無しさん
09/01/11 14:32:31
>>940
そんなに強調したいんならもうちょい説明お願いしようか。
>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
こう思う理由はなんだ？
お前の言っている理論は、根拠が抜けてるんだよ。
リファクタリングツールは高性能であればそのほうがいいだろう。
保守対象となったシステムの前任者が、
分かりにくいソースコードを書いていたらなおさらの話。
てか、常識的な事をいちいち俺にレスさせるな。
お前もしかして仕事で開発やったこと無いの？
学生？？
946:仕様書無しさん
09/01/11 15:21:29
>>938
CもC++も、ライブラリの山だと思うんだが
STLもboostも、その他Cが便利な理由は全部ライブラリだろ
stdioさえもライブラリなんだから、Javaとさほど変わらない程度には依存していると言えそうだが
947:仕様書無しさん
09/01/11 15:32:41
>>943-944
代表例組み込み
組み込みは極端過ぎるが科学計算関係も良い例。
入出力関係と一部の数学系関数以外は計算が大半を締める。
948:仕様書無しさん
09/01/11 16:02:00
>>945
リファクタリングツールは有るに越したことは無い。
しかし、型依存しない言語などだとどうだい？
色々リリースされているリファクタリング機能の内
何割が必要になる？大体必要になるとすれば
名前変更と、重複管理ぐらいになるだろうよ。
君がJavaしか使えなら知らないが。他の言語の
知識があるならオープンソースの世界でどう
保守されているか覗いてみるといい。
949:仕様書無しさん
09/01/11 17:46:28
>>948
>型依存しない言語などだとどうだい？
すまんがさっきから何が言いたいのか全然伝わらんぞ？
型依存しない言語だと、型の変更をするためのリファクタリングが必要ないから、
リファクタリングツールのほとんどの機能がいらない。とでも言うのか？
本気でそんな事言っているとしたら話にならないよ。
確かに狭義の意味での「リファクタリング」であれば、百歩譲って一理あると言ってもいいが、
統合開発環境があれば、継承関係や委譲関係が一目瞭然だし、
UMLへのリバースエンジニアリングも一瞬だ。
いくら言語が優れていようとも、これらの機能が不要とはならないと思うんだが。
950:仕様書無しさん
09/01/11 19:42:04
>>947
く、組み込み？？
か、科学計算関係？？
な、なんかアホらしくなってくるな。