1 ：
デフォルトの名無しさん ：
03/02/19 17:19 どっち派？
VC++
MSがBCBをだしてBorlandがVCをだしてたら、
__,,,,＿
／´ ￣｀ヽ,
/ 〃 _,ｧ---‐一ﾍヽ
i ／´ 0 ﾘ}
| 〉. -‐ '''ｰ {!
| | ‐ｰ くー |
ﾔヽﾘ /// ,ｒ "_,,>//'｝ ／ー
ヽ_｣ (つト‐＝‐ｧ' ! < ﾊｧ～・・・
ゝ i、 ` ｀二´' 丿 ＼
ﾄ､､ ／￣｀`ｰ､
|｀.-/
>>1 ヽ
／ヽ| ,. ﾞ､
/ | ﾉ⌒) .| ﾞ､
／;. .| (ノＯ | ﾞ､
.／ ﾞ| ,. | | ﾞ､
／ . /" .| .| _,_.ﾞ､____,,,,､=､
.／ ./! .| / ／￣､-‐‐'''''''ｰ-､＼,_
_,.､--' /-‐''''''~~~` /／‐''"´ ｀＼＼
_,,,､--''''~´ __...､-‐'''~~´ 0 ｀ヽヽ
ノ" _,,､--‐'''~ (⌒ヽ (⌒) ヽ|､
,,､-‐'''"~ しノ ）丿 .|;;|
''" (ノ ./､;|
､,,,_ ／/ヾ
｀` ｰ､ _／´／ |
＼＿＿＿＿ _,,,,,､､､-=‐'''"´ |
＼ /ヾ￣￣~~｀二>='''~..､-‐'／´ |
＼ ヽ ヽ:::|:::,.､-‐'ﾞ´ `'''''''''''ﾞ´ ./
＼ ﾞ､ |／´ /
＼ ＼´ ／
5 ：
デフォルトの名無しさん ：03/02/19 18:05
ｖｃ
BCB VS VC++はVCL VS MFCとほぼおなじ
＿＿＿＿＿ ＿＿＿＿＿ ＿＿＿＿＿＿
8 ：
デフォルトの名無しさん ：03/02/19 21:11
BCB最高！
9 ：
デフォルトの名無しさん ：03/02/19 21:19
>BCB VS VC++はVCL VS MFCとほぼおなじ
(；´ー｀)y-~~.｡oO(BCBでコンパイルするとやたらとサイズが（略）
11 ：
デフォルトの名無しさん ：03/02/20 18:23
あの質問ですが
個人で買ったのはBCB、仕事ではVC++
13 ：
デフォルトの名無しさん ：03/02/20 18:28
13GET
欲しいなら VC6は急がないと、もう買えなくなるよ。
16 ：
デフォルトの名無しさん ：03/02/21 17:38
そりゃGCCだろ！
>>15 俺はM%の営業じゃないから知らないが、プロフェッショナルは販売店の在庫限りだと思うよ
近所のお店で聞いてみたら？
>>10 MFCのライブラリをスタティックリンクにすれば無問題（´ー`）y-~~
19 ：
デフォルトの名無しさん ：03/02/22 16:31
ていうかBCBとVC++は何がどうちがうの？
vs.net Pro以上 MSDNならVS6が入手できる、
21 ：
デフォルトの名無しさん ：03/02/22 17:52
VCProとBCBProでは機能的にどちらのほうが上なのですか？
22 ：
デフォルトの名無しさん ：03/02/22 22:59
コンパイラのISOC++準拠度がややBCBの方が高いので使いやすい。
23 ：
デフォルトの名無しさん ：03/02/23 00:21
>>22 ( ﾟДﾟ)ﾊｧ?
IDEならBCBのほうが上だろ？
使ったことあんのか？
VCなのが上なのはデバッガとかだろ。
25 ：
デフォルトの名無しさん ：03/02/23 00:28
Win98で使えるのは、VC++6.0が最新に
Delphiが最強ですよ(ﾎﾞｿｯ
BCBのDelphiスタイルのIDEはコードを縦に長く表示出来るから便利だよ
最適化機能とかではどちらの方が上ですか？
>>29 MSは機械に、某は人間に最適化されています
>>31 全部のバーをドッキングオフしても、それが前面に来るからウットシイんだよ
>>35 フルスクリーンにしたら、今度はPDFファイル見て仕様をコピペしながらとかが面倒になるじゃないか
非表示にするかでかいモニタ買えよ｡
38 ：
デフォルトの名無しさん ：03/02/23 20:28
まあ、某は腐ってるって事で。OK?
スーパーカリフラジリスティックエクスピアリドーシャス
>>37 おいおい、便利だよって言ってるだけの事でそこまで噛み付くなよ
まったく40の言うとおりだな
BCBはなかなか仕事で使わせてくれないが、
43 ：
デフォルトの名無しさん ：03/02/23 21:26
gtk--最強
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/
（＿フ彡 / ←
>>39 貧乏人でもデュアルモニタにする程度の金はあるだろ
>>45 私にもデュアルモニタにするくらいのお金はあるわよ。
でも会社で使うモニタのために自腹を切るのはいやだわ。
えっ 業務の開発をシングルモニタでしてる人がいるの?
>>48-49 お前ら明日の朝一でモニタ買ってこい｡
モニタの金額と人件費じゃ桁が違いまくりだろ｡
余裕で元が取れるよ｡それくらい効率が上がるだろ｡
>>50 実は私の席にも液晶モニタとCRTが1台ずつあるのよ。
でもパソコンが4台(1台は個人所有ノート)あるからマルチモニタにするためのスペースがないのよね。
#私的にはマルチモニタよりも複数マシンでの作業の方が効率がいいと思うわ。
#そりゃあ、複数マシンのマルチモニタが理想でしょうけどね。
モニタが2台あれば後は切り替えろよ
複数マシンはむしろ効率悪いだろ｡メリットが思いつかない｡
>>52 あら、あなた頭いいわね。(ﾟε゜;)
でもデュアルモニタ対応のグラフィックカードも買わなきゃいけないわ。
私、こう見えても実はケチなのよ。だからやっぱり我慢するわ。
>>53 >切り替えも面倒だし設定も毎回しないといけないし｡
いまどきのモニタにはメモリ機能があるから、入力信号に応じて設定が自動的に切り替わるのよ。
それは置いといて、私のメインはWindowsなのよ。だから異なるOSや開発環境のインストールされていない
マシンでリモートデバッグしたいときにはどうしても複数マシンが必要なのよね。
もちろんVirtual PCなんかも使うわ。
あと、処理時間が長くてCPUパワーを使うプログラムの実行をしている間だって暇なことがあるじゃない。
そんなときに別のマシンがあると暇つぶしにホームページを見れてとっても便利だわ。
モニター厨は余所でやれ
57 ：
デフォルトの名無しさん ：03/02/26 15:49
Java大好き！
Javaはこれからも不滅だ！！！！！！！！！！！！
Javaはこれからも不滅だ！！！！！！！！！！！！
63 ：
デフォルトの名無しさん ：03/02/27 16:30
Javaは滅亡だ！！！！！！！！！！
「これからも不滅だ！」ってのがわからないな。
>>62 断末魔の叫びなんだから生暖かく見守ってやれよ
Javaはこれからも不滅だ！！！！！！！！！！！！
おーーーいここはJavaスレじゃねーぞ
BCB と VC++ だと煽りあいにならないようで。
71 ：
デフォルトの名無しさん ：03/03/01 14:36
C最高！
C最低！
73 ：
デフォルトの名無しさん ：03/03/01 15:16
Cは最高だよ！！
75 ：
デフォルトの名無しさん ：03/03/01 15:22
Cにはポインタもある構造体もあるおまけに自作関数もつくれる
76 ：
デフォルトの名無しさん ：03/03/01 15:26
Cは、やっている時は夢中だけど、終わるとちょっとむなしくなるんだよな。
BCBのプログラマはM$に拉致されて、監禁されてC#を作ってます
Delphiにはポインタもある構造体もある、おまけに自作関数も作れる
79 ：
デフォルトの名無しさん ：03/03/01 16:01
Cにはポインタもある構造体もあるおまけに自作関数もつくれる
Ｃ++にはポインタもある構造体もあるおまけに関数テンプレートもつくれる
81 ：
デフォルトの名無しさん ：03/03/01 16:10
VBはVisualBの略ですか？
82 ：
デフォルトの名無しさん ：03/03/01 16:11
>>80 むむっ！
Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
おまけにintやCharも使える、
おまけにlongも使える
もうこれ以上のものはないね！
最高だよ！！！
やったー俺の勝ち！
C++にはポインタもある構造体もあるおまけに関数テンプレートもつくれる
>>84 Lokiがそのまま通るC++処理系は少ない。
ははは、
で、いつからここは言語対決スレになったんですか？
>>88 ここはBCB vs Delphiスレになりました（ﾟ∀｡）
やはり一番プログラムを書きやすいのは68000アセンブラだな。
91 ：
デフォルトの名無しさん ：03/03/01 17:21
H8-500シリーズもアセンブラで書きやすいね
BCB VS VC++はVCL VS MFCとほぼおなじBCB VS VC++
93 ：
デフォルトの名無しさん ：03/03/01 17:44
OWL最強
この板相当低レベルな雑談板になってるみたいだね｡
大学が休みに入ってるから仕方ない。。。
96 ：
デフォルトの名無しさん ：03/03/01 21:04
Cにはポインタもある構造体もあるおまけに自作関数もつくれる
>>96 C++はCでできる事は全部できる訳だが・・・・
C∈C++ です。
BCBで100ゲッツ
102 ：
デフォルトの名無しさん ：03/03/02 14:39
>>97 ここはＣスレだよ。
Cにはポインタもある構造体もあるおまけに自作関数もつくれる
おまけにファイル操作使える、
おまけに配列も使える
おまけにintやCharも使える、
おまけにlongも使える
おまけにwhileも使える
おまけにforも使える
おまけにifも使える
おまけに乱数も使える
おまけにアルゴリズムも使える
おまけに配列の初期化も使える
おまけに変数も使える
おまけに#includeも使える
おまけにC++より実行速度が速い
もうこれ以上のものはないね！
最高だよ！！！
>>102 Cスレじゃないよ。BCCとVC++を対比させて語るスレだよ。
>>102 全部C++でも使えるという突っ込みは無しか？
＞ ／⌒⌒〆ヽ
106 ：
デフォルトの名無しさん ：03/03/02 17:23
ようするにBASICが最高ということだ！
TurboPascalやDelphi、VCLの開発者であるヘルスバーグ氏がBorlandから
おい！！！！このスレの題名をみろ！！！！！
111 ：
デフォルトの名無しさん ：03/03/03 14:00
DirectX9をダウンロードしようと思い
>>102 C++より速いかどうかはコードやコンパイラの性能によると思うが・・・
実行速度は置いておくにしても、それ以外の項目はほとんど全ての言語に当てはまる罠。
MS嫌い。
VC++.NET入れてみたよ。BCBと共用してます。
117 ：
デフォルトの名無しさん ：03/03/04 22:32
>>115 ひねくれとは言わないね。
人間として当然の感性を持っていることを恥じる必要はないのだよ。
ひねくれてるというのはMS嫌いなのにMSのOSで動く言語を使うような事とかだろう。
119 ：
デフォルトの名無しさん ：03/03/05 06:30
MS 嫌いだけど、主流の OS は MS だからそれを使う。-> OK
120 ：
デフォルトの名無しさん ：03/03/05 06:37
>119
121 ：
デフォルトの名無しさん ：03/03/05 06:43
>>120 > 何が「まとも」なのですか？
コンパイラが。
> 実測データをもとに科学的な根拠を明記するべき。
何が気に入らないのか知りませんが、空気も読まずに
随分偉そうにモノを要求しますね:-P
>>121 自然に考えたらコンパイラの何が「まとも」かってことだろうに。
何がまともか言えないのがバレバレ
123 ：
デフォルトの名無しさん ：03/03/05 06:49
>>122 > 自然に考えたら
自然、などという怪しげな表現で押し通そうとする余裕の無さは
一体なんなのでしょう(笑)
> 何がまともか言えないのがバレバレ
願い事と現実はいちおう切り離しておくべきでは? :-P
>>123 話がずれているので戻す。
BCBのコンパイラのどこが「まとも」なのですか？
まともって定義をしてから言えよって感じか？
だから、そいつが「まとも」だと思ったことを書けばいいんじゃん。
>>126 まともなんてのは感情で、綺麗とか凄いとか旨いとかいうのと同じだよ。
本人がそう思ったんならそれでいいじゃん。
細かくみりゃ、単にコンパイルオプションがデフォルトではそうなってないとか、そんなレベルの話なんだろうしね
>>127 > 本人がそう思ったんならそれでいいじゃん。
だからいいって言ってるだろ。
思うのは勝手、理由を述べろって事。
templateも名前空間もまともに扱えないMSのｺｿﾊﾟｲﾗなんぞｲﾗﾈ
130 ：
デフォルトの名無しさん ：03/03/05 15:31
BCB は VC++ よりもより ANSI に準拠していて、他の C++ コンパイラとの移植性が高い。
131 ：
デフォルトの名無しさん ：03/03/05 15:32
VC++ は、MFC ぐらいしかついていないが、BCB は VCL が使えるから、より使いやすい。
>>130 VCL使ったコードを他のC++コンパイラに移植してください。
正直、コンパイラの性能はどうでもよくて、
135 ：
デフォルトの名無しさん ：03/03/05 15:37
>>132 C ではない。C++ だ。
まともなプログラマは、問題領域は ANSI C++ で、コンピュータ領域は VCL など
処理系やプラットフォーム依存のライブラリで書いている。
136 ：
デフォルトの名無しさん ：03/03/05 15:38
正直、ライブラリはどうでもよくて、
137 ：
デフォルトの名無しさん ：03/03/05 15:38
>>133 馬鹿だなあ。
VCL を使う部分はコンピュータ領域のみ。
問題領域、ロジック部分は ANSI C++ で書く。
VCL を使う部分を移植する場合は、移植先のプラットフォームのライブラリで
記述する。
そんな使い分けもできないのか。
だからそんな頓珍漢なお願いをするんだ。
出直して濃い。
139 ：
デフォルトの名無しさん ：03/03/05 15:42
>>136 初心者のうちはそれでもいいけど、ちゃんとクラス設計をして、
VCL や Windows API でしか実現できない部分と、ANSI C++ でも実現できる
部分とに分けて、ANSI C++ で記述できるところは特段の理由がない限り
ANSI C++ で記述するようにする。
すると、ユーザ・インターフェースや通信部分以外は、他のコンパイラで
そのまま利用できる。
VC++ だと、それすらやりにくい。
140 ：
デフォルトの名無しさん ：03/03/05 15:44
> 他のコンパイラでそのまま利用できる。
142 ：
デフォルトの名無しさん ：03/03/05 15:46
>>141 矛盾していない。
BCB などのまともなコンパイラ同士なら可能。
VC++ は ANSI C++ の準拠がへっぽこだから、BCB などのまともなコンパイラ同士では
ソースが交換できるのに、VC++ だけ交換できないことが多い。
>>141 (´-`).｡ｏＯ（どこが矛盾してるんだろ・・・）
144 ：
デフォルトの名無しさん ：03/03/05 15:48
C++のコンパイラにBCBとVCとGCCしか思いつかない人は氏んでください。
>>139 > すると、ユーザ・インターフェースや通信部分以外は、他のコンパイラで
> そのまま利用できる。
以外の部分って何よ？ まさか標準ライブラリを自作したものとか言わないだろうな。
>>147 (´-`).｡ｏＯ（この人の作る物はｲﾝﾀｰﾌｪｲｽだけなの・・・？）
150 ：
デフォルトの名無しさん ：03/03/05 15:58
>>147 > 以外の部分って何よ？
問題領域。
FFT とか、シミュレーションとか、広い意味でのデータ処理。
ユーザ・インターフェースとは関係のない、データ処理の本質的な部分。
> まさか標準ライブラリを自作したものとか言わないだろうな。
全然違う。やりたきゃやってもいいが。
>>147 俺が思うに・・・
見てくれのｲﾝﾀｰﾌｪｲｽとかは、OS依存だが、
内部の処理は、ちゃんとANSI C++で書けば、
どのOSにも使いまわしができるってことだろ？
おばかちゃん。
152 ：
デフォルトの名無しさん ：03/03/05 16:00
>>147 > まさか標準ライブラリを自作したものとか言わないだろうな。
わかっとらんな。
標準ライブラリを自作したコードが、ANSI C++ の範囲で書けるわけなかろう。
コンピュータや OS ごとに記述を変えないですむようにするための標準ライブラリ
でもあるわけなんだよ。
なんのための標準ライブラリなんだか……
BCBは何の略だよ
154 ：
デフォルトの名無しさん ：03/03/05 16:01
155 ：
デフォルトの名無しさん ：03/03/05 16:02
>>153 検索して調べてみなさい。業界の人なら常識だ。
（VC++ って何の略だよ。コンパイラの意で使うなら cl.exe と書いてくれ、
というのと同じレベルだ）
156 ：
デフォルトの名無しさん ：03/03/05 16:04
>>151 そして、ANSI C++ の準拠がへぼな VC++ では、それがネックになっている。
(´-`).｡oO( bcc32という単語を出しているﾔｼに「検索して調べなさい」って、ｱﾌｫか… )
(´-`).｡oO(にしてもずいぶん釣れたなぁ。)
BCBは、ちゃんとしたANSI準拠ｺﾝﾊﾟｲﾗを作っている。
(´-`).｡oO( 漏れはRAD開発環境はBCB,コンパイラはBCCと呼び分けてるけど… )
161 ：
デフォルトの名無しさん ：03/03/05 16:14
>>159 VC++ が C++ とは別の言語だよと明示してあれば。
M$のロードマップだと、だんだんとVC++もANSI互換性は向上するそうだよ
>>161 BASICとVBは別物。
C++とVC++は別物。
こういう認識で行ってみよう。
164 ：
デフォルトの名無しさん ：03/03/05 16:22
拡張されてもいいんだけど、最低限 ANSI C++ を高い互換性で理解できるという、
>>162 いくら拡張されようが、ANSI準拠コードをコンパイルできれば問題ないだろう。
166 ：
デフォルトの名無しさん ：03/03/05 16:25
>>165 いまの VC++ は、ANSI 互換オプション（しかも大して互換じゃないが）を
ON にしてコンパイルすると、今度は MFC のコードが文法違反でコンパイルできない
とかお茶目だけど、そういうのがなくなれば VC++ ももっと使いやすくなるよね。
167 ：
デフォルトの名無しさん ：03/03/05 16:28
結局、VCも BCB+VCLみたいに VC+.NETな感じになるでしょうね
>>167 は「出会いナビ 日本最大級★出会いのポータル」でした。
盛りあがってるね。
また厨房が出てきたよ。┐(´ｰ｀)┌ ﾔﾚﾔﾚ
173 ：
ぽこちーな ：03/03/06 01:38
最近、仕事でＢＣＢとＶＣ使ってます。
>>173 どこらへんが貧弱？
機能的にはBCBのが上な部分もあると思うけど。
インターフェースのことを言ってるなら同意。
慣れれば使えるけど。
175 ：
デフォルトの名無しさん ：03/03/06 03:56
>>173 VC6 のデバッガ、BCB のよりどんなふうにすごいの？
176 ：
デフォルトの名無しさん ：03/03/06 05:22
C++Builder6
177 ：
デフォルトの名無しさん ：03/03/06 05:58
>>176 > 例外をthrowするとその先をトレースできない。
ウソ。
> それからコンストラクタありのstaticオブジェクト
> があると非常に不安定。
バグだね。BCB5 を使おう。BCB フリークでは BCB6 はまだ買わない方が
いいとされています。
>>176 >それからコンストラクタありのstaticオブジェクト
>があると非常に不安定。
このスレと前スレを読んで、英語版のUpdate2以降を当てれ。
IDEが英語化けしないようにインストールすればOK。
179 ：
デフォルトの名無しさん ：03/03/06 12:17
>>177 ええぇ！？
BCB6より、BCB5の方がいいの！？
・・・BCB6買う所だった・・・
今なら、5買った方がいいのかな？
180 ：
デフォルトの名無しさん ：03/03/06 12:27
>> 例外をthrowするとその先をトレースできない。
181 ：
デフォルトの名無しさん ：03/03/06 13:07
>>180 そう設定しているからでしょ。
もし例外で止まらないように設定してあるのに止まるのなら、BCB6 のバグだね。
182 ：
デフォルトの名無しさん ：03/03/06 13:11
>>179 VCL が一部書き換えられていて、BCB5 にはないバグが少し多いので、BCB5 を
使った方が快適です。
たとえば、TThread クラスが書き換えられていて、まだバグがあったりします。
詳しくは C++ Builder Mailing List の過去ログを見てね。
183 ：
デフォルトの名無しさん ：03/03/06 13:18
BCB6で、WinXPのエクスプローラにある、
184 ：
デフォルトの名無しさん ：03/03/06 16:47
>そう設定しているからでしょ。
なるほど、BCBは6より5の方がいいのか。
187 ：
デフォルトの名無しさん ：03/03/06 21:49
>>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だぞ。それ。
ボーランド->インプライズ->ボーランド
190 ：
デフォルトの名無しさん ：03/03/06 21:58
>>188 ML を見よって書いてあるんじゃ？
おんぶに抱っこ君はプログラムできないね。
191 ：
デフォルトの名無しさん ：03/03/06 22:05
>>189 どっか Linux の会社と組んでなんかやるのに INPRISE にしたけど、
破談になったので戻した。
>>190 情報の提示も出来ない奴がML会員か。どんなレベルのMLだ？
>>190 MLって情報を発信する人のためのコミュニティだと思われ。
>189
195 ：
デフォルトの名無しさん ：03/03/06 22:09
>>192 知りたいなら、検索して読んでみるだけのこと。
どのMLかくらい教えてあげれば良いのに。。。。
197 ：
デフォルトの名無しさん ：03/03/07 10:56
198 ：
デフォルトの名無しさん ：03/03/08 21:48
VC++にインラインアセンブラってありますか？
あるよ
ついでに200ｹﾞｯﾂ
198=199=200
ﾜﾗﾀ
203 ：
デフォルトの名無しさん ：03/03/09 01:12
なんだかんだ言っても、仕事じゃソースの納品規定がＶＣなんだよな～。
204 ：
デフォルトの名無しさん ：03/03/09 02:18
>なんだかんだ言っても、仕事じゃソースの納品規定がＶＣなんだよな～。
ｷﾑﾁ
オイキムチになってまつ
>>207 たまにはキムチの気むちになるのもいいもんだ。
キムチの気持ちか…。
キムチばっかり食べると痔になりますよ。
>>211 とっととキムチになっちゃえばそんな心配は無い。
痔になるなんてのはキムチになれない奴の戯言。
ｷﾓﾁ(･∀･)ｲｲ!!
214 ：
デフォルトの名無しさん ：03/03/09 17:37
キムチ・・・食いすぎて腹こわした。。
215 ：
デフォルトの名無しさん ：03/03/09 18:00
結論 (ﾟДﾟ)ｳﾏｰ な順位
216 ：
デフォルトの名無しさん ：03/03/09 21:47
ただいまよりこのスレはキムチスレになりますた。
キムチビルダー＋＋きぼんぬ
七瀬スレム板分室になりました。
219 ：
デフォルトの名無しさん ：03/03/09 22:20
初心者でよく分からないのですが、やっぱり韓国製のキムチは日本のよりも激辛だと考えてよろしいでしょうか？
BCBの方がUI作りやすいのでBCBに一票
キムチの方がチゲ作りやすいのでキムチに一票
VC++ に一票
VC++ に一票
VC++ に一票
VC++ に一票
VC++ に一票
VC++ に一票
228 ：
デフォルトの名無しさん ：03/03/10 00:00
>>219 韓国の唐辛子は日本の唐辛子の辛さの 1/10 です。
キムチも、韓国のキムチの辛さは日本の 1/10 ぐらいです。
日本にキムチは辛すぎるんです。
230 ：
デフォルトの名無しさん ：03/03/10 00:05
訂正
231 ：
デフォルトの名無しさん ：03/03/10 00:07
>>220 BCB は UI が作りやすいだけじゃなくて、OO すること自体やりやすい。
VCL は Java のライブラリほどではないけど、ちゃんと OO として設計
されているから、それを OO の手法で自然に利用できる。
MFC はクラス・ライブラリだけど、OO ではないので、不自然になる。
>>231 VCLは多重継承が出来ないからクソ。しかもC++だからインタフェースもない。
233 ：
デフォルトの名無しさん ：03/03/10 00:16
>>232 多重継承ができず、インターフェースがなくて、どう困った？
234 ：
デフォルトの名無しさん ：03/03/10 00:17
>>232 は、やっと覚えたての多重継承が自慢でたまらないと思はれ。
>>233 observerパターンが適用できない。
236 ：
デフォルトの名無しさん ：03/03/10 00:19
>>232 表面的なことにこだわっているね。
C++ には、多重継承ができないライブラリもあるけど、Adaptor パターンとか
知らないのかな。
>>232 多重継承が出来て便利なケースは具体的に答えられますか？
俺はほとんど必要ないと思うが。C++PrimerのP995から読んでみて
いるが、今ひとつ理解できない。
あ、でも、std::istreamとstd::ostreamはstd::iosから派生し、
239 ：
デフォルトの名無しさん ：03/03/10 00:22
>>235 >>236 のようにすればいい。
または、TMyForm をもつクラスを Observer にするだけのこと。
たとえば、TFormObserver クラスを VCL を継承しない純粋な C++ クラスとして
つくり、それに TMyForm へのポインタを参照させればいい。
それだけで Observer パターンになるよ。
VCL がクソなんじゃなくて、
>>235 の頭が固い。
240 ：
デフォルトの名無しさん ：03/03/10 00:22
MFCが仮想関数でイベントをハンドルしないのが糞。
241 ：
デフォルトの名無しさん ：03/03/10 00:24
>>238 でも、自前で多重継承を使ったライブラリを作るのは、特別な理由がない限り避けた方が賢明。
多重継承の振る舞いは、いろいろな場合わけをしないといけないから、それだけテストも
たくさん書かなくちゃならない。
そうする価値がある場合以外はしない方がいい。
>>236 多重継承できないからAdaptorパターンにも制限が出てしまうね。
まぁ、Adaptorパターン使わないといけない時点でOO的に不自然んだが。
>>239 そんな風に作っていくとRADが凄く使いにくくなるよ。
244 ：
デフォルトの名無しさん ：03/03/10 00:30
>>242 VCL と、自前のクラスとの区別ができてます？
多重継承ができないのは VCL とその派生クラスだけだよ。
>>239 の TFormObserver は、多重継承はできるよ。
それに、Adaptor パターンは多重継承とは関係ない。
仮に、多重継承ができない場合でも、Adaptor パターンが制約を受けることはない。
そもそも、何か作る時点で多重継承が気になること自体、クラス設計を間違えているか、
basic_ios の作者かメインテナであるといった特別な場合に限られる。
245 ：
デフォルトの名無しさん ：03/03/10 00:30
>>243 全然ならないけど。
RAD 部分とは関係がない。
246 ：
デフォルトの名無しさん ：03/03/10 00:32
>>243 は、クラス設計をせずに、VB のように TForm のハンドラの中にどんどん
コーディングしていくだけのプログラマだと思はれ。
>>246 それでも、そこそこ動くモノができてしまうのがＢＣＢのいいところであり、
悪いところでもあるな。
>>240 メッセージマップは、仮想関数テーブルの節約と、処理速度向上のためだそうだ。
設計よりバイナリをとったって事だろうな。
249 ：
デフォルトの名無しさん ：03/03/10 00:38
>>247 そこでやめてしまうこともできるし、そこから進みたい人には進めるようにできているのが
BCB のいいところだね。
250 ：
デフォルトの名無しさん ：03/03/10 00:41
>>248 BCB は、メッセージマップもできるんですね。
もし計測して本当にパフォーマンスが上がるのであれば、VC++ と同様のコードを書けば、
簡単にメッセージマップを使える。
というか、VCL 自体も、親クラスで VC++ のようにメッセージをマップして、イベント・ハンドラの関数を
呼び出しているだけ。
BCBのクロシージャはC#のdelegateみたいでクソ
252 ：
デフォルトの名無しさん ：03/03/10 00:43
>>248 そうやって変に OO ライクなところとパフォーマンスを取るところとをポリシーなしに
設計しているから MFC はいびつなクラス・ライブラリになるんだね。
253 ：
デフォルトの名無しさん ：03/03/10 00:44
>>251 __closure だろ？ < クロジージャ
あれは delegate じゃない。
254 ：
デフォルトの名無しさん ：03/03/10 00:45
delegate 使いたいなら AspectJ とかだな。
BCBはコード補完遅すぎ。
256 ：
デフォルトの名無しさん ：03/03/10 00:52
なくても大して困らないが。
257 ：
デフォルトの名無しさん ：03/03/10 00:53
>>248 BEGIN_MESSAGE_MAPとEND_MESSAGE_MAP知らないんでつか？
259 ：
デフォルトの名無しさん ：03/03/10 00:54
>>239 のTFormObserverは多重継承できない欠点を補うためだけに
存在しているのであって、設計自体には本来不必要なものだ。
多重継承できないVCLはやはり設計を複雑にさせる。
>>252 その思想は .NET にも受け継がれています。
C# は、ソースの見た目ばかりで、バイナリを省みない Java の様には
ならないように設計されています。
ソースの見た目のみの Java は極端な例にしても、
最適なバランスはグレーな位置にあるのは、
現実世界では一般的なことだと思います。
ここではC#とかJavaは関係ないだろ
俺はｱﾝﾁﾃﾞｻﾞﾊﾟﾀのOO主義者なんだけど
263 ：
デフォルトの名無しさん ：03/03/10 01:32
>>259 多重継承できるよりは、クラス 1 つ分複雑になるけど、VCL でそのままできないのは
Observer パターンだけなんでしょ？
だったら、MFC より VCL の方が、それを差し引いてもあまりある利便性があります。
264 ：
デフォルトの名無しさん ：03/03/10 01:39
VCL のクソ派は VCL の悪いところをあげて、VCL 素晴らしい派は VCL のいいところや
265 ：
デフォルトの名無しさん ：03/03/10 01:41
>>260 MFC のは「思慮がない」というレベル。
同じ事をするのにも、統一性がない。あるときはメンバ変数への代入だったり、
あるときはメンバ関数の呼び出しだったり、あるときはメッセージのハンドルだったり。
同じコントロールなのに、ダイアログ上にあるときと、パネル上にあるときと、MDI の
時とで扱いが全然異なる。
すごく複雑。
だから、まあ MFC の本が売れたりするんだろうけど。
266 ：
デフォルトの名無しさん ：03/03/10 01:44
>>265 コントロールのカプセル化に失敗していると思はれ。
MFC は、たくさんある Windows API を覚えるのが大変だから、コントロールごとに
ちょいとまとめようね、ぐらいのノリだから。
Windows API がニーモニックなら、MFC はマクロ・アセンブラのマクロのようなノリ。
MFC 素晴らしい派なんていないよ。
268 ：
デフォルトの名無しさん ：03/03/10 01:47
BCB でも MFC 使えるけど、BCB の使いやすいところと、必要ならそこだけ MFC を使うという
俺はATL/WTLがよくできてると思ってるんだけど
>>268 俺も最初はそうしようかと思ったが、結局BCBとVC7両方入れている。
IDEの支援で糞ソース生成するのは、得る物も大きいが失う物も大きい。
272 ：
デフォルトの名無しさん ：03/03/10 02:49
>>271 BCB 使ったことないでしょ。IDE は糞ソース生成しません。VC++ は変なスケルトンを生成しますが。
273 ：
デフォルトの名無しさん ：03/03/10 02:51
>>271 失うものはないと思うが。
糞か知らないけど、IDE が生成するソースの仕組みを知りたい人にとっては、
ソースが生成される以上に得るものが多い。
>>272 変なスケルトンと糞ソースの違いはどこ？
VC++のAppWizardのことなら
BCBの何もないフォームを生成しただけで凄いサイズになるのは何とかして欲しい。
277 ：
デフォルトの名無しさん ：03/03/10 05:57
確かに。ぶくぶくって感じだよな。
278 ：
デフォルトの名無しさん ：03/03/10 06:11
MFC の場合は、DLL で追い出してあるからサイズが小さく見えるんね。
279 ：
デフォルトの名無しさん ：03/03/10 06:12
スタティックリンクで比較しても結構違うと思うよ。
280 ：
デフォルトの名無しさん ：03/03/10 06:36
そっか。
>280
確かに VCLを使うと 実行時型情報の実現の為に色んな下支えが必要になるからね
>>281 Delphiで小さい実行ファイルをのスレで紹介されてるKOLは使えないのかな？
>282
>>284 じゃあ、やっぱりDelphiで小さなで紹介されてる実行ファイル圧縮ソフト使え。半分くらいになるよ
え・・なんで圧縮ソフト？
実行ファイル圧縮ソフトを使ったらどのソフトも半分くらいになるので
>>287 VCで2KB位のプログラム作ってUPXで圧縮しようとしても、
Program is too smallとかエラー出て圧縮さえ出来なかったぞ。
今試したらProgram is too smallじゃなくてNotCompressibleExceptionだったけど
>>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は役に立たないなあ
292 ：
デフォルトの名無しさん ：03/03/10 13:37
そういえば、VC++ ってデフォルトで RTTI が OFF になっていて、virtual デストラクタが
RTTI OFFでもvirtualデストラクタは動くだろ。
294 ：
デフォルトの名無しさん ：03/03/10 14:00
class A {
>>294 VC5のとき、派生クラスにオーバーライドした関数を追加したら
リビルドしないとオーバーライドした関数がちゃんと呼ばれないときが
あったけど、そういう話ではないの?
296 ：
デフォルトの名無しさん ：03/03/10 14:30
>>295 確かめるために、両方のデストラクタに ofstream でログを吐かせてめっけたので、
両方のクラスは再コンパイルされていたはず。リビルドしたかは忘れた。
297 ：
bloom ：03/03/10 14:32
>>294 それはRTTIとかとは関係なくバグだろう。
BCB派でVC++使ったことある人は結構いそうだけど、
VC++とDelphiがあれば十分
VC++とDelphiとBCC55があれば十分
302 ：
デフォルトの名無しさん ：03/03/11 20:48
VC++とDelphiとBCC55とnasmがあれば十分
織田信長だけで十分。
304 ：
デフォルトの名無しさん ：03/03/11 21:41
明智光秀だけじゃ自滅
徳川だけで300年
牛丼一筋300年
屁のつっぱりはいらんですよ
ここまでのまとめとしては、Javaが最強ということでよろしいか？
310 ：
Javaええよ ：03/03/12 18:07
Java厨が粘着だということが良く分かった。
>>311 思い込みたい内容を相手から見て取りたいだけでしょう。
馬鹿ですね（ｗ
>>312 ん？ 粘着って言葉にむかついたのか？
じゃあJava厨が無意味にあげてると真実を述べてあげよう。
>>313 あなたじゃあるまいし、別にむかつきませんよ。
それにしても、Java厨が、とか決めつけるあたりが最高に馬鹿ですね（ｗ
14日は2chが落ちる日…。
>>316 > (激藁嘲笑
おやおや、こんな余裕の無い煽りを引き出されちゃってまぁ（ｗ
>>317 プログラム板初心者がなんだか調子に乗っております。
そういうことにしたいのですね(・_。)ｽﾞﾘｯ
GCC >>>>>>>>>>>>>>>>>>>>>> JAVA >>>>>>>>>>>>> VC >>>>>>>>>>>>>>> BCC
323 ：
デフォルトの名無しさん ：03/03/14 01:09
Java > BCB >> GCC = BCC >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VC++
Delphiがねぇよ。
C++ >>>>>>>>>>>>>>>>> 漏れ
>>324 なにが「こう」なのでしょう。肝心なところをぼかした稚拙な文章ですね。
いずれにせよ、正しくは
「すぐJAVA厨とみなしたがる厨が来るとｽﾚがこうなるという見本」
なのでしょうけど（ｗ
328 ：
Javaええよ ：03/03/14 16:18
Javaはいつまでも主流なのさ！
329 ：
デフォルトの名無しさん ：03/03/14 16:20
DelphiとBCBって一般的にどちらが実行速度は高速なのですかね？
>>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ソースに触れることになるし。
と、ここまで書いて、遅かったことに気付いたわけだが(哀
最適化については、今時、あんまり気にしない方がいいかもしれない。
337 ：
デフォルトの名無しさん ：03/03/14 18:01
BCB も Delphi も実行速度は大差ないよ。
結局VCLばっかり呼び出してたら、どっちも変わらん罠
339 ：
Javaええよ ：03/03/14 21:43
JAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVAJAVA
Javaじゃないところが(ﾜﾗ
まあ、普通は気にする必要もないけど、遅いと体感できるような箇所ではやはり効果があるものなので
実際VC++使ってる企業が多く、BCBは少数でしょ？
>>342 で？ VC++ で何作るの？ 単なる労働者になりたいならそういう道もあるよね
VC++の俺的最大の謎は、long doubleとdoubleが同じだったりすることなのだが。
VC++使ってるところも、大部分VBで作って、API叩く部分なんかをVC++というパターンが多いんじゃないのかな。
BCBは企業レベルで使えないほどバグだらけ。
>VC++使えなきゃまずくない？
VC++ のほうがバグ多いような気がするけどな。ましてやプラットホーム
>>342 企業というか仕事ならクライアントの希望もあるしなー。
某のコンパイラよりM$を使うことが多いのは伝統というか保守性というか。
おうちで自分で遊ぶ分には、結局好みの問題に落ち着くと思う。
そういう俺も仕事はM$、趣味は某。GUI弄るの楽だからね。
C++とDelphiは、やっぱ参考書籍とか情報が違いすぎるね。
本屋さんに行けばわかる。
本屋さんいけばなんとかなるような仕事しかしてないからこの不況なんだろうよ
352 ：
デフォルトの名無しさん ：03/03/15 08:49
>>351 バブルのときは「専門書って何？」って人たちが大手を振ってプログラマを名乗って
いましたが、それが何？
353 ：
デフォルトの名無しさん ：03/03/15 09:06
Win98環境だから
>>352 よく知らないが、それは今でもそうなんじゃない？
残業酷くて勉強する時間も無いようだから、状況が変ってるとは思えない。
結局は、悪循環なんだろうな。
>>353 漏れも去年まではCeleron 1.4G + BCB or VC++.NET で開発していた
けど、重くてしょうがないので思い切って P4 2.8GにしたＹＯ！
結構軽くなって満足。やっぱ最近のCPUは違うよ。
356 ：
デフォルトの名無しさん ：03/03/15 14:38
P4なんて出たんだ・・。
>>356 Pentium4とタイプするのが面倒だからP4にしてる。いつもそう（ｗ
さすがにCeleronがCじゃわからないけどね（ｗ
>>358 そう言えばそんなCPUあったっけ。ならP4って略すのこれからやめるよ（ｗ
とりあえず、VC++/MFCが標準、BCBが亜流という時代はｵﾜﾀ。
VC++は 次のバージョンで ANSI互換性を98%にするそうだ
VC++はCOM用に最適化されてる。
gcc3.2最強という事でファイナルアンサー？
>>363 Windowsに関してはちょっと・・・
いまさらDOSやWin16なんてどうでもいい。
もともと .NET FrameworkにC++は馴染まない。他に適した言語がある。。
っていうか、VC++を使ってるプログラマーの大半はVisualStudioユーザだからVC#も持っている。
Linuxには、Linuxに最適な開発環境がある。
Windowsに最適化されたVC++をわざわざLinuxに持ち込もうという発想さえ起きない。
よってBCB厨のVC++批判の大半は難癖。
>>362 > 良いところが無いのにダイアログエディタで開発効率落としてくれる...
意味がよく分からないのですが・・・
>もともと .NET FrameworkにC++は馴染まない。他に適した言語がある。。
>> 良いところが無いのにダイアログエディタで開発効率落としてくれる...
＞あるソースを色んなターゲットに吐き出すのがコンパイラの仕事。基本。
ひと昔前はハードウエア依存を減らす事がひとつの目標だった
>>あるソースを色んなターゲットに吐き出すのがコンパイラの仕事。基本。
ま、VC++が他OSに移植されたとしても、COMベースでありゴミでしかないけど...
どっちにしろMSはマルチプラットフォームなんぞ全く考えてないだろ。
373 ：
Javaええよ ：03/03/15 17:57
java
M$の言うマルチプラットフォームとは
マルチプラットフォームの時代は終わったよ。始まってもいなかったけど。
結局ドライバとか低レベルの物を書こうと思ったらネイティブコード吐ける言語がいるわけで。
Kylixが少しは賑わっていれば、
>>370 に説得力も出てくるのだが…
まあ、Win慣れしてしまった俺が明日からLinux使えー！と言われたら、Kylixしか無いだろうけどなー
しかしKylixの現状を見るに、そんな事を言われた人間は思いのほか少ないと予想される。
>そもそもVC++とC#は完全に棲み分けが出来ている。
>>379 じゃあWindowsいらないじゃん。ぽい。
>そもそもVC++とC#は完全に棲み分けが出来ている。
>>381 ＞同じM$ワールド内で...
VC++がN88BASIC用のコードをコンパイルできないのはどうしてでしょうか？
VC++がMFC利用するとANSI C++コードをコンパイル出来ないのはどうしてでしょうか？
>＞同じM$ワールド内で...
>>384 ＞カバーする範囲。
従来のネイティブなプログラムと.NET Frameworkと言うより抽象度を高め統制した「箱庭」。
実行環境の時点で全然畑が違うわけだが。
>>358 頭悪いの分かったから、もう書かなくても良いよ。
Delphi.NETも出るし、BCB.NETも出るし。
.NETは要らないけど。
>>386 お前も少しは勉強してからしゃべった方が良いぞ。
誰一人として話しに参加してこようと言う奴がいない。お前も俺もかなりの低レベルってこった。
388 ：
デフォルトの名無しさん ：03/03/15 19:11
バカふたり晒しage
>お前も少しは勉強してからしゃべった方が良いぞ。
>>367 >>> 良いところが無いのにダイアログエディタで開発効率落としてくれる...
>>意味がよく分からないのですが・・・
>これの意味が分からないのは、VC++を実は使うことが出来ないM$厨。
( ´,_ゝ`)ﾌﾟ お前の文章能力が無いだけだろうが。
「A のに B」という表現を用いる場合、B は A を否定する内容でないといけないといことを教えてあげよう。
●VC++には良いところが全く無く、特にダイアログエディタによる開発効率の悪さには辟易させられる。
●VC++にはダイアログエディタによる開発効率の悪さに代表されるように、良いところが全く無いといえる。
こういう風に書け。
ここまでの結論としてマルチプラットフォームでオブジェクト指向かつ
ゲッ、脱字だ。
じゃあ、結論。
>>392 それよりも
×「A のに B」
○「A なのに B」
の方が気になったよ、俺は
>>391 が確信を突く発言をスィタ！
お前らこれからは、事前のコンパイル不要 ".TXT" 構想でいこーぜ！
>>395 パッケージソフトビジネスが崩壊するカモな。
>>1-399 で導いた結論
趣味ならBCB
仕事ならVC++
でよろしいか？
趣味なら実をとるが
>>402 違うと思われ。
VC → デファクトスタンダード
BCB → 安置MS御用達
え？趣味なのにMFCで開発するの！？
>>400 前の会社では、GUIはBCB、実装はVC++で顧客用画面を作ったものだ
WindowsXPですが、VC++.NETをインストールしたら、IEが動かなくなった。
407 ：
デフォルトの名無しさん ：03/03/16 10:23
>>406 俺もＸＰは資産継承がイマイチなので見捨てて次まで待つよ。
．ｎｅｔは使わん。
408 ：
デフォルトの名無しさん ：03/03/16 14:04
>>407 XPを見捨てるというのと .NET を使わないということにはどういうつながりがあるのですか?
409 ：
デフォルトの名無しさん ：03/03/16 14:39
漏れＢＣＢ派、ＶＣ＋＋は最初のあの意味のわからない画面でやる気無くす。
>>409 で、VCLがどれだけ壮大な世界を持っているというのだ。
412 ：
デフォルトの名無しさん ：03/03/16 14:48
>>411 おれは別にアンチM$ではないが、BCB派だが。
>>413 Ｍ＄などと書く人が公平に見ているとは思えませんが？
ＢＣＢ派の無論フリーコンパイラ派ね。
それはシャレ。というかわざわざこんなこと書かせないでほしい。
420 ：
Javaええよ ：03/03/16 20:43
Java
M$マンセーだったとしても、
俺は初心者なんでよくわからないが、ﾎﾞｰﾗﾝﾄﾞのサイトの
>>422 宣伝だから策略以外に無いのは間違いない。
が、内容は事実。否定出来ない。
>>423 ということはBCBのほうが圧倒的に高機能ってこと？
まぁ、VC++はOS Winを使っている限り 安定性は抜群だとは予想できるが…。
>>424 情報量もVC++のほうが圧倒的に多いよ。
>まぁ、VC++はOS Winを使っている限り 安定性は抜群だとは予想できるが…。
>情報量もVC++のほうが圧倒的に多いよ。
>>424 ところが安定してないってのがM$のミラクルなところ
ActiveXが死んだ今、MSDNの情報はゴミと化した。
ま、使ってみることさ。
VC++を使ってる企業の開発の中には
>>427 > この多い情報はActiveXに関するものヴぁかり。
本当にMSDNライブラリを見たことがあるの？
BCBを愛しているのはよく分かるんだけど、一人で連続カキコしているあたりがイタい。
>>433 イタイ、としか反論出来ないんでしか。
ま、某の宣伝のVC++ボロクソ比較でも読んでなさい。
反論出来ないくせに。
>>429 >>432 MSDN無用は言い過ぎではないかと
俺は主に某で開発してるけど結構MSDNのお世話になってるよ
（特にWindows SDK関係）
>>435 そんなこと言ったって、自分はMSDNのSDKを全く読まないよ。
MS-Cの時代からWin16の開発してたから。
で、Win16からダイアログエディタ使ってたが、VC++はゴメンだね。
サブシステムの開発者光臨age
440 ：
デフォルトの名無しさん ：03/03/16 23:28
俺はCFormViewはあまり使わないし、ダイアログも環境設定用に作るぐらいだから
いやいや、ActiveXの死亡はVC++の死亡。
ダイアログがどうこう書いてる時点でVC++に毒されてる、手遅れかも。
>>440 言い訳がましいこと書いてるだけで、VC++に良さは無いわけね。
>VC++の次バージョンではほぼANSI準拠になるみたいだし。
そもそもActiveXコントロール自体あまり作ってないしな。一般的なCOMオブジェクトは作るけど。
やっぱSeaSharpだよね！
440さん、どうも有難う。VC++を使ってる人が非論理的思考であることを教えてくれて。
>だからVC++が今死んでいるとはとても思えないよ。
>しかも.NETでCOMが不要になるとはいえ、今現在の仕事はWin32だしCOMももちろん使われている。
もしかしてまなげどC++のことでしか？
まなげどC++は、ダメっしょ。
んなこたーない
M$のCOMはウニックスすると散々宣伝して、動作しなかったのに、
(´-`).｡ｏO(某社員必死だな…)
>>454 そういう反論しか出来ないんだ。かわいそうでし。
某の宣伝のVC++比較に一つでも反論してみたら？
悪貨は良貨を駆逐するとか。。。
COMの標準クライアントってVBだよね。
( ﾟдﾟ)ﾎﾟｶｰﾝ
457に( ﾟдﾟ)ﾎﾟｶｰﾝ
もうね（以下略
>>457 またまたそういう反論でしか。
VC++に良さが無いんだから書きようが無いのは分かるけど。
勝負あったな。。。
結論：
ということにしたいのですね？
>>457 の選択肢
１．論点をそらし、詭弁ではぐらかす
２．コピペ荒らし
３．厨房を装う
>>466 ４．いつものＭ＄厨というスタンスをとり、ﾌﾟﾌﾟ嘲笑激藁レスで逃げ切る。
469 ：
デフォルトの名無しさん ：03/03/17 00:19
選択1
470 ：
デフォルトの名無しさん ：03/03/17 00:19
BCB？何それ？うまいの？
>VC++を使ってる人はそれですべてをまかなおうとは思ってないと思うよ。
>少なくとも仕事で使ってる人にとってはVisualStudioで一つの製品なんだから。
>>471 えーと、DOSはどうでもいいし、Win16はMSDNからVC1.51をダウンロードできるから
実質的な差はLinuxに対応しているかどうかだね。
>>473 頭おかしいＹＯ！
一つで出来るやつと、色々組み合わせても、まだDOSが足りないものと。
組込みではDOSがあるんだけど...
>>473 だから、VC++の良さは書けないわけね。
VC++に足りないのは○○だけ、ってのヴぁっかり。
VC++みたいなダメダメコンパイラ使ってると、思考もダメになるんだな...
初心者がMFCを真似て不気味なキャストの使い方を覚えてしまうのも
MFC自体が困り物だ罠。
以上、某社員のｼﾞｻｸｼﾞｴﾝ （･∀･） ﾃﾞｼﾀ !!
え？BCBで作ったバイナリはプラットフォーム依存じゃないの？
In article
>>480 , デフォルトの名無しさん/sage/480 wrote:
> 以上、某社員のｼﾞｻｸｼﾞｴﾝ （･∀･） ﾃﾞｼﾀ !!
ということにしたいのですね。:)
某社員が大漁に釣れるスレはここですか？
趣味ではともかく、仕事じゃやっぱVC使わんと。
古い Cプログラマが頑固に Cを使い続けるのと同じだな。
>趣味ではともかく、仕事じゃやっぱVC使わんと。
485は、ActiveXを買って仕事をしてるﾌﾞﾋﾞ厨だね。
489 ：
デフォルトの名無しさん ：03/03/17 07:17
しょーがねーな、そこまで言うんだったらちょっくらTrial版でも入れてみるか
でもさぁ、XercesとかORBacusとか、なかなかBCBで使えなくて苦労したよ。
491 ：
ケンタ様（神） ：03/03/17 07:20
おいお前ら
なにをばか荒らし相手にやってんだ
うんこな荒らしばっかりだし（大爆笑
なんだよ、もんくあるのか？
http://jbbs.shitaraba.com/computer/5310/ ここに来いよ、いくらでもあいてしてやるよ
まぁ、おめえらだったら帰り打ちが精いっぱいだろうな（大爆笑
あとさ、あんまりムカつくやつあらわれたら、
IPから住所出して家になぐりこみに行くからな。
俺やくざみたいな友達が1万人もいるからさ、
おめらなんてイチコロだよ（大爆笑
まぁ俺はお前ラと違って頭もいいし（大学で１ばん
ぶっちゃけ情報量の差で決まると思うが。
>>490 VC++用の メークファイルがあるのなら、そのまま動くと思うが？
VC++用のプロジェクトがあるなら、プロジェクト変換ツールが添付されてると思うが？
どこでつまづいたの？
>>492 情報量の差って・・・・・
同じネイテブコンパイラである以上 VCのコンパイラオプション以外の情報は
全て共有出来ると思うが？
もちろん VCL は pascalだから VCL の情報はVCでは意味がないが
さらに ActiveX/COMは BCB でもVCと同じように使う事も作る事も出来る。
>>490 プロジェクト変換だけじゃだめだったんだよ。
あと、VC++用のlibやらdllがそのまま使えないし。
BCBでDirectXは100%使えるの？
>>500 100% は VC++ でも無理だろう。
なんせDirectX にバグがあるんだから。
>>498 まさか C++ のままで作った DLL ？ そりゃ動かないよ。
・・・・というかそんなレベルの仕事してるなら 確かに VC でなきゃ仕事出来ないだろな。
>>496 マジか？ってどういう意味？
まさか、「この順番にキーボードを触ったら ほら出来上がり」 みたいな本が必要なのか？
そうでないなら、同じC++なんだから
C++の文法書も、STLの解説も、 Windows API の解説も、COMも MFC も
全て共有出来るのが当然だろ？
なんか、VC++の良さを情報量でやっとやっと説明したみたいだが、
>>502 ライブラリがDLLで提供されることなんてざらだろ？
>>503 VCLコンポーネントの作り方に関する書籍はかなり少ないな。
>>505 ○ライブラリがDLLで提供される事はザラ
×ライブラリがC++の型保証名のままDLLで提供される事はザラ
前者なら、BCBでもVBでもDelphiでもWindows上の大抵のプログラミングツールから使える
後者は その環境でしか使えない
>>506 かなり少ないというのは正確ではない。
VCLコンポーネントの作り方を解説してる独立した書籍は
日本では最近出たDelphi用のもの１冊しかない。
しかし、古いスタイルのOOPと理解すれば、
普通に継承して普通に書けば良いのであまり困らないと思うが？
>>508 いや、例えば、コンポーネントを複数登録できるプロパティのつくり方なんか、ヘルプ見るだけじゃわからんし。
>>507 ×ライブラリがC++の型保証名のままDLLで提供される事はザラ
ようするにクラスをもったDLLですよね？
よく遭遇したのだが、漏れだけか。。。
あと、必要なライブラリがわかってて、その資料にBCBでの動作を保証しないことが記述されてれば
BCBで動くとしてもBCBだけでは開発できない。
関係無い。
>>508 最近出たの？
なんて本か教えてほしい。
DDJJの記事くらいしか資料がなくて不便だったんだよね。
>>503 同じ・・っていうのがそもそも違う。
コンパイラで見たら GCC != BCB != VC なのは明らか。
VC++ でコンパイルできるソースが BCB でコンパイルできるとは限らない。
>>511 情報も開発環境のうち。
マニュアルも解説もなしでVCL使いたいか？
Delphiコンポーネント設計＆開発 完全解説
>>513 ○VC++ でコンパイルできるソースが BCB でコンパイルできるとは限らない
これは正しいが、
では、
C++の文法も、STLの解説も、 Windows API の解説も、BCBでは使えない
は正しいのか？
まるで コピペで動かなきゃ イヤダヨ～ ってだだこねてるだけにしか思えないのだが？
>>515 たとえば既存のライブラリを使わないといけない場合。
テンプレート周りを使う場合。
その他バグ。
わかった？
>>515 は数人での仕事でBCB使ったことがあるのかな？
既存のライブラリを使わないといけない場合。
>>518 BCB はワンマンアーミが使ってこそ武器になるツールでしょ。
だいたい、自作、コンポーネントを他人に使わせるなんて絶対に嫌だね。
>>519 あんたねぇ・・・
バグとか出たらどうすんの？
実際使ったことあんのか？
なんかここまで言うのがあほらしいんだが・・・
ちなみに、数人でVC++を使うような怖いことはたぶんしません。
>>520 ひとりで使うなら、自分さえ知ってればいいから、資料はいらないね。
でも、世の中の多くの人は、数人でプログラム組んでるんだよね。
>>523 羨ましいよ。 数人で組めるってのは、いいクライアント掴んでるんだね。
お金もらえる所の仕事なら、新人の教育を兼ねて、ちまちまVCで出来るんだが、
最近、そういう仕事が無くなって、納期無いお金貰えないだからしょうがないさ。
525 ：
デフォルトの名無しさん ：03/03/17 13:05
>>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++ を理解
できないため、そのままではコンパイルできないという問題がある。
526 ：
デフォルトの名無しさん ：03/03/17 13:07
ちなみに、Windows API の解説書は、BCB でも何ら問題なく使える。
VC++を使えば、MFC経由で非公開APIを使えるということはないでつか？
528 ：
デフォルトの名無しさん ：03/03/17 13:10
>>506 いまどき、質のいい情報が書籍で出ているとは限らない。
qmail の作者じゃないけど、いい情報はウェブに出ていることがおおい。
529 ：
デフォルトの名無しさん ：03/03/17 13:12
>>527 非公開な機能を使うなんて、まともなプログラミングでやることじゃない。
PC-9801 で高速なゲームを作らなきゃならなかった時代じゃないんだから。
531 ：
デフォルトの名無しさん ：03/03/17 13:26
>>530 てかさ、マニュアルとヘルプに書いてあるぜ。
>>531 マニュアルに書いてあるのって、ごく基本的なコンポーネントの作り方だけじゃない？
>>532 ソース嫁
Pro版以上はソースが付いてくる
534 ：
デフォルトの名無しさん ：03/03/17 13:41
既存のコンポーネントを継承してコンポーネントを作るならソースを見ればいいんだよね。
確かに コンポーネント作成は、Delphiのコードが読めないと厳しいだろうな。
536 ：
デフォルトの名無しさん ：03/03/17 13:44
つまり、Web上の情報はあきらめろと。
ゴメン QuickReport は使った事ないや 便利そうだけど それ使うと、なんかVB屋になった気分で
539 ：
デフォルトの名無しさん ：03/03/17 13:47
VCL コンポーネントはただのクラスだから、自分のライブラリを VCL にしようと
思ったら、しごくかんたん。TObject を親にするだけのこと。
付属 VCL を拡張するなら VCL を理解すればいいね。
Inside VCL
http://www.asahi-net.or.jp/~HA3T-NKMR/invcl.htm ようするに、コンポーネントの作り方は簡単なの。
何から拡張してコンポーネントを作るかは、コンポーネントの作り方じゃなくて、
もととなるライブラリの知識が必要。
540 ：
デフォルトの名無しさん ：03/03/17 13:48
>>538 それは Crystal Report じゃないの？
>>539 TObjectだとコンポーネントにはならない。
TComponentじゃないと ポトペタは出来ない。
コンポーネントの要素として使う場合でも最低TPersistent継承にしないといけない
>>540 ソースの付いてこないコンポーネントを使うのは
中の実装を知らずにActiveXを使うVB屋と同じようだ
という意味でないのけ
>>539 いや、別にTButton継承して音が出るボタンつくるくらいなら簡単なわけだが。
プロパティデザイナ作るときとか、配列プロパティ作るときとか、そういうときの資料がないんです。
そういえば、VCLって多重継承ができないのもいやだよね。
>>543 プロパティデザイナ→プロパティページかな
配列プロパティはソースを読めばフツーに分かる
「多重継承はめったに使わないだろ？」っていう詭弁キボン。
546 ：
デフォルトの名無しさん ：03/03/17 13:58
MFCやるよりマシだろ、という詭弁。
548 ：
デフォルトの名無しさん ：03/03/17 13:59
>>543 ああ確かに デザイナは最初 サンプルコード漁りまくったな・・・・
で、やってるうちに、別に自分で使うのに無理に作る必要ないやって気分に
配列プロパティって 無理にプロパティにする必要は無いと思うけどなあ
どっちにしてもpublished に出来ないんだし
550 ：
デフォルトの名無しさん ：03/03/17 14:03
てかさ、VCL を多重継承して嬉しいことはない。
551 ：
デフォルトの名無しさん ：03/03/17 14:07
クラスの拡張って、継承（多重継承も含む）しか知らない人って結構多いんだね。
多重継承はVCLも使ってる筈だけどなあ
>>551 VCLの中ではhasしまくってるのにね
>>550 VCLクラスを継承して、VCL外クラスも継承したいとか。
Javaならインターフェイスを使うような多重継承のことだが。
>>554 それがやりたいならそうすればいいのでは？
どこで困ってるの・
>>555 出来ないから困ってるんですが。
どうやってやるの？
>>549 配列プロパティって、TDBGridのColumnsみたいなプロパティのつもり。
558 ：
デフォルトの名無しさん ：03/03/17 14:35
class TObservableForm : public IObserver
559 ：
デフォルトの名無しさん ：03/03/17 14:36
あ、virtual デストラクタを IObserver に追加しといてね。
560 ：
デフォルトの名無しさん ：03/03/17 14:43
template <class T> class ISubject
561 ：
デフォルトの名無しさん ：03/03/17 14:45
なるほど。
>>558 たとえばTLabelを拡張したコンポーネントとTButtonを拡張したコンポーネントを作ったとして
その２つのコンポーネントに共通の関数をつけたい、というだけなんだけど。
そのコード書くならイベント使った方がいいね。
>>557 こんな感じ
property Items[Index: Integer]: TColumn read GetColumn write SetColumn;
564 ：
デフォルトの名無しさん ：03/03/17 14:49
>>562 全然関係のないクラスに共通の関数をつけるのに、
多重継承なんて使っちゃだめでしょ。
565 ：
デフォルトの名無しさん ：03/03/17 14:51
>>562 その場合は、Memento パターンを使うんだな。
ついでにTObservableForm に operator IObserver *(void) も定義しといたら
あ、共通って、
>>562 共通の関数なら、VCLの __published メンバの実行時型情報を使うと便利だよ
>>567 THogeButton と THogeLabel の両方に IHoge と hogehoge()と operator IHoge *(void) を持たせたらいいのでは？
570 ：
デフォルトの名無しさん ：03/03/17 15:01
そっか、やたら多重継承が使いたい人って、正しい使い方（Java の interface 的なもの
571 ：
デフォルトの名無しさん ：03/03/17 15:04
>>567 それだけのことに多重継承を使っちゃいけない。
多重継承が使える場合でもそんなことはしちゃいけない。
たとえば、THoge というオブジェクトを作り、
THoge::Hogehoge(TButton *Button);
THoge::Hogehoge(TLabel *Label);
などと、メンバ関数のオーバーロードで対応すると、同じオペレーションでの
記述が得られ、多重継承を避けることができる。
実現方法はいくらでもあるんだけど、多重継承使えればすっきりかけるのに、と思うのですよ。
573 ：
デフォルトの名無しさん ：03/03/17 15:07
>>572 OO のやり方として、実現方法がいくらかある場合、多重継承は真っ先に
除外するのがスマートです。
574 ：
デフォルトの名無しさん ：03/03/17 15:08
デザイン・パターンなどで、定石的に多重継承が用いられている場合や
もちろん、THogeButtonとTHogeButtonがHogeという共通の責任を持つということを示した上での共通の関数だよ。
ちなみに
>>554 で書いてるように、Javaのインターフェイスがやりたいのね。
577 ：
デフォルトの名無しさん ：03/03/17 15:13
>>527 >>567 のような方法は、呼び出すコードを見る分にはシンプルな気がしますよね。
でも、何の脈絡もないクラス同士がなんで同じ親を多重継承しているんだろう、
ってなって、いい設計じゃないですね。
Java の Runnable のような interface なら納得いくかもしれませんけど。
578 ：
デフォルトの名無しさん ：03/03/17 15:15
>>575 なるほど、そういうことなら、設計として多重継承の意味があるね。
あと、THogeButtonとTHogeLabelがHogeという共通の責任を持つということが、委譲ベースだと示しにくいと思うのでつ。
完全に同じ処理なら、単純に void hogehoge( TControl * hoge); って関数を作って
581 ：
デフォルトの名無しさん ：03/03/17 15:24
>>579 それなら、Visitor パターンかな。
>>580 OO 的に、素の関数って作らない方がいいと思う。
582 ：
デフォルトの名無しさん ：03/03/17 15:26
親クラスに関連のないクラス郡に、一貫性を持ってアクセスするのなら Visitor だろうな。
>>581 どうかな JAVA のデザインパターンは基本的に 関数ポインタが使えないって条件でのパターンだからね
それをそのまま持ち込んでも冗長なだけでしょ。
ところで、506 は CButton と CEditなら 同じ問題をどう解決するんだろ？
ただ、実は一番こまったことは、多重継承のよい例をVCLから勉強できないことでした。
Delphiには interface 型 もあって、実際VCLは IDEでコンポーネント操作する為に interface型を使ってるし
COM/ActiveXを扱う時に使ってる。
しかし、その部分を BCB 側で見ると、
>>558 のような仕掛けに変換されてしまうわけで
ATLスタイルの仕掛けとは違う。
でも、それは違う言語(Delphi)からの借り物だからしょうがないでしょ。
C++でコードを書く時はC++のメリットを生かせる使い方をしたらいいのであって、
VCLはシンプルで強力なのがメリットなのだから、それを心がけて使う方が幸せでしょう。
だいいち、コンポーネントを拡張したいなら、Delphi言語で書いた方が楽ですよ。
Delphiって、データ構造に弱くない？
結局コンポーネント作るならDelphiで、ってことですね。
588 ：
デフォルトの名無しさん ：03/03/17 15:56
>>583 「Java のデザインパターン」ってなに？ゆう話もあるけど、C++ は OO やない
こともできるのであって、できるからゆうのとやるゆうのとは違うやんか。
>>586 Delphiの構造体型(record)は Cの union と struct を兼ねたものです。
Delphiと C++では Delphiの方が基本型が多いだけで、同じ程度の記述力でしょう。
>>587 そうですね。
それに コンパイルも高速だしで 自分は GUI フォーム回りまでは Delphiで書いています。
590 ：
デフォルトの名無しさん ：03/03/17 15:59
OO の仮想関数は、関数ポインタを排除するのも目的のひとつだから、OO の
591 ：
デフォルトの名無しさん ：03/03/17 16:02
>>586 TDeque とか TMap みたいなのが欲しいってこと？
似たようなのはあるけど C++ みたいにいろいろはないなあ。
>>589 STLに用意されてるデータ構造が、Delphiでは使えないので。
TListなんかも見さかいなくて、ちょっと。
593 ：
デフォルトの名無しさん ：03/03/17 16:08
VC++6.0でDOSのプログラムを作る場合は
最近VC++の話がでてきませんね。
あ、だから
>>583 はCButtonとCEditって言う風に話を振ったのですね。
>>592 なら、データ処理はC++で ビューはDelphiって別けた方が楽ですよ。
>>593 MSC++ をどこかで入手しないと無理でしょ
>>595 でも、ひとつのコンポーネント作るなら、どっちかにしたほうがよくない？
>>597 VC++ も BCB も 32bit コンパイラです
16bitコンパイラは MS-C++ BC++ 迄です。 Delphiは 1.5 迄が 16bitコンパイラでした。
VC++1.4あたりも16bitだったと思うんだけど。
>>596 Delでうまく記述できないようなデータ構造を必要とする
高度なコンポーネントが必要なら、自分でなんとかするしかないでしょ
テンプレートといっても同じ内容をDelで記述できないわけではないし
普段開発してる分には困ることはないんだけどね
そう。日ごろはBCBで困らない。コンパイル時間以外。
>>590 そもそも厳密にOOのスタイルで書くなら C++ を使うメリットは？
＞デザイン・パターンって Java だと思ってる？
その３割がたはJavaの事情から生まれたものだと思っています。
>>596 C++側でコンポーネントを書く事も出来るし、Delphi側で全部書く事も出来るし
それを自分で好きなように調整出来るのがBCBの良さだと思います。
603 ：
ケンタ様（神） ：03/03/17 16:30
604 ：
デフォルトの名無しさん ：03/03/17 16:35
>>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ビット(でも構わない)アプリを作りたいんではなかろうか
といってみるテスト
607 ：
デフォルトの名無しさん ：03/03/17 16:44
なるほど、Eric Gamma が、既存のデザイン・パターンに名前を付け出したのが
608 ：
デフォルトの名無しさん ：03/03/17 16:45
>>605 VC++ 2.0 には DOS 用の EXE も作れる CL.EXE がついていてたような気がしたけど、
幻か？
609 ：
デフォルトの名無しさん ：03/03/17 16:47
VC++ 2.0 には MS-C 7.0 がついていたような気がするのう。
610 ：
デフォルトの名無しさん ：03/03/17 16:53
ＢＣＢで作ったＤＬＬを"ＶＣ６＋＋"もしくは、
>>607 それより、Javaが出たのとGoFの本が出たのが同じくらいの年だからでは？
で、Javaのひろがりとデザインパターンのひろがりがリンクして。
デザインパターンの説明も、Javaが多いし。
あと、Javaのクラスライブラリでたくさんデザインパターンが使われているという紹介も多い。
で、Smalltalkはいつからなんだ？
>>610 基本的に、他の言語で使えるようにするには型保証名は使わない事
つまり extern "C" で公開すれば OK
クラス的な構造にしたいなら ActiveX にするのがVB側からは楽でしょ
デザインパターンは最初 C++ で言われてたと記憶してる。
>>615 あれは、「パターンを整理して名前を付けた」といことに価値があったのですね。
617 ：
Javaええよ ：03/03/17 17:40
なぜ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社製のコンパイラを使って開発してるニダ。
まあどっちにしても、この業界 タソガレてるような雰囲気が・・・・
正直、このスレみてるとVC++(M＄)になんのとりえがあるのかと思ってくる
てーか本当にBCB.NETって発売される予定なのかと問いたい。
624 ：
Javaええよ ：03/03/17 21:05
Javaはね最高のプログラミング言語なの分かる？
Javaは泥棒猫。
>>624 なんの言語を使うかは人による。
何を基準に最高と取るんだ？
627 ：
デフォルトの名無しさん ：03/03/17 21:21
>>611 そういえば、日本語でデザイン・パターンが話題になりだした頃は C++ での
説明が多かったけど、Java での説明の方が今はだいぶ増えているね。
628 ：
デフォルトの名無しさん ：03/03/17 21:23
Javaの利点は
ドパミンの出具合で最高が決まるんじゃないの？
631 ：
Javaええよ ：03/03/17 21:31
Java==C++ + C
632 ：
デフォルトの名無しさん ：03/03/17 21:32
>>628 試しちゃいないが、java/javaw コマンドに -server オプションをつけて
起動をすると、めちゃくちゃ速くなるらしい。
環境がある人、だれか、試してみて。
633 ：
デフォルトの名無しさん ：03/03/17 21:33
634 ：
デフォルトの名無しさん ：03/03/17 21:34
>>629 いや、セロトニン回路が発達していると、せっかくドーパミンが出ても
感情が押さえられちゃうよ。
635 ：
デフォルトの名無しさん ：03/03/17 21:50
BMPとかからTIFFのGroup3(FAX)形式に変換するライブラリとかない？
637 ：
デフォルトの名無しさん ：03/03/17 22:46
>>636 あなたのような親切な方がいるからです。
638 ：
デフォルトの名無しさん ：03/03/17 23:57
一晩で150ﾚｽ近く…煽りとしては上々か。
641 ：
デフォルトの名無しさん ：03/03/18 00:47
>>640 implib や MFC 取り込みで問題なく使えていますが、それが何？
やっぱり知ったかのﾌﾞﾋﾞ厨じゃん
つーか
644 ：
デフォルトの名無しさん ：03/03/18 01:12
>>640 > Winｱﾌﾟﾘの新規作成なんて仕事はまず無い。
すごくありますけど。
645 ：
デフォルトの名無しさん ：03/03/18 01:31
>>644 確かに
パッケージソフトの世界では
まだまだVCの出番が多い
実際、CADカーネルとかの実装も
MFCでフレームワーク組んであったりする事が多いし
悲しいかなデファクトスタンダード
>>640 ５点
もっとがんばりましょう
つか、（・∀・）ｶｴﾚ!!
647 ：
デフォルトの名無しさん ：03/03/18 01:33
>>645 社内 C/S みたいなのでも、クライアントに Windows アプリケーション
新規案件は多いですね。
結局末端にはWindowsがいるわけだし。
652 ：
デフォルトの名無しさん ：03/03/18 02:34
ヘルズバーグの居なくなったB社についていく理由などない。
653 ：
デフォルトの名無しさん ：03/03/18 02:42
>すごくありますけど。
ヘルス・バイキング？
>>653 映画会社に就職していい映画を撮るのは無謀でも、個人でいい映画を撮って認められる時代ですからね。
ゼネコンソフトハウスが崩壊してるだけ + 普通に大不況。
>>653 ニッチな分野に特化したソフトは
これからも産業として成り立っていくと思うよ
ノウハウの蓄積がソフト化されてるものは、
その価値がノウハウにあるからね
一般的な市販アプリの市場はコンペチタも多く
薄利で厳しいだろうけど
激しくスレ違いなのでsage
BCBってそんなに良かったんだ？
性能がいいソフトはBCBやDelphiよりもVCが多い気がするし。
BCBはそんなにユーザ数が多くない気がする…。検索してもあんまり情報が出てこないのが悲しい。
661 ：
デフォルトの名無しさん ：03/03/18 07:12
BCBがVCと戦ってはいけません。ターゲット層が違いすぎます。
662 ：
デフォルトの名無しさん ：03/03/18 07:20
って言うかBorlandは数年前に経営者以下ほとんどが総入替になっている罠。
で今は帰ってきてるとか？
664 ：
デフォルトの名無しさん ：03/03/18 07:50
正確には昔BorlandでDelphiとか開発環境作っている部隊とビジネス製品を作っている部隊で
665 ：
デフォルトの名無しさん ：03/03/18 10:23
>>661 BCB は VB ユーザも取り込めるし、VC++ よりいいので、使っているうちに
VC++ よりいいということに気づくという販売戦略だな。
BCB vs VB
>>651 >仕事でそんなんやったら…
やってますが何か？
669 ：
デフォルトの名無しさん ：03/03/18 16:16
BCBEnterprice
>>669 残念ながら人じゃなくて組織が購買層なのだよ。
672 ：
デフォルトの名無しさん ：03/03/18 16:29
いつのまにかBCBのスレになってますな。
>>669 DecisionCubeが高いんじゃないかな。
同等製品が20万くらいしてるし。
>>672 BCBもVCとほとんど同じだよ
>>673 VC7はイマイチだけど、7.1 のベータはちょっといじったところ、かなりいい感じ。
テンプレートの特殊化ができるようになったのが大きな進歩
676 ：
デフォルトの名無しさん ：03/03/18 18:24
>>672 テンプレートがまともに動かないのは VC++ の専売特許じゃん。
BCB の方がはるかに ANSI に準拠しているよ。
G++ だって ANSI にとても準拠しているのに、VC++ はぼろい。
677 ：
デフォルトの名無しさん ：03/03/18 18:26
だいたい、VC++ でこれが通るかね。
678 ：
デフォルトの名無しさん ：03/03/18 18:29
VC++ って、こんなのも理解できない。
VC++の粗悪品もさることながら、
680 ：
デフォルトの名無しさん ：03/03/18 18:33
>>678 にわかには信じ難いんだが、どんなエラーメッセージが出るの？
682 ：
デフォルトの名無しさん ：03/03/18 18:41
>>677 これも普通に通った。例外関係でwarn出るのでGX付けたけど。
684 ：
デフォルトの名無しさん ：03/03/18 18:45
>>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' : 識別子がｸﾗｽ名でも名前空間名でもありません。
685 ：
デフォルトの名無しさん ：03/03/18 18:46
>>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' に変換
できません。 (新しい機能 ; ﾍﾙﾌﾟを参照)
この変換を実行可能なﾕｰｻﾞｰ定義変換演算子がないか、または演算子を呼び出せ
ません。
686 ：
デフォルトの名無しさん ：03/03/18 18:47
E:\>cl test.cpp
687 ：
デフォルトの名無しさん ：03/03/18 18:47
01: #include <iostream>
688 ：
デフォルトの名無しさん ：03/03/18 18:47
20:
689 ：
デフォルトの名無しさん ：03/03/18 18:47
C:\home>cl -GX -W3 traits.cpp
690 ：
デフォルトの名無しさん ：03/03/18 18:49
>>686 VC++ 7 はやっとまともになったんだね。
ようこそ、BCB や GCC と同じレベルのコンパイラへ。
VC5で未定義だった機能を勝手にMSが実装したが、標準仕様にはなれず。
ついでにVC7もMCで忙しいので完璧とは言い難いな。
まぁ、未だにMS-Cで組込DOSがメインな俺はVCをエディタ以外の用途で使っていないが。
このスレ開くたびに皇太子殿下が目に入る
BCBのC++標準度はG++の足元にも及ばない。
696 ：
デフォルトの名無しさん ：03/03/18 20:36
g++のC++標準度はcomeauの足下にも及ばない。
698 ：
デフォルトの名無しさん ：03/03/18 21:38
>>696 ライブ・コンサートで曲と曲の間のいわゆるおしゃべり。
699 ：
デフォルトの名無しさん ：03/03/18 21:39
701 ：
Javaええよー ：03/03/18 21:42
ねーなぜC++なの？
>>699 はぁ、はぁ・・・ありがとー！
きょうは・・・はぁ。このツアー最後のライブということで、いつもより気合いを入れてたんですが・・・
はぁ・・・っあ～、みんな元気だね～？
ははは。えー、今日はっみんな、一緒に楽しい思い出を作っていこうね～！
ダダダダダンダン
703 ：
Javaええよー ：03/03/18 21:45
>>702 はぁ？
なんでC++なんだよ！
Javaだろ！！！！
VC++はなー、エヂタがいいんだよエヂタ
Javaみたいな初心者言語とC++を一緒にするな
706 ：
Javaええよー ：03/03/18 21:57
>>705 なんだと！！！！
JavaはなC++以上にいい言語なんだぞ！
707 ：
デフォルトの名無しさん ：03/03/18 23:11
JavaはC#とでも戦ってなさい。
Javaの次派生言語は
死者腐です
710 ：
デフォルトの名無しさん ：03/03/18 23:29
MS的にはJ#.NETが最先端らしい。
>>708 Java++はともかく、Java#は激しく意味不明。
あれはCだから趣がある。
ってーか、CのつぎはPだと思ってたよ！
712 ：
デフォルトの名無しさん ：03/03/19 00:35
>>621 なーんだ。VC++のほうが成績がいいんだな。
713 ：
デフォルトの名無しさん ：03/03/19 00:44
>>712 VC++ 7 からは、ましになったんだね。
えがったえがった。
>>708 Java.NETにきまってるだろうが。
>>704 はげどう。
あのえぢたはええね。
BCBのえぢたの貧弱さ、どうにかならんのかな。
最新版では改行コードよりも右にカーソルがいかないようになったのかな。
716 ：
デフォルトの名無しさん ：03/03/19 01:10
717 ：
デフォルトの名無しさん ：03/03/19 01:10
フリーキャレットは使いにくいね。なんか違和感あるよ。
719 ：
デフォルトの名無しさん ：03/03/19 01:17
>>718 Turbo Pascal の頃からそうやったからなあ。全然気にならへんな。
単なる慣れだよ、慣れ
721 ：
デフォルトの名無しさん ：03/03/19 01:24
アメリカ人や香港人、インド人などと比べると、日本人は
「Emacsでなきゃヤダ」って人もいれば
END押せよ
>>723 そんなこと知ってるよ。
他のエディタがみんな改行より右にいかないようにできるのに、BCBだけ設定できない。
某のサポートに問い合わせると、「そのほうが使いやすいから」という回答。
そのくせ、その後出たJBuilderは改行より右にいかなかった。
フリーカーソルとかいうやつだっけ。
726 ：
デフォルトの名無しさん ：03/03/19 01:46
>>724 > そのくせ、その後出たJBuilderは改行より右にいかなかった。
それについて、ボーランドのサポートに問い合わせしてなんて答えたか
やってみて宜保ーん。
C++Builder6はviをメニュー登録するといい感じ。
>>720 そだね。まだ使い始めて間が無いから違和感あるんだけど、でもできれば設定できるともっといいのになあと。
もう二三日もすれば違和感も無くなるだろうけど。
>>728 しばらくBCBから離れて戻るとまた違和感感じる罠
MicrosoftとBorlandが共同でDelphi.NET開発中だと。
731 ：
デフォルトの名無しさん ：03/03/19 10:48
732 ：
デフォルトの名無しさん ：03/03/19 11:01
おれはそのエディタのフリーカーソルが駄目でBCB捨てたんだが。
733 ：
デフォルトの名無しさん ：03/03/19 11:05
つーかね、上下移動はどうでもいいとして、
＞行末でカーソルの→押したら、
>735
フリーカーソルはいいのだけどオートインデントが嫌なんだよね。
738 ：
デフォルトの名無しさん ：03/03/19 13:59
直前の行のインデントに合わせる機能で、あれを自動化しないときには
'------------------------------------------------------------------------------
Sub UnloadAgent()
742 ：
Javaええよー ：03/03/19 17:01
Java＞C++>C>
743 ：
デフォルトの名無しさん ：03/03/19 17:04
>>739 「バックスペースアンインデント」のチェックをはずすだけのことじゃないの？
>>743 本当だこんなチェック項目あったんだね、見逃していた。さんくすです。
でもやはり直前行のインデントに揃えるのは手動化したい(w
自動インデントも(・Ａ・)ｶｼｺｸﾅｲ
もう少しカスタマイズに融通が利けば文句ないんだけどなあ。
標準のｴﾁﾞﾀに使いやすくなって欲しいのでつ。
∧,,∧ ／ それなら
ミ,,ﾟДﾟ彡 ＜ 同意です。
ﾐつ旦(ﾐ~~ ＼
>>748 さん
確かにコダワリはあると思うな。
まだね、X68K -> Winみたいに環境が変わるのなら、仕方ないと割り切れるんだよね。
うーん。
脳みそが固まってる恐れがある。
754 ：
デフォルトの名無しさん ：03/03/19 21:51
VC++netにはいろいろなエディションがあるのですが
VC++.NETはStandardだけだが。
756 ：
デフォルトの名無しさん ：03/03/20 01:33
和声とインベンションがあるのは「四季」。
757 ：
デフォルトの名無しさん ：03/03/20 17:14
デバッグというものは
便利な事って・・・デバッカの事？
デバッグは間違えた場所を教えることだけしかないの？
>>760 それじゃなんのためのデバッグかと小一時間問いつめたい。
つーか誰に教えるんだよ。後輩か？
762 ：
デフォルトの名無しさん ：03/03/20 18:33
>>760 とりあえず間違えた場所はコンパイラに教えてもらえ。
763 ：
デフォルトの名無しさん ：03/03/20 18:38
>>762 そんなの文法ミスしかわからないじゃん。
ちゃんと BCBUnit 使わないとだめだよ。
>>763 うむ。
と言われもインテリセンスに憧れて既にVCへ亡命してしまった俺。
ついでにVCに付いていたWordPadのソースにﾊｧﾊｧした俺。
デバッグとデバッガの区別がつかない人がいるし。
767 ：
デフォルトの名無しさん ：03/03/20 18:50
>>759 そんなことを言っているプログラマはペテン師だ。
優れたプログラマは、プログラムを書く前にテストを書く。
バグの場所が見つけやすいようにプログラムを書く。
768 ：
デフォルトの名無しさん ：03/03/20 18:51
デヴァッグよりはいい。Vじゃないって言ってるのに。
ふぅ…正直、VC++を使うかBCB使うか本気で迷ってる。
簡単に言ったらデバッグって何？
>>773 むかしデヴィルズバッグっていう競走馬がいてな、
そいつの
質問した俺が馬鹿だった・・・
>>773 よく知らないけどガンダムに出てくるやつ
よくしらないので敵か見方のろぼっとかもわからない
それはズゴック
778 ：
デフォルトの名無しさん ：03/03/20 21:45
>>773 同盟軍の宇宙艦隊司令長官だよ
よく知らないけどヤン提督の上司だと思う
もう飽きた。
781 ：
デフォルトの名無しさん ：03/03/20 21:54
時代はIntelC/C++コンパイラとVTuneの組み合わせだよ。
>>770 悩むって事はまだ何もソフト作った事ないんでしょ？
なら HSP とか Delphi とか無料のツールで何か作ってみたら？
783 ：
デフォルトの名無しさん ：03/03/20 22:04
>>770 無料なら.NET Frameworkも無料だから、これで試してみるのも一興。
密かにBCの無料版もお勧め。
>>770 DirectXならBCBを選ぶ意味があまり無いと思うんだが
デバッグとは、バグを取り除くことだ、ってマジレスしちゃだめでつか？
コンパイラの内部エラーはバグだと思うが｡
コンパイラのね
>>786 それは仕様です。
本当のﾊﾞｸﾞならエラーメッセージなんて出ません。
「仕様想定外」を無くすのがデバッグだと思ふ。
789 ：
デフォルトの名無しさん ：03/03/21 02:43
あーもー、なんだっていいじゃん。
>>789 気持ちはわかるけど
戦時中でも結構日常生活してるんだよね
明日死ぬかもしれないのに1ヶ月後の納品を心配したりして
おいおい、あんまり某を虐めるなよ～ただでさえ氏にそうなのに
意図しない動作をすることがバグですな。
793 ：
デフォルトの名無しさん ：03/03/21 04:29
VCLを一度使うと、MFCのクソさ加減がイヤになる。
>>794 VC++にもpropertyあるぞ。宣言はめんどくさいけど。
797 ：
デフォルトの名無しさん ：03/03/21 10:39
>>794 BCBユーザはやたらとANSI対応度を重視しながら、言語拡張にも頼っているんだね。
>794
799 ：
デフォルトの名無しさん ：03/03/21 13:27
>>797 問題領域とコンピュータ領域とをきちんと分けながらね。
800 ：
デフォルトの名無しさん ：03/03/21 13:28
ウソ 800 ゲット！
Uppercamelな変数名もふざけてるとしか想えん奈
802 ：
デフォルトの名無しさん ：03/03/21 13:31
803 ：
デフォルトの名無しさん ：03/03/21 13:35
俺様専門用語
805 ：
デフォルトの名無しさん ：03/03/21 13:38
>>804 「コンピュータ領域」、「問題領域」が？
OO やったことないとか？
806 ：
デフォルトの名無しさん ：03/03/21 13:43
807 ：
デフォルトの名無しさん ：03/03/21 13:50
ANSI C++ がサポートしているコンピュータ領域は、ファイル I/O とメモリ・アロケーション
わかりやすく言えばインタフェースと実装という事か。
809 ：
デフォルトの名無しさん ：03/03/21 13:52
>>807 BCB や G++ 遣いは、そーゆーのをきちんと気にしているから、ANSI 準拠度を
大切にするのです。
VC++ 遣いはどーでもいいのでしょうけど。
810 ：
デフォルトの名無しさん ：03/03/21 13:53
>>808 インターフェースとロジックといった方が正しいのでは？
811 ：
デフォルトの名無しさん ：03/03/21 13:54
「コンピュータ領域」は初めて聞いた
813 ：
デフォルトの名無しさん ：03/03/21 14:02
>>812 知らないことを聞いたときに
>>804 みたいに、自分の狭い枠で反応する癖を
付けていると、技術者としての成長は、きついものがありますね。
814 ：
Alexandrescu ：03/03/21 14:03
>>809 ANSI/ISO準拠ﾏﾝｾｰ派はBCBなんか使いません。Comeau C++を使うのです。
Comeau C++こそが究極のC++コンパイラなのです。
そして私の作ったライブラリを使うことによりC++の力を最大限に発揮できるのです。
>>813 どうでもいいけど804ではないよ
「computer-area object-oriented」で検索したがいまいちだった
817 ：
デフォルトの名無しさん ：03/03/21 14:14
とりあえずケン・トンプソンたちが見捨てたC++でVCもBCBもないかと。
818 ：
デフォルトの名無しさん ：03/03/21 14:19
おまいら、そんなことよりBoost 1.3が出ましたよ。
>>817 Alefって日本じゃ受け入れられない名前のような・・・
820 ：
Javaええよー ：03/03/21 16:00
どいつもこいつもC++かよ！！！
これからはJAVAの時代・・・
NEOGEO の CM を思い出した。何メガショックだっけか。
824 ：
デフォルトの名無しさん ：03/03/21 16:53
VC++よりBCBの方が機能が上なんですか？
>>824 機能って何の機能？ 指標が無いと評価は出来ないよ
機能数や一つの機能の完成度。
高機能だが性能は低い。
Ruby以外どれも糞。C++なんて・・・ねえ？（苦笑
>>827 機能数？
コンパイラの最適化オプションの事なら VCが上
拡張構文の数なら どっちもどっちかな GCCの方が余程楽しいかもね
ライブラリの豊富さなら VCLの分 BCBが上だろうな
機能の完成度？
デバッグ類はVCが上という意見もあるけど、これは使い慣れた人が多いせいだろ
ただ、使うかどうか判らないようなデバッグ用のツール類はVCが豊富かな・・まあ初心者には便利かも
あと VCだとMSDNが付いてくる。 API日本語訳はMSDNの方が少し・・いや大分豊富
といっても結局は英文に突き当たるんだけどね
いろいろと有名なオブジェクト指向言語であるC++とRubyを比較すると:
>>824 おい、VC++買うんだったらもう2～3ヶ月待った方が良いぞ。
>>832 6.0を買います。Windows98SEなんで。
>>833 おいおいおい、今更クソい6.0買っても何にも良いことないぞ。
ついでに98も窓から投げ捨てろ。
6.0いいよ。軽いもん。
軽いのが好きなら BCB でもいいんじゃないの？
Version 2003が出るからさ。
そろそろ2スレ目だな。
824 そんな質問するレベルなら Delphi やっとけ
Delphiなめんなよ！！
846 ：
デフォルトの名無しさん ：03/03/21 18:35
Boost 1.3.0 出たね。
ちょっとしたテストコードを書く程度だと、BCB1.0が軽くて便利
なんて親切なんだ。
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/
（＿フ彡 / ←
>>844 850 ：
デフォルトの名無しさん ：03/03/21 18:58
>>847 > いちいちプロジェクトを作らなくてもいいしね。
そうだったっけ。
BCBのメリットが、VCLだけなら結局、「Delphi使っとけば？」
C++ってDelphiが想定しているアプリを開発するには若干水準が低いからね｡
要するにいつもの結論だな
>>853 惜しい！
IntelVTuneのJavaネイティブコンパイラ最強
>>853 (ﾟДﾟ)ﾊｧ????
Delphi：C++がわからなかった落ちこぼれ用だろ。
誰がどう見たってC++の方がDelphiよりも遙かに複雑で難解だと
思うが？
まぁ時代はMSX-BASICな訳だよ
>>856 おまえはアセンブラが使えない落ちこぼれですね。
えむまがのテクニカルノートでも読んで帰れ。
858 ：
デフォルトの名無しさん ：03/03/22 02:24
MSX-C ってさ、<stdio.h> もなかったような気がするけど。
某から抜けた連中が今M$で.NETをやってるというが、
>>855 BCB以上のことがシンプルに実現できるDelphiのほうがいいに決まってるだろ
C++資産の活用以外にBCBの価値はない
現にBorlandのホームページの扱いはJBuilder,Delphi>>>超えられない壁>>>BCB
ユーザー数でもDelphiはおろかBCC以下じゃん
842書いた者だけど、
JavaやってからVC++やるのって
>>863 悪くはないけど、JAVAに慣れすぎると弊害もある。 学習を阻害するかもね。
>>863 VC++に慣れすぎると弊害がある。 学習を阻害するかもね。
866 ：
デフォルトの名無しさん ：03/03/22 19:52
867 ：
デフォルトの名無しさん ：03/03/22 19:56
Javaに慣れすぎた場合はもっとひどいけどね
それはよかったね
やっぱDelphiだね
最近この板、お子様しかいなくなった
はるなのに
876 ：
デフォルトの名無しさん ：03/03/23 15:15
あんたならVC++とBCBどっちが好き？
877 ：
Javaええよー ：03/03/23 16:19
そろそろJavaも人気が出てきたな。
Pascalって結局メジャーになりきれなかった言語だよな。
未だに 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 なんだな（ｗ
884 ：
Javaええよー ：03/03/23 21:11
だからJavaの時代だって、もうC++の時代は終ったの、分かる？
うるせーよガキ
886 ：
Javaええよー ：03/03/23 21:36
>>885 あら、嫉妬ですか？
血圧上がりますよ？
>>878 pascal好きは英語圏の人。
英語圏では{}がキモくて、begin/endがなじむ。
日本では逆。
>>887 ほー、そうなんだ。
{・・・}のほうが、エディタで編集しているときにカッコの対応が分かりやすいけどなぁ。
ところで、マックＯＳはPascalで記述されていたんだっけ？
（もちろんアセンブラの部分はあるだろうけど）
ちなみにマイクロソフトの製品はVC++で作っているのだろうか・・・
Pascalで書かれた技術書もけっこうあるわけで
一貫性を書いてたニャ（恥ず・・・逝ってくるニャ
言語の話題で字句しかあがらないところが厨房っぽくて良いな。
892 ：
Javaええよー ：03/03/24 16:10
C++の勢力も弱まってきたな。
893 ：
デフォルトの名無しさん ：03/03/24 19:17
VC++でUNICODE/SJIS変換はどうやりますか。
CStringT
895 ：
デフォルトの名無しさん ：03/03/24 19:31
>>894 有難う。
BSTRってのは、UNICODE側でしたっけ？ASCIIでしたっけ？
>>896 >マックＯＳはPascalで記述
ってのも一応ありだと思うが。昔の話だけど。
Windows も昔は Pascal だったとかなんとか。
Mac は char255 型(だっけ？)とかあるし、Windows3.1の関数
呼び出しは Pascal 方式。
>>896 ネタだと思うが一応突っ込んどく。
マックＯＳは、Pascal とアセンブラで書かれたんだにゃ。
で、マクＯＳのグラフィック描画ルーチンは最初 Pascal で書いて
逆汗して天才ビル・アトキンソンが神業的なハンドオプチマイズを
施し 64Kbyte のROMにぶちこんだ。
ビルはプログラマから足を洗って今は写真家だーよ。
あ、今のマクＯＳ Ｘは Objective-C かもね？
今でもそしてこれからもCが主流だね！！！！！
Delでお気楽プログラムをした後にC/C++を使うと
903 ：
デフォルトの名無しさん ：03/03/24 22:36
>>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作った、なんて絶対にない話。
910 ：
デフォルトの名無しさん ：03/03/25 05:35
>>909 MS は、昔どこかから Pascal のコンパイラを買ったんだよ。
MS-Pascal ってあったよ。
だけど、バージョン・アップできなかったんだな。
買収は得意だけど、技術力がなかった。
そうこうしているうちに Borland に負けて、MS-Pascal はもうないんじゃないの。
911 ：
デフォルトの名無しさん ：03/03/25 05:37
1986 年
あ、それで、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は衝撃的だった。
コンパイルスピードが爆速だし、統合環境だったしね。
915 ：
デフォルトの名無しさん ：03/03/25 10:06
>>913 1986 年っていうと、Lattice C の OEM を MS-C で出していたかいないかの
ぐらいじゃないかな。
916 ：
デフォルトの名無しさん ：03/03/25 10:07
まだ、cl.exe じゃなくて msc.exe だった。
MS-C ver.4はDOS用だったと思うが。
918 ：
デフォルトの名無しさん ：03/03/25 15:43
VC++のデバッグ最強。
VC++はデバッグの前にコンパイルが通らない。
http://program.station.ez-net.jp/special/vc/general/conpatible.asp □ Visual C++ の互換性…
それまでに静的ライブラリを Visual C++ 7.0 にてサクッとコンパイルすることができていたので、COM コンポーネントも何気なくコンパイルできて当然のものと思っていました。
が、なにやらいっぱいエラーが…。
□ COM 動かず…
さて、エラーも取り除けたということで動作させてみたのですけど、CreateObject をして、そのあとでメソッドを呼び出してみると…、DLL の読み込みでエラーが発生してしまいました。
どうやらうまく移行できなかったようです。
920 ：
Javaええよー ：03/03/25 16:09
VC++?・・・・・ちがう！
ﾌﾟﾌﾟﾌﾟ
BCB使えればVC++も使える？
使える度合いによる。
>>923 Javaのよさは良くわかった。
ついでだから、Javaでかちゅの後継アプリとMIDIシーケンサ作ってくれるか。
ほんじゃ、俺もJava信者になる。
それまでは「時代が来る」とかいうな。
すまん、
>>923 は
>>920 の間違い。
とりあえず、かちゅ後継とMIDIシーケンサ、頼んだぞ。
口先だけはもういいから。
できないんなら黙っててね。
Javaじゃなくてあんたがうざいんで。
>>925 > かちゅ後継
monalipseどう？
927 ：
デフォルトの名無しさん ：03/03/26 15:54
BCB6pro買おうと思ってるんだけど・・・
928 ：
Javaええよー ：03/03/26 16:52
では黙っています。
>>925 javax.sound.midi.Sequencer
これでJava信者がひとり増えたな。
930 ：
デフォルトの名無しさん ：03/03/26 17:21
VC++?・・・・・ちがう！
>>931 半角「?」って文字化けに見える漏れはJava厨ですか？
>>927 >>862 が書いてるように、BCB6買おうと思ってるなら、
年内にBCB7が出るみたいだからそれを買えば？
BCB.NETについては知らない。いつ出るかも分からない。
>>927 >ずっとﾚｽ読んでると、BCB.NETなる物が出るの？
そんなもん出る予定ないよ。
どっからきた話か知らないけど。
935 ：
デフォルトの名無しさん ：03/03/26 19:52
>>933 なるほど。BCB7が出るんだ・・・
年内っていつだろう・・・冬とかだったら待ちきれないよ。
ボーランドのHPにソースある？
>>934 >>386
936 ：
デフォルトの名無しさん ：03/03/26 21:33
Delphi.NETはMSとBorlandで共同開発中らしいが、BCB.METは聞いたことがないぞ。
またボーランドは出遅れるわけか。
939 ：
デフォルトの名無しさん ：03/03/26 23:22
( ﾟ∀ﾟ)ﾉ Java信者の924がいるスレはここですか？
>>937 これ読んでると、BCBが.NETサポートするって書いてあるね。
941 ：
デフォルトの名無しさん ：03/03/27 08:21
RAD環境がVS.NETでコンパイラがBCBなら密かに最強っぽい。
>>937 おぉ、サンクス。
.NET開発陣が元ボーランド社員達なのでVC++のマネージッド版より相性良さそうだね
とりあえず次BCBは買い、というわけだな。
早く出してくれBCB7
945 ：
デフォルトの名無しさん ：03/03/27 16:07
VC++?・・・・・ちがう！
ああ確かに C# はその中で一番に消滅しそうだな
VC++?・・・・・ちがう！
「目の付け所がC#でしょ」という某CMの反転ギャグが成立するまで
949 ：
デフォルトの名無しさん ：03/03/27 16:31
VC++?・・・・・ちがう！
VC++?・・・・・ちがう！
BCB6のインスコサイズって幾らくらい？
953 ：
デフォルトの名無しさん ：03/03/27 21:47
VC++?・・・・・ちがう！
雑魚言語どもが・・・
ま、結局行き着く先は皆HSPなんだよな。
実は最強の言語は 「はだしのゲン語」 ギギギ…
>>953 それでｳｲｿのアプリを作れるんかいな？
>>957 MacのアプリもGameboyAdvanceのアプリも作れる
Lispが最強かと思ってたら、BrainFuckというさらに上逝く言語が…
・ﾟ・(つД｀)・ﾟ・ ｳﾜｧｧｧﾝ
>>952 がスレ違いに見える。。。
>>959 わけがわからんといえば、Intercalでしょ。
962 ：
デフォルトの名無しさん ：03/03/28 02:34
VC++とBCBを併合すると最強の開発環境になると思われ
>>962 でも、二つで一つを開発するのは大変っぽ。
VCでするならVCで。
BCBでするならBCBでするのがよろしかと。
俺はBCB以外使うつもりないが。
DelphiとBCBを併合すると最強の開発環境になると思われ。
966 ：
デフォルトの名無しさん ：03/03/28 10:24
>>962 BCB は MFC を内包しているから、VC++6.0 までだったら BCB5 で OK。
968 ：
デフォルトの名無しさん ：03/03/28 10:32
>>967 VC のデバッガって、BCB のブレーク・ポイントみたいに、何回目に止まるとか、
何回通過したみたいなプロファイラみたいに使えたりとかしますか？
>>965 Delphiは溶けてバターになってしまいますた。
>>965 コンパイルできるだけでIDEがサポートしてないやん
971 ：
デフォルトの名無しさん ：03/03/28 20:14
>>968 VC++ のデバッガはそういうインテリジェンスな機能はついていない。
せいぜい、ある条件のときに止まる、です。
972 ：
デフォルトの名無しさん ：03/03/29 02:14
973 ：
デフォルトの名無しさん ：03/03/29 17:00
bcc32最強。
なにげに
>>971 が恥ずかしいことを書いてるな。
VC6には何回目に止まるはあるけど何回通過したは無いな
ヒットカウントの事？
977 ：
デフォルトの名無しさん ：03/03/30 08:46
あるじゃん。
>>977 VCってブレークポイントで停まってるときにコード書き直せなかったっけ？
あれがやりたい。
980 ：
デフォルトの名無しさん ：03/03/30 11:51
>>980 そうなの？
AnsiString a;
●a = "aaa";
label1->Caption=a;
でとまってるときにa="bbb"って書き換えたらlabel1にbbbって表示される？
BCB5までしかもってないけど、6からできるようになった？
>>979 あれって便利だけど本来動かない（動いちゃいけない）プログラムが
高機能なデバッガのおかげで動いてしまうんだよな。
デバッガ使う前にコード読み直せって。
>>982 漏れはやってみたいだけ。
最近デバッガ使う機会がないのは気のせいか。
984 ：
デフォルトの名無しさん ：03/03/30 18:51
あげとこう
>>980 でも書き直すとまた再構築させられるし。
…って、書き直した分をバイナリに適用させる場合の話だけど。
漏れもBCBのデバッガ機能は好きだな。
ということは漏れはとなりの芝が青くみえてるBCB厨ということでつね？
ビルダーの方がGUIアプリ作りやすい。
『BCBとVC++』version2
BCB vs VC++ 2 MILLIONAIRE FIGHTING 2003
Delphiの方がGUIアプリ”も”作りやすい。
>タブが勝手にスペースに置き換わったり
992 ：
デフォルトの名無しさん ：03/03/31 11:10
>>987 TAB 文字の使用にチェックを入れれば OK。
てか、おれ的には TAB 文字の表示幅は環境依存なので、全部スペースの方が好き。
993 ：
デフォルトの名無しさん ：03/03/31 11:25
次スレは？
994 ：
デフォルトの名無しさん ：03/03/31 11:28
>>993 ありません。BCBの圧勝という結論が出ましたので。
995 ：
デフォルトの名無しさん ：03/03/31 11:30
俺的には、GUIはVBでその他はVC++。これをCOMで融合。
996 ：
デフォルトの名無しさん ：03/03/31 11:36
＿＿＿＿＿＿
＿＿＿＿＿＿
＿＿＿
♪こわれてきえた～ 从"､;从
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。