[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 14:23 / Filesize : 215 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

JAVAとC++どちらが優れているか教えてください



1 名前:仕様書無しさん [2007/02/14(水) 15:14:25 ]
言語機能的にも実装的にもどっちが上なんですか?


878 名前:仕様書無しさん mailto:sage [2009/01/04(日) 20:03:40 ]
> 本当ポリモーフィズムじゃないってのはインターフェース等で
> 束縛されたポリモーフィズム。

では、インターフェース等で束縛(?)されないポリモーフィズムが、
本当のポリモーフィズムだと?

ひょっとして、ダックタイピングと強い型付けの話をしてない?
それはポリモーフィズムじゃなく、単に型についての議論では?

本当のとそうでないのとのポリモーフィズムについての議論、
なんかどっかにソースある? Smalltalk界隈とか?
ポリモーフィズムはどこまで行っても単にポリモーフィズムでは?

879 名前:仕様書無しさん mailto:sage [2009/01/04(日) 21:11:39 ]
議論に参加しようと思ったけど
ポリモーフィズムをまともに論じようと思えば圏論の知識が要るらしいから
勉強してからにします

880 名前:仕様書無しさん mailto:sage [2009/01/04(日) 21:35:27 ]
>>878
いい反応だねぇ。もっと具体的に言えばメッセージング。まぁ、
これを言うとRubyなんかも若干中途半端な言語ということになるけど。
感覚として完全なポリモーフィズムと言うと
Smalltalk>Objective-C、Javascript>Ruby、Python他OO系LL>>>>Java>C++
こんなかんじかな。C++もダックタイプはできるけど配列なんかじゃ生かせない。
Javaはライブラリを使えば近いことはできるけど言語機能であるのとは訳が違う
(それが有りならC++も有りだ
Objective-Cはメッセージングとしてかなりいい線を行っているがメッセージその物を
オブジェクトとしては扱えない。

881 名前:865 mailto:sage [2009/01/05(月) 20:13:34 ]
>>871 >>872
それは趣味でプログラム書きたいときの話?
それだったら別に好きなほうで書けばいいじゃない。

俺が言ったのは、会社などの組織で使う場合の話ね。

>まともに書いたコードのこしておけば大差さないだろ。
>一回ライブラリ化してしまえばC++でGUI表示させるのもこんなもんだし。

オブジェクト指向なんだから一度モジュール化してしまえば使えるのは当然。

しかし、大規模なシステムになってくると、
そういうモジュールも属人的な部分が目立ち始めて保守性も悪くなる。

その点Javaであれば標準として備わっているものが多い。
例えば新しい人を雇った場合には、
前の同じようなフレームワークやライブラリを使った経験があれば、
すぐにその技術を活かしてもらうことができる。

882 名前:仕様書無しさん mailto:sage [2009/01/06(火) 02:27:09 ]
>873
クロスプラットホームの縛りが無いようなので、C#でも挙げとこうかw

ちなみ.NETはM$製であるせいかウケが悪いが、(漏れも眼中に無かった)
Javaの利点に加えてgccのように多言語対応、パフォーマンスもVB並(?)なんで
個人的には期待してる。

好みの言語で作ったライブラリを、対応言語・対応プラットホーム全てで共有できるというのは、
M$発祥であることを考慮しても、もっと評価されて良いと思うんだが。

883 名前:仕様書無しさん mailto:sage [2009/01/06(火) 10:48:15 ]
>>881
 デファクトスタンダードなライブラリならC++の方が多いんだよチミ。
そもそも、標準ライブラリは最小限にして他で補うのがC++の指針だからね。
もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
ならご愁傷様としか言いようは無いけどねぇ。
 あと、新規にライブラリ構築するならJavaだろうがC++だろうが他の言語だろうが
状況は変わらないだろ。優秀なアーキティクトやライブラリアン居るかいないかって
だけの事。
#とは言っても日本にゃ居なそうだけどナァ


884 名前:仕様書無しさん mailto:sage [2009/01/06(火) 19:44:51 ]
>>883
>もし標準ライブラリ以外使用禁止で有名ライブラリが使えないという職場環境
>ならご愁傷様としか言いようは無いけどねぇ。

まぁそういうこと。
システムには当然信頼性が求められるわけだが、
それにはサポートがきっちりされているかどうかも大切な一要素とされる。

もっとも俺はC++にJavaを超えるほどの良質なライブラリがあって、
Javaよりも手早くシステムの作成が可能だなんて思えないが。
仮に百歩譲ってそうだったとしても、
どうしても利益を求める組織は、
標準で用意されている機能が豊富なJavaを使いたがるだろうな。


885 名前:仕様書無しさん mailto:sage [2009/01/06(火) 19:56:04 ]
標準で、っていうところがポイントで、
Javadocで作られたあのびっしりとしたAPI 仕様、
あれが標準で用意されているのもでかいと思う。

886 名前:仕様書無しさん mailto:sage [2009/01/06(火) 21:16:52 ]
>>884
 よくある経営者の流行り乗り。
金がある奴は何かうまくと聞くと
知りもしないのによく飛びつくw
ウチの取引先の管理職なんて
オブジェクト指向はGUIの様な
もんだと思ってる。
 そりゃ、社員も青ざめるわな。



887 名前:仕様書無しさん mailto:sage [2009/01/06(火) 21:37:59 ]
>>886
???
全然違う話をしているな??

俺はリスクの観点で話してるんだが。
要はシステムに不具合が発生したとき、
標準のを使っていると原因を特定しやすいし、責任とかもしっかりしてるだろ。

888 名前:仕様書無しさん [2009/01/06(火) 22:00:01 ]
あと、有名ライブラリよりも、
標準で用意されていたほうが、
スキルをどこでも活かせるというメリットがある。

標準で用意されていないと、
現場によって使っているライブラリ違ったら、
また学習しなおしだから、それだけ人件費がかかるということ。

889 名前:仕様書無しさん [2009/01/07(水) 08:22:31 ]
馬鹿が多い現場ではJAVAがいい

890 名前:仕様書無しさん mailto:sage [2009/01/07(水) 17:48:48 ]
>>889
Javaが良いって言うか…
まぁC++をバカに触らせるよりは、確かに問題は減るかもなw

891 名前:仕様書無しさん mailto:sage [2009/01/07(水) 19:22:36 ]
結論:どっちも優れている。状況に応じて使い分ければいい

892 名前:仕様書無しさん mailto:sage [2009/01/07(水) 20:18:36 ]
>>889
そういうこと。
バカが多い現場でJavaを使えば問題が減る。
優秀なやつが多い現場でJavaを使えばより開発がスムーズに行く。

どちらにせよJavaを使えば間違いなし。終了。

893 名前:仕様書無しさん mailto:sage [2009/01/07(水) 20:22:57 ]
でも、止めちゃイケナイものが入れ替え後に問題起こして止まってしまうのは
いつもJavaを採用したもの。

894 名前:仕様書無しさん mailto:sage [2009/01/07(水) 20:52:33 ]
>>893
意味が分からんw
たまたまだろ。

895 名前:仕様書無しさん mailto:sage [2009/01/08(木) 07:02:53 ]
去年トラブった某J○Bの基幹系システムってたしかJavaだったよね。


896 名前:仕様書無しさん mailto:sage [2009/01/08(木) 11:33:50 ]
>>893
その理論は無理があるw
C++で作ったって、止まるときゃ止まるw



897 名前:仕様書無しさん mailto:sage [2009/01/08(木) 12:25:29 ]
むしろC++のほうが(ry

898 名前:仕様書無しさん [2009/01/08(木) 12:32:12 ]
889に戻る

899 名前:仕様書無しさん mailto:sage [2009/01/08(木) 17:04:39 ]
Javaなら低コストかつ安全です^^v
ってJava厨がしつこいから入れ替えてみたらトラブル多発とか。

900 名前:仕様書無しさん [2009/01/08(木) 17:15:05 ]
IBMとスルガ銀行のやつがJAVAだっけ?

901 名前:仕様書無しさん mailto:sage [2009/01/08(木) 23:34:36 ]
Javaは軟派なイメージ
C++は硬派なイメージ

902 名前:仕様書無しさん mailto:sage [2009/01/09(金) 01:58:28 ]
>>899
>Javaなら低コストかつ安全です^^v
そりゃうそだ。Javaの開発は決して安くはない。

903 名前:仕様書無しさん [2009/01/09(金) 03:34:38 ]
C++が先にできて..だから、その改良型だよJAVAは。

C++がF1カーとすれば、JAVAは日産GT−Rのようなもの。

プロの君は、どっちを使う? もう分かったよね?

904 名前:仕様書無しさん mailto:sage [2009/01/09(金) 07:26:07 ]
なら例えばC#はさらに改良されたと言えるのではないかい?
あるいはDだってあるぞ。

905 名前:仕様書無しさん mailto:sage [2009/01/09(金) 21:50:38 ]
C/C++はドライバや中小規模のアプリを作成するのには向いているが、
大規模なアプリやサービス構築するのには不向き。
Javaは逆に大〜中規模のアプリやサービスには向いてるが、
小規模なアプリやドライバとかには向かない。

例えるなら戦術に長けるC/C++、戦略に長けるJavaと言った所。

906 名前:仕様書無しさん mailto:sage [2009/01/09(金) 22:18:22 ]
>>905
君の知る大規模とは何だい?
まさか、銀行システム程度の規模じゃないよね。
各種ミドルウェアは何で構成されているか知ってるかい?
DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。
どれもCかC++。
アプリケーションレベルでもExcel、Word、統合開発環境。
本当に大規模なプログラムは大抵CかC++になるんだよ。
2000年からリリースされて早9年。なんで、JavaでEclipseや
Opera、OOoぐらいしか著名アプリが作成されていないか解るかい?
Javaの謳い文句が現場のメリットとして形を成してないんだよ。



907 名前:仕様書無しさん [2009/01/09(金) 22:21:06 ]
このスレ意味なくね?

908 名前:仕様書無しさん mailto:sage [2009/01/09(金) 22:44:55 ]
本当に優秀なのはどっちも使えるプログラマってことだよな

909 名前:仕様書無しさん mailto:sage [2009/01/09(金) 22:52:50 ]
>>906
ムキになってるところすまんが、規模って案件の規模のことじゃね?
銀行の基幹系みたいに何百人が開発に関わるような規模だと
使える技術者を集めやすいかとか、低コスト短期間でそれなりの
クオリティのものを出せるかで使える言語も変わってくるだろ。
そりゃコストに制限がなければ優秀なC++プログラマでも集めて
好きなだけオーバーエンジニアリングしてりゃいいけどさ。


910 名前:仕様書無しさん mailto:sage [2009/01/09(金) 23:10:29 ]
>>906

>>905じゃないけどよ、

>2000年からリリースされて早9年。
>著名アプリが作成されていないか解るかい?

そりゃ古い有名アプリはC/C++が主流の頃作られたんだから、
Java使われてなくて当たり前だろw
分かってないのお前だけじゃないのか?w

Javaはほとんどの場合の現場において、C/C++よりも効率的な事は事実。

もっとも俺は、小規模でもJavaが向かない理由は無いと思うがね。
main関数一つで出来たような、本当に小さい規模なら別かもだがw

911 名前:仕様書無しさん mailto:sage [2009/01/09(金) 23:12:14 ]
てか、

>DB、VM、各種COMアパートメント、エミュレーター、インタプリタ。

低次元の事をやりたいんならC/C++が向いてるに決まっているだろw
だが、そんな低次元のコーディングが求められる事は、
ほとんどのシステム開発においてないよ。

912 名前:仕様書無しさん [2009/01/09(金) 23:43:13 ]
コマンドプロンプトで、コンパイルするとclはバッチ ファイルとして認識されていませんとなるのですが、どうしてか教えてください><
プログラミング初心者です。

913 名前:仕様書無しさん mailto:sage [2009/01/10(土) 00:00:25 ]
使えないなら無理して使わなくていいと思う

914 名前:仕様書無しさん mailto:sage [2009/01/10(土) 00:55:02 ]
>>910
一応著名なアプリOOoは破綻気味ですが
なんでだろうね?

>>911
JRuby、Jythonなどある訳ですが?
別にJavaで、できない程低水準な訳じゃない。
ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。

915 名前:仕様書無しさん mailto:sage [2009/01/10(土) 04:37:47 ]
なんでそんなに低水準を基準にして考えるのでしょうか?
業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。
言語として優れてるかどうかなんてプログラムが好きな人間が考えること。
企業は将来的に保守に金かからない言語とるのは当然だし、だからJavaが
今でも新規開発で使われてると思ふ。
一昔前のJavaならCチックなコーディングもかなりあるけど新規で開発してる
Javaに関してはかなりきちんとしたオブジェクト指向のソースですよ。
なので業務という点でいえばJavaのほうが優れている。
言語としてはしらん。

916 名前:仕様書無しさん mailto:sage [2009/01/10(土) 07:20:16 ]
>906,911
ドライバ開発とか組み込みを忘れて内科医。
Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。

>915
>業務用アプリでJava使うのはメンテナビリティを考えてるからでしょ。

COBOLやVBと同じで、「質より量」的運用ができるからだと思うけど。
実際、業務で競合する言語はC/C++じゃなくてそっちでしょ。



917 名前:仕様書無しさん mailto:sage [2009/01/10(土) 11:32:34 ]
>>915
その水準ならグルー系言語で十分だよ。
暫くしたらJavaも取って代わられるよ。
早さはミドルウェアに任せれば良いし、
POSIXコマンドや、CPANの様にJava
ライブラリとは比較に成らない規模の
ライブラリがある。

918 名前:仕様書無しさん mailto:sage [2009/01/10(土) 13:39:20 ]
結局2ch並みに大量に処理する必要があるなら
必然的にメモリ単位で処理を設計できる
C++が圧勝だろ

919 名前:仕様書無しさん mailto:sage [2009/01/10(土) 17:01:35 ]
結局は適材適所ということか

920 名前:仕様書無しさん mailto:sage [2009/01/10(土) 18:04:11 ]
適材適所なんて、少なくとも >>20 で答えが出てる訳で

921 名前:仕様書無しさん mailto:sage [2009/01/10(土) 18:13:47 ]
>>914
正直言っている意味がわからねぇw

>別にJavaで、できない程低水準な訳じゃない。
>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。

この二つの行で既に言っている事が矛盾しているわけだがw

>>918
大量の処理をするのにメモリ単位で処理を設計?
何年前の話だw
今はそんなのを意識しなくても済むようなハードウェア性能があるんだよ。

むしろ、そんなプログラム作られた日にゃ保守が困るからやめて欲しいだろう。

>>917
Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか?

>>916
組み込みの話なんて誰がしたの?
大規模なシステムっていったら基幹システムとか、
日々の業務処理を行っている重要な部分のことだろ。

922 名前:仕様書無しさん mailto:sage [2009/01/10(土) 18:37:45 ]
で、ナルトとルフィはどっちが強いんだ?

923 名前:仕様書無しさん mailto:sage [2009/01/10(土) 18:54:01 ]
>>922
ナルト=C++ ルフィ=Java という認識でよろしいか意識あわせしましょう。

924 名前:仕様書無しさん mailto:sage [2009/01/10(土) 21:00:58 ]
>921
「組み込み」とは誰も書いてないけどけど、>905に
 c/c++ … ドライバや中〜小規模アプリ向き
 Java … 大〜中規模アプリ向き
って書いてあるのを良く見てね。(’ドライバ’に注目)

あと基幹システムとかにはJava’の方’が向いてるのは否定してないから。
ただしJava’だけ’が向いてるとは思わないけどね。


925 名前:仕様書無しさん mailto:sage [2009/01/10(土) 21:32:51 ]
>>921

>>別にJavaで、できない程低水準な訳じゃない。
>>ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。

>この二つの行で既に言っている事が矛盾しているわけだがw
矛盾か?一行目は「組み込みレベルでは実質Javaを使うのは無理だが
ミドルウェアレベルならAPI直叩きする必要は無いから実装は可能。」
ということだと思うが?で二行目は、ライブラリに無いアルゴリズムや
テクの比率が多い場合言語機能で凌ぐしかないって事だろ。


>Javaと比較にならないほどの高性能統合開発環境や、マニュアルが存在するのか
Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの?
着色とソースコードを飛び回るぐらいならemacsやvi、幾らでもある。
使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。


926 名前:仕様書無しさん mailto:sage [2009/01/10(土) 21:38:34 ]
ところで、特に意味もなくC/C++と表記するのは何故?
機能規模が全然違うんだからC++だったらC++と書けば?
C++で開発経験が無いのに書き込んでる様に見える。



927 名前:仕様書無しさん mailto:sage [2009/01/10(土) 23:46:00 ]
>>926
C++がCと同じ使われ方しかしてないからそう表記するんじゃね?
Java/Javascriptとはかかんでそ?

928 名前:仕様書無しさん mailto:sage [2009/01/11(日) 00:14:01 ]
>>927
世間一般の表記の事を言ってる?
そういうことじゃなくて、このスレの中の話でCとC++を
ごっちゃにしてるのはどうよと言う話。
CとC++じゃ機能や移植性が異なるから開発する
世界かなりが違う。単に早さやCの仕様内の話ならC/C++
で構わんだろうがテンプレートなどを含めた話ならC++と
書かないとあんまり仕様を知らないように見える。

昔かし、C/C++が使えますと言って入ってきた新人が
全然C++を知らなかった事があって個人的どうしてもそう見える。
(学校でVC++を触ったことがあってそう言ったらしい)

929 名前:仕様書無しさん mailto:sage [2009/01/11(日) 00:32:52 ]
課題だして確かめなかったのが悪いのさ。

930 名前:仕様書無しさん mailto:sage [2009/01/11(日) 00:56:37 ]
ではVBよりVC++使うことがあるということは
C++には何らかの利点があるということか

931 名前:仕様書無しさん mailto:sage [2009/01/11(日) 01:32:10 ]
>>924
>「組み込み」とは誰も書いてないけど

はぁ?

>>916
>ドライバ開発とか組み込みを忘れて内科医。
>Javaでドライバなんて聞いた事ないし、組み込みもケータイアプリ等に用途が限られてる。

書いてんじゃん。
だめだ。お前はもう話にならない。

>>925
>Java向け統合開発環境以上の統合開発環境が無いとまともに開発できないの?

保守的な人はこれだから…(笑)
非効率な事を一生懸命やって、評価される時代は終わったのw
これからの時代は、利用できるものは利用して、
仕事を効率的に進めた人の勝ちなの。w

お前が言っているのは「自分はviを使いこなせる」とか、
「リファクタリングツールが無くてもまともな開発ができる」と自慢をしているだけで、
Javaより優れた言語であるか?という問いに関してはまるで答えになっていない。

まぁ、お前は必死に 統合開発環境vi(笑)つかってプログラミングしててくださいよ。

932 名前:仕様書無しさん mailto:sage [2009/01/11(日) 01:39:31 ]
>926
組み込み分野だと、ハードに近い部分ほとC的、遠くなるにつれてC++的になる傾向があり
C++をベターC的に使うことが多いんで、CでもC++でもなくC/C++。

>930
ライブラリやフレームワークの類が、ヘッダとlib/dllしか無いってのは割とあるから、
MFCが扱える程度のC++の知識/技術があれば、VC++使った方が手っ取り早い。
ただCOMとかはVBの方が扱いやすい。(VBじゃなくても良いけど)

933 名前:仕様書無しさん mailto:sage [2009/01/11(日) 01:54:10 ]
>931

えーと。
>921が>916に対して「誰が組み込みと言った」とツッコミ入れたのに対し、
>924は>916は>905を受けて書いてるから…と返している。
要するに>924は>916へのフォロー。

それに対して「>916が書いてるだろ」って…
「バカと言う奴がバカ」に対し、「今言った」と返すようなもんだぞ?

934 名前:仕様書無しさん mailto:sage [2009/01/11(日) 02:06:26 ]
>931
Java使いが他を「保守的」と言うのは違和感があるな…

emacs、viは安全性より利便性を追求する傾向にあるから、
保守的とは言わんと思うんだが。(C++も同様)
古臭いとか、時代遅れというならまだ分かるんだが…

933の件もそうだけど、よく国語力が無いとか言われない?

935 名前:仕様書無しさん mailto:sage [2009/01/11(日) 02:44:54 ]
>>933 >>934
そういう揚げ足はもういいよ。
面倒くさい。

本題と関係ないし。
話をすりかえるな。

936 名前:仕様書無しさん mailto:sage [2009/01/11(日) 02:54:02 ]
933はむしろ意味不明な揚げ足取りへの反論。



937 名前:仕様書無しさん mailto:sage [2009/01/11(日) 03:20:11 ]
Java = 凡人
C++ = 職人気取り
C = 原住民
VB = 新成人
VC++ = 五月病

こんな感じだな

938 名前:仕様書無しさん mailto:sage [2009/01/11(日) 12:44:59 ]
>>914
> ライブラリに依存しすぎて言語機能として貧弱なんだよJavaは。

ライブラリに依存しすぎて、の意味が分からない。
誰か分かるやついる?

939 名前:仕様書無しさん mailto:sage [2009/01/11(日) 12:50:41 ]
>>914
ついでにこれも意味が分からない。

>一応著名なアプリOOoは破綻気味ですが

なにがどう破綻してるのか。

>>934
>emacs、viは安全性より利便性を追求する傾向にあるから、

viが利便性追求??
あのー。何年前の話してるんでしょうかw

>よく国語力が無いとか言われない?

国語ではなく、Java言語、C++言語の話をしています。

>>936
反論??
どう見ても苦し紛れのいいわけだろw
なんだよ、あの日本語はw論理にもなってねぇ

940 名前:925 mailto:sage [2009/01/11(日) 13:00:24 ]
>>931

>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。
俺が強調したいのはこっちなんだが。
レスするならこっちにレスしてくれ。

941 名前:仕様書無しさん mailto:sage [2009/01/11(日) 13:04:59 ]
【オープンソース】開発者24人のOpenOffice.は「極めて病んでいる」「停滞している」(2008/12/30)
pc11.2ch.net/test/read.cgi/pcnews/1230658127/

942 名前:仕様書無しさん mailto:sage [2009/01/11(日) 13:15:53 ]
>>938はもしかしたらライブラリと自前のコードが1:9になるような
開発をした事が無いんじゃなかろうか?


943 名前:仕様書無しさん mailto:sage [2009/01/11(日) 13:25:43 ]
>>942
1:9って言われても、ねえw
>>914の言ってること、分かる人?

944 名前:仕様書無しさん mailto:sage [2009/01/11(日) 13:30:10 ]
>>942
> >>938はもしかしたらライブラリと自前のコードが1:9になるような

ライブラリと自前のコードが1:9になる、の意味が分からない。
誰か分かるやついる?

945 名前:仕様書無しさん mailto:sage [2009/01/11(日) 14:32:31 ]
>>940

そんなに強調したいんならもうちょい説明お願いしようか。

>使いやすい言語ならテンプレート生成やインテリセンスとか凝ったリファクタリングツールは要らんぞ。

こう思う理由はなんだ?
お前の言っている理論は、根拠が抜けてるんだよ。

リファクタリングツールは高性能であればそのほうがいいだろう。
保守対象となったシステムの前任者が、
分かりにくいソースコードを書いていたらなおさらの話。

てか、常識的な事をいちいち俺にレスさせるな。
お前もしかして仕事で開発やったこと無いの?
学生??

946 名前:仕様書無しさん mailto:sage [2009/01/11(日) 15:21:29 ]
>>938
CもC++も、ライブラリの山だと思うんだが
STLもboostも、その他Cが便利な理由は全部ライブラリだろ
stdioさえもライブラリなんだから、Javaとさほど変わらない程度には依存していると言えそうだが



947 名前:仕様書無しさん mailto:sage [2009/01/11(日) 15:32:41 ]
>>943-944
代表例組み込み
組み込みは極端過ぎるが科学計算関係も良い例。
入出力関係と一部の数学系関数以外は計算が大半を締める。

948 名前:仕様書無しさん mailto:sage [2009/01/11(日) 16:02:00 ]
>>945
リファクタリングツールは有るに越したことは無い。
しかし、型依存しない言語などだとどうだい?
色々リリースされているリファクタリング機能の内
何割が必要になる?大体必要になるとすれば
名前変更と、重複管理ぐらいになるだろうよ。
君がJavaしか使えなら知らないが。他の言語の
知識があるならオープンソースの世界でどう
保守されているか覗いてみるといい。


949 名前:仕様書無しさん mailto:sage [2009/01/11(日) 17:46:28 ]
>>948
>型依存しない言語などだとどうだい?

すまんがさっきから何が言いたいのか全然伝わらんぞ?

型依存しない言語だと、型の変更をするためのリファクタリングが必要ないから、
リファクタリングツールのほとんどの機能がいらない。とでも言うのか?

本気でそんな事言っているとしたら話にならないよ。

確かに狭義の意味での「リファクタリング」であれば、百歩譲って一理あると言ってもいいが、
統合開発環境があれば、継承関係や委譲関係が一目瞭然だし、
UMLへのリバースエンジニアリングも一瞬だ。
いくら言語が優れていようとも、これらの機能が不要とはならないと思うんだが。

950 名前:仕様書無しさん mailto:sage [2009/01/11(日) 19:42:04 ]
>>947

く、組み込み??
か、科学計算関係??

な、なんかアホらしくなってくるな。

951 名前:仕様書無しさん mailto:sage [2009/01/11(日) 21:14:46 ]
>950
今時そんな仕事ねーよという意味でアホらしいとか言ってるなら、
あるわボケ、と返しておく。

あと組み込みだと1:9どころか0:10に限りなく近い現場もごく稀にある。
一昔前だとコンパイラも作ってたり。

科学計算に関しては1:9はちょっとうそ臭い。piとかsinとかも自作してるんだろうか?
パッケージ使わないの?

952 名前:仕様書無しさん mailto:sage [2009/01/12(月) 08:08:10 ]
科学計算で無理矢理JavaやC++を使う理由はない。
FORTRANでいい。

953 名前:仕様書無しさん mailto:sage [2009/01/13(火) 01:32:39 ]
最近はMatlabとかの方が主流な希ガス。

954 名前:仕様書無しさん mailto:sage [2009/01/13(火) 18:26:50 ]
1:9というとおかしいかもしれないけど、
3Dの計算やmpgなんかのアーカイバ、医療分析
データマイニングの計算部分、様々な解析処理ってな部分じゃ
Javaのライブラリでもjava.utilとjava.mathあと入出力系ぐらいしか使えるもんが無くね?
しかも、これ系統のライブラリなら大抵の言語に付属してるからJavaの取り柄でもなんでもない。
外部パッケージ使えばと言われるなら、それぐらいなら別の言語使った方がマシ。

955 名前:仕様書無しさん mailto:sage [2009/01/15(木) 02:09:30 ]
そいやBlitz++ってどうなの?
相変わらずFORTRANの方がマシ?

956 名前:仕様書無しさん mailto:sage [2009/01/22(木) 22:14:18 ]
C++はスザクでjavaはルルーシュってことですか



957 名前:仕様書無しさん mailto:sage [2009/01/22(木) 22:45:36 ]
Fortranは誰だろうね

958 名前:仕様書無しさん mailto:sage [2009/01/23(金) 21:17:14 ]
Javaは画面設計が面倒なんだろ?

959 名前:仕様書無しさん mailto:sage [2009/01/24(土) 01:17:06 ]
Javaの空気はうめぇなぁ

960 名前:仕様書無しさん mailto:sage [2009/01/24(土) 15:26:29 ]
AWTとSwingか。

961 名前:仕様書無しさん mailto:sage [2009/01/24(土) 19:09:16 ]
VBAが最強

962 名前:仕様書無しさん mailto:sage [2009/01/25(日) 01:27:41 ]
コードで書く分には画面作るのも楽だけど。
まぁ、これはライブラリの問題であって言語の問題でもないし。
ただ、多重継承ができない分MVCがめんどい。

963 名前:仕様書無しさん mailto:sage [2009/02/02(月) 09:19:35 ]
おい、Lisp様を忘れてもらっては困る

964 名前:仕様書無しさん mailto:sage [2009/02/02(月) 14:11:32 ]
お前ら、そうかりかりせずにObjective-C++で仲良くしよや。
codepad.org/N2sI3yA8

965 名前:仕様書無しさん mailto:sage [2009/02/13(金) 23:09:22 ]
プロのトレーダだけどLC食らった

966 名前:仕様書無しさん mailto:sage [2009/02/14(土) 06:25:09 ]
>>964
Dだろ



967 名前:仕様書無しさん [2009/03/17(火) 07:43:57 ]
>>801
967ゲットオォオオォ!!!!!
  ∧∧
  (^ω^)
 cu_uっ バイーン
  彡
 / ̄ ̄\
 | ̄1 ̄|
 | ̄2 ̄|
 ̄ ̄ ̄ ̄ ̄ ̄


968 名前:仕様書無しさん mailto:sage [2009/03/18(水) 21:50:56 ]
Javaの方がC++より女子率が高いので優れている。

という仮説を立ててみる。

969 名前:仕様書無しさん mailto:sage [2009/03/20(金) 13:06:47 ]
コンパイラー=通訳者


970 名前:仕様書無しさん [2009/03/26(木) 08:31:27 ]
>>967
  通訳者ってインタプリタだよね?
  ∧∧
 (・ω・ )
 _| ⊃/(__
/ ヽ-(___/
 ̄ ̄ ̄ ̄ ̄ ̄


971 名前:仕様書無しさん mailto:sage [2009/03/26(木) 12:35:07 ]
翻訳者

972 名前:仕様書無しさん mailto:sage [2009/04/03(金) 13:40:27 ]
InfoQ: C++とJavaのレガシーについて語るのは時期尚早か?
ttp://www.infoq.com/jp/news/2009/04/C-Plus-Plus-Java-Legacy

973 名前:仕様書無しさん [2009/04/12(日) 04:31:47 ]
>>970
   ヤッパリ…
  ∧∧
  (´・ω)
 _|⊃/(___
/ ヽ_(____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄


974 名前:仕様書無しさん [2009/04/12(日) 08:08:03 ]
COBOL経験者だけど、Cプラプラをマスターするには何ヵ月くらいかかりそう?

975 名前:仕様書無しさん mailto:sage [2009/04/12(日) 08:11:17 ]
ポインタ判る?オブジェクト指向判る?

976 名前:仕様書無しさん mailto:sage [2009/04/12(日) 11:09:10 ]
>>974
業務知識がしっかりしてれば3ヶ月もあれば十分。
クラスなんてCOBOLのモジュールとさほど変わらない。




977 名前:仕様書無しさん [2009/04/12(日) 14:51:29 ]

業務知識(笑)など関係ないだろうが。
こういう低学歴のカスがいるからC++技術者が舐められる。

現実的にはこの板の住人の99.999%は凡人はC++を完全理解など不可能。
ネットだからなんとでも言えるだけ。




978 名前:仕様書無しさん mailto:sage [2009/04/12(日) 16:15:43 ]
>>977
別に言語の機能をすべて使いこなさないとシステムが組めないってわけじゃないし。
なんでC++が特別な存在って思いたいの?ただの言語じゃん。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef