- 1 名前：仕様書無しさん [2007/02/14(水) 15:14:25 ]
- 言語機能的にも実装的にもどっちが上なんですか？
- 657 名前：葉猫 ◆Jz.SaKuRaM mailto:sage [2008/06/14(土) 12:07:12 ]
- 全てをおっぱいおっぱいにちないで処理スピードのために型を残ちたJava、ﾀﾞｻ
- 658 名前：仕様書無しさん mailto:sage [2008/06/14(土) 13:03:24 ]
- >>656
してない。
てか、653と656はオートボクシング知ってるの？
- 659 名前：仕様書無しさん mailto:sage [2008/06/14(土) 13:21:37 ]
- てか、>>653は、文面から察するに、オートボクシング型どころか、
Integer型やDouble型の存在すら知ってるかどうか危ういんだが…。
- 660 名前：仕様書無しさん mailto:sage [2008/06/14(土) 13:23:58 ]
- 間違えた、オートボクシングのあとに
なぜか「型」がついてるのは気にしないでくれ。
- 661 名前：仕様書無しさん mailto:sage [2008/06/14(土) 13:33:40 ]
- >658
ほう、こんなものが追加されたのか。
4.0までしか使ってなかったから知らんかった。
でも↓は酷すぎ…
ttp://d.hatena.ne.jp/nowokay/20071028
ttp://d.hatena.ne.jp/shawshank99/20080125
- 662 名前：仕様書無しさん mailto:sage [2008/06/14(土) 14:15:18 ]
- >>659 Autoboxing は最近知ったがな。
基本型のラッパーを使っていも、同じオブジェクトから作った2つのラッパーが
同じオブジェクトになるわけではないし。
しかも Integer は -128 から 127 は特別扱いされてややこしい。
Autoboxing は単にラッパーオブジェクトへの変換を自動化しているだけで
面倒な部分を隠しているだけ。ラッパーではなく基本型のオブジェクトで
なければ混乱するだけ。
それに 5.hashCode() みたいな事ができるのか? できたとしてもいちいち
Integer オブジェクトに変換されていたら重くてしょうがないが。
言語が特別扱いするクラスも増えて Java はどんどん複雑になっている。
- 663 名前：仕様書無しさん mailto:sage [2008/06/14(土) 14:50:52 ]
- > -128 から 127 は特別扱いされて
これは知らなかったが、だがこんなものは開発標準で規約を決めれば良いだけの話。
Javaのコードの簡潔性や、開発速度等のメリットから見たら小さな話。
5.hashCode()これは出来ないし、C++でも出来ないだろ。
C#なら出来るか？
だが、それがどうしたというのか…。
- 664 名前：仕様書無しさん mailto:sage [2008/06/14(土) 15:07:39 ]
- >>663
> 5.hashCode()これは出来ないし、C++でも出来ないだろ。
> C#なら出来るか？
> だが、それがどうしたというのか…。
基本型だけ Object を継承していないのが非対称ということ?
C++ はもともと共通のベースクラスを持っていないので
できなくても不自然ではない。
5.hashCode() みたいな書き方は Ruby ならできる。
C# は知らないが結構オブジェクト指向っぽくなっている
ようなことは聞いたことがある。
- 665 名前：仕様書無しさん mailto:sage [2008/06/14(土) 15:42:40 ]
- >663
全然小さな話じゃないよ。
規約決めた所で、徹底不足だったら意味ないし、
知識として知っててもミスしないと言い切れない代物。
レビューでも注意深く見ないと気付けないだろうし、
動作テストでも検出できない恐れが十分あり得る。
これがIntegrなんてごく基本的なクラスに存在するのは
かなり致命的だと思うが。
- 666 名前：仕様書無しさん mailto:sage [2008/06/14(土) 15:45:24 ]
- >663,664
ttp://www.ne.jp/asahi/techno/ostra/ccj/CShObjCJava-type.html
C#はこれを克服し、基本型をなくしてしまった。
全ての型はクラスであるとしたのである。
intはSystem.Int32のエイリアス。
stringはSystem.Stringのエイリアス、そして配列までも
System.Arrayのエイリアスだとしている。
- 667 名前：仕様書無しさん mailto:sage [2008/06/14(土) 15:57:06 ]
- >>665
>規約決めた所で、徹底不足だったら意味ないし、
C++だったらnewしたらdeleteしなきゃメモリリーク起こすの知ってるよな？
それだって対策が徹底不足だったら意味ないし、当然ミスもありうる。
それに比べたら別にIntegerの問題くらい大した事はないだろう。
てか、>>661のページは面白おかしく書いてるだけであって、
実際の実務でそんなIntegerの使い方はありえない。
>>666
C#なんてJavaほどマニュアルも揃ってないし、微妙極まりないだろ。
Rubyなんてインタプリタだし却下。
- 668 名前：仕様書無しさん mailto:sage [2008/06/14(土) 15:59:23 ]
- >>665
>動作テストでも検出できない恐れが十分あり得る。
そんなのどんなバグでも検出できない恐れは十分にある。
>これがIntegrなんてごく基本的なクラスに存在するのは
Integerは実はそれほど頻出するクラスでもないよ。
>かなり致命的だと思うが。
全然。
- 669 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:04:33 ]
- >667
メモリリークはツールなりデバッグ関数なりで、
動作テスト1回で簡単に検出できる。
何が最悪かって動作テストをきっちりやっても
防止できない所なんだよ。
そこが最悪か否かの境界線。
あとC#のマニュアルはMSDNで十分過ぎる。
Javaに倣ってソースからドキュメントを生成する仕組みもあったはず。
- 670 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:09:46 ]
- >>668
> Integerは実はそれほど頻出するクラスでもないよ。
Autoboxing 導入されたら知らないうちに頻出するよ。
- 671 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:12:29 ]
- C#は結構まとも
悪くないよ
一般的には.net依存なのが最大の難点になるけど
- 672 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:16:05 ]
- >>669
メモリリークがIntegerのそれより簡単に検出出来るなんて、どこにそんな根拠が？
そもそもIntegerで==を使って比較なんてして、最後まで気づかないなんてありえない。
てか、Integerをそんな頻繁に使っていること自体ありえない。
悪いけど、うちでそんなソース書いてたら、すぐ直させるよ。
MapやListに使う事はあるが、外に出す時は必ずintに直すべき。
C#はマニュアル、開発環境ともにJavaに劣るよ。
- 673 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:21:25 ]
- >>670
Listとかに挿入する時に知らないうちにオートボクシング行われている。
…といいたいのか？
オートボクシングが採用されたバージョンでは、同時にジェネリクスも採用されてる。
つまり実際にはList<Integer>などと宣言することがほとんどで、
知らないうちなんてありえない。
- 674 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:28:46 ]
- >672
メモリリーク検出用のツールとか関数というのがきちんとある。知らんの?
※適切なタイミングでメモリの仕様状態を確認するだけで分かる。
- 675 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:36:09 ]
- >672
>MapやListに使う事はあるが、外に出す時は必ずintに直すべき。
そうすると
>653
>Javaは基本型とクラス型の機能が非対称すぎる。
>- 基本型は参照を使えない
>- 基本型は Object のメソッドが使えない
に戻ってくるわけで。
- 676 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:40:47 ]
- >>674
デバッグツールはcoreを解析する時くらいしか使ったことないな…
>>675
だからそのデメリットが分からないのよ。
基本型とクラス型の二つがあったらなぜいけないのか。
C#やRubyに慣れすぎてて、Javaに違和感を感じてるだけなんじゃないの？
- 677 名前：仕様書無しさん mailto:sage [2008/06/14(土) 16:50:12 ]
- >>673
変数宣言の場所と変数を使う場所が離れているときは型チェックがあると助かるんだよ。
List<Integer>に int を突っ込むときはエラーを出してくれると助かるんだけどね。
- 678 名前：仕様書無しさん mailto:sage [2008/06/14(土) 17:01:53 ]
- >676
>C#やRubyに慣れすぎてて、Javaに違和感を感じてるだけなんじゃないの？
逆にJavaに慣れすぎてしまってるんじゃ…
例えばList<Integer>の各要素に+1するのに、わざわざ変換するのは面倒だろ?
だからこそAutoboxingが導入されたんだろうが、>661の問題が発生するから
>672の言うような運用でカバーせざるを得なくなり、Autoboxingのメリットは無くなる。
更にAutoboxingに頼らないのなら、>677の言うように暗黙の変換は無い方が
規約を遵守させるのには便利だ。
要するに>662の言うように
>言語が特別扱いするクラスも増えて Java はどんどん複雑になっている。
- 679 名前：仕様書無しさん mailto:sage [2008/06/14(土) 17:15:39 ]
- >>678
俺はC#, C++, Javaどれも実務で使ったことある上で
比較をしてるんだが…
まぁJavaが特別扱いするクラスが増えてるってのは認めるよ。
Stringの+=と、StringBufferのappendのメモリの扱いの違いとかもあるだろうし。
しかし、そのおかげで使用する側は簡潔なソースを素早く書けるようになっている事も事実。
うちではシステムはどんどんJavaに移行してるよ。
C#なんかはVisual Studioとかで使うとシステムが高級すぎて
逆に融通が利かなくなる事も多い。
リファクタリングとか環境に依存したりとかでね。
- 680 名前：仕様書無しさん mailto:sage [2008/06/14(土) 18:21:42 ]
- >>661
この仕様がどうこう、と言うより、こういう一貫性を失うような仕様を
安易に取り入れるような、美学を持たない人たちが言語仕様を作っている
こと自体が嫌だなぁ。
もっとも、C++のauto_ptrの代入で、右辺値にも副作用がある、という
点でも、同種の嫌悪感を覚えたが。
(auto_ptrの場合は、無理に代入演算子をoverrideせず、明示的な名前の
クラス関数にすればよかったと思う)
まぁ美学だけじゃ食っていけないこともまた事実ですけど。
- 681 名前：仕様書無しさん mailto:sage [2008/06/14(土) 19:40:59 ]
- Integerはもともと==で比較することを想定していないからね。
つまり、equalsを使わなかった方が悪いという事。
127までとそれ以降の挙動の違いは、
普通にパフォーマンスの都合でしょう。
確かソートのアルゴリズムも、内部で要素の数に応じて
バブルソートとクイックソートを使い分けていたと思う。
だから、その仕様を持ってJavaを悪く言うのは筋違いだと思う。
- 682 名前：仕様書無しさん mailto:sage [2008/06/14(土) 21:48:17 ]
- 速度だけの違いで済むならいいんだけどね。
Integer の場合、数値の比較なら equals() でもダメじゃないか?
Long と比較したら常に false になるから。
- 683 名前：仕様書無しさん mailto:sage [2008/06/14(土) 22:08:47 ]
- >>682
だから基本型に直せって。
てか、ここでIntegerネタで粘着してるやつって何なんだ？
からくり分かってるんなら気をつけてコーディングすりゃいいだけの話だろ。
-128〜127の件も、無駄なインスタンスが増えないように
工夫されて作られてるだけだろ。
Integer型と基本型が両方用意されているのも、
パフォーマンスの都合で基本型が残されているだけだろ。
Mapとかに入れる時用にラッパークラスも用意されているわけで。
こんな簡単なものの使い分けもできない馬鹿が、
これほどまでに多いのか？
こりゃ日本のプログラマの扱いがひどくなるのも当然だよ。
- 684 名前：仕様書無しさん mailto:sage [2008/06/14(土) 22:11:16 ]
- >>680
一貫性がないって、
パフォーマンスのために、状況に応じて処理を変えるのは当然じゃないのか。
むしろ美学があると思えないようじゃ、あんさんの腕もたかが知れてるぞ。
- 685 名前：684 mailto:sage [2008/06/14(土) 22:27:05 ]
- なんか腹が立ってきたな…
- 686 名前：仕様書無しさん mailto:sage [2008/06/14(土) 22:36:49 ]
- >>684
> むしろ美学があると思えないようじゃ、あんさんの腕もたかが知れてるぞ。
君は C++ に美学を感じているのかい?
- 687 名前：684 mailto:sage [2008/06/14(土) 23:13:54 ]
- >>686
なんだと！？
そりゃどういう意味だ。
- 688 名前：仕様書無しさん mailto:sage [2008/06/14(土) 23:27:57 ]
- C++は作者自身がs いやなんでもない
- 689 名前：仕様書無しさん mailto:sage [2008/06/15(日) 12:51:08 ]
- >>687
C++ の設計に美学を感じているのか、それとも美学を感じてないかという疑問。
俺も >>680 のように Java の設計には美学を感じていない。
Java と C++ の設計思想は間逆なので両方の設計に美学を感じることはないと思うが。
- 690 名前：仕様書無しさん mailto:sage [2008/06/15(日) 14:41:01 ]
- なんかわかりやすい自演がいますね
- 691 名前：仕様書無しさん mailto:sage [2008/06/15(日) 14:47:27 ]
- 漏れは極力makeの時点で不具合を検出できるか、
極力短い時間で書る（テストにより多く時間を割ける）のが
美学だと思うんだが。
その点Javaは中途半端だと感じた。
- 692 名前：仕様書無しさん mailto:sage [2008/06/15(日) 15:22:15 ]
- >>689
間逆ぅ？どこが？
同じオブジェクト指向だろ、いみわかんね。
>>691
中途半端どころか、
Javaは開発環境もテスト環境もかなり整っている言語なんだが。
- 693 名前：仕様書無しさん mailto:sage [2008/06/15(日) 15:23:39 ]
- てか、C++がmakeの時点で不具合を検出できるのなら、
Javaのeclipseの場合はコーディングしたそばから不具合検出できるがな。
- 694 名前：仕様書無しさん mailto:sage [2008/06/15(日) 15:38:52 ]
- 「eclipseが優れている」だったらJavaに拘らなくても良い気ガス
- 695 名前：仕様書無しさん [2008/06/15(日) 15:47:21 ]
- ＞間逆ぅ？どこが？
＞同じオブジェクト指向だろ、いみわかんね。
レクサスとダイハツは設計思想が間逆ぅ？どこが？
同じ四輪自家用自動車だろ、いみわかんね。
・・・と同じくらい、あなたの発言は滑稽ですが。
- 696 名前：仕様書無しさん mailto:sage [2008/06/15(日) 16:00:34 ]
- eclipseでJavaしか使ったことがない新人なんですよ。
JVMすら分かってないような厨房です
- 697 名前：仕様書無しさん mailto:sage [2008/06/15(日) 16:14:57 ]
- >>694
確かにほかの言語でもeclipseは使えるが、
Javaほどはどれもしっかりしてない。
>>695-696
はいはい、根拠を言えないで煽ることしかできない馬鹿は黙っててくださいね。
- 698 名前：仕様書無しさん mailto:sage [2008/06/15(日) 16:22:09 ]
- >>694
俺はC++のmakeの利点に対して、
Javaのeclipseの利点を出しただけなんだがな。
何でそれが「Javaの利点 = eclipseが優れている」になっちゃうのよ。
お前の論理回路大丈夫か？
- 699 名前：仕様書無しさん mailto:sage [2008/06/15(日) 17:12:29 ]
- ところでeclipseはIntegerを==で比較したら警告してくれるの?
- 700 名前：仕様書無しさん mailto:sage [2008/06/15(日) 17:26:18 ]
- どうだっけ？
FindBugs (プラグイン)で String の == は警告してくれた記憶あるけど
- 701 名前：仕様書無しさん mailto:sage [2008/06/15(日) 17:39:15 ]
- どうでもいいけどInteger厨は消えろｸｽﾞ
- 702 名前：仕様書無しさん mailto:sage [2008/06/15(日) 18:16:15 ]
- >>697
Java と C++ の設計思想の違いが知りたければ '94 年ぐらいに書かれた
D&E の 4章「C++ 言語の設計ルール」あたりを読んでみなよ。
面白いくらいに Java と反対だから。
第一 Java は C++ を批判する形で出てきただろ。
- 703 名前：仕様書無しさん mailto:sage [2008/06/15(日) 18:34:41 ]
- >>701
同意
Integerではまるような低レベルはさっさと消えろよ。
つーか、まだいたのかよ。
- 704 名前：仕様書無しさん mailto:sage [2008/06/15(日) 18:38:33 ]
- >>690
自作自演呼ばわりかよ。
ちなみに俺も Integer 厨だぞ。
- 705 名前：仕様書無しさん mailto:sage [2008/06/15(日) 21:06:42 ]
- >>704
消えろ。
- 706 名前：699 mailto:sage [2008/06/15(日) 21:29:25 ]
- とりあえず反応を見る限りでは指摘してくれないんだろうねw
では消えます。
- 707 名前：仕様書無しさん mailto:sage [2008/06/15(日) 23:44:09 ]
- Javaってデストラクタないんだっけ？
- 708 名前：仕様書無しさん mailto:sage [2008/06/16(月) 00:47:43 ]
- >>707
ttp://www.bohyoh.com/Java/FAQ/FAQ00072.html
- 709 名前：仕様書無しさん mailto:sage [2008/06/16(月) 01:08:19 ]
- おいおいw
ファイルとかスレッドとか、コンストラクタ/デストラクタで管理したいリソースは
他にもあるだろうに。
- 710 名前：仕様書無しさん mailto:sage [2008/06/16(月) 01:39:16 ]
- IDisposable って持ってなかったっけ?
- 711 名前：仕様書無しさん mailto:sage [2008/06/16(月) 07:49:33 ]
- >>710
それはドットネット。
Javaだとファイナライザがあるけど、すぐ呼ばれる保証は無い。
- 712 名前：仕様書無しさん mailto:sage [2008/06/16(月) 12:43:43 ]
- 確かJava(JVM)のファイナライザは最終的に呼ばれる保証もなかったんじゃない?
- 713 名前：仕様書無しさん mailto:sage [2008/06/16(月) 21:02:14 ]
- ここで「デストラクタが無くてもなんとかなる」と反論が来そうだな。
- 714 名前：仕様書無しさん mailto:sage [2008/06/16(月) 21:30:41 ]
- >>713
いや、総合的にはJavaが優れていると思うが、
C++のデストラクタは確かに便利だ。
- 715 名前：仕様書無しさん mailto:sage [2008/06/16(月) 23:55:25 ]
- C++だけじゃなくてC#、PHP、Python辺りにもあるよ。
Rubyは無いけど代わりにクロージャブロックというものがある。
参考：
ttp://ja.wikipedia.org/wiki/RAII
- 716 名前：仕様書無しさん mailto:sage [2008/06/17(火) 00:06:31 ]
- C#でファイナライザは滅多に使わないだろ
むしろオブジェクトの生滅を制御できない言語で
ファイナライザに依存する処理を書くほうがアホ
- 717 名前：仕様書無しさん mailto:sage [2008/06/17(火) 01:13:53 ]
- リソースの所有権を持っているオブジェクトがそのリソースの後処理をするべきで
try-finally でクライアント側がリソースの後処理をしなければいけないというのは
オブジェクト指向言語とは思えないね。
- 718 名前：仕様書無しさん mailto:sage [2008/06/17(火) 01:31:24 ]
- 道具に振り回されてる厨房はもっとたくさんの言語に触れて見聞を広めなさい
- 719 名前：仕様書無しさん mailto:sage [2008/06/17(火) 16:36:22 ]
- まぁ、デストラクタなくても代用手段はいくらでもあるし、
困ったことはないけどね。
- 720 名前：仕様書無しさん mailto:sage [2008/06/18(水) 01:33:00 ]
- Javaって const ないんだっけ？
- 721 名前：仕様書無しさん mailto:sage [2008/06/18(水) 02:20:42 ]
- static final
- 722 名前：仕様書無しさん mailto:sage [2008/06/18(水) 07:42:07 ]
- オブジェクトの寿命を管理する必要があるシビアな処理にはC++
業務系などの比較的緩い処理にはJAVA
特にイベント駆動アプリの場合
処理が走るタイミングがユーザーの操作時に局所化されるため
ガベージコレクションによる遅延も問題ではなくなる
- 723 名前：仕様書無しさん mailto:sage [2008/06/18(水) 13:25:23 ]
- >>721
final は変数の初期化後にその変数への代入操作を禁止するだけじゃないか?
>>722
マウスドラッグ操作のときはカクッと止まってイラッとする。
基本的にアニメーション系は同じ問題が起きる。
- 724 名前：使用書無しさん [2008/06/21(土) 22:17:16 ]
- javaで帳票設計ツール(jdrafter.sakura.ne.jp)を作ったんだが、結構使える。開発には4ヶ月ほどかかったが、javaの豊富なAPIとガベージコレクターのおかげで割りとスムーズに開発できた。
これをC++で作ろうとすると、細かい部分について一から作らなければならないし、あとメモリーリークやオブジェクトの管理やら貧乏くさい作業が増えるため、何年かかるかわからん。
どっちが優れているかは好みの問題だけど、２者択一なら俺は間違いなくJavawを選ぶな。
- 725 名前：仕様書無しさん mailto:sage [2008/06/22(日) 04:19:06 ]
- >>724
なかなかよさそうじゃないですか
- 726 名前：仕様書無しさん mailto:sage [2008/06/22(日) 12:33:27 ]
- 今の Java のジェネリクスはこの時よりまともになっているかな?
「Java Generics 〜 C++ template との比較 〜」
ttp://www.mamezou.net/modules/xfsection/article.php?articleid=6
- 727 名前：仕様書無しさん mailto:sage [2008/06/22(日) 13:50:23 ]
- Java・・・優れた言語
C++・・・優れた人が使う言語
- 728 名前：使用書無しさん [2008/06/22(日) 18:36:16 ]
- >>725
よかったら使ってね。
- 729 名前：仕様書無しさん [2008/06/22(日) 20:12:13 ]
- 初心者から中級者ってどこで判断するんだ
開発経験年数？
- 730 名前：仕様書無しさん mailto:sage [2008/06/22(日) 22:10:57 ]
- ガベージは無いだろガベージは
garbageなんだから
- 731 名前：仕様書無しさん mailto:sage [2008/06/23(月) 14:08:03 ]
- ガルバゲと読めと？
- 732 名前：仕様書無しさん mailto:sage [2008/06/23(月) 21:05:28 ]
- 発音はこちらでﾄﾞｿﾞｰ
ttp://dictionary.goo.ne.jp/search.php?MT=garbage&kind=ej&mode=0&kwassist=0
- 733 名前：使用書無しさん [2008/06/23(月) 23:07:00 ]
- ぼんくらjavafreekのみなさん
くやしかったら jdrafter.sakura.ne.jp
に匹敵するプログラム作ってねばか
- 734 名前：使用書無しさん [2008/06/23(月) 23:14:35 ]
- ぼんくらc++ふりーくのみなさん
くやしかったら jdrafter.sakura.ne.jp/
に匹敵するプログラム作ってねばか
- 735 名前：仕様書無しさん mailto:sage [2008/06/24(火) 00:53:59 ]
- ねばか って何だ?
- 736 名前：仕様書無しさん mailto:sage [2008/06/25(水) 00:48:49 ]
- C++って、教科書に載ってる以上の勉強がたくさん必要だよな。
独特の規約というか…
それを分かってなくて作る奴もいるのが頭痛い
- 737 名前：仕様書無しさん mailto:sage [2008/06/25(水) 01:09:25 ]
- C++の時代はもうすぐ終わる
- 738 名前：仕様書無しさん mailto:sage [2008/06/25(水) 01:27:10 ]
- 最初から来ていない
- 739 名前：仕様書無しさん mailto:sage [2008/06/25(水) 01:36:22 ]
- これから来る
- 740 名前：仕様書無しさん mailto:sage [2008/06/25(水) 01:45:41 ]
- まぁようやくコンパイラがまともになってきた事だしね。
テンプレ駆使したライブラリもぼちぼち出揃ってきたし。
- 741 名前：仕様書無しさん mailto:sage [2008/06/25(水) 02:06:35 ]
- >>736
お約束のような気がするけど、それはC++に限ったことじゃないぞ。
たしかに、C++は特にまともなコードを書くにあたっての要求が高いほうだとは思うけど。
- 742 名前：仕様書無しさん [2008/06/27(金) 00:41:39 ]
- Java書くようになったらもうC++書くのが面倒くさいよ。
状況が書くことを求められる時にだけC++も使う気でいたいと。
- 743 名前：仕様書無しさん mailto:sage [2008/06/27(金) 02:16:19 ]
- やる夫で学ぶJRuby最適化
ttp://recompile.net/2008/06/jruby-3.html
どうあがいてもJavaに任せられん部分もあると思うんだ。
- 744 名前：使用書無しさん [2008/06/27(金) 21:03:09 ]
- >>743 やる夫 やられる妻
- 745 名前：仕様書無しさん mailto:sage [2008/06/28(土) 07:03:13 ]
- C++で受けると泥臭い仕事ばかりな気がするよ
- 746 名前：仕様書無しさん mailto:sage [2008/06/28(土) 07:12:44 ]
- 個人で趣味で組んでるときはC++の方が楽しいよ
- 747 名前：仕様書無しさん [2008/07/03(木) 23:21:10 ]
- エディターとコマンドプロンプトでJavaを修行してたころ、省略形が欲しいとよく思ってました。
つまり、mainメソッドをmain（default）とか、newの後のコンストラクタが同じ型なら（）だけ書いて終わらせるような省略。
今は家でもnetbeans使ってるため、もうそんな事は思わないけど。
その点C++って面倒でも書く理由は納得できたかな。
- 748 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:28:41 ]
- >>747
俺はJavaのソース書くときにテキストエディタは使わないけど、お前の言ってるレベルのことは
省略文字列の登録だとか単語補完みたいなエディタの機能で十分カバーできるだろ。
- 749 名前：仕様書無しさん mailto:sage [2008/07/04(金) 00:40:52 ]
- 省略形は下手な使い方すると読みにくくなる要因にしかならないからなあ
- 750 名前：使用書無しさん [2008/07/05(土) 16:29:33 ]
- >>747 テキストエディタ使わずにソース書けるのか? IDEだって
組み込みのテキストエディタだがな..
と突っ込んでみる。
- 751 名前：仕様書無しさん [2008/07/05(土) 17:01:11 ]
- バイナリエディタでソース書いてます
- 752 名前：仕様書無しさん mailto:sage [2008/07/05(土) 17:12:01 ]
- >>751
ソースの意味失点の過渡
- 753 名前：仕様書無しさん mailto:sage [2008/07/05(土) 17:17:21 ]
- バイナリエディタでテキストファイルを作ればいいのでは？
- 754 名前：使用書無しさん [2008/07/05(土) 17:35:23 ]
- >>751頭をわって、脳の中身をみてみたい。
- 755 名前：仕様書無しさん mailto:sage [2008/07/05(土) 23:56:17 ]
- バイナリエディタならclassファイルやjarを作ってもいいんじゃない。
- 756 名前：仕様書無しさん mailto:sage [2008/07/28(月) 02:03:08 ]
- 全部！全部！
- 757 名前：仕様書無しさん [2008/11/11(火) 11:22:09 ]
- Javaに決まってんだろ
|
 |
