BCBとVC++

どっち派？

VC++

MSがBCBをだしてBorlandがVCをだしてたら、
みんなどっちを使ってただろう。

　　　　　　　　　　　　__,,,,＿
　　　　　 　 　 　 ／´　　 　 ￣｀ヽ,
　 　 　 　 　 　 / 〃　 _,ｧ---‐一ﾍヽ
　　　　　　　　 i　　／´　　　0　　　ﾘ}
　　　　　 　 　 | 　 〉. 　 -‐　　 '''ｰ {!　
　　　　　 　 　 | 　 |　　 ‐ｰ　 くー　|　　
　　 　 　 　 　 ﾔヽﾘ /// ,ｒ "_,,>//'｝ 　／ー
　　　　　　　　 ヽ_｣ 　(つト‐＝‐ｧ'　!　<　ﾊｧ〜・・・
　　　　　　　　　 ゝ i、 　 ` ｀二´' 丿 　 ＼
　　　　　　　　　　 ﾄ､､　／￣｀`ｰ､　　　　 　　　　　　　　 　　　　　　　　　　　　　
　　　　　　　　　　 |｀.-/　　　>>1 ヽ
　　　　　　　　　　／ヽ|　　　　　　　,. ﾞ､
　　 　　　　　　　/　　　|　ﾉ⌒)　　 .|　 ﾞ､
　　　　　　　　／;.　　　.|　(ノＯ　　 |　　 ﾞ､
　　　　　 　.／　 ﾞ|　,.　 |　　　　　　|　　　 ﾞ､
　　　　 　／　　. /"　　.|　　　　　 .|　　　_,_.ﾞ､____,,,,､=､
　　　　.／　　　./!　　　.|　　　　　/　／￣､-‐‐'''''''ｰ-､＼,_
　_,.､--'　　　　/-‐''''''~~~`　　　 /／‐''"´　　　　　　　 ｀＼＼
　　 _,,,､--''''~´　　　 　__...､-‐'''~~´　　　　　　　0　　　　　 ｀ヽヽ
　ノ"　　　　 _,,､--‐'''~　　　　　　　　(⌒ヽ　　　　　(⌒)　　　　ヽ|､
　　 ,,､-‐'''"~　　　　　　　　　　　　　　しノ　　　　　 ）丿　 　　　.|;;|
　''"　　　　　　　　　　　　　　　　　　　　　　　　　　(ノ　　 　　 ./､;|
　　　 ､,,,_　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ／/ヾ
　　　　　 ｀` ｰ､　　　　　　　　　　　　　　　　　　　　 　　_／´／　 |
　　　　　　　　　＼＿＿＿＿　　　　　　　　　 _,,,,,､､､-=‐'''"´　　　|
　　　　　　　　　　 ＼　 　/ヾ￣￣~~｀二>='''~..､-‐'／´　　　　　　 |
　＼　　　　　　　　　 ヽ　 ヽ:::|:::,.､-‐'ﾞ´　　`'''''''''''ﾞ´　　　　　 　　 ./
　　 ＼　　　　　　　　　ﾞ､　|／´　　　　　　　　　　　　　　　　 　　/
　　　　＼　　　　　　　　＼´　　　　　　　　　　　　　　　　　　　／

ｖｃ

BCB VS VC++はVCL VS MFCとほぼおなじ

　 ＿＿＿＿＿　　　　　＿＿＿＿＿　　　　　　　　　　　 ＿＿＿＿＿＿
　｜書き込む｜名前：｜ 　 　 　 　｜E-mail(省略可)：｜hage 　　　　｜
　 ￣￣￣￣￣　　　　　￣￣￣￣￣　　　　　　　　　　　 ￣￣￣￣￣￣
　　　　 , -'~￣￣￣~`ｰ､　 　 　 　　／)　　　　　　　　　　　　 ↑　↑　↑
　　 　 /　　　　　　ﾟ ○　ヽ　　　／／
　　　 |　　＝ 三 ＝　　oヾ､　/ つ^^ヽ 　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　l|.　 ,-―'､　>ー--､　l;;l､/　テﾉﾉﾉ ＜　あのねえ、メアド欄に「hage」！！
　 　i^| 　-<・> |.| <・>-　　b |　 r'^^´　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
　 　.|| 　　￣　|.|　￣　 　 .|/　 ﾉ
　 　 .| 　 　／(oo) ヽ　　　|　 /　
　 　　 | _(⌒)＿＿_ 　　/　/　
　　 /,-r┤~.lニ　 ` ／　
　　（ｒｆ .|　|　ヽ-― '　
　　.lヽλ_八_　,,￣） 　
　　 ｀ー┬‐-ｰ'￣　 　　

BCB最高！

>BCB VS VC++はVCL VS MFCとほぼおなじ
はぁ？

(；´ー｀)y-~~.｡oO(BCBでコンパイルするとやたらとサイズが（略）

あの質問ですが
今選ぶのなら
VC++netと6.0どちらのほうがいいのですか？

個人で買ったのはBCB、仕事ではVC++

13GET

欲しいなら VC6は急がないと、もう買えなくなるよ。
といっても、エンタープライズだからなあ、買えるの？

>>14
プロフェッショナルは？

そりゃGCCだろ！

>>15
俺はM%の営業じゃないから知らないが、プロフェッショナルは販売店の在庫限りだと思うよ

近所のお店で聞いてみたら？

>>10
MFCのライブラリをスタティックリンクにすれば無問題（´ー`）y-~~

ていうかBCBとVC++は何がどうちがうの？

vs.net Pro以上 MSDNならVS6が入手できる、
が何時まで入手可能なのかは不明

VCProとBCBProでは機能的にどちらのほうが上なのですか？

コンパイラのISOC++準拠度がややBCBの方が高いので使いやすい。
IDEとかそういう表面的な使いやすさならVC++の方がいいと思う。

>>22
( ﾟДﾟ)ﾊｧ?
IDEならBCBのほうが上だろ？
使ったことあんのか？

VCなのが上なのはデバッガとかだろ。

>>23
ネタはsageでやってほしい。

Win98で使えるのは、VC++6.0が最新に
なるんだっけ？

>>23
VCL以外に上なところってないだろ｡

Delphiが最強ですよ(ﾎﾞｿｯ

BCBのDelphiスタイルのIDEはコードを縦に長く表示出来るから便利だよ

最適化機能とかではどちらの方が上ですか？

>>29
悲しいけどVC++の方が上。

>>28
それくらいVCだってできるだろ

>>29
MSは機械に、某は人間に最適化されています

>>32
某は人間を(某向けに)最適化します

>>31
全部のバーをドッキングオフしても、それが前面に来るからウットシイんだよ

>>34
全画面表示使えよ

>>35
フルスクリーンにしたら、今度はPDFファイル見て仕様をコピペしながらとかが面倒になるじゃないか

非表示にするかでかいモニタ買えよ｡
しょぼい環境でのみ発生する問題をMSのせいにするんじゃない｡

まあ、某は腐ってるって事で。OK?

スーパーカリフラジリスティックエクスピアリドーシャス
supercalifragilisticexpialidocious

　 ∧＿∧
　（　´∀｀）＜　ぬるぽ

>>37
おいおい、便利だよって言ってるだけの事でそこまで噛み付くなよ

まったく40の言うとおりだな

BCBはなかなか仕事で使わせてくれないが、
それ解決したらBCBに移行してもいい。
ただ、BCBのエディタがVCのやつだったらなあ。
最近VCはDLL作るときぐらいしか出番ないな。mingwでもいいし。
結局ガワ以外は両方で動く様に作ってて消すことはないだろうけど。

gtk--最強

　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　 　　/ 　←>>39

貧乏人でもデュアルモニタにする程度の金はあるだろ　

>>45
私にもデュアルモニタにするくらいのお金はあるわよ。
でも会社で使うモニタのために自腹を切るのはいやだわ。

えっ 業務の開発をシングルモニタでしてる人がいるの?

>>47
ﾉ

>>47
リア厨は黙りなさいよ。

>>48-49
お前ら明日の朝一でモニタ買ってこい｡
モニタの金額と人件費じゃ桁が違いまくりだろ｡
余裕で元が取れるよ｡それくらい効率が上がるだろ｡

>>50
実は私の席にも液晶モニタとCRTが1台ずつあるのよ。
でもパソコンが4台(1台は個人所有ノート)あるからマルチモニタにするためのスペースがないのよね。

#私的にはマルチモニタよりも複数マシンでの作業の方が効率がいいと思うわ。
#そりゃあ、複数マシンのマルチモニタが理想でしょうけどね。

モニタが2台あれば後は切り替えろよ
CPU切り替え器が高いといっても（ｒｙ

複数マシンはむしろ効率悪いだろ｡メリットが思いつかない｡
切り替えも面倒だし設定も毎回しないといけないし｡
どっかからもう一台モニタがめてきて三面モニタにしたいよ｡
他のマシンに触るときはssh経由｡

>>52
あら、あなた頭いいわね。(ﾟε゜;)
でもデュアルモニタ対応のグラフィックカードも買わなきゃいけないわ。
私、こう見えても実はケチなのよ。だからやっぱり我慢するわ。

>>53
>切り替えも面倒だし設定も毎回しないといけないし｡
いまどきのモニタにはメモリ機能があるから、入力信号に応じて設定が自動的に切り替わるのよ。

それは置いといて、私のメインはWindowsなのよ。だから異なるOSや開発環境のインストールされていない
マシンでリモートデバッグしたいときにはどうしても複数マシンが必要なのよね。
もちろんVirtual PCなんかも使うわ。
あと、処理時間が長くてCPUパワーを使うプログラムの実行をしている間だって暇なことがあるじゃない。
そんなときに別のマシンがあると暇つぶしにホームページを見れてとっても便利だわ。

モニター厨は余所でやれ

Java大好き！

>>57
ｷｼｮ

Javaはこれからも不滅だ！！！！！！！！！！！！

>>57
ｷｼｮ

Javaはこれからも不滅だ！！！！！！！！！！！！

>>61
Javaは不滅だがお前は氏ね。

Javaは滅亡だ！！！！！！！！！！

>>57
ｷｼｮ

「これからも不滅だ！」ってのがわからないな。
「今まで不滅だったものがこれからは不滅じゃなくなる」
なんてことがあるのだろうか。

>>62
断末魔の叫びなんだから生暖かく見守ってやれよ

Javaはこれからも不滅だ！！！！！！！！！！！！
Javaはこれからも主流だ！！！！！！！！！！！！

おーーーいここはJavaスレじゃねーぞ

BCB と VC++ だと煽りあいにならないようで。

>>69
諸説入り乱れるってことがまずないし。

C最高！

C最低！

Cは最高だよ！！

>>73
ｷﾓｯ

Cにはポインタもある構造体もあるおまけに自作関数もつくれる
最高だよ！！！

Cは、やっている時は夢中だけど、終わるとちょっとむなしくなるんだよな。
まあ、うまくいった時の快感がほしくてまたやるわけだけど。

BCBのプログラマはM$に拉致されて、監禁されてC#を作ってます
引き渡しを求めても、もう死んでいますという答えしか返ってきません

Delphiにはポインタもある構造体もある、おまけに自作関数も作れる
さらに、アセンブラも使えて、クラスもあるしインターフェース型もある

最高だよ！！

Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
もうこれ以上のものはないね！

最高だよ！！！

Ｃ++にはポインタもある構造体もあるおまけに関数テンプレートもつくれる
おまけにクラスも作れる、
おまけに演算子の再定義もできる
もうこれ以上のものはないね！

最高だよ！！！

VBはVisualBの略ですか？

>>80
むむっ！

Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
おまけにintやCharも使える、
おまけにlongも使える
もうこれ以上のものはないね！

最高だよ！！！

やったー俺の勝ち！

C++にはポインタもある構造体もあるおまけに関数テンプレートもつくれる
おまけにクラスも作れる、
おまけに演算子の再定義もできる
おまけに例外も使える
おまけに参照も使える
おまけにSTLも使える
おまけにBoostも使える
おまけにLokiも使える
もうこれ以上のものはないね！

>>84
Lokiがそのまま通るC++処理系は少ない。

>>84
ついでにBoostも今の所はボロボロ。

ははは、
演算子の再定義なんてコードが判り難くなるだけ　Variantの拡張で十分さ、ムダムダ！　
テンプレートもあれは抽象化の次元を間違ってるな、ムダムダ

で、いつからここは言語対決スレになったんですか？

>>88
ここはBCB vs Delphiスレになりました（ﾟ∀｡）

やはり一番プログラムを書きやすいのは68000アセンブラだな。
直感的に書けば、思ったとおりに動く。

H8-500シリーズもアセンブラで書きやすいね

BCB VS VC++はVCL VS MFCとほぼおなじBCB VS VC++
はVCL VS MFCとほぼおなじBCB VS VC++はVCL VS MFC
とほぼおなじBCB VS VC++はVCL VS MFCとほぼおなじBCB VS
VC++はVCL VS MFCとほぼおなじBCB VS VC++はVCL V
S MFCとほぼおなじBCB VS VC++はVCL VS MFCとほぼおなじBC
B VS VC++はVCL VS MFCとほぼおなじBCB VS VC++はVCL VS
MFCとほぼおなじBCB VS VC++はVCL VS MFCとほぼおなじBCB VS VC+
+はVCL VS MFCとほぼおなじ

OWL最強

この板相当低レベルな雑談板になってるみたいだね｡
あるいは数人で上位スレを荒らしまわってるのかな?

大学が休みに入ってるから仕方ない。。。

Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
おまけにintやCharも使える、
おまけにlongも使える
おまけにwhileも使える
おまけにforも使える
おまけにifも使える
もうこれ以上のものはないね！

最高だよ！！！

>>96
C++スレでなんでCの話視点の？

>>96
だんだんショボくなってきてるぞ。

>>96
C++はCでできる事は全部できる訳だが・・・・
C∈C++ です。

BCBで100ゲッツ

　

>>97
ここはＣスレだよ。

Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
おまけにintやCharも使える、
おまけにlongも使える
おまけにwhileも使える
おまけにforも使える
おまけにifも使える
おまけに乱数も使える
おまけにアルゴリズムも使える
おまけに配列の初期化も使える
おまけに変数も使える
おまけに#includeも使える
おまけにC++より実行速度が速い
もうこれ以上のものはないね！

最高だよ！！！

>>102
Cスレじゃないよ。BCCとVC++を対比させて語るスレだよ。

>>102
全部C++でも使えるという突っ込みは無しか？

＞　　　　　 ／⌒⌒〆ヽ
　　　　　//ノノﾉ ＼ ヽ　
　　　　　|(| ∩　 ∩ |)|　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 从ゝ_ ▽_ ノ 从　＜　え〜動く改造バカ一台♪
　　　∋8ノハヽ8∈　＼ 　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 （´�D｀　）_ ノ 　 |
　　　　　∪　.Ё|＿＿ノ|
　　　　　　∪ ∪

ようするにBASICが最高ということだ！

>>104
>>99でガイシュツだから書かなかった。
馬の耳に念仏かと。

TurboPascalやDelphi、VCLの開発者であるヘルスバーグ氏がBorlandから
Inpriseへ社名変更するときにMSへ移って以来、MS派です。
おかげさまで.NETのライブラリがVCL改良した程度なので快適な生活を送っております。

誘導

最高に頭悪そうな発言をして下さい【マ板】 paat4
http://pc.2ch.net/test/read.cgi/prog/1042377112/

おい！！！！このスレの題名をみろ！！！！！

DirectX9をダウンロードしようと思い
dxwebsetup.exeこんなファイル名のをダウンロードしたのですが
これがDirectX9なのでしょうか？

>>102
C++より速いかどうかはコードやコンパイラの性能によると思うが・・・

>>111
なんでこのスレにコピペしてんだ

実行速度は置いておくにしても、それ以外の項目はほとんど全ての言語に当てはまる罠。
QuickBASICだってファイルも配列も…'$INCLUDEもできるぞ(w

MS嫌い。
だからBCB使う
極力MS買わない。
ああ、ひねくれてます。

VC++.NET入れてみたよ。BCBと共用してます。
VC++.NET難しー！！全然わからん。こんなんで本当にWindowsの
プログラム作れるのか？
コードの質は確かにいいね。

>>115
ひねくれとは言わないね。
人間として当然の感性を持っていることを恥じる必要はないのだよ。

ひねくれてるというのはMS嫌いなのにMSのOSで動く言語を使うような事とかだろう。

MS 嫌いだけど、主流の OS は MS だからそれを使う。-> OK
でもコンパイラぐらいはまともなの（BCB）を使う。-> OK

自然ですが、それが何？

>119

BCBが「まとも」というご意見ですが、何が「まとも」なのですか？

実測データをもとに科学的な根拠を明記するべき。

>>120
> 何が「まとも」なのですか？
コンパイラが。
> 実測データをもとに科学的な根拠を明記するべき。
何が気に入らないのか知りませんが、空気も読まずに
随分偉そうにモノを要求しますね:-P

>>121
自然に考えたらコンパイラの何が「まとも」かってことだろうに。
何がまともか言えないのがバレバレ

>>122
> 自然に考えたら
自然、などという怪しげな表現で押し通そうとする余裕の無さは
一体なんなのでしょう(笑)
> 何がまともか言えないのがバレバレ
願い事と現実はいちおう切り離しておくべきでは? :-P

>>123
話がずれているので戻す。

BCBのコンパイラのどこが「まとも」なのですか？

まともって定義をしてから言えよって感じか？

しかし、そいつがマトモだと思った基準でまともなんだろ。

実際 BCB は俺の基準でもVCよりマトモだしな。
まあ、次のVSじゃ、だいぶ改善されたそうじゃないか。よかったね。

だから、そいつが「まとも」だと思ったことを書けばいいんじゃん。
聞いてるのは「まとも」かどうかじゃなく、「まとも」の理由ですね。
他人が定義することじゃないですよ。自分の意見すら言えませんか？

>>126
まともなんてのは感情で、綺麗とか凄いとか旨いとかいうのと同じだよ。
本人がそう思ったんならそれでいいじゃん。

細かくみりゃ、単にコンパイルオプションがデフォルトではそうなってないとか、そんなレベルの話なんだろうしね

>>127
> 本人がそう思ったんならそれでいいじゃん。
だからいいって言ってるだろ。
思うのは勝手、理由を述べろって事。

templateも名前空間もまともに扱えないMSのｺｿﾊﾟｲﾗなんぞｲﾗﾈ

BCB は VC++ よりもより ANSI に準拠していて、他の C++ コンパイラとの移植性が高い。

VC++ は、MFC ぐらいしかついていないが、BCB は VCL が使えるから、より使いやすい。

>>130
Cの移植性か。もはや神話だな。

>>130
VCL使ったコードを他のC++コンパイラに移植してください。

正直、コンパイラの性能はどうでもよくて、
ライブラリでBCBを選びまつ。

>>132
C ではない。C++ だ。
まともなプログラマは、問題領域は ANSI C++ で、コンピュータ領域は VCL など
処理系やプラットフォーム依存のライブラリで書いている。

正直、ライブラリはどうでもよくて、
ポトペタで作れるからBCBを選びまつ。

>>133
馬鹿だなあ。
VCL を使う部分はコンピュータ領域のみ。
問題領域、ロジック部分は ANSI C++ で書く。
VCL を使う部分を移植する場合は、移植先のプラットフォームのライブラリで
記述する。
そんな使い分けもできないのか。
だからそんな頓珍漢なお願いをするんだ。
出直して濃い。

>>135=>>137 ﾊｯｹﾝ
http://www.google.co.jp/search?num=20&hl=ja&ie=UTF-8&oe=UTF-8&q=%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E9%A0%98%E5%9F%9F+%E5%95%8F%E9%A1%8C%E9%A0%98%E5%9F%9F&lr=lang_ja

>>136
初心者のうちはそれでもいいけど、ちゃんとクラス設計をして、
VCL や Windows API でしか実現できない部分と、ANSI C++ でも実現できる
部分とに分けて、ANSI C++ で記述できるところは特段の理由がない限り
ANSI C++ で記述するようにする。
すると、ユーザ・インターフェースや通信部分以外は、他のコンパイラで
そのまま利用できる。
VC++ だと、それすらやりにくい。

>>132
君の頭の方が神話だ。

> 他のコンパイラでそのまま利用できる。
> VC++ だと、それすらやりにくい。
矛盾してますよ（ｗ

>>141
矛盾していない。
BCB などのまともなコンパイラ同士なら可能。
VC++ は ANSI C++ の準拠がへっぽこだから、BCB などのまともなコンパイラ同士では
ソースが交換できるのに、VC++ だけ交換できないことが多い。

>>141
(´-`).｡ｏＯ（どこが矛盾してるんだろ・・・）

>>143
>>141 はコンパイラに BCB と VC++ だけしかないと思っていると思はれ。

C++のコンパイラにBCBとVCとGCCしか思いつかない人は氏んでください。

>>145
zotec C++

>>139
> すると、ユーザ・インターフェースや通信部分以外は、他のコンパイラで
> そのまま利用できる。
以外の部分って何よ？ まさか標準ライブラリを自作したものとか言わないだろうな。

>>147
(´-`).｡ｏＯ（この人の作る物はｲﾝﾀｰﾌｪｲｽだけなの・・・？）

>>148
逝けてるな。

>>147
> 以外の部分って何よ？

問題領域。
FFT とか、シミュレーションとか、広い意味でのデータ処理。
ユーザ・インターフェースとは関係のない、データ処理の本質的な部分。

> まさか標準ライブラリを自作したものとか言わないだろうな。

全然違う。やりたきゃやってもいいが。

>>147
俺が思うに・・・
見てくれのｲﾝﾀｰﾌｪｲｽとかは、OS依存だが、
内部の処理は、ちゃんとANSI C++で書けば、
どのOSにも使いまわしができるってことだろ？
おばかちゃん。

>>147

> まさか標準ライブラリを自作したものとか言わないだろうな。

わかっとらんな。
標準ライブラリを自作したコードが、ANSI C++ の範囲で書けるわけなかろう。
コンピュータや OS ごとに記述を変えないですむようにするための標準ライブラリ
でもあるわけなんだよ。
なんのための標準ライブラリなんだか……

BCBは何の略だよ
コンパイラの意で使うならbccとかbcc32と書いてくれ

>>151
まさにその通り。

>>153
検索して調べてみなさい。業界の人なら常識だ。
（VC++ って何の略だよ。コンパイラの意で使うなら cl.exe と書いてくれ、
というのと同じレベルだ）

>>151
そして、ANSI C++ の準拠がへぼな VC++ では、それがネックになっている。

(´-`).｡oO( bcc32という単語を出しているﾔｼに「検索して調べなさい」って、ｱﾌｫか… )

(´-`).｡oO(にしてもずいぶん釣れたなぁ。)

BCBは、ちゃんとしたANSI準拠ｺﾝﾊﾟｲﾗを作っている。
VC++は、VC++独自言語を作っている。
そういう意味では、どちらもヘボではない。

・・・ってことでOK？

(´-`).｡oO( 漏れはRAD開発環境はBCB,コンパイラはBCCと呼び分けてるけど… )

>>159
VC++ が C++ とは別の言語だよと明示してあれば。

M$のロードマップだと、だんだんとVC++もANSI互換性は向上するそうだよ
ただ、..NET対応の為に BCB以上に拡張もされてしまうだろうけど

>>161
BASICとVBは別物。
C++とVC++は別物。

こういう認識で行ってみよう。

拡張されてもいいんだけど、最低限 ANSI C++ を高い互換性で理解できるという、
ベースのところで仕様をしっかりしてくれれば、C++ コンパイラとしては合格だろうな。

>>162
いくら拡張されようが、ANSI準拠コードをコンパイルできれば問題ないだろう。

>>165
いまの VC++ は、ANSI 互換オプション（しかも大して互換じゃないが）を
ON にしてコンパイルすると、今度は MFC のコードが文法違反でコンパイルできない
とかお茶目だけど、そういうのがなくなれば VC++ ももっと使いやすくなるよね。

みんな回り道している間にこうなってしまっているぞ。
どうする？取り返しつくかなあ。

http://www.deai-navi.net/linkrank/linkrank.cgi?mode=in&id=fdeai

>>167
ああ。
実に気分が萎えた。

結局、VCも BCB+VCLみたいに VC+.NETな感じになるでしょうね

>>167は「出会いナビ 日本最大級★出会いのポータル」でした。

盛りあがってるね。
燃料を投下した甲斐があったよ。俺って神だね(^^)v

また厨房が出てきたよ。┐(´ｰ｀)┌ ﾔﾚﾔﾚ

最近、仕事でＢＣＢとＶＣ使ってます。
緊急でＧＵＩアプリが必要な場合はＢＣＢ。
複雑な処理が多いものや、コンソールアプリ、ＤＬＬはＶＣ６使ってます。（デバッガが強力なので）
ＢＣＢは、ＧＵＩアプリ作るのはＶＣと比べて物凄く楽だけど
デバッガが腰が抜ける程、貧弱だよね・・・。
ＶＣのデバッガまでとは言わないけど、もうちょっと機能付けて欲しい。
ＢＣＢのデバッガ使ってるとＧＤＢ使ってる様な気分になる・・・(；´Д｀)

>>173
どこらへんが貧弱？
機能的にはBCBのが上な部分もあると思うけど。
インターフェースのことを言ってるなら同意。
慣れれば使えるけど。

>>173
VC6 のデバッガ、BCB のよりどんなふうにすごいの？

C++Builder6
例外をthrowするとその先をトレースできない。
デバッグ後、再コンパイルなしで実行ファイルを
コンソールから起動すると落ちる。
それからコンストラクタありのstaticオブジェクト
があると非常に不安定。
（つーかちゃんと正式にアップデート出してくれ）

VC++6
言語仕様がなんか変
標準C++入門テキストのソース通らなそう
初心者にお勧めできない。

>>176
> 例外をthrowするとその先をトレースできない。

ウソ。

> それからコンストラクタありのstaticオブジェクト
> があると非常に不安定。

バグだね。BCB5 を使おう。BCB フリークでは BCB6 はまだ買わない方が
いいとされています。

>>176

>それからコンストラクタありのstaticオブジェクト
>があると非常に不安定。

このスレと前スレを読んで、英語版のUpdate2以降を当てれ。
IDEが英語化けしないようにインストールすればOK。

>>177
ええぇ！？
BCB6より、BCB5の方がいいの！？
・・・BCB6買う所だった・・・
今なら、5買った方がいいのかな？

>> 例外をthrowするとその先をトレースできない。
>ウソ。
throw std::runtime_error("エラーです");
と途中にあるとアセンブラの画面でとまるが。

>>180
そう設定しているからでしょ。
もし例外で止まらないように設定してあるのに止まるのなら、BCB6 のバグだね。

>>179
VCL が一部書き換えられていて、BCB5 にはないバグが少し多いので、BCB5 を
使った方が快適です。
たとえば、TThread クラスが書き換えられていて、まだバグがあったりします。
詳しくは C++ Builder Mailing List の過去ログを見てね。

BCB6で、WinXPのエクスプローラにある、
DHTMLみたいなメニューコントロールは足されてる？

文字メニューをクリックすると、下に文字メニューがいっぱい出るヤシ。
例えば、「ファイルとフォルダのタスク」文字メニューのサブが「このファイルの名前を変更する、、、」とか。

>そう設定しているからでしょ。
例外処理のデバッグに関するスイッチはない。

>>184
ネタか？ もう一度良く調べろ。

なるほど、BCBは6より5の方がいいのか。
Delphiは7が出たけど、あれはどうなんすかね。

>>186
Delphi 7 はいいみたいですよ。
同じバージョンの BCB と Delphi は基本的に同じ VCL を使っているんですけど、
Delphi ML や BCB ML を見ていると、Delphi 7 のはだいぶ改善されているそうです。
持っていないので実際は知りませんが、詳しくは量 ML の過去ログを。
Delphi 7 で VCL が改善されているのに、どうして BCB7 が出ないんだろうねなんて
話題も書き込まれていましたから、Delphi 7 はいいのでしょう。

>>184
オプションあるですよ。それじゃなかったら、俺の愛用している CppUnit for C++ Builder は
まともに動かない。

>>187
「何が」改善されたのか？

長々となんか書いてるが情報量0だぞ。それ。

ボーランド->インプライズ->ボーランド
社名を変えた理由は一体なんだったんだろうか。

>>188
ML を見よって書いてあるんじゃ？
おんぶに抱っこ君はプログラムできないね。

>>189
どっか Linux の会社と組んでなんかやるのに INPRISE にしたけど、
破談になったので戻した。

>>190
情報の提示も出来ない奴がML会員か。どんなレベルのMLだ？

>>190
MLって情報を発信する人のためのコミュニティだと思われ。

>189
結局知名度による影響。売上や株に悪影響を及ぼした。
検索等で使われるのはいつもボーランドで、
インプライズのニュースには「ボーランド」と注釈が必ず入った。
まあ、インプライズって覚えにくいし。賛同者もいなかったよね。

>>192
知りたいなら、検索して読んでみるだけのこと。

どのMLかくらい教えてあげれば良いのに。。。。

>>196
>>187 に書いてないか？ < Delphi ML & BCB ML

VC++にインラインアセンブラってありますか？

あるよ

ついでに200ｹﾞｯﾂ

198=199=200

ﾜﾗﾀ

なんだかんだ言っても、仕事じゃソースの納品規定がＶＣなんだよな〜。
ＢＣＢは家や、開発チーム内で使うツールのみにしか使ってない。（重宝してる）
まぁ、EXCELみたいにデファクトスタンダードだしね。ＶＣ。

>なんだかんだ言っても、仕事じゃソースの納品規定がＶＣなんだよな〜。
チミがバイトや外注を使う機会が訪れたときにBCBを指定すればいいだけの話。

>>204
何ムキになってるの？

ｷﾑﾁ

>>206
何キムチになってるの？

オイキムチになってまつ

>>207
たまにはキムチの気むちになるのもいいもんだ。

キムチの気持ちか…。
とりあえず唐辛子漬けになるのは勘弁だな。

キムチばっかり食べると痔になりますよ。

>>211
とっととキムチになっちゃえばそんな心配は無い。
痔になるなんてのはキムチになれない奴の戯言。

ｷﾓﾁ(･∀･)ｲｲ!!
キムチの気持になってみますた

キムチ・・・食いすぎて腹こわした。。

結論 (ﾟДﾟ)ｳﾏｰ な順位

キムチ >>>> VC++ >>>>>>>>>>>>>>>>>>>>>> BCB

ただいまよりこのスレはキムチスレになりますた。

キムチビルダー＋＋きぼんぬ

七瀬スレム板分室になりました。

初心者でよく分からないのですが、やっぱり韓国製のキムチは日本のよりも激辛だと考えてよろしいでしょうか？

BCBの方がUI作りやすいのでBCBに一票

キムチの方がチゲ作りやすいのでキムチに一票

VC++ に一票

VC++ に一票

VC++ に一票

VC++ に一票

VC++ に一票

VC++ に一票

>>219
韓国の唐辛子は日本の唐辛子の辛さの 1/10 です。
キムチも、韓国のキムチの辛さは日本の 1/10 ぐらいです。
日本にキムチは辛すぎるんです。

>>228
キムチネタはもういらん。

訂正
> 日本にキムチは辛すぎるんです。
日本のキムチは辛すぎるんです。

>>220
BCB は UI が作りやすいだけじゃなくて、OO すること自体やりやすい。
VCL は Java のライブラリほどではないけど、ちゃんと OO として設計
されているから、それを OO の手法で自然に利用できる。
MFC はクラス・ライブラリだけど、OO ではないので、不自然になる。

>>231
VCLは多重継承が出来ないからクソ。しかもC++だからインタフェースもない。

>>232
多重継承ができず、インターフェースがなくて、どう困った？

>>232 は、やっと覚えたての多重継承が自慢でたまらないと思はれ。

>>233
observerパターンが適用できない。

>>232
表面的なことにこだわっているね。
C++ には、多重継承ができないライブラリもあるけど、Adaptor パターンとか
知らないのかな。

>>232
多重継承が出来て便利なケースは具体的に答えられますか？
俺はほとんど必要ないと思うが。C++PrimerのP995から読んでみて
いるが、今ひとつ理解できない。

あ、でも、std::istreamとstd::ostreamはstd::iosから派生し、
std::iostreamはstd::istreamとstd::ostreamから多重継承して
いるね。卑近にこんな例があったとは・・・

>>235
>>236 のようにすればいい。
または、TMyForm をもつクラスを Observer にするだけのこと。
たとえば、TFormObserver クラスを VCL を継承しない純粋な C++ クラスとして
つくり、それに TMyForm へのポインタを参照させればいい。
それだけで Observer パターンになるよ。
VCL がクソなんじゃなくて、>>235 の頭が固い。

MFCが仮想関数でイベントをハンドルしないのが糞。
(これはWindows3.1時代からの負の遺産ではないかと思う)
VCLだとコールバックは仮想関数で
関数ポインタいじったりテーブル定義したり
ごちゃごちゃやる必要なし。

>>238
でも、自前で多重継承を使ったライブラリを作るのは、特別な理由がない限り避けた方が賢明。
多重継承の振る舞いは、いろいろな場合わけをしないといけないから、それだけテストも
たくさん書かなくちゃならない。
そうする価値がある場合以外はしない方がいい。

>>236
多重継承できないからAdaptorパターンにも制限が出てしまうね。
まぁ、Adaptorパターン使わないといけない時点でOO的に不自然んだが。

>>239
そんな風に作っていくとRADが凄く使いにくくなるよ。

>>242
VCL と、自前のクラスとの区別ができてます？
多重継承ができないのは VCL とその派生クラスだけだよ。
>>239 の TFormObserver は、多重継承はできるよ。
それに、Adaptor パターンは多重継承とは関係ない。
仮に、多重継承ができない場合でも、Adaptor パターンが制約を受けることはない。

そもそも、何か作る時点で多重継承が気になること自体、クラス設計を間違えているか、
basic_ios の作者かメインテナであるといった特別な場合に限られる。

>>243
全然ならないけど。
RAD 部分とは関係がない。

>>243 は、クラス設計をせずに、VB のように TForm のハンドラの中にどんどん
コーディングしていくだけのプログラマだと思はれ。

>>246
それでも、そこそこ動くモノができてしまうのがＢＣＢのいいところであり、
悪いところでもあるな。

>>240
メッセージマップは、仮想関数テーブルの節約と、処理速度向上のためだそうだ。
設計よりバイナリをとったって事だろうな。

>>247
そこでやめてしまうこともできるし、そこから進みたい人には進めるようにできているのが
BCB のいいところだね。

>>248
BCB は、メッセージマップもできるんですね。
もし計測して本当にパフォーマンスが上がるのであれば、VC++ と同様のコードを書けば、
簡単にメッセージマップを使える。
というか、VCL 自体も、親クラスで VC++ のようにメッセージをマップして、イベント・ハンドラの関数を
呼び出しているだけ。

BCBのクロシージャはC#のdelegateみたいでクソ

>>248
そうやって変に OO ライクなところとパフォーマンスを取るところとをポリシーなしに
設計しているから MFC はいびつなクラス・ライブラリになるんだね。

>>251
__closure だろ？ < クロジージャ
あれは delegate じゃない。

delegate 使いたいなら AspectJ とかだな。

BCBはコード補完遅すぎ。

なくても大して困らないが。

>>255
補完の秒数を早くしたら？

>>248
BEGIN_MESSAGE_MAPとEND_MESSAGE_MAP知らないんでつか？

>>239のTFormObserverは多重継承できない欠点を補うためだけに
存在しているのであって、設計自体には本来不必要なものだ。
多重継承できないVCLはやはり設計を複雑にさせる。

>>252
その思想は .NET にも受け継がれています。
C# は、ソースの見た目ばかりで、バイナリを省みない Java の様には
ならないように設計されています。
ソースの見た目のみの Java は極端な例にしても、
最適なバランスはグレーな位置にあるのは、
現実世界では一般的なことだと思います。

ここではC#とかJavaは関係ないだろ

俺はｱﾝﾁﾃﾞｻﾞﾊﾟﾀのOO主義者なんだけど
MFCはもちろんVCLも好きになれん

>>259
多重継承できるよりは、クラス 1 つ分複雑になるけど、VCL でそのままできないのは
Observer パターンだけなんでしょ？
だったら、MFC より VCL の方が、それを差し引いてもあまりある利便性があります。

VCL のクソ派は VCL の悪いところをあげて、VCL 素晴らしい派は VCL のいいところや
回避方法を挙げたりするけど、MFC 素晴らしい派は MFC がどんなに素晴らしいのか
教えてよ。

>>260
MFC のは「思慮がない」というレベル。
同じ事をするのにも、統一性がない。あるときはメンバ変数への代入だったり、
あるときはメンバ関数の呼び出しだったり、あるときはメッセージのハンドルだったり。
同じコントロールなのに、ダイアログ上にあるときと、パネル上にあるときと、MDI の
時とで扱いが全然異なる。
すごく複雑。
だから、まあ MFC の本が売れたりするんだろうけど。

>>265
コントロールのカプセル化に失敗していると思はれ。
MFC は、たくさんある Windows API を覚えるのが大変だから、コントロールごとに
ちょいとまとめようね、ぐらいのノリだから。
Windows API がニーモニックなら、MFC はマクロ・アセンブラのマクロのようなノリ。

MFC 素晴らしい派なんていないよ。
ただ俺みたいにシェアウェアつくってると、
物を出来るだけ高速・高機能にしたい。
しかたなくMFCかなと。

BCB でも MFC 使えるけど、BCB の使いやすいところと、必要ならそこだけ MFC を使うという
スタンスで BCB 使っている人はいないのかな。

俺はATL/WTLがよくできてると思ってるんだけど

>>268
俺も最初はそうしようかと思ったが、結局BCBとVC7両方入れている。

IDEの支援で糞ソース生成するのは、得る物も大きいが失う物も大きい。

>>271
BCB 使ったことないでしょ。IDE は糞ソース生成しません。VC++ は変なスケルトンを生成しますが。

>>271
失うものはないと思うが。
糞か知らないけど、IDE が生成するソースの仕組みを知りたい人にとっては、
ソースが生成される以上に得るものが多い。

>>272
変なスケルトンと糞ソースの違いはどこ？

VC++のAppWizardのことなら
「こんなに簡単に、こんなアプリケーションが出来ちゃうの？」v(￣Д￣)v
「なだよこのソース、パズルかよ、意味わかんねーよ」(+д+)
とモチベーションを急降下させるのが問題かな

BCBの何もないフォームを生成しただけで凄いサイズになるのは何とかして欲しい。

確かに。ぶくぶくって感じだよな。

MFC の場合は、DLL で追い出してあるからサイズが小さく見えるんね。

スタティックリンクで比較しても結構違うと思うよ。

そっか。
サイズは BCB の負けだな。
TForm だけのアプリケーションを作っても、全部のメソッドを利用している
わけではないからなあ。

>280
Tiny版も欲しいとこだね。
つーか、VCLのソース入ってるんだから、余分なもの削除して、
小さい版て作れないの？

確かに VCLを使うと　実行時型情報の実現の為に色んな下支えが必要になるからね
でも、HDD1ギガの時代ならともかく
0.1テラの時代に、気になるサイズか？　FDに入れて実行する事も可能なサイズなんだし。

>>281
Delphiで小さい実行ファイルをのスレで紹介されてるKOLは使えないのかな？

>282
例え、HDDが1Gになろうが、気になりますが何か？

>>284
じゃあ、やっぱりDelphiで小さなで紹介されてる実行ファイル圧縮ソフト使え。半分くらいになるよ

え・・なんで圧縮ソフト？
ソースの話は？

実行ファイル圧縮ソフトを使ったらどのソフトも半分くらいになるので
結局Delphiで作られた実行ファイルが大きいのは変わらない。

>>287
VCで2KB位のプログラム作ってUPXで圧縮しようとしても、
Program is too smallとかエラー出て圧縮さえ出来なかったぞ。

今試したらProgram is too smallじゃなくてNotCompressibleExceptionだったけど
どっちにしろ1バイトも圧縮できない。

>>289
今ハンドアセンブルで
00000000: 4D 5A 60 00 01 00 00 00 04 00 00 00 FF FF 00 00
00000010: B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040: 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 0D 0A
00000050: 49 74 74 65 79 6F 73 68 69 21 21 21 2E 0D 0A 24
って作ってみたらfile is too smallって出たぞ。

まったく、285は役に立たないなあ

そういえば、VC++ ってデフォルトで RTTI が OFF になっていて、virtual デストラクタが
うまく働かず、はまったことがあります。
OO するためじゃなくて、純粋にパフォーマンスを求めているのかな。

RTTI OFFでもvirtualデストラクタは動くだろ。

class A {
virtual ~A();
};
class AChild : public A
{
virtual ~AChild();
};

のとき、

A *a = new AChild;

して、

delete a;

は、VC++ のデフォルトではデストラクタ AChild::~AChild() は呼ばれまへん。

>>294
VC5のとき、派生クラスにオーバーライドした関数を追加したら
リビルドしないとオーバーライドした関数がちゃんと呼ばれないときが
あったけど、そういう話ではないの?

>>295
確かめるために、両方のデストラクタに ofstream でログを吐かせてめっけたので、
両方のクラスは再コンパイルされていたはず。リビルドしたかは忘れた。

http://www.agemasukudasai.com/bloom/

>>294
それはRTTIとかとは関係なくバグだろう。

BCB派でVC++使ったことある人は結構いそうだけど、
VC++派でBCB使ったことある人は少ないような気がする。

VC++とDelphiがあれば十分

VC++とDelphiとBCC55があれば十分

VC++とDelphiとBCC55とnasmがあれば十分

織田信長だけで十分。

明智光秀だけじゃ自滅

徳川だけで300年

牛丼一筋300年

屁のつっぱりはいらんですよ

ここまでのまとめとしては、Javaが最強ということでよろしいか？

>>308
COBOLだっての。

>>308
そうゆうこと。

Java厨が粘着だということが良く分かった。

>>311
思い込みたい内容を相手から見て取りたいだけでしょう。
馬鹿ですね（ｗ

>>312
ん？ 粘着って言葉にむかついたのか？
じゃあJava厨が無意味にあげてると真実を述べてあげよう。

>>313
あなたじゃあるまいし、別にむかつきませんよ。
それにしても、Java厨が、とか決めつけるあたりが最高に馬鹿ですね（ｗ

14日は2chが落ちる日…。

>>314
Java厨必死だな (激藁嘲笑

>>316
> (激藁嘲笑
おやおや、こんな余裕の無い煽りを引き出されちゃってまぁ（ｗ

>>317
プログラム板初心者がなんだか調子に乗っております。

>>318
妄想でしかものを書かないのですね（ｗ

そういうことにしたいのですね(・_。)ｽﾞﾘｯ

GCC >>>>>>>>>>>>>>>>>>>>>> JAVA >>>>>>>>>>>>> VC >>>>>>>>>>>>>>> BCC

だろ。異論あるか？

>>321
ある

Java > BCB >> GCC = BCC >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VC++

ぐらいだろな。

Delphiがねぇよ。

C++ >>>>>>>>>>>>>>>>> 漏れ

>>324
なにが「こう」なのでしょう。肝心なところをぼかした稚拙な文章ですね。
いずれにせよ、正しくは
「すぐJAVA厨とみなしたがる厨が来るとｽﾚがこうなるという見本」
なのでしょうけど（ｗ

Javaはいつまでも主流なのさ！

DelphiとBCBって一般的にどちらが実行速度は高速なのですかね？
やっぱり、BCB？

>>329
Delphi

>>329
一般的にはC++でよかろうと。ちうか、Delphi と C++ は指向が違う。

実際にはDelphiとBCBはどんな感じで使い分けたらよいのでしょうかね？
今は専門学校生なので実践的な事は分からないのです。

>>332
　自分で両方使えるなら、主にDelphiで、
　C++ソースが手に入った部分はBCBを使う

Delphiで書いたコードはそのままBCBで使えるから

>>333
分かりました、そうします。
ありがとうございました。

>>329
一般的にはC++が速い。
ただし文字列まわりはコンパイラが直々にサポートしている分Delphi。
(C文字列を扱うほぼ全ての関数についてまわるstrlen相当の処理が要らないから)
あと関数呼出しを多用したりするなら__fastcallがデフォで、関数内関数も使えるDelphiが若干有利。
ついでに、何故かlong double(10バイト浮動小数点)使う時もDelphiが速い。(実測経験あり、理由は不明)

まあ、inline関数とかtemplateとかは、そういう細かいことを吹き飛ばして余りあるぐらい強力なので、
C++が速いと思っておけば間違い無いかと。
というかDelphiが速いのはこんな特殊ケースぐらいしかないし。
ObjectPascalコンパイラ(dcc32)は速度優先で最適化明らかに手抜きだしなー。

んでもって、使い分けは、好きにすればいいんじゃない？
BCBなら両方のソースが使えるわけだし、
C++一本で行こうとしても、BCBでVCL使う限りは嫌でもPascalソースに触れることになるし。

と、ここまで書いて、遅かったことに気付いたわけだが(哀

最適化については、今時、あんまり気にしない方がいいかもしれない。
キャッシュにあるかどうかの差はCPUの世代毎に大きくなるばかり

inlineとかtemplateは確かにそこだけベンチマークを取れば速いって結果になるけど、
その結果コードサイズが肥大化してしまうようでは逆効果の時代だしね。

BCB も Delphi も実行速度は大差ないよ。
コンパイル速度は Delphi がダントツだけどね。

結局VCLばっかり呼び出してたら、どっちも変わらん罠

JAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVA
JAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJVAA

Javaじゃないところが(ﾜﾗ

まあ、普通は気にする必要もないけど、遅いと体感できるような箇所ではやはり効果があるものなので

実際VC++使ってる企業が多く、BCBは少数でしょ？
VC++使えなきゃまずくない？
BCB使えればVC++もつかえるの？

>>342
で？ VC++ で何作るの？　単なる労働者になりたいならそういう道もあるよね

VC++の俺的最大の謎は、long doubleとdoubleが同じだったりすることなのだが。
MSがExtended浮動小数点型(IntelのFPUの機能)を使わないなんて信じられん。

VC++使ってるところも、大部分VBで作って、API叩く部分なんかをVC++というパターンが多いんじゃないのかな。
それだったら、全部BCBというのが楽な気もする。

BCBは企業レベルで使えないほどバグだらけ。
しかも日本法人はやる気0で、外国ではBCB6UpdatePack4まで出てるのに、
日本はBCB6のアップデートパックなんか一つも出してない。
致命的なバグの修正もたくさん入ってるのに。

>>346
スジはいいのになぁ。

>VC++使えなきゃまずくない？
まずくない。もうWindowsのプログラムでは利益が出ない。

VC++ のほうがバグ多いような気がするけどな。ましてやプラットホーム
は自社製の OS だというのに。

>>342

企業というか仕事ならクライアントの希望もあるしなー。
某のコンパイラよりM$を使うことが多いのは伝統というか保守性というか。

おうちで自分で遊ぶ分には、結局好みの問題に落ち着くと思う。
そういう俺も仕事はM$、趣味は某。GUI弄るの楽だからね。

C++とDelphiは、やっぱ参考書籍とか情報が違いすぎるね。
本屋さんに行けばわかる。

本屋さんいけばなんとかなるような仕事しかしてないからこの不況なんだろうよ

>>351
バブルのときは「専門書って何？」って人たちが大手を振ってプログラマを名乗って
いましたが、それが何？

Win98環境だから
VC++.netは絶望・・・
BCB6は無用の長物だろうか？
動作環境のこの壁は一体なんだ？開発ツールがこんなに重くてどうする・・・
BCB5で我慢するか。

>>352 　よく知らないが、それは今でもそうなんじゃない？　
残業酷くて勉強する時間も無いようだから、状況が変ってるとは思えない。

結局は、悪循環なんだろうな。

>>353
漏れも去年まではCeleron 1.4G + BCB or VC++.NET で開発していた
けど、重くてしょうがないので思い切って P4 2.8GにしたＹＯ！
結構軽くなって満足。やっぱ最近のCPUは違うよ。

P4なんて出たんだ・・。

>>356
Pentium4とタイプするのが面倒だからP4にしてる。いつもそう（ｗ
さすがにCeleronがCじゃわからないけどね（ｗ

>>357
PentiumはP5な訳だが。

>>358
そう言えばそんなCPUあったっけ。ならP4って略すのこれからやめるよ（ｗ

とりあえず、VC++/MFCが標準、BCBが亜流という時代はｵﾜﾀ。

VC++は言語仕様からハズレ、
MFCはバージョンアップは停止された（が、得意のバグふぃクスでアプした）、
MFCは.NETもサポートしない、
VC++が他OSを対応する可能性は０。

VC++は 次のバージョンで ANSI互換性を98%にするそうだ
VC++は CE 用に・

VC++はCOM用に最適化されてる。
COMが死んだ、というか、もともとCEでCOMは動作しない。
良いところが無いのにダイアログエディタで開発効率落としてくれる...
VC++は全てが終わった世界。

残念だが、次BCBがCE、DOS、Win16、.NET、Linuxサポートとなってる。

gcc3.2最強という事でファイナルアンサー？

>>363
Windowsに関してはちょっと・・・

いまさらDOSやWin16なんてどうでもいい。
もともと .NET FrameworkにC++は馴染まない。他に適した言語がある。。
っていうか、VC++を使ってるプログラマーの大半はVisualStudioユーザだからVC#も持っている。
Linuxには、Linuxに最適な開発環境がある。
Windowsに最適化されたVC++をわざわざLinuxに持ち込もうという発想さえ起きない。

よってBCB厨のVC++批判の大半は難癖。

>>362
> 良いところが無いのにダイアログエディタで開発効率落としてくれる...
意味がよく分からないのですが・・・

>もともと .NET FrameworkにC++は馴染まない。他に適した言語がある。。

いやいや、Windowsでも最悪であることが、360に書いてある。

>っていうか、VC++を使ってるプログラマーの大半はVisualStudioユーザだからVC#も持っている。

さらにVC#という別物も要るわけ？VC++だけでハードディスクがゴミだらけになるのに。ｻﾑｰ

>Linuxには、Linuxに最適な開発環境がある。
そう。Winだけの時代は終わった。VC++の時代も終わり。
あるソースを色んなターゲットに吐き出すのがコンパイラの仕事。基本。

>> 良いところが無いのにダイアログエディタで開発効率落としてくれる...
>意味がよく分からないのですが・・・

これの意味が分からないのは、VC++を実は使うことが出来ないM$厨。
一回でも使った人はリソースのダイアログによる開発効率の悪さに幻滅してるから、文意が分かるはず。

＞あるソースを色んなターゲットに吐き出すのがコンパイラの仕事。基本。
そして理想論。

ひと昔前はハードウエア依存を減らす事がひとつの目標だった
次の目標はOS 依存を減らす事だろうな

>>あるソースを色んなターゲットに吐き出すのがコンパイラの仕事。基本。
>そして理想論。

コンパイラってのはC/C++で書かれてて色んなOSでも実装される。
言語資産の保証は基本。VBやCOM、MFC、WTLが丸ごと消えるのは前代未聞。

クロスGUIライブラリが売り出されては売れずに消えた。
が、近年成功しだしたのが、Delphi/VCLをはじめとするクラスライブラリ。
ま、VC++はお呼びでないってこった。

ま、VC++が他OSに移植されたとしても、COMベースでありゴミでしかないけど...

どっちにしろMSはマルチプラットフォームなんぞ全く考えてないだろ。

GUIライブラリのネームスペースにSystem.Windowsなんて名前を付けちゃうんだから。

java

M$の言うマルチプラットフォームとは
Win32・Win64等、Winの中だけの話でし

マルチプラットフォームの時代は終わったよ。始まってもいなかったけど。

結局ドライバとか低レベルの物を書こうと思ったらネイティブコード吐ける言語がいるわけで。
そもそもVC++とC#は完全に棲み分けが出来ている。
MC++はネイティブとFrameworkを接続させるために使われるのを想定している。

Kylixが少しは賑わっていれば、>>370に説得力も出てくるのだが…
まあ、Win慣れしてしまった俺が明日からLinux使えー！と言われたら、Kylixしか無いだろうけどなー
しかしKylixの現状を見るに、そんな事を言われた人間は思いのほか少ないと予想される。

http://pc2.2ch.net/test/read.cgi/tech/1047322829/615

ZDNetより

　Microsoftの担当者はbCentralが.NET Frameworkに対応していない理由について、
　bCentralの顧客1万5000社からの要望がほとんどなかったためだと説明している。

つまり、MSの中でさえ .NET が既に死んでるって事だ

>そもそもVC++とC#は完全に棲み分けが出来ている。

VC++が要らないし、.NETが既に死んでるし...

>>379
じゃあWindowsいらないじゃん。ぽい。

>そもそもVC++とC#は完全に棲み分けが出来ている。

というか、散々書かれてることを読んでも理解出来ない人が居るんだね。
あるコードを色んなターゲットに吐き出すのがコンパイラ。
なのに、C#がVC++エリアをカバーできないし、逆もしかり。
同じM$ワールド内で...

>>381
＞同じM$ワールド内で...

VC++がN88BASIC用のコードをコンパイルできないのはどうしてでしょうか？

VC++がMFC利用するとANSI C++コードをコンパイル出来ないのはどうしてでしょうか？

答え
VC++要らないからどうでも良いじゃん。

>＞同じM$ワールド内で...

>VC++がN88BASIC用のコードをコンパイルできないのはどうしてでしょうか？

この人頭悪くない？
コンパイル出来る出来ないじゃなくて、カバーするエリアの話なのに。

>>384
＞カバーする範囲。

従来のネイティブなプログラムと.NET Frameworkと言うより抽象度を高め統制した「箱庭」。
実行環境の時点で全然畑が違うわけだが。

>>358
頭悪いの分かったから、もう書かなくても良いよ。

Delphi.NETも出るし、BCB.NETも出るし。
.NETは要らないけど。

>>386
お前も少しは勉強してからしゃべった方が良いぞ。
誰一人として話しに参加してこようと言う奴がいない。お前も俺もかなりの低レベルってこった。

バカふたり晒しage

>お前も少しは勉強してからしゃべった方が良いぞ。

負け惜しみでしか？

>>367
>>> 良いところが無いのにダイアログエディタで開発効率落としてくれる...
>>意味がよく分からないのですが・・・

>これの意味が分からないのは、VC++を実は使うことが出来ないM$厨。

( ´,_ゝ`)ﾌﾟ　　お前の文章能力が無いだけだろうが。
「A のに B」という表現を用いる場合、B は A を否定する内容でないといけないといことを教えてあげよう。

●VC++には良いところが全く無く、特にダイアログエディタによる開発効率の悪さには辟易させられる。
●VC++にはダイアログエディタによる開発効率の悪さに代表されるように、良いところが全く無いといえる。

こういう風に書け。

ここまでの結論としてマルチプラットフォームでオブジェクト指向かつ
GUIの実装も簡単にできる最強の言語は Perl/TK ということでよろしいか？

ゲッ、脱字だ。

× 「A のに B」という表現を用いる場合、B は A を否定する内容でないといけないといことを教えてあげよう。
○ 「A のに B」という表現を用いる場合、B は A を否定する内容でないといけないということを教えてあげよう。

じゃあ、結論。

VC++には良いところが全く無く、特にダイアログエディタによる開発効率の悪さには辟易させられる。

>>392
それよりも
×「A のに B」
○「A なのに B」
の方が気になったよ、俺は

　　>>391 が確信を突く発言をスィタ！


お前らこれからは、事前のコンパイル不要 ".TXT" 構想でいこーぜ！

>>394
それは >>362 の文章を例として挙げただけでしょう。

>>395
パッケージソフトビジネスが崩壊するカモな。

>>397
崩壊ｷﾎﾞﾝ

>>395
これですか？
ttp://www.watch.impress.co.jp/pc/docs/2002/0401/uocchi/ms.htm

>>1-399で導いた結論

趣味ならBCB
仕事ならVC++

でよろしいか？

>>400
散々外出。

趣味なら実をとるが
仕事なら建前優先

でよろしいか？

>>402
違うと思われ。

VC → デファクトスタンダード
BCB → 安置MS御用達

え？趣味なのにMFCで開発するの！？

>>400
前の会社では、GUIはBCB、実装はVC++で顧客用画面を作ったものだ

WindowsXPですが、VC++.NETをインストールしたら、IEが動かなくなった。
結局WindowsXPを上書きインストールしますた。
しかしその後もOutlook Express 6 の起動が著しく遅くなったり、何か変です。

>>406
俺もＸＰは資産継承がイマイチなので見捨てて次まで待つよ。
．ｎｅｔは使わん。

>>407
XPを見捨てるというのと .NET を使わないということにはどういうつながりがあるのですか?

漏れＢＣＢ派、ＶＣ＋＋は最初のあの意味のわからない画面でやる気無くす。
クラスの概念とかなかった初心者にとってはＶＣ＋＋はわけわかんないまま
ＭＳに毒されていくという感じだった。概要を分かっている人にとっては
ＶＣ＋＋の最初に掛かれているいろいろなソースは手間が省けていいかもしれないが
初心者にとってはいいお世話。さっぱりわけわかんなくなっちまう。
んで、俺はＢＣＢ派でＭＦＣはどうせＭＳの世界しか通じないくそクラスの塊。

>>409
で、VCLがどれだけ壮大な世界を持っているというのだ。

>>403 が確信を突く発言をスィタ！

こっちがサンプルムービーのページで
http://homepage3.nifty.com/digikei/sample/sample.html
こっちがHOME
http://homepage3.nifty.com/digikei/

>>411

おれは別にアンチM$ではないが、BCB派だが。

>>413
Ｍ＄などと書く人が公平に見ているとは思えませんが？

>>414
あなたはプログラム板素人ですね？

>>415
ということにしたいんですね。

ＢＣＢ派の無論フリーコンパイラ派ね。

それはシャレ。というかわざわざこんなこと書かせないでほしい。

>>418は>>414へのコメント。ｽﾏｿ。

Java

M$マンセーだったとしても、

>VC++には良いところが全く無く、特にダイアログエディタによる開発効率の悪さには辟易させられる。

これを否定することは出来ない。

俺は初心者なんでよくわからないが、ﾎﾞｰﾗﾝﾄﾞのサイトの
BCBとVC++の比較表には、VC++がボロ糞に書かれているんだが。
あれはもちろん、ﾎﾞｰﾗﾝﾄﾞの策略だろ？

>>422
宣伝だから策略以外に無いのは間違いない。
が、内容は事実。否定出来ない。

>>423
ということはBCBのほうが圧倒的に高機能ってこと？

まぁ、VC++はOS Winを使っている限り 安定性は抜群だとは予想できるが…。

>>424
情報量もVC++のほうが圧倒的に多いよ。

>まぁ、VC++はOS Winを使っている限り 安定性は抜群だとは予想できるが…。
VC++はActiveXベースの開発。ActiveXは不安定。

>ということはBCBのほうが圧倒的に高機能ってこと？
その通り。クラスライブラリの派生で自作コンポーネント貼りまくり。

>情報量もVC++のほうが圧倒的に多いよ。
この多い情報はActiveXに関するものヴぁかり。
ActiveXのコードは暗号みたい。だし、性能悪いし、クラスじゃないし。

>>424
ところが安定してないってのがM$のミラクルなところ

ActiveXが死んだ今、MSDNの情報はゴミと化した。
ゴミが何百メガ。
それに対してBCBのペタペタ貼りまくり＆ＳＴＬ完璧＆、ついでに不要なMFCも対応。

ま、使ってみることさ。
VC++でのリソースで画面定義してActiveXコード書いてると涙出そうになるよ。
次にBCBの膨大なコンポーネントを画面に貼っただけで高速動作するのをみたら、魔法みたいに見える。
ついでにDBまわりもDelphi/BCBが最強と言われてるし。

VC++を使ってる企業の開発の中には
BCB（つーか某）の存在そのものを知らない人も結構いるからな
最初は信じられんかったけど

>>427
> この多い情報はActiveXに関するものヴぁかり。
本当にMSDNライブラリを見たことがあるの？

BCBを愛しているのはよく分かるんだけど、一人で連続カキコしているあたりがイタい。

>>433
イタイ、としか反論出来ないんでしか。
ま、某の宣伝のVC++ボロクソ比較でも読んでなさい。
反論出来ないくせに。

>>429 >>432
MSDN無用は言い過ぎではないかと
俺は主に某で開発してるけど結構MSDNのお世話になってるよ
（特にWindows SDK関係）

>>435
そんなこと言ったって、自分はMSDNのSDKを全く読まないよ。
MS-Cの時代からWin16の開発してたから。

で、Win16からダイアログエディタ使ってたが、VC++はゴメンだね。
そのころ評価が高かったBC++/OWLはシカトしてたけど、BCBは良い。

>>436
あんまり参考にならん意見だな。

サブシステムの開発者光臨age

俺はCFormViewはあまり使わないし、ダイアログも環境設定用に作るぐらいだから
どうやらVC++からBCBに乗り換える必要は特になさそうだな。
VC++の次バージョンではほぼANSI準拠になるみたいだし。

いやいや、ActiveXの死亡はVC++の死亡。
BCBに乗り換えるかどうかは知らんが、VC++は棄てるべし。

ダイアログがどうこう書いてる時点でVC++に毒されてる、手遅れかも。
BCBならコンポーネントのドッキングも標準であるし、
画面の位置あわせもコーディングレスだし。

>>440
言い訳がましいこと書いてるだけで、VC++に良さは無いわけね。

>VC++の次バージョンではほぼANSI準拠になるみたいだし。
今までなんだったの？羊頭狗肉？

そもそもActiveXコントロール自体あまり作ってないしな。一般的なCOMオブジェクトは作るけど。
しかも.NETでCOMが不要になるとはいえ、今現在の仕事はWin32だしCOMももちろん使われている。
だからVC++が今死んでいるとはとても思えないよ。
.NETが主流になったらC#にいつでも乗り換えられるしね。(実は今でもASP.NETでC#を使っていたりする)

やっぱSeaSharpだよね！

440さん、どうも有難う。VC++を使ってる人が非論理的思考であることを教えてくれて。

>.NETが主流になったらC#にいつでも乗り換えられるしね。
Del.NETもBCB.NETも出るのに...

>しかも.NETでCOMが不要になるとはいえ、今現在の仕事はWin32だしCOMももちろん使われている。
不要になるものを使ったり可愛そう。
BCBをやっとけば、無理にCOMしなくて良かったのに...

>だからVC++が今死んでいるとはとても思えないよ。
>.NETが主流になったらC#にいつでも乗り換えられるしね。

この論理の流れはマジですか？キティを装ってるんでしか？

>しかも.NETでCOMが不要になるとはいえ、今現在の仕事はWin32だしCOMももちろん使われている。
>だからVC++が今死んでいるとはとても思えないよ。

「COMが不要になるからVC++が不要」、という流れに対する反論が、
「COMが不要になるとはいえ、VC++が今死んでるとはとても思えない」？？？
ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

もしかしてまなげどC++のことでしか？

まなげどC++は、ダメっしょ。
だって、過去のC++コードを活かせないわけで。ま、それがM$のWin縛りつけ戦略だけど。

でも、BCB.NETは普通のC++コードをコンパイルしてくれるかも。

んなこたーない

M$のCOMはウニックスすると散々宣伝して、動作しなかったのに、
Kylix C++は売り物してるわけだし。
で、次期BCBにKylixバンドルしてくれるって。

(´-`).｡ｏO(某社員必死だな…)

>>454
そういう反論しか出来ないんだ。かわいそうでし。

某の宣伝のVC++比較に一つでも反論してみたら？

悪貨は良貨を駆逐するとか。。。

>>455
その余裕の無さはどこから来るの？

COMの標準クライアントってVBだよね。
VBは出荷停止だし、VC++も出荷停止した方が良いと思ふ。
まなげどC++は.NETし難いわけで。
Win32アプリはBCBの圧勝だし。

(　ﾟдﾟ)ﾎﾟｶｰﾝ

457に(　ﾟдﾟ)ﾎﾟｶｰﾝ

もうね（以下略

>>457
またまたそういう反論でしか。

VC++に良さが無いんだから書きようが無いのは分かるけど。

勝負あったな。。。
　　　　　　　　　　　　　　　　　
　　

結論：



　　　　JAVA

ということにしたいのですね？

>>457の選択肢

１．論点をそらし、詭弁ではぐらかす
２．コピペ荒らし
３．厨房を装う

>>465
すまん、タダの煽りでつ。

>>466

４．いつものＭ＄厨というスタンスをとり、ﾌﾟﾌﾟ嘲笑激藁レスで逃げ切る。

選択1
VC++を使ってる人はそれですべてをまかなおうとは思ってないと思うよ。
少なくとも仕事で使ってる人にとってはVisualStudioで一つの製品なんだから。

BCB？何それ？うまいの？

>VC++を使ってる人はそれですべてをまかなおうとは思ってないと思うよ。
これダメダメ君じゃん。
BCBのカバー範囲が、DOS、Win16/32/64、.NET、Linuxになるわけだし。

>少なくとも仕事で使ってる人にとってはVisualStudioで一つの製品なんだから。

VBは消えたし、WTLはサポート停止、MFCもバグ対応のみ、
.NETは立ち上がらないしC#はネイティブしないし...

VSはBCBよりカバー範囲せまくてゴミダメでしか？

>>471
えーと、DOSはどうでもいいし、Win16はMSDNからVC1.51をダウンロードできるから
実質的な差はLinuxに対応しているかどうかだね。

>>473
頭おかしいＹＯ！
一つで出来るやつと、色々組み合わせても、まだDOSが足りないものと。

組込みではDOSがあるんだけど...

>>473
だから、VC++の良さは書けないわけね。

VC++に足りないのは○○だけ、ってのヴぁっかり。

VC++みたいなダメダメコンパイラ使ってると、思考もダメになるんだな...

>>475
だって、いいとこないもん。

初心者がMFCを真似て不気味なキャストの使い方を覚えてしまうのも
困りもの。

MFC自体が困り物だ罠。
消えてくれるのでラッキー。

以上、某社員のｼﾞｻｸｼﾞｴﾝ （･∀･） ﾃﾞｼﾀ !!

え？BCBで作ったバイナリはプラットフォーム依存じゃないの？
そいつはすげーよ。馬路で。

In article >>480, デフォルトの名無しさん/sage/480 wrote:
>　以上、某社員のｼﾞｻｸｼﾞｴﾝ （･∀･） ﾃﾞｼﾀ !!

ということにしたいのですね。:)

某社員が大漁に釣れるスレはここですか？

>>466
>>457は１と３を選択した模様。

趣味ではともかく、仕事じゃやっぱVC使わんと。
MFCが腐ってようが、WTLのｻﾎﾟｰﾄが止まろうが関係無し。
重要なのは他のﾗｲﾌﾞﾗﾘ。
BCBにも正式対応してるﾗｲﾌﾞﾗﾘなんて、全体の何%あることやら。
勿論手を加えりゃ大半はBCBでも動くだろうけど、
手直しにかかる時間やﾘｽｸ、ﾗｲﾌﾞﾗﾘそのものにかかるｺｽﾄを考えりゃ
素直にVC使ってた方が遥かに安上がりです罠。

古い Cプログラマが頑固に Cを使い続けるのと同じだな。

>趣味ではともかく、仕事じゃやっぱVC使わんと。
>MFCが腐ってようが、WTLのｻﾎﾟｰﾄが止まろうが関係無し。
仕事で将来消えるライブラリ使うんだ。

>重要なのは他のﾗｲﾌﾞﾗﾘ。
C++用にライブラリ買うんだ。実はこの人ﾌﾞﾋﾞ厨だな。

>手直しにかかる時間やﾘｽｸ、ﾗｲﾌﾞﾗﾘそのものにかかるｺｽﾄを考えりゃ
>素直にVC使ってた方が遥かに安上がりです罠。
C++で言うライブラリはオプソでありBCBの方が良い。この人C++出来ない人だね。

485は、ActiveXを買って仕事をしてるﾌﾞﾋﾞ厨だね。
それもVC++の良さは、ライブラリを買うことにより、
>手直しにかかる時間やﾘｽｸ、ﾗｲﾌﾞﾗﾘそのものにかかるｺｽﾄを考えりゃ
>素直にVC使ってた方が遥かに安上がりです罠。
らしい。誰がこれに同意するよ。

しょーがねーな、そこまで言うんだったらちょっくらTrial版でも入れてみるか

でもさぁ、XercesとかORBacusとか、なかなかBCBで使えなくて苦労したよ。
VC++用のMakeしかなくてさぁ。

おいお前ら
なにをばか荒らし相手にやってんだ
うんこな荒らしばっかりだし（大爆笑
なんだよ、もんくあるのか？
http://jbbs.shitaraba.com/computer/5310/
ここに来いよ、いくらでもあいてしてやるよ
まぁ、おめえらだったら帰り打ちが精いっぱいだろうな（大爆笑
あとさ、あんまりムカつくやつあらわれたら、
IPから住所出して家になぐりこみに行くからな。
俺やくざみたいな友達が1万人もいるからさ、
おめらなんてイチコロだよ（大爆笑
まぁ俺はお前ラと違って頭もいいし（大学で１ばん

ぶっちゃけ情報量の差で決まると思うが。

BCB vs VC++ ： BCB > VC++ だというのが事実でも
BCB ユーザー数 vs VC++ ユーザー数 ： BCB < VC++ なわけで情報も多い。
情報がなけりゃ自分で手探りで探さないといけない。
そういう手間を考えると　BCB < VC++ 。

それと 「ActiveXが」 って、そういう悪質なの使わなければ良し。
VCLにもバグはある。

>>490
VC++用の メークファイルがあるのなら、そのまま動くと思うが？
VC++用のプロジェクトがあるなら、プロジェクト変換ツールが添付されてると思うが？

どこでつまづいたの？

>>492
情報量の差って・・・・・
同じネイテブコンパイラである以上 VCのコンパイラオプション以外の情報は
全て共有出来ると思うが？

もちろん VCL は pascalだから VCL の情報はVCでは意味がないが

さらに ActiveX/COMは BCB でもVCと同じように使う事も作る事も出来る。
さらに VCLを通じて使えば VB並に簡単に使える。
作る方は VCL で作ると、ちょっと手間だな(Delphiで作れ)

>>494
(;´Д`)・・・マジか？・・・

>>496
ﾈﾀだﾈﾀ

>>490
プロジェクト変換だけじゃだめだったんだよ。
あと、VC++用のlibやらdllがそのまま使えないし。

>>498は>>493だったよ。。。

BCBでDirectXは100%使えるの？

>>500
100% は VC++ でも無理だろう。
なんせDirectX にバグがあるんだから。

>>498
　まさか C++ のままで作った DLL　？　そりゃ動かないよ。

・・・・というかそんなレベルの仕事してるなら　確かに VC でなきゃ仕事出来ないだろな。

>>496
マジか？ってどういう意味？
　まさか、「この順番にキーボードを触ったら　ほら出来上がり」　みたいな本が必要なのか？

そうでないなら、同じC++なんだから
　C++の文法書も、STLの解説も、 Windows API の解説も、COMも　MFC も
全て共有出来るのが当然だろ？

なんか、VC++の良さを情報量でやっとやっと説明したみたいだが、
残念ながら、BCBはMFCなんかもコンパイルできるわけで...

>>502
ライブラリがDLLで提供されることなんてざらだろ？

>>503
VCLコンポーネントの作り方に関する書籍はかなり少ないな。

>>505
○ライブラリがDLLで提供される事はザラ
×ライブラリがC++の型保証名のままDLLで提供される事はザラ

前者なら、BCBでもVBでもDelphiでもWindows上の大抵のプログラミングツールから使える
後者は その環境でしか使えない

>>506
　かなり少ないというのは正確ではない。
　VCLコンポーネントの作り方を解説してる独立した書籍は
　日本では最近出たDelphi用のもの１冊しかない。

しかし、古いスタイルのOOPと理解すれば、
普通に継承して普通に書けば良いのであまり困らないと思うが？

>>508
いや、例えば、コンポーネントを複数登録できるプロパティのつくり方なんか、ヘルプ見るだけじゃわからんし。

>>507
×ライブラリがC++の型保証名のままDLLで提供される事はザラ
ようするにクラスをもったDLLですよね？
よく遭遇したのだが、漏れだけか。。。

あと、必要なライブラリがわかってて、その資料にBCBでの動作を保証しないことが記述されてれば
BCBで動くとしてもBCBだけでは開発できない。

関係無い。
VCLの情報が少なくとも、それが有効だから使われてるわけで、
情報量議論が無効であることが現実が否定している。

というか、VCLを否定したところで、VC++がダメなのは変わらず。

>>508
最近出たの？
なんて本か教えてほしい。
DDJJの記事くらいしか資料がなくて不便だったんだよね。

>>503
同じ・・っていうのがそもそも違う。
コンパイラで見たら GCC != BCB != VC なのは明らか。
VC++ でコンパイルできるソースが BCB でコンパイルできるとは限らない。

>>511
情報も開発環境のうち。
マニュアルも解説もなしでVCL使いたいか？

Delphiコンポーネント設計＆開発 完全解説
発売日： 2003.03.17発売 ： インプレス
定価： 本体5,700円＋税
ページ数： 536P
サイズ・判型： B5変型判
ISBNコード： 4-8443-1746-6


■著者よりひと言
本書は、本格的なDelphiのカスタムコンポーネント開発のための解説書です。
コンポーネント開発のあらゆるノウハウが詰まっています。
Delphiはカスタムコンポーネントを開発することで、より強力なツールに育てることができます。
本書を読めば、自在にカスタムコンポーネントを開発できるようになります。
Delphiを有能な右腕に育てたい方は、是非、本書で腕を磨いてください！

中村 拓男

だそうだ。

>>513
　○VC++ でコンパイルできるソースが BCB でコンパイルできるとは限らない
　これは正しいが、

では、

　C++の文法も、STLの解説も、 Windows API の解説も、BCBでは使えない

は正しいのか？

まるで　コピペで動かなきゃ　イヤダヨ〜　ってだだこねてるだけにしか思えないのだが？

>>515

たとえば既存のライブラリを使わないといけない場合。
テンプレート周りを使う場合。
その他バグ。

わかった？

すまん。

>>515
そういう時は使えるね。

>>515は数人での仕事でBCB使ったことがあるのかな？

既存のライブラリを使わないといけない場合。
テンプレート周りを使う場合。

そりゃ当然じゃないの？　それと情報量に何の関係が？

既存のVBコードを使わなきゃいけないのに、わざわざ VCで書くか？
既存のライブラリを使って素早くメインテナンスする必要があるなら、当然その環境でやるのが当然で、

自分の会社はVC用の既存ライブラリが多いから使ってるという理由なら
そりゃ他人からはご苦労さんと言うしかないでしょ？

自分の作ったライブラリが VC用だから　なんて理由ならバカだと思うだけだが

>>518
　BCB はワンマンアーミが使ってこそ武器になるツールでしょ。
　だいたい、自作、コンポーネントを他人に使わせるなんて絶対に嫌だね。

>>519
あんたねぇ・・・
バグとか出たらどうすんの？
実際使ったことあんのか？

なんかここまで言うのがあほらしいんだが・・・

ちなみに、数人でVC++を使うような怖いことはたぶんしません。
VC++1人 & BCB/VB 他の人
みたいな感じにすると思う。いまのところ、そんな機会はないが。

>>520
ひとりで使うなら、自分さえ知ってればいいから、資料はいらないね。
でも、世の中の多くの人は、数人でプログラム組んでるんだよね。

>>523
　羨ましいよ。　数人で組めるってのは、いいクライアント掴んでるんだね。

お金もらえる所の仕事なら、新人の教育を兼ねて、ちまちまVCで出来るんだが、

最近、そういう仕事が無くなって、納期無いお金貰えないだからしょうがないさ。

>>513
> C++の文法も、STLの解説も、 Windows API の解説も、BCBでは使えない

大嘘。
VC++ の方が、ANSI C++ に対応していない。
GCC や BCB/BCC は ANSI C++ に非常に高く準拠している。
VC++ は正しい C++ のコードを理解できない。
完全に準拠している C++ コンパイラはないと思うが、VC++ はへぼ。

コードをポータブルにするため、C++ のような標準がある言語では、
問題領域、つまりロジックは標準に準拠して書いておいて、GUI や API
といったコンピュータ領域、つまりインターフェースは処理系独自の
ライブラリで書くということがよくある。

BCB/BCC や GCC、その他 Solaris などの C++ ではそういう可搬性が
とりやすいが、そういったコンパイラではエラーにならない C++ の文法や
template クラス／関数であっても、VC++ は満足に ANSI C++ を理解
できないため、そのままではコンパイルできないという問題がある。

ちなみに、Windows API の解説書は、BCB でも何ら問題なく使える。
同じだもん。

VC++を使えば、MFC経由で非公開APIを使えるということはないでつか？

>>506
いまどき、質のいい情報が書籍で出ているとは限らない。
qmail の作者じゃないけど、いい情報はウェブに出ていることがおおい。

>>527
非公開な機能を使うなんて、まともなプログラミングでやることじゃない。
PC-9801 で高速なゲームを作らなきゃならなかった時代じゃないんだから。

>>528
で、コンポーネントの作り方、あるの？

>>530
てかさ、マニュアルとヘルプに書いてあるぜ。

>>531
マニュアルに書いてあるのって、ごく基本的なコンポーネントの作り方だけじゃない？

>>532
ソース嫁
Pro版以上はソースが付いてくる

既存のコンポーネントを継承してコンポーネントを作るならソースを見ればいいんだよね。

確かに コンポーネント作成は、Delphiのコードが読めないと厳しいだろうな。

俺も、コンポ作成はDelphi側でやってる。
C++コードを使いたいところはイベントにすりゃ簡単便利

ｵﾛｵﾛ(ﾟﾛﾟ;))((;ﾟﾛﾟ)ｵﾛｵﾛ
http://hkwr.com/
http://hkwr.com/bbs

つまり、Web上の情報はあきらめろと。
標準VCLはソースがあるからいいとして、QuickReportはどうしましょうねぇ？

ゴメン　QuickReport　は使った事ないや　便利そうだけど　それ使うと、なんかVB屋になった気分で

VCL コンポーネントはただのクラスだから、自分のライブラリを VCL にしようと
思ったら、しごくかんたん。TObject を親にするだけのこと。
付属 VCL を拡張するなら VCL を理解すればいいね。
Inside VCL
http://www.asahi-net.or.jp/~HA3T-NKMR/invcl.htm

ようするに、コンポーネントの作り方は簡単なの。
何から拡張してコンポーネントを作るかは、コンポーネントの作り方じゃなくて、
もととなるライブラリの知識が必要。

>>538
それは Crystal Report じゃないの？

>>539
TObjectだとコンポーネントにはならない。
　TComponentじゃないと　ポトペタは出来ない。

　コンポーネントの要素として使う場合でも最低TPersistent継承にしないといけない

>>540
ソースの付いてこないコンポーネントを使うのは
中の実装を知らずにActiveXを使うVB屋と同じようだ
という意味でないのけ

>>539
いや、別にTButton継承して音が出るボタンつくるくらいなら簡単なわけだが。
プロパティデザイナ作るときとか、配列プロパティ作るときとか、そういうときの資料がないんです。

そういえば、VCLって多重継承ができないのもいやだよね。

>>543
プロパティデザイナ→プロパティページかな
配列プロパティはソースを読めばフツーに分かる

「多重継承はめったに使わないだろ？」っていう詭弁キボン。

>>543
オブジェクト・コンポジションを知らないやつ発見。

>>541
そでした。失礼。

MFCやるよりマシだろ、という詭弁。

>>543>>545
多重継承できるようにすればいい。

>>543
　ああ確かに　デザイナは最初　サンプルコード漁りまくったな・・・・
　で、やってるうちに、別に自分で使うのに無理に作る必要ないやって気分に

　配列プロパティって 無理にプロパティにする必要は無いと思うけどなあ
　どっちにしてもpublished に出来ないんだし

てかさ、VCL を多重継承して嬉しいことはない。
どーすんのさ。TStringList と TMemo とを多重継承する？
何と何を多重継承したいのさ？

クラスの拡張って、継承（多重継承も含む）しか知らない人って結構多いんだね。

多重継承はVCLも使ってる筈だけどなあ
ActiveXの取り込みすると 使ってるみたいだが？

>>551
VCLの中ではhasしまくってるのにね

>>550
VCLクラスを継承して、VCL外クラスも継承したいとか。
Javaならインターフェイスを使うような多重継承のことだが。

>>554
それがやりたいならそうすればいいのでは？
どこで困ってるの・

>>555
出来ないから困ってるんですが。
どうやってやるの？

>>549
配列プロパティって、TDBGridのColumnsみたいなプロパティのつもり。

class TObservableForm : public IObserver
{
public:
　　TMyForm *Form;
　　TObservableForm(TMyForm *AForm)
　　{
　　　Form = AForm;
　　}

　　// IObserver より
　　virtual void Update()
　　{
　　　// TMyForm になにかする
　　}
};

って、これだけのことでしょ。こうするとさらに便利。

template<class T> class IObserver
{
public:
　　T *VCLClass;
　　IObserver(T *AVCLClass)
　　{
　　　VCLClass = AVCLClass;
　　}

　　virtual void Update() = 0;
}:

あ、virtual デストラクタを IObserver に追加しといてね。

template <class T> class ISubject
{
private:
　std::vector<IObserver<T> *> m_ObserverList;
public:
virtual ~ISubject() { }

virtual void Attach(IObserver<T> *Observer)
{
　　m_ObserverList.push_back(Observer);
}
virtual void Detach(IObserver<T> *Observer)
{
　　// find して vector から erase
}
virtual void Notify()
{
　　// すべての vector 要素に対して ->Update();
}
};

なるほど。
1 回 template を作れば、interface 系の多重継承は何の問題もないですね。

>>558
たとえばTLabelを拡張したコンポーネントとTButtonを拡張したコンポーネントを作ったとして
その２つのコンポーネントに共通の関数をつけたい、というだけなんだけど。

そのコード書くならイベント使った方がいいね。

>>557
こんな感じ
property Items[Index: Integer]: TColumn read GetColumn write SetColumn;

>>562
全然関係のないクラスに共通の関数をつけるのに、
多重継承なんて使っちゃだめでしょ。

>>562
その場合は、Memento パターンを使うんだな。

ついでにTObservableForm に operator IObserver *(void) も定義しといたら

あ、共通って、
THogeButton *b = new THogeButton();
THogeLabel *l = new THogeLabel();
っていうのがあったときに
Hoge* h = b;
h->hogehoge();
とか
h = l;
h->hogehoge();
とかって呼び出せる、共通の関数、ってことね。

>>562
共通の関数なら、VCLの __published メンバの実行時型情報を使うと便利だよ

>>567
THogeButton と THogeLabel の両方に IHoge と　hogehoge()と operator IHoge *(void) を持たせたらいいのでは？

そっか、やたら多重継承が使いたい人って、正しい使い方（Java の interface 的なもの
や、多重継承を意図して作られた親クラスの Mix-in アーキテクチャなど）として
使いたいってわけでもないんだね。
なんだか、もっとシンプルで一般的な手法があるのに、それを知らないばかりに
苦肉の策で多重継承を使っているうちに、それしかできなくなっちゃったという
人が多いのね。< VCL に多重継承を求める人

多重継承は、うまく狙って設計するとどーんとはまるけど、自分でやる場合には
interface としての多重継承以外は避けた方がいい。
とくに C++ の多重継承の振る舞いは複雑だから、テストもたくさん書かなくちゃ
ならなくなる。

>>567
それだけのことに多重継承を使っちゃいけない。
多重継承が使える場合でもそんなことはしちゃいけない。

たとえば、THoge というオブジェクトを作り、

THoge::Hogehoge(TButton *Button);
THoge::Hogehoge(TLabel *Label);

などと、メンバ関数のオーバーロードで対応すると、同じオペレーションでの
記述が得られ、多重継承を避けることができる。

実現方法はいくらでもあるんだけど、多重継承使えればすっきりかけるのに、と思うのですよ。

>>572
OO のやり方として、実現方法がいくらかある場合、多重継承は真っ先に
除外するのがスマートです。

デザイン・パターンなどで、定石的に多重継承が用いられている場合や
interface 的な場合は比較的安全ですから、やってもいいですけど。

もちろん、THogeButtonとTHogeButtonがHogeという共通の責任を持つということを示した上での共通の関数だよ。
Hoge::hogehogeの実装はナシね。

ちなみに>>554で書いてるように、Javaのインターフェイスがやりたいのね。

>>527
>>567 のような方法は、呼び出すコードを見る分にはシンプルな気がしますよね。
でも、何の脈絡もないクラス同士がなんで同じ親を多重継承しているんだろう、
ってなって、いい設計じゃないですね。
Java の Runnable のような interface なら納得いくかもしれませんけど。

>>575
なるほど、そういうことなら、設計として多重継承の意味があるね。

あと、THogeButtonとTHogeLabelがHogeという共通の責任を持つということが、委譲ベースだと示しにくいと思うのでつ。

完全に同じ処理なら、単純に　void hogehoge( TControl * hoge); って関数を作って
関数内で処理した方が簡単かつスマートだと思うけどね

>>579
それなら、Visitor パターンかな。

>>580
OO 的に、素の関数って作らない方がいいと思う。

親クラスに関連のないクラス郡に、一貫性を持ってアクセスするのなら Visitor だろうな。

>>581 どうかな JAVA のデザインパターンは基本的に 関数ポインタが使えないって条件でのパターンだからね
　それをそのまま持ち込んでも冗長なだけでしょ。

ところで、506 は CButton と CEditなら　同じ問題をどう解決するんだろ？

ただ、実は一番こまったことは、多重継承のよい例をVCLから勉強できないことでした。

Delphiには interface 型 もあって、実際VCLは　IDEでコンポーネント操作する為に interface型を使ってるし
COM/ActiveXを扱う時に使ってる。

しかし、その部分を　BCB 側で見ると、>>558のような仕掛けに変換されてしまうわけで
ATLスタイルの仕掛けとは違う。

でも、それは違う言語(Delphi)からの借り物だからしょうがないでしょ。

C++でコードを書く時はC++のメリットを生かせる使い方をしたらいいのであって、
VCLはシンプルで強力なのがメリットなのだから、それを心がけて使う方が幸せでしょう。

だいいち、コンポーネントを拡張したいなら、Delphi言語で書いた方が楽ですよ。

Delphiって、データ構造に弱くない？

結局コンポーネント作るならDelphiで、ってことですね。
そしたらDelphiでも使えるし。

>>583
「Java のデザインパターン」ってなに？ゆう話もあるけど、C++ は OO やない
こともできるのであって、できるからゆうのとやるゆうのとは違うやんか。

>>586
Delphiの構造体型(record)は Cの union と struct を兼ねたものです。
Delphiと C++では Delphiの方が基本型が多いだけで、同じ程度の記述力でしょう。

>>587
そうですね。
それに コンパイルも高速だしで　自分は GUI フォーム回りまでは Delphiで書いています。

OO の仮想関数は、関数ポインタを排除するのも目的のひとつだから、OO の
スタイルで書くなら、関数ポインタは使わない方がいいね。

C++ Builder でも別にコンポーネント作るのに苦労はないけどね。

デザイン・パターンって Java だと思ってる？

>>586
TDeque とか TMap みたいなのが欲しいってこと？
似たようなのはあるけど C++ みたいにいろいろはないなあ。

>>589
STLに用意されてるデータ構造が、Delphiでは使えないので。
TListなんかも見さかいなくて、ちょっと。

VC++6.0でDOSのプログラムを作る場合は
プロジェクトの種類は何を選べばいいのでしょうか？

最近VC++の話がでてきませんね。
あ、だから>>583はCButtonとCEditって言う風に話を振ったのですね。

>>592
　なら、データ処理はC++で ビューはDelphiって別けた方が楽ですよ。

>>593
MSC++ をどこかで入手しないと無理でしょ

>>595
でも、ひとつのコンポーネント作るなら、どっちかにしたほうがよくない？

>>595
そのままじゃできないんですか？

>>597 VC++ も BCB も 32bit コンパイラです
16bitコンパイラは MS-C++ BC++ 迄です。 Delphiは 1.5 迄が 16bitコンパイラでした。

VC++1.4あたりも16bitだったと思うんだけど。
そして、VC++ProのCD-ROMについてると思うんだけど。

>>596
Delでうまく記述できないようなデータ構造を必要とする
高度なコンポーネントが必要なら、自分でなんとかするしかないでしょ

テンプレートといっても同じ内容をDelで記述できないわけではないし
普段開発してる分には困ることはないんだけどね

そう。日ごろはBCBで困らない。コンパイル時間以外。

>>590
　そもそも厳密にOOのスタイルで書くなら C++ を使うメリットは？

＞デザイン・パターンって Java だと思ってる？
　その３割がたはJavaの事情から生まれたものだと思っています。

>>596
　 C++側でコンポーネントを書く事も出来るし、Delphi側で全部書く事も出来るし
　それを自分で好きなように調整出来るのがBCBの良さだと思います。

おいてめえら
なにをゴチャゴチャやってんだ
なにをアホな荒らしにてこずってるんだよ
うんこだな、お前ら
なんだよ、文句あるのか？
俺にかなうとおもてんのか？
http://jbbs.shitaraba.com/computer/5310/
文句あるやつはここにこいよ、俺にはやくざみたいな友達が1万人いるんだぜ
てめえらアホとちがって頭もいいし（大学で１ばん）
荒らしはしねよ（大爆笑

>>602
> そもそも厳密にOOのスタイルで書くなら C++ を使うメリットは？

従来の C のソースが利用できますね。

> ＞デザイン・パターンって Java だと思ってる？
> その３割がたはJavaの事情から生まれたものだと思っています。

うわあ、そんな人がいたんだ。
Java よりはるか前、Smalltalk の頃からあったでよ。

>>506
>VC++1.4あたりも16bitだったと思うんだけど。
>そして、VC++ProのCD-ROMについてると思うんだけど。
VC4についてた1.5x(1か2か忘れた)がVCについてた最後だろ

それはそうと、>>593はWindowsのDOSプロンプトで動かす32ビット(でも構わない)アプリを作りたいんではなかろうか
といってみるテスト

なるほど、Eric Gamma が、既存のデザイン・パターンに名前を付け出したのが
1991 年からで、Oak（1995 年に Java に改称）の開発がはじまったのも 1991
年からだから、デザイン・パターンが Java のためと思っている初心者もいるの
かのう。

>>605
VC++ 2.0 には DOS 用の EXE も作れる CL.EXE がついていてたような気がしたけど、
幻か？

VC++ 2.0 には MS-C 7.0 がついていたような気がするのう。

ＢＣＢで作ったＤＬＬを"ＶＣ６＋＋"もしくは、
"ＶＢ６"で使えるようにする為にどうすればいいのでしょう？

>>607
それより、Javaが出たのとGoFの本が出たのが同じくらいの年だからでは？
で、Javaのひろがりとデザインパターンのひろがりがリンクして。
デザインパターンの説明も、Javaが多いし。
あと、Javaのクラスライブラリでたくさんデザインパターンが使われているという紹介も多い。

で、Smalltalkはいつからなんだ？
そりゃまあ発明されたものじゃなく発見された物だから　ソフトウエアの歴史から
あったといいはれば言い張れるんだろうがな

>>610
　基本的に、他の言語で使えるようにするには型保証名は使わない事
　つまり extern "C" で公開すれば OK

　クラス的な構造にしたいなら ActiveX にするのがVB側からは楽でしょ

>>612
http://ma2tak.dyndns.org:8888/ma2tak/395#SmalltalkHistical

デザインパターンは最初 C++ で言われてたと記憶してる。
で、そんなの当たり前じゃんレベルの話だった。

その後のいわゆるJAVA プログラマのVB並に酷いスパゲッティコードを矯正するには良い教材って事だろ

>>615
あれは、「パターンを整理して名前を付けた」といことに価値があったのですね。

なぜJavaは実行速度が遅いのか・・・

>>608
>VC++ 2.0 には DOS 用の EXE も作れる CL.EXE がついていてたような気が
>したけど、幻か？
VC2にはVC1.5がついてた
>VC++ 2.0 には MS-C 7.0 がついていたような気がするのう。
MSCでのVerは覚えてないけどVC1でMSC7だったような気がする

<丶｀∀´> MSの中の人もBorland社製のコンパイラを使って開発してるニダ。


(´-`).｡ｏO(だったらおもしろいのになぁ…)

まあどっちにしても、この業界　タソガレてるような雰囲気が・・・・

C++の方向性が袋小路なのかな

まあ、何と言うかBoostの成績表
http://boost.sourceforge.net/regression-logs/cs-win32-diff.html

正直、このスレみてるとVC++(M＄)になんのとりえがあるのかと思ってくる

てーか本当にBCB.NETって発売される予定なのかと問いたい。
出るとしたらいつ頃だろうなのかも問いたい。

Javaはね最高のプログラミング言語なの分かる？

Javaは泥棒猫。

>>624
なんの言語を使うかは人による。
何を基準に最高と取るんだ？

>>611
そういえば、日本語でデザイン・パターンが話題になりだした頃は C++ での
説明が多かったけど、Java での説明の方が今はだいぶ増えているね。

Javaの利点は
　激しく遅い＝＝馬鹿高いハードもセット売り。
　

ドパミンの出具合で最高が決まるんじゃないの？

ドパミン受容体のDRD4 には48 塩基対の繰り返し配列が存在することが知られていて、
この配列の繰り返し回数には2〜10 回があることがわかっているそうだ。
一般に多い繰り返し回数は4 回であるが、7 回繰り返しをホモで有する例では性格行動パタ
ーンから新規探索傾向(新し物好き)があることが多いのだそうだ。

米国人は7回の人が20%もいて、日本人は1〜2%なんだと

で、新規探索傾向があるほど、ドパミンに鈍い。　つまり幸せじゃないって事だね。


まあ、XXサイコーなんて言う奴は、しっかり日本人してるんだなって事だ。

>>629
テレビの見すぎだ。
ちっとは働け。

Java==C++ + C

>>628
試しちゃいないが、java/javaw コマンドに -server オプションをつけて
起動をすると、めちゃくちゃ速くなるらしい。
環境がある人、だれか、試してみて。

http://accessplus.jp/staff/in.cgi?id=7030

>>629
いや、セロトニン回路が発達していると、せっかくドーパミンが出ても
感情が押さえられちゃうよ。

BMPとかからTIFFのGroup3(FAX)形式に変換するライブラリとかない？

>>635
なんでこのスレで聞くの？
ttp://homepage1.nifty.com/snap/room03/c01/cg/cg.html
ttp://gd.tuwien.ac.at/gnu/cygwin/release/tiff/
ttp://www.borland.co.jp/3rdparty/img5.html

>>636
あなたのような親切な方がいるからです。

>>635
TIFF といったらこれでしょ。
http://www-6.ibm.com/jp/developerworks/linux/020517/j_l-libtiff.html

VCL じゃないし C だけど。
BCB であるメリットは、こんなものも、多少の修正は必要かもしれないけど
ちゃんとこんぱいるできることだね。
クラスでラップしたり VCL にしたりしてもいいけど。

あ、Susie の plug-in は VCL になってたと思うから、それでも
できるかもよ。

比較表てこれか
ttp://www.borland.co.jp/cppbuilder/competitive/compare1.html

一晩で150ﾚｽ近く…煽りとしては上々か。

しかしﾚｽを見ると夢見る学生さんが多いようだなここ。
ﾗｲﾌﾞﾗﾘ使うっつーても、買ったりする訳じゃないぞ。
客が使いたいﾊﾟｯｹｰｼﾞをｶｽﾀﾏｲｽﾞための付属ﾗｲﾌﾞﾗﾘや、
現在使用中のｼｽﾃﾑ(Win上)が、VC製である事が多いって事だ。
(Winｱﾌﾟﾘの新規作成なんて仕事はまず無い。)
前者は当然ｿｰｽが公開されてない事が殆どだし、Libの形式が違うから
BCBは使えない。
後者は例えｿｰｽがあっても、完全丸投げでもしてもらわん限り、
全体をいぢる事なんてできんからやはりBCBは使えん。

まぁ夢を見るのは構わんが、いずれ現実との差に愕然とするぞ。

>>640
implib や MFC 取り込みで問題なく使えていますが、それが何？

やっぱり知ったかのﾌﾞﾋﾞ厨じゃん

つーか
現実に比較もせずにVCを選択した会社が多すぎるんだよな
それで満足に使える頭数がそろわずにプロジェクトがこけたり

VCがデファクトスタンダードになったことで
世界的には莫大なお金が無駄に使われたような気がする

>>640
> Winｱﾌﾟﾘの新規作成なんて仕事はまず無い。

すごくありますけど。

>>644
確かに
パッケージソフトの世界では
まだまだVCの出番が多い
実際、CADカーネルとかの実装も
MFCでフレームワーク組んであったりする事が多いし
悲しいかなデファクトスタンダード

>>640
５点
もっとがんばりましょう

つか、（・∀・）ｶｴﾚ!!

>>645
社内 C/S みたいなのでも、クライアントに Windows アプリケーション
新規案件は多いですね。

>>645
オープンインベンターとか？

結局末端にはWindowsがいるわけだし。
入力効率ならアプレットやFlash・JavaScriptで逝けるが
ちょっとでもデバイスが必要だとｱﾌﾟﾘが必要になる

>>648
ACIS, Parasolidとか

>>641
仕事でそんなんやったら…

>>644
ごめん、誇張し過ぎた。

>>645
はい、頑張り松。

ヘルズバーグの居なくなったB社についていく理由などない。

>すごくありますけど。
確かにあるところにはあるだろうけど、
これから先もう斜陽産業なんで、これからPCのソフト開発で食っていこう
というのは映画会社に就職しようというぐらい無謀ではなかろうか。

ヘルス・バイキング？

>>653
映画会社に就職していい映画を撮るのは無謀でも、個人でいい映画を撮って認められる時代ですからね。
ゼネコンソフトハウスが崩壊してるだけ + 普通に大不況。

>>653
ニッチな分野に特化したソフトは
これからも産業として成り立っていくと思うよ
ノウハウの蓄積がソフト化されてるものは、
その価値がノウハウにあるからね
一般的な市販アプリの市場はコンペチタも多く
薄利で厳しいだろうけど

激しくスレ違いなのでsage

BCBってそんなに良かったんだ？
なんか、遅くてサイズがでかくて、インターフェイスがなんか標準と違う
ようなイメージしかなかったな･･･
断然VCだと思ってたのだが、違ったのか。

性能がいいソフトはBCBやDelphiよりもVCが多い気がするし。
元々VCの数が多いだけ？

どうして
http://pc.2ch.net/test/read.cgi/prog/1042079443/447
ってこんなところで誤爆してるんだろう？

BCBはそんなにユーザ数が多くない気がする…。検索してもあんまり情報が出てこないのが悲しい。
delphiので我慢してるけど。

BCBがVCと戦ってはいけません。ターゲット層が違いすぎます。
BCBは対VB用です。

って言うかBorlandは数年前に経営者以下ほとんどが総入替になっている罠。
んでもって、TurboPascal/DELPHI開発者達が.NET作っている罠。

で今は帰ってきてるとか？

正確には昔BorlandでDelphiとか開発環境作っている部隊とビジネス製品を作っている部隊で
内部抗争が勃発して仁義なき戦いが繰り広げられた。

戦いに敗れた開発環境部隊と指揮をとったヘルスバーグが
Microsoftへ亡命し.NET構想で報復戦争を行っている。

>>661
BCB は VB ユーザも取り込めるし、VC++ よりいいので、使っているうちに
VC++ よりいいということに気づくという販売戦略だな。

BCB vs VB
Delphi vs VC++
実際はこうだろ　

>>666
実際って？

>>651
>仕事でそんなんやったら…

やってますが何か？

BCBEnterprice
あれ高すぎない？
36万！
買う人いてるの？

>>669
残念ながら人じゃなくて組織が購買層なのだよ。

>>670
ちなみにアレって1ライセンス？

Loki や Boost まともに動かない…
早い話がテンプレートもまともにつかえない BCB はいらないよ。
もはやテンプレートなしでプログラムは組めない。

>>672
VCは動くようになったんですか？

いつのまにかBCBのスレになってますな。

>>669
DecisionCubeが高いんじゃないかな。
同等製品が20万くらいしてるし。

>>672
BCBもVCとほとんど同じだよ

>>673
VC7はイマイチだけど、7.1 のベータはちょっといじったところ、かなりいい感じ。
テンプレートの特殊化ができるようになったのが大きな進歩

>>672
テンプレートがまともに動かないのは VC++ の専売特許じゃん。
BCB の方がはるかに ANSI に準拠しているよ。
G++ だって ANSI にとても準拠しているのに、VC++ はぼろい。

だいたい、VC++ でこれが通るかね。

01: #include <list>
02: #include <vector>
03:
04: int main()
05: {
06: using namespace std;
07:
08: list<int> l;
09: vector<int> v;
10: v.insert(v.end(), l.begin(), l.end());
11:
12: return 0;
13: }

VC++ って、こんなのも理解できない。

#include <cstdio>

int main()
{
std::printf("やあ、世界\n");
return 0;
}

VC++の粗悪品もさることながら、
VC++とActiveXの相性の悪さをなんとかして欲しい。
意味不明コンパイルエラーと実行時にエラー出るべきでないところで出たり。
例えば、ADOもVT_I2とVT_I4の違いくらい実行時にカバーできるだろうが。
BCBはActiveX使わなくてさくさく動作するところも非常に良い。

>>679
どう考えてもさくさくは動かんぞ。

>>678
にわかには信じ難いんだが、どんなエラーメッセージが出るの？

>>678
VC7で普通に通ったが…。

>>677
これも普通に通った。例外関係でwarn出るのでGX付けたけど。

>>681
C:\home>cl -GX -W3 printf.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

printf.cpp
printf.cpp(5) : error C2653: 'std' : 識別子がｸﾗｽ名でも名前空間名でもありません。

>>683
C:\home>cl -GX -W3 list_vector.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

list_vector.cpp
list_vector.cpp(10) : error C2664: 'void __thiscall std::vector<int,class std::a
llocator<int> >::insert(int *,unsigned int,const int &)' : 2 番目の引数を 'class
std::list<int,class std::allocator<int> >::iterator' から 'unsigned int' に変換
できません。 (新しい機能 ; ﾍﾙﾌﾟを参照)
この変換を実行可能なﾕｰｻﾞｰ定義変換演算子がないか、または演算子を呼び出せ
ません。

E:\>cl test.cpp
Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj

E:\>test
やあ、世界

01: #include <iostream>
02: #include <iterator>
03: #include <list>
04:
05: using namespace std;
06:
07: template<class InputIterator>
08: iterator_traits<InputIterator>::value_type
09: mean(InputIterator first, InputIterator last)
10: {
11: iterator_traits<InputIterator>::value_type sum = 0;
12: int count = 0;
13: while(first != last) {
14: sum += *first++;
15: ++count;
16: }
17:
18: return sum / count;
19: }

20:
21: int main()
22: {
23: double arr[4] = { 10.0, 0.0, -10.0, 5.0 };
24: list<double> arrlist(arr + 0, arr + 4);
25:
26: double sum = mean(arrlist.begin(), arrlist.end());
27: cout << "sum = " << sum << endl;
28: sum = mean(arr + 0, arr + 4);
29: cout << "sum = " << sum << endl;
30:
31: return 0;
32: }

C:\home>cl -GX -W3 traits.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

traits.cpp
traits.cpp(28) : error C2440: '=' : 'double *' から 'double' に変換することはで
きません。(新しい動作 ; ﾍﾙﾌﾟを参照)
この変換が可能なｺﾝﾃｷｽﾄはありません。

>>686
VC++ 7 はやっとまともになったんだね。
ようこそ、BCB や GCC と同じレベルのコンパイラへ。

VC5で未定義だった機能を勝手にMSが実装したが、標準仕様にはなれず。
このため、後発のBCBやGCCの方が標準仕様に近い。

ついでにVC7もMCで忙しいので完璧とは言い難いな。

まぁ、未だにMS-Cで組込DOSがメインな俺はVCをエディタ以外の用途で使っていないが。

このスレ開くたびに皇太子殿下が目に入る

BCBのC++標準度はG++の足元にも及ばない。

>>692
MCってなんでつか？

g++のC++標準度はcomeauの足下にも及ばない。

>>696
ライブ・コンサートで曲と曲の間のいわゆるおしゃべり。

>>695
たとえば？

>>696
マリオカートに決まってるだろ。

ねーなぜC++なの？
今の時代やっぱりJavaでしょ！

>>699

はぁ、はぁ・・・ありがとー！

きょうは・・・はぁ。このツアー最後のライブということで、いつもより気合いを入れてたんですが・・・

はぁ・・・っあ〜、みんな元気だね〜？

ははは。えー、今日はっみんな、一緒に楽しい思い出を作っていこうね〜！


ダダダダダンダン

>>702
はぁ？
なんでC++なんだよ！
Javaだろ！！！！

VC++はなー、エヂタがいいんだよエヂタ
あー、なんて言うの？そうそう、インテルセンス
あれでご飯3杯は逝けるくらいウマいんだよ
たまに壊れることがあるけどさー
あとはやっぱMSDNだね。これもウマくてご飯5杯は軽い

Javaみたいな初心者言語とC++を一緒にするな

>>705
なんだと！！！！
JavaはなC++以上にいい言語なんだぞ！

JavaはC#とでも戦ってなさい。

Javaの次派生言語は
Java++　ですか
Java#　ですか
討論してください

死者腐です

MS的にはJ#.NETが最先端らしい。

>>708

Java++はともかく、Java#は激しく意味不明。
あれはCだから趣がある。

ってーか、CのつぎはPだと思ってたよ！

>>621
なーんだ。VC++のほうが成績がいいんだな。

>>712
VC++ 7 からは、ましになったんだね。
えがったえがった。

>>708
Java.NETにきまってるだろうが。

>>704
はげどう。
あのえぢたはええね。

BCBのえぢたの貧弱さ、どうにかならんのかな。
最新版では改行コードよりも右にカーソルがいかないようになったのかな。

>>715
それがどうしてそんなに重要なんだい？

>>716
うんうん、全然気にならへん。

フリーキャレットは使いにくいね。なんか違和感あるよ。

>>718
Turbo Pascal の頃からそうやったからなあ。全然気にならへんな。

単なる慣れだよ、慣れ

アメリカ人や香港人、インド人などと比べると、日本人は
すごくエディタにこだわる民族なんですってね。
海外で仕事をしていたとき、IDE のエディタに一言あり、
なんていう人は珍しがられた。
秀丸なんか広げていると、「こだわってるね〜」なんてよく
いわれた。

「Emacsでなきゃヤダ」って人もいれば
「なにあのエディタ」って思う人もある
最初に使い込んだエディタが一番いいと思いやすいんでないかい

END押せよ
改行へ逝くから

Home押しても左端までいかないVCはどうも慣れないや

>>723
そんなこと知ってるよ。

他のエディタがみんな改行より右にいかないようにできるのに、BCBだけ設定できない。
某のサポートに問い合わせると、「そのほうが使いやすいから」という回答。
そのくせ、その後出たJBuilderは改行より右にいかなかった。

フリーカーソルとかいうやつだっけ。

>>724
> そのくせ、その後出たJBuilderは改行より右にいかなかった。

それについて、ボーランドのサポートに問い合わせしてなんて答えたか
やってみて宜保ーん。

C++Builder6はviをメニュー登録するといい感じ。
外部エディタとの連携機能はイイ
viとの連携強化きぼんぬ。

>>720
そだね。まだ使い始めて間が無いから違和感あるんだけど、でもできれば設定できるともっといいのになあと。
もう二三日もすれば違和感も無くなるだろうけど。

>>728
しばらくBCBから離れて戻るとまた違和感感じる罠

MicrosoftとBorlandが共同でDelphi.NET開発中だと。
Managed BCBも出るのかな？

>>729
かわいそうに。

おれはそのエディタのフリーカーソルが駄目でBCB捨てたんだが。

つーかね、上下移動はどうでもいいとして、
行末でカーソルの→押したら、
次の行になって欲しいだけなのよ。

なんでそのまま右行っちゃうの？
なんか意味あんの？
手抜きとしか思えないね（ﾌﾟ

＞行末でカーソルの→押したら、
＞次の行になって欲しいだけなのよ。
心臓止まるほど同意

フリーカーソルが嫌な人はこれでいいんでないの？
↓
Delphi/BCB5フリーカーソル無効化アドイン
http://homepage1.nifty.com/fuu/software/nonfreecursor.htm

>735
そんなの知らなかったよ。
教えてくれてTHX。

フリーカーソルはいいのだけどオートインデントが嫌なんだよね。
かといって解除してしまうと Shift+Enter でインデントできない。。
＜ BCC のエディタ

BCB は Shift+Enter 使えるようになってるのかな。

>>737
TAB キーでしょ。

直前の行のインデントに合わせる機能で、あれを自動化しないときには
手動 (Shift+Enter) で出来たらなあと。オートインデントモードだと
バックスペースをタイプしたときにもインデントしてしまって、とても
使いにくいのです。

'------------------------------------------------------------------------------
'FILE DESCRIPTION: Agentビルド報告支援スクリプト (MSAGTMAC.dsm)
'------------------------------------------------------------------------------

Dim MyAgent
Dim MyAgentCharacters
Dim MyAgentEntity

ACSFile = "C:\WINNT\msagent\chars\Peedy.acs"

Sub Application_BuildFinish(A1, A2)
'DESCRIPTION: ビルドの完了時

If IsEmpty(MyAgent) Then
Set MyAgent = CreateObject("Agent.Control.2")
MyAgent.Connected = True
Set MyAgentCharacters = MyAgent.Characters
MyAgentCharacters.Load "秘密結束社", ACSFile
Set MyAgentEntity = MyAgentCharacters("秘密結束社")
End If
If Not MyAgentEntity.Visible Then
MyAgentEntity.Hide True
MyAgentEntity.MoveTo 800, 600
MyAgentEntity.Show False
End If

Message = "エラ-数: " & CStr(A1) & " 警告数:" & CStr(A2)
MyAgentEntity.Speak Message
End Sub

Sub UnloadAgent()
'DESCRIPTION:

Set MyAgentEntity = Nothing
Set MyAgentCharacters = Nothing
Set MyAgent = Nothing
MyAgentEntity = Empty
MyAgentCharacters = Empty
MyAgent = Empty
End Sub

' もちVC派

Java＞C++>C>

>>739
「バックスペースアンインデント」のチェックをはずすだけのことじゃないの？

>>743
本当だこんなチェック項目あったんだね、見逃していた。さんくすです。
でもやはり直前行のインデントに揃えるのは手動化したい(w

自動インデントも(・Ａ・)ｶｼｺｸﾅｲ
ほんとにC++のIDE？という感じですね。

もう少しカスタマイズに融通が利けば文句ないんだけどなあ。
リソースファイルを作るとき以外は別のエディタを使ってる。

BCBとVC++
http://pc2.2ch.net/test/read.cgi/tech/1045642742/l50

　ミ,,ﾟДﾟﾐつ
ツールに、お気に入りｴﾁﾞﾀを
登録すればいいのではないですか？
>>やり方はDelWikiへ。

DelIDEとEmEditorと併用する時もあるですが
全然違和感ないですよ。

標準のｴﾁﾞﾀに使いやすくなって欲しいのでつ。

まとめてインデントも、「選択してTAB」じゃできないし。。。

　 　∧,,∧　　 ／　それなら
　　ミ,,ﾟДﾟ彡 ＜　　同意です。
　 　ﾐつ旦(ﾐ~~ ＼　>>748さん

確かにコダワリはあると思うな。
俺は今だに NECPC98のキーボードじゃないとダメだし、

エディタは　X86K附属のEDで慣れたもんだから　VZでもキーアサインはこれにして
WZでも最初それしかダメだったけど、やっと最近 ctrl-S crtl-V ctrl-F ctrlR に
慣れて、それさえ使えるなら大丈夫な人になった。

けっこう時間かかるよな

まだね、X68K -> Winみたいに環境が変わるのなら、仕方ないと割り切れるんだよね。
実際、Linux使うときはHomeやEndの変わりにctrl-a ctrl-eで問題なかったりするし。

問題はね、Windowsという同じ環境で、ほかの多くのｴﾁﾞﾀがデフォルトにしてる動作と同じことができないことなんだよね。

うーん。
俺は特定の操作する時は　そのやり方を覚えてる別のツールを使う事にしてるから
そんなに気にしなくなったけどな。

BCBでも出来るんだろうけど、わざわざWZのgrepで検索したりみたいなね
あ、BCBというかDelphiは矩形置換が出来るからそれだけの為にエディタとして使う事があるな・・・

脳みそが固まってる恐れがある。

VC++netにはいろいろなエディションがあるのですが
何がどう違うのですか？

VC++.NETはStandardだけだが。
いろんなエディションがあるのはVisualStudio。

和声とインベンションがあるのは「四季」。

デバッグというものは
間違えてる場所を教えてくれる以外にほかにどんな便利なことをしてくれるのですか？

便利な事って・・・デバッカの事？

デバッカが無くとも、
優れたプログラマは動作してるのを見ただけでデバッグすべき個所が判り
コードを見ただけでバグ取りが出来るものです。

>>758
優れたプログラマはバグを出しません。

デバッグは間違えた場所を教えることだけしかないの？

>>760
それじゃなんのためのデバッグかと小一時間問いつめたい。
つーか誰に教えるんだよ。後輩か？

>>760
とりあえず間違えた場所はコンパイラに教えてもらえ。

>>762
そんなの文法ミスしかわからないじゃん。
ちゃんと BCBUnit 使わないとだめだよ。

>>763
うむ。
と言われもインテリセンスに憧れて既にVCへ亡命してしまった俺。

ついでにVCに付いていたWordPadのソースにﾊｧﾊｧした俺。

デバッグとデバッガの区別がつかない人がいるし。
デバッカとか言っちゃっている人がいるし。もう見てらんない。

>>759
そんなことを言っているプログラマはペテン師だ。
優れたプログラマは、プログラムを書く前にテストを書く。
バグの場所が見つけやすいようにプログラムを書く。

>>764
かわいそうに……

デヴァッグよりはいい。Vじゃないって言ってるのに。

ふぅ…正直、VC++を使うかBCB使うか本気で迷ってる。
自分はアプリよりゲームを作る系のプログラミングをしたいんだけど どっちがいいかな？
やはりライブラリが有利なことからVC++でしょうか？それとも高機能なところからBCBか。
マジで悩んでる。助言プリーズ…。

>>770
VC++

>>770
BCB

簡単に言ったらデバッグって何？

>>773
むかしデヴィルズバッグっていう競走馬がいてな、
そいつの

質問した俺が馬鹿だった・・・

>>773
よく知らないけどガンダムに出てくるやつ
よくしらないので敵か見方のろぼっとかもわからない

それはズゴック

>>773
Voyager の保安主任だよ。

>>773
同盟軍の宇宙艦隊司令長官だよ
よく知らないけどヤン提督の上司だと思う

もう飽きた。

時代はIntelC/C++コンパイラとVTuneの組み合わせだよ。
BCBもVCもダメダメだね。

>>770
悩むって事はまだ何もソフト作った事ないんでしょ？
なら HSP とか Delphi とか無料のツールで何か作ってみたら？

>>770
無料なら.NET Frameworkも無料だから、これで試してみるのも一興。
密かにBCの無料版もお勧め。

>>770
DirectXならBCBを選ぶ意味があまり無いと思うんだが

デバッグとは、バグを取り除くことだ、ってマジレスしちゃだめでつか？

しかしまぁ、コンパイルエラーをバグって思ってる奴多いな。

コンパイラの内部エラーはバグだと思うが｡

コンパイラのね

>>786
それは仕様です。
本当のﾊﾞｸﾞならエラーメッセージなんて出ません。

「仕様想定外」を無くすのがデバッグだと思ふ。

あーもー、なんだっていいじゃん。
どうせ戦争なんだぜ。

>>789
気持ちはわかるけど
戦時中でも結構日常生活してるんだよね
明日死ぬかもしれないのに1ヶ月後の納品を心配したりして

おいおい、あんまり某を虐めるなよ〜ただでさえ氏にそうなのに

意図しない動作をすることがバグですな。
仕様とあってるかあってないか、ということはたいした問題ではない。
というのは、仕様のバグ、というのもありえるから。
もちろん用語というものは、シチュエーションによって、意味が異なる。

イラクは悪の枢軸国家だし、アメリカは正義だし、アメリカが攻撃する場所はすべて軍事施設だ。

つくったばっかでださいけどよろしく。
http://www.h4.dion.ne.jp/~pc-pow/

VCLを一度使うと、MFCのクソさ加減がイヤになる。
それと、propertyキーワードは超便利。
SetHogehoge(), GetHogehoge()なんていうメンバアクセス関数を使うより
直感的にコーディング出来る。
（もちろんアクセス関数は、クラス内部で実装する必要はあるが）

ていうか、m_strHoge、m_nHogeなんていうふざけているとしか思えない
メンバ変数名はやめれ。

それにコンポーネントを作成すると、再利用性が高くなるのもいいな。
でも派遣で仕事すると必ずと言っていいほど、VC指定なんだよな。
それでも画面プロトくらいは「さくさく」っとBCBで作っちゃうけどね。

後は、BCBにもVSSのようなバージョン管理ツールを付けてIDEと連携させて欲しいな。

>>792
御社は軍事施設ですよﾆﾔｿ

>>794
VC++にもpropertyあるぞ。宣言はめんどくさいけど。

>>794
BCBユーザはやたらとANSI対応度を重視しながら、言語拡張にも頼っているんだね。

>794
なんか、５年ぐらい前にBCBが登場したときに、
そんなことを言ってﾏﾝｾｰしてる人が多かったなぁ…（遠い過去

>>797
問題領域とコンピュータ領域とをきちんと分けながらね。

ウソ 800 ゲット！

Uppercamelな変数名もふざけてるとしか想えん奈

>>799
は？

>>802
どこがわからへんのん？

俺様専門用語

>>804
「コンピュータ領域」、「問題領域」が？
OO やったことないとか？

>>802>>804
そんなこともわからんで、言語拡張がどうとかいっているのですか。
http://www.google.co.jp/search?num=50&hl=ja&ie=UTF-8&oe=UTF-8&as_qdr=all&q=%E5%95%8F%E9%A1%8C%E9%A0%98%E5%9F%9F+%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E9%A0%98%E5%9F%9F&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

ANSI C++ がサポートしているコンピュータ領域は、ファイル I/O とメモリ・アロケーション
ぐらいだからね。
でも、問題領域は充分に記述できるから、問題領域は ANSI C++ で書くべき。

コンピュータ領域は、BCB でも VC++ でも、VCL や MFC、または Windows
API を使わないと、事実上どうにもならないから、これらを使う。

ただし、問題領域のコードにコンピュータ領域の処理を混ぜたり、コンピュータ領域の
コードに問題領域の役目を負わせたりしてはいけない。

わかりやすく言えばインタフェースと実装という事か。

>>807
BCB や G++ 遣いは、そーゆーのをきちんと気にしているから、ANSI 準拠度を
大切にするのです。
VC++ 遣いはどーでもいいのでしょうけど。

>>808
インターフェースとロジックといった方が正しいのでは？

>>810
うん、どちらも設計と実装とがあるし。

「コンピュータ領域」は初めて聞いた

>>812
知らないことを聞いたときに >>804 みたいに、自分の狭い枠で反応する癖を
付けていると、技術者としての成長は、きついものがありますね。

>>809
ANSI/ISO準拠ﾏﾝｾｰ派はBCBなんか使いません。Comeau C++を使うのです。
Comeau C++こそが究極のC++コンパイラなのです。
そして私の作ったライブラリを使うことによりC++の力を最大限に発揮できるのです。

　　 　 ∧＿∧∩　／￣￣￣￣￣￣￣￣￣￣￣
　　　 （　´∀｀）/＜先生！こんなのがありました！
　＿ / /　　 /　　　＼＿＿＿＿＿＿＿＿＿＿＿
＼⊂ノ￣￣￣￣＼
　||＼　　　　　　　　＼
　||＼||￣￣￣￣￣||
　||　 ||￣￣￣￣￣||
http://saitama.gasuki.com/hiroyuki/

>>813
どうでもいいけど804ではないよ
「computer-area object-oriented」で検索したがいまいちだった

とりあえずケン・トンプソンたちが見捨てたC++でVCもBCBもないかと。
ベル研では、これからはAlefやLimboが次世代言語らしい。

おまいら、そんなことよりBoost 1.3が出ましたよ。

>>817
Alefって日本じゃ受け入れられない名前のような・・・

どいつもこいつもC++かよ！！！
これからはJavaの時代というのに。

これからはJAVAの時代・・・

い　つ　の　時　代　の　フ　レ　ー　ズ　だ　？

　　　　　　　　　　　　とうとうやってきた！250メガバイト時代！

NEOGEO の CM を思い出した。何メガショックだっけか。

VC++よりBCBの方が機能が上なんですか？

>>824
機能って何の機能？　指標が無いと評価は出来ないよ

>>825
ハッカー気取りですか？

機能数や一つの機能の完成度。

高機能だが性能は低い。

Ruby以外どれも糞。C++なんて・・・ねえ？（苦笑
そんなに必死に糞同士を比較するなよお前等。

>>827
機能数？
　コンパイラの最適化オプションの事なら　VCが上
　拡張構文の数なら　どっちもどっちかな GCCの方が余程楽しいかもね
　ライブラリの豊富さなら VCLの分 BCBが上だろうな

機能の完成度？
　デバッグ類はVCが上という意見もあるけど、これは使い慣れた人が多いせいだろ
　ただ、使うかどうか判らないようなデバッグ用のツール類はVCが豊富かな・・まあ初心者には便利かも
　あと VCだとMSDNが付いてくる。　API日本語訳はMSDNの方が少し・・いや大分豊富
　といっても結局は英文に突き当たるんだけどね

いろいろと有名なオブジェクト指向言語であるC++とRubyを比較すると:

C++なぞ問題外．^^;;;

>>824
おい、VC++買うんだったらもう2〜3ヶ月待った方が良いぞ。

>>832
6.0を買います。Windows98SEなんで。

>>833
おいおいおい、今更クソい6.0買っても何にも良いことないぞ。
ついでに98も窓から投げ捨てろ。

6.0いいよ。軽いもん。

軽いのが好きなら BCB でもいいんじゃないの？

>>833
自作自演？

>>832
2,3ヶ月待ったら何がいいんですか？

>>838
ぐぐれ

Version 2003が出るからさ。

そろそろ2スレ目だな。
誰かが1000Getしたら2スレ目にするか。

824　そんな質問するレベルなら Delphi やっとけ

就職前に一つ勉強とか思ってるなら、GCCやBCCで十分

Delphiなめんなよ！！

>>843
はいはい、お前は帰っていいよ。

>>844
はあ

Boost 1.3.0 出たね。
BCB でコンパイルするには、bjam.exe をダウンロードしてきて、

C:\boost_1_30_0>set BCCROOT="C:\Progra~1\Borland\CBuilder5"
C:\boost_1_30_0>set TOOLS=borland
C:\boost_1_30_0>bjam

だよん。

ちょっとしたテストコードを書く程度だと、BCB1.0が軽くて便利
いちいちプロジェクトを作らなくてもいいしね。

なんて親切なんだ。

　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　 　　/ 　←>>844

>>847
> いちいちプロジェクトを作らなくてもいいしね。
そうだったっけ。

BCBのメリットが、VCLだけなら結局、「Delphi使っとけば？」
っていうところに落ち着くんだよな（w
フリー/シェアのコンポーネントは両方で使えるやつも多いけど、ソースはDelphiのやつが多いしね。

C++ってDelphiが想定しているアプリを開発するには若干水準が低いからね｡

要するにいつもの結論だな
BCB：PASCALがわからなかった落ちこぼれ用
VC++：仕事で泣く泣く使用
Delphi：最強

>>853
惜しい！
IntelVTuneのJavaネイティブコンパイラ最強

>>853
(ﾟДﾟ)ﾊｧ????
Delphi：C++がわからなかった落ちこぼれ用だろ。

誰がどう見たってC++の方がDelphiよりも遙かに複雑で難解だと
思うが？

まぁ時代はMSX-BASICな訳だよ

>>856
おまえはアセンブラが使えない落ちこぼれですね。
えむまがのテクニカルノートでも読んで帰れ。

MSX-C ってさ、<stdio.h> もなかったような気がするけど。

某から抜けた連中が今M$で.NETをやってるというが、
某に復讐どころか塩送ってるような気がするのは漏れだけか。
Java対.NETでどちらが勝っても、某は敗者を受け入れ可能な
ポジションにいる。

>>858
あったよ。

>>855
BCB以上のことがシンプルに実現できるDelphiのほうがいいに決まってるだろ
C++資産の活用以外にBCBの価値はない
現にBorlandのホームページの扱いはJBuilder,Delphi>>>超えられない壁>>>BCB
ユーザー数でもDelphiはおろかBCC以下じゃん

842書いた者だけど、
　どっちが上とかいう意味じゃなくて、今パソコンがWin98で　BCB/VC6と比べて悩んでるなら
今はDelphiで勉強して、C++の勉強は BCC/GCCでやった方が効率いいよって意味さ

それは、
　VCは夏にもVS2003が出るみたいだから待て。
　それにBCBも年内にBCB7が出るだろう。

　でも、出たとしてもWin98のパソコンじゃまともに動かない
　BCBの方が軽いけど、それでもWin98だと補完機能とか遅くてイライラするだろう。

そして、プログラミングは適性があって、C++をスーっと3日も使ったら理解出来る人もいるけど
8割は、段階を追って理解しないと厳しい。
特にC++だと　他人のコードはとても読みにくいしね

JavaやってからVC++やるのって
効率いいですか？

>>863
悪くはないけど、JAVAに慣れすぎると弊害もある。　学習を阻害するかもね。

>>863
VC++に慣れすぎると弊害がある。　学習を阻害するかもね。

>>865
うんうん、あるある。

Javaに慣れすぎた場合はもっとひどいけどね

それはよかったね

やっぱDelphiだね

>>867
だから、嘲笑激ﾜﾗ忘れてるって。

>>870
ごめんよ。>>865か>>866は嘲笑激ﾜﾗ厨だったんだね。気づかなかったよ。

>>871
おまえのことだろ(張勝劇笑

最近この板、お子様しかいなくなった

>>873
はるなので。

はるなのに

あんたならVC++とBCBどっちが好き？

そろそろJavaも人気が出てきたな。

Pascalって結局メジャーになりきれなかった言語だよな。

プロジェクトでDelphi使おうとすると、メンバ集めるのに大変だったり
「保守するのが大変」ということで、上司からストップがかかるけど、
BCBなら、「いちおー、言語的にはC++ですし・・・」という理由でなんとか
ごまかせる。

ところで、Delphiﾏﾝｾｰな会社ってあるのか？

>>850
セーブしなくてよければ・・・

未だに bc++ 5 を使ってる漏れは糞？

↑某のツールはBC++5以降は死んでるから、そのままで良いよ。

>>880
BCB1->軽いけどデバッグ機能がプア、BCB3.0以降に移植しにくい。
BCB3.0->バグがやたらと多かった。
BCB5.0->やっと普通に動くようになって、メモリリークチェックやバックグランドコンパイルが
　　　　　　出来るようになった。
BCB6.0->何か5.0から変わったのか？

結局、VC++を使っているプロジェクトに投入されたためBCB1のみを残している状態。
VCでVCLが使えればいいのに・・・って無理か。

BC++B 5 で無くて BC++ 5 なんだな（ｗ

だからJavaの時代だって、もうC++の時代は終ったの、分かる？

うるせーよガキ

>>885
あら、嫉妬ですか？
血圧上がりますよ？

>>878
pascal好きは英語圏の人。
英語圏では{}がキモくて、begin/endがなじむ。
日本では逆。

>>887
ほー、そうなんだ。
{・・・}のほうが、エディタで編集しているときにカッコの対応が分かりやすいけどなぁ。
ところで、マックＯＳはPascalで記述されていたんだっけ？
（もちろんアセンブラの部分はあるだろうけど）
ちなみにマイクロソフトの製品はVC++で作っているのだろうか・・・

Pascalで書かれた技術書もけっこうあるわけで
C++ニャら読めるけどPascalだと読めニャいとか
C++ニャら保守できるけどPascalだと保守できニャい
というのはちょっと恥ずかしいかニャ

プロならC/C++/Pascalくらいは読み書きできて当然だと思うけどニャ

一貫性を書いてたニャ（恥ず・・・逝ってくるニャ

言語の話題で字句しかあがらないところが厨房っぽくて良いな。

C++の勢力も弱まってきたな。

さーいよいよJavaの時代だ！！！！

VC++でUNICODE/SJIS変換はどうやりますか。

BCBなら、
WideString/Stringの代入＝により変換されたと思いますが。

CStringT

>>894
有難う。
BSTRってのは、UNICODE側でしたっけ？ASCIIでしたっけ？

>>888
＞ところで、マックＯＳはPascalで記述されていたんだっけ？
おいおい誰に騙されたんだよｗ
MacOSは、Apple副社長の『Pascal Cagni氏』が開発したんだよ。

マックＯＳはPascalで記述×
マックＯＳはPascalが記述○

一応ソースも張っとく
ttp://www.zdnet.co.jp/macwire/0302/07/ne00_europej.html

>>896
>マックＯＳはPascalで記述
ってのも一応ありだと思うが。昔の話だけど。
Windows も昔は Pascal だったとかなんとか。

Mac は char255 型(だっけ？)とかあるし、Windows3.1の関数
呼び出しは Pascal 方式。

>>896
『Mac de Pascal（無料開発環境のお勧め）』
いまさら、Pascalと思われる方もいるでしょうが、MacOSは元々、Pascalで書かれました。
InsideMacの記述もPascalフォーマットが多いのは歴史的なことです。
CとPascalは従兄弟くらいの近しい言語です。
↓
http://www.makie.com/ja/makitips/pascal_fun.html

>>897
かぶったニャ

>>896
ネタだと思うが一応突っ込んどく。

マックＯＳは、Pascal とアセンブラで書かれたんだにゃ。
で、マクＯＳのグラフィック描画ルーチンは最初 Pascal で書いて
逆汗して天才ビル・アトキンソンが神業的なハンドオプチマイズを
施し 64Kbyte のROMにぶちこんだ。

ビルはプログラマから足を洗って今は写真家だーよ。

あ、今のマクＯＳ Ｘは Objective-C かもね？

今でもそしてこれからもCが主流だね！！！！！

Delでお気楽プログラムをした後にC/C++を使うと
大文字小文字の区別に神経を使い
全部大文字のマクロで肩がこる
・・・なんか、やだ・・・

>>893
ICU を使うと楽チンなんじゃない。

>>902
大文字小文字区別されないと逆に名前のバッティングが気にならない？

>>904
HWND hwnd
HDC hdc
みたいな書き方に慣れてると大文字小文字が区別されないのが不安かもしれないけど
実際に困ることなど全くないよ

>>893
A2W/W2A char*<->WCHAR*
T2A/A2T char*<->TCHAR*

なるほどそういうものなのか。

>>897
＞Windows も昔は Pascal だったとかなんとか。
_pascal呼び出し規約の関数CALLがスタックの積み方云々の理由で
パフォーマンスが上がるからでは無かったっけ？

マックで扱うchar255型？文字列は、0バイト目に文字数、1バイト目以降に
文字列が格納されていたよね。
よって、最高255文字(バイト)だった記憶がある。
これってPascal文字列だよね、CBCのTStringの仕様も1バイト目が1最初の
文字だったりするし。
＃[0]も何故か最初の文字が取り出せる・・・

MicrosoftがPascalでwindows作った、なんて絶対にない話。
ノウハウなんて全く無い。

>>909
MS は、昔どこかから Pascal のコンパイラを買ったんだよ。
MS-Pascal ってあったよ。
だけど、バージョン・アップできなかったんだな。
買収は得意だけど、技術力がなかった。
そうこうしているうちに Borland に負けて、MS-Pascal はもうないんじゃないの。

1986 年
日本語版 MS-Windows 1.0 が発売。知り合い宅で操作体験した。
ウィンドウをタイル上にしか配置できないものだった。Windows アプリの開発には、
アセンブラーか MS-Pascal が必須であり、別途 MS-Windows SDK (システム開発キッ
ト)の購入が必要でった。
当時としては聞き慣れない「イベント駆動型プログラミング」である事を文献から知るが、
開発環境が手に入らなかったのでプログラム作成は経験出来ず。

あ、それで、far pascalコールだったんだ。
スタックの積み方で高速になるという話は知ってたが。

>>911
いや、Windows発売前からMS-Cは出してたし、pascal呼出もあったから、MS-C
でも開発できたんじゃないか?

>>911
MS-Windows 2.11ではSDKはC言語I/Fだったが・・・
当時は、MSC5.0+SDKでWindowsアプリを開発していたよ。
MS-Windows3.1時代にちょっと使った、Borland-Turbo Cは衝撃的だった。
コンパイルスピードが爆速だし、統合環境だったしね。

>>913
1986 年っていうと、Lattice C の OEM を MS-C で出していたかいないかの
ぐらいじゃないかな。

まだ、cl.exe じゃなくて msc.exe だった。
あれは MS-C Ver. 3 か。

MS-C ver.4はDOS用だったと思うが。

VC++のデバッグ最強。

VC++はデバッグの前にコンパイルが通らない。
http://program.station.ez-net.jp/special/vc/general/conpatible.asp

□ Visual C++ の互換性…
それまでに静的ライブラリを Visual C++ 7.0 にてサクッとコンパイルすることができていたので、COM コンポーネントも何気なくコンパイルできて当然のものと思っていました。

が、なにやらいっぱいエラーが…。

□ COM 動かず…
さて、エラーも取り除けたということで動作させてみたのですけど、CreateObject をして、そのあとでメソッドを呼び出してみると…、DLL の読み込みでエラーが発生してしまいました。

どうやらうまく移行できなかったようです。

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！

Java?・・・・そうだ！！！！！！！！！

ﾌﾟﾌﾟﾌﾟ

BCB使えればVC++も使える？

使える度合いによる。

>>923

Javaのよさは良くわかった。
ついでだから、Javaでかちゅの後継アプリとMIDIシーケンサ作ってくれるか。
ほんじゃ、俺もJava信者になる。

それまでは「時代が来る」とかいうな。

すまん、>>923は>>920の間違い。

とりあえず、かちゅ後継とMIDIシーケンサ、頼んだぞ。
口先だけはもういいから。
できないんなら黙っててね。













Javaじゃなくてあんたがうざいんで。

>>925
> かちゅ後継
monalipseどう？

BCB6pro買おうと思ってるんだけど・・・
ずっとﾚｽ読んでると、BCB.NETなる物が出るの？
どーしよう、.NETが出るまで待ってる方がいいの？
.NETって、いつ出るの？

では黙っています。

>>925
javax.sound.midi.Sequencer

これでJava信者がひとり増えたな。

　　 。　　*　　　 。 　☆　　 。 　+ 　。　 + ☆　　*
　☆　http://www5b.biglobe.ne.jp/~ryo-kyo/osu.html　☆
　。 ☆ 。 * ☆ 　　+ 。　　　。　　+　　+　　☆　　☆

おすすめの無料オンラインゲームは↓　vector
http://my.vector.co.jp/servlet/System.FileDownload/download/ftp/0/278022/pack/win95/game/table/pachinko/majo_.lzh

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
C＃?・・・・ちがう！

ACL?・・・・そうだ！！！！！！！！！

>>931
半角「?」って文字化けに見える漏れはJava厨ですか？

>>927
>>862が書いてるように、BCB6買おうと思ってるなら、
年内にBCB7が出るみたいだからそれを買えば？
BCB.NETについては知らない。いつ出るかも分からない。

>>927
>ずっとﾚｽ読んでると、BCB.NETなる物が出るの？

そんなもん出る予定ないよ。
どっからきた話か知らないけど。

>>933
なるほど。BCB7が出るんだ・・・
年内っていつだろう・・・冬とかだったら待ちきれないよ。
ボーランドのHPにソースある？

>>934
>>386

Delphi.NETはMSとBorlandで共同開発中らしいが、BCB.METは聞いたことがないぞ。

>>935,936
http://www.borland.com/news/press_releases/2002/02_12_02_Product_strategy_NET.html

またボーランドは出遅れるわけか。

( ﾟ∀ﾟ)ﾉ Java信者の924がいるスレはここですか？

>>937

これ読んでると、BCBが.NETサポートするって書いてあるね。

RAD環境がVS.NETでコンパイラがBCBなら密かに最強っぽい。

>>937
おぉ、サンクス。
.NET開発陣が元ボーランド社員達なのでVC++のマネージッド版より相性良さそうだね

とりあえず次BCBは買い、というわけだな。

早く出してくれBCB7

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
VB?・・・・ちがう！

C＃？・・・・そうだ！！！！

ああ確かに C# はその中で一番に消滅しそうだな

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
VB?・・・・ちがう！
C＃？・・・・ちがう！

Ruby？・・・・そうだ！！！！

「目の付け所がC#でしょ」という某CMの反転ギャグが成立するまで
あとちょっとです。

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
VB?・・・・ちがう！
Ruby?・・・・ちがう！
C#?・・・・ちがう！

コボル？・・・・そうだ！！！！

>>949
そろそろこっち逝け
http://pc2.2ch.net/test/read.cgi/tech/1047183153/

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
VB?・・・・ちがう！
Ruby?・・・・ちがう！
C#?・・・・ちがう！
コボル？・・・・ちがう！

TASM？・・・・漢ならこれだ！！！！

BCB6のインスコサイズって幾らくらい？

VC++?・・・・・ちがう！
BCB?・・・・・ちがう！
デルファイ?・・・ちがう！
Pascal?・・・・・ちがう！
Java?・・・・ちがう！
VB?・・・・ちがう！
Ruby?・・・・ちがう！
C#?・・・・ちがう！
コボル？・・・・ちがう！
TASM？・・・・ちがう！

SYMDEB？・・・・これや！！！！

雑魚言語どもが・・・

ま、結局行き着く先は皆HSPなんだよな。

実は最強の言語は　「はだしのゲン語」　ギギギ…

>>953
それでｳｲｿのアプリを作れるんかいな？

>>957
MacのアプリもGameboyAdvanceのアプリも作れる

Lispが最強かと思ってたら、BrainFuckというさらに上逝く言語が…

え、何の話かって?読み辛さの話ですよ。

・ﾟ・(つД｀)・ﾟ・ ｳﾜｧｧｧﾝ
>>952がスレ違いに見える。。。

>>959

わけがわからんといえば、Intercalでしょ。

VC++とBCBを併合すると最強の開発環境になると思われ

>>962
でも、二つで一つを開発するのは大変っぽ。
VCでするならVCで。
BCBでするならBCBでするのがよろしかと。

俺はBCB以外使うつもりないが。

DelphiとBCBを併合すると最強の開発環境になると思われ。

>>964
それってBCBでは？w

>>962
BCB は MFC を内包しているから、VC++6.0 までだったら BCB5 で OK。

>>962
デバッガとエディタはVCで。

>>967
VC のデバッガって、BCB のブレーク・ポイントみたいに、何回目に止まるとか、
何回通過したみたいなプロファイラみたいに使えたりとかしますか？

>>965
Delphiは溶けてバターになってしまいますた。

>>965
コンパイルできるだけでIDEがサポートしてないやん

>>968
VC++ のデバッガはそういうインテリジェンスな機能はついていない。
せいぜい、ある条件のときに止まる、です。

>>968
>何回目に止まるとか
使えるよ

bcc32最強。

なにげに >>971 が恥ずかしいことを書いてるな。

VC6には何回目に止まるはあるけど何回通過したは無いな
自分でカウンタつけるかプロファイラ使えば済む話だが

ヒットカウントの事？

>>967
じゃあデバッガは BCB の方がいいね。 < >>975

あるじゃん。

>>977
VCってブレークポイントで停まってるときにコード書き直せなかったっけ？
あれがやりたい。

>>979
BCB ではできますね。

>>980
そうなの？
　AnsiString a;
●a = "aaa";
　label1->Caption=a;
でとまってるときにa="bbb"って書き換えたらlabel1にbbbって表示される？
BCB5までしかもってないけど、6からできるようになった？

>>979
あれって便利だけど本来動かない（動いちゃいけない）プログラムが
高機能なデバッガのおかげで動いてしまうんだよな。

デバッガ使う前にコード読み直せって。

>>982
漏れはやってみたいだけ。

最近デバッガ使う機会がないのは気のせいか。

あげとこう

>>980
でも書き直すとまた再構築させられるし。
…って、書き直した分をバイナリに適用させる場合の話だけど。

漏れもBCBのデバッガ機能は好きだな。

ということは漏れはとなりの芝が青くみえてるBCB厨ということでつね？

ビルダーの方がGUIアプリ作りやすい。
でも、コンパイル時間かかるので
テストや、GUI関係ない内部のソース書くとき、テストはVC
VCは、
ソースエディタも使いやすいし。
BCBのエディタってタブが勝手にスペースに置き換わったり
文字かいてないところにもスペースとみなしてカーソルが移動できるから
なんか、きもい。
最近なれた。

結局両方使ってる。
一長一短だ。

『BCBとVC++』version2
スレは必要なのでしょうか？

もうそろそろ1000なので、誰かまとめてください。
俺はいやです。

BCB vs VC++ 2 MILLIONAIRE FIGHTING 2003

Delphiの方がGUIアプリ”も”作りやすい。
しかも、インタプリタと間違えそうなくらいコンパイルが速い。
ただしエディタはキモイ罠。

>タブが勝手にスペースに置き換わったり
オプションあるはず

>>987
TAB 文字の使用にチェックを入れれば OK。
てか、おれ的には TAB 文字の表示幅は環境依存なので、全部スペースの方が好き。

次スレは？

>>993
ありません。BCBの圧勝という結論が出ましたので。

俺的には、GUIはVBでその他はVC++。これをCOMで融合。
これ最強。

　　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　ネェー、1000取り合戦してくださ〜い　　　　　　　　　,,､,､,,,
　　　 　/三√ToT)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　タリー　　　　　　　　　　タリー
　　 　 　//三/|三|＼　　 　　　　　 （＼＿／）　　　　　　　　めんどくせー　　　タリー
　　　　　　∪　 ∪ 　　　　　　 　　　（　　´Д） 　　　タリー　　　　勝手にやれよ
　,,､,､,,,　　　　　　　,,､,､,,,　　　　 / 　　つ（＼＿／）　　　（＼＿／）ノ⌒ヽ、
　　　　　　,,､,､,,,　　　　　　　　　　（_（＿＿つ⊂(´Д｀⊂⌒｀つ（´Д｀　）＿人＿_）

　 　 　 　 　 　 ＿＿＿＿＿＿
　　　　　　　　/////////////＼　　　　　　　　　♪しゃ〜ぼんだまとんだ〜
　　　　　　　 ///////////// ″ ＼
　　　　　　 .///////////// ″___　 ＼
　　　　　　///////////// ″ |.:::|　 　 ＼　　　　　　　　　　　　　　　　　　○　　 o
　　　　　 ///////////// ″　 ~~ 　 　 　 ＼　　　　　　　　　　　　　　　　　　○
　　　　 .///////////// ″　|￣|￣|　　　 　 ＼　　　　　　　　　　　　　　　　　　o
　　　　///////////// ″o　|＿|＿|　o 　 　 　 ＼　　　　　　 ∧＿∧　　　○
　　　./////////////ｲ″　　 　 　 　 　 　 　 　 　 l＼　　　　 （　・∀・）
　　　￣|￣￣￣￣￣::.|　　　|￣￣|￣￣|　 　 　 　 |￣　　　　 （つ日　つ━O
　　　　 |　　　　　 ﾛﾛ :.|　　　|　 　 |　 　 |　 　 　 　 |　　　　　　｜ ｜　|
　　　　 |　 　 　 　 　 ::.|　　　|＿＿|＿＿|　 　 　 　 |　　　　　　（_＿）＿）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　　　 　 　 　 　 　 ＿＿＿＿＿＿
　　　　　　　　　　　　　　　　　　/////////////＼
　　　　　　　　　　　　　　　　　 ///////////// ″ ＼
　　　　　　　　　　　　　　　　 .///////////// ″　 　 ＼
　　　　　　　　　　　　　　　　///////////// ″　　　 　 .＼
　　　　　　　　　　　　　　　 ///////////// ″　　　　 　 　 ＼
　　　　　　　　　　　　　　 .///////////// ″　　　　　　　　 　 ＼
　　　　　　　　　　　　　　///////////// ″　　　　　　　　　 　 　 ＼
　　　　　　　　　　　　　./////////////ｲ″　　 　 　 　 　 　 　 　 　 l＼

　　　　　　　　　　　　　　　　　 .＼
　　　　　　　　　　　　　　　　　 ″ ＼　　　　　　　　　　　　　♪やねまでとんだ〜
　　　　　　　　　　　　　　　　 .″___　 ＼
　　　　　　　　　　　　　　　　″ |.:::|　 　 ＼　　　　　　　　　　　　　　　　　　○　　 o
　　　　　　　　　　　　　　　 ″　 ~~ 　 　 　 ＼　　　　　　　　　　　　　　　　　　○
　　　　　　　　　　　　　　 .″　|￣|￣|　　　 　 ＼　　　　　　　　　　　　　　　　　　o

　　　　　　　　　　　　　　″o　|＿|＿|　o 　 　 　 ＼　　　　　　　∧＿∧　　　○
　　　　 |￣￣￣￣￣::.|″　　 　 　 　 　 　 　 　 　 l　　　　　Σ（・∀・； ）
　　　　 |　　　　　　　 :.|　　　|￣￣|￣￣|　 　 　 　 |　　　　　　（つ日　つ━O
　　　　 |　　　　　 ﾛﾛ :.|　　　|　 　 |　 　 |　 　 　 　 |　　　　　　｜ ｜　|
　　　　 |　 　 　 　 　 ::.|　　　|＿＿|＿＿|　 　 　 　 |　　　　　　（_＿）＿）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　　　　　　 ＿＿＿
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　///////＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /////// ″ ＼
　　　　　　　　　　　　♪やねまでとんで〜　　　　　　　　 彡/////// ″　 　 ＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /////// ″　　　 　 .＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　彡 /////// ″　　　　 　 　 ＼
　 　　∧＿∧
　　　（； ・∀・）ﾊｧﾊｧ
　　 .（ つ　 つ
　　 人　 Ｙ
　(( し （＿）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　　　　　　　♪こわれてきえた〜　　　　　　　　　　　 从"､;从
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(( ; ;"; :、))　　ﾄﾞｶｰｿ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　((; ;．;")) ）; ;";) ）
　　　　　　　　ｏ　　 ∧＿∧ ｱｱﾝ　　　　　　　　　　　　　 　((; ;．;")) ）; ;";) ） ;; ．;))
　　　　　⊂二´⌒ つ T∀T）つ　　　　　　　　　　　　　　((; ;．;"((; ．;"));．;")) ; ;．;")) ）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。