VC++とC++Builderではどっちがいいですか？

すみません。VC++歴約１年程度の厨房です。
VC++って学習すんのに疲れます。
で、C++Builderのインターフェースを見ると、ぱっと見
VBライクでひょっとしてこっちのほうが勉強するのが楽なんじゃ
ないかと思い始め、乗り換えを検討してます。
ただ参考書が少なくて困ってます。
そこで両者の長所と短所を教えていただけませんか？
既出かもしれませんがよろしくお願いします。

二兎を追うもの一兎をも得ず

VC++ を１年もやってモノになってないのなら、C++Builder をやっても無駄！

VC++ のどの辺が疲れるんだ？

>>1
>VBライクでひょっとしてこっちのほうが勉強するのが楽なんじゃ
　インターフェースの設計が楽なだけ。C++の基礎ができてないのなら
必ず挫折します。キミにはHSPを推薦する。

ＨＳＰって、コレのこと？
http://hspcenter.com/

でも、>>1 には HSP でも無理と思われ。

　いったい１年も何してたんだろ？

C++で何開発する気なんだ？
ま、どうせネタだろうけど

ネタなのは>>2-7全員だろ。

BCB使った事もなさそうやヤツばっか。

>>8
BCG なら知っておるが、、BCB はマイナーだろ？

予防注射？

会社でVC++、自宅でC++Builderを使っていたが、
MFCが使えない事がかなりイタイ。
C++Builderを使い続ける方がよっぽど根性がいる。
よって自宅もVC++に変えた。何の未練もない。

>>1
疲れるかもしれんが、
付録で付いているはずのMSDNをしっかり読むことを勧める。

>>11
>>8 は、そのＭＦＣがイタイのだと言いたいと思われ。

>>1
ダイアログベースでやれ。
ドキュメント・ビューは逝ってよし。

>>1
ちゅーかこの手のスレはプログラム板あたりで既に幾つもあったと思われ。
先にそっち読んだらどうかな？

>>13
世のWindowsプログラミングのサンプルは、MFC使用のものばかりだ。
使いやすいと思ったことはないが、3.1時代に比べたらマシなので
ヨシとした。

ちなみにC++Builderを使ってたら、あんなVBライクなインタフェース
よりもコード書いたほうが楽だと思った春の日。

>>11
MFCの方がVCLよりも優れているといった感じの発言は
あまり聞いたことがないのだけど。

やっぱり使い慣れた道具がその人にとっては一番なんだね。

自分は C++Builder 使いだけど本格的な開発するなら
先に API ベースで修行積むことを薦める。
VCL は内部で色々とトリッキーなことをやってるので
MFC と違って不足部分を API で補おうとするかなり苦労する。
開発効率は明らかに高いと思うけど
デバッガやドキュメントなどの質は VC 環境の方が上だね。
丸々一本単位でソフトを作るのでなければあまりお勧めできない。
逆に、そういう使い方をするなら VC よりも圧倒的に楽。

18 だけどちと訂正。
API で補おうとすると、ってのは、安易に API で補おうとすると、の意。
VCL の内部をきちんと自分で追っかけられないと結構ハマる。
なお、VCL は C++ じゃなくて ObjectPascal で書かれてる。
あと、C++Builder のは独自拡張構文のある非標準の C++。
したがって C++Builder 用のソースは他の環境では使えない。
最後まで自分で責任とれる場合以外はなかなか使いづらい。

>>18
つまり、VCL はブラックボックスとしては扱いにくいわけか。

>>18
>MFC と違って不足部分を API で補おうとするかなり苦労する。
同意。

自分は主にDelだけど
派生でなんとかしようとしても肝腎のメンバがPrivateだったり
Interfaceにない関数を使ってたりで思うようにいかないことが
良くある。

>>20
いや、ブラックボックスとして扱う分には非常に優秀。
ライブラリのデフォのクラスを駆使するだけで実用上は問題ない。

ただ、その範囲をちょっとでも踏み越えたときに苦労する。
例えば VCL だとウィンドウをアイコン化する時に
縮小していくアニメーションが表示されない。
これを表示しようとすると VCL 内部を割と真面目に調べる必要がある。
ところが内部で独自のフレームワークを持っているので
API 使う場合の標準的な感覚で山を張ると迷うことになる。
仕事だとライブラリの能力不足で困るということはまずない。
自分は趣味でシェアウェア作ってるんで凝ったことをしだすと苦労する(笑)
なんにしても、VCL だけでできることから踏み出すとかなり厄介。
内側だけでやるなら文句なしなんだけどね。

>>21
>派生でなんとかしようとしても肝腎のメンバがPrivateだったり

あるある(笑)全体的にはとてもよくできたデザインだと思うけどね。
ところどころが間抜け。あと、ネット関係のコンポーネントは
いまいち使えない。おまけ程度だね。

>>21-23 は、>>1 の理解の範囲を越えていると思われ(w

DelphiとBCBは同じクラスライブラリなのですか?

>>25
肺

１じゃないけど
APIに強くなるにはどういう本がありますか？VC++の本はたくさんあるのに
ウィンドウズの仕組みまできちんと書かれた参考書がほとんどないように
感じるのですが

Programming Windows というのがベスト。
Windows プログラマの標準教科書。
今は上下巻セットの最新版がある。

http://www.ascii.co.jp/books/detail/4-7561/4-7561-3600-1.html

ただし、これはあくまでもスタート地点。

そんなあなたはＭＡＳＭからやり直しなさい。

入門用ならハーバート・シルトの本がお勧めだよ。

C++に精通してるんじゃないんなら、素直にDelphi選んどき。
VCLの本質はObject Pascalで、C++Builderってのは、
VCLをC++で使えるようにしただけのものだから。

BCBは、いいよ。
MFC移植とかパスカルとか、どんな環境にも順応できるし、
VCみたいに「使いにくく」ないし。

>>31
>VCLをC++で使えるようにしただけのものだから
それは、はっきり言って、間違ってるよ。
C++Builderの機能は、もっと幅が広い。
推測でものを言うのは、お願いだからやめてくれ。

>派生でなんとかしようとしても肝腎のメンバがPrivateだったり
ソースコピペでGoね。

せっかくVCLソースついてんだしー。


ここの人らの意見はピッタリ当てはまるのだが
1の役にはあまりたたないな。

1はさっさとBuilder使った方が幸せになれる。
VC++で挫折してプログラム辞めるよりマシ

>>33
ある視点から見ると>>31の言うとおりだよ

純粋にVCLだけを使うならDelの方がいい。

ただ、BCBはそれだけに終わらないというのは
同意。

>>33 推測じゃねー、VCLのソース眺めながら
アプリ組んでると、どうしてもそうとしか
思えてこないのだ。
ただ、偏った視点でモノ言ってたことは認める。
さんくす>>35
逝くよ…鬱だ刺のう

BCBはメモリ食い過ぎ・・・
それさえ無ければ・・・

>>34
>ソースコピペでGoね。
みんなそうなんだね、やっぱり(w

>1
ただ漠然と学習しようとするから疲れるのだと思う。

「自分はこんなアプリを作りたい」という目標を見つけましょう。

そうすれば、VC++でもC++BでもDelでも
楽しく学習できると思うよ。

>>38
21の間違いでした。23さんごめんなさい。

VCL抜きでもDelは好きだけどなー。
実際なしで組んでるし。

>>40
やや病気

現在は営業SEしてますが、
１０年近くCや86系アセンブラで制御系（組み込み）
のソフト作ってました。
MSDOSの頃はTSRなんぞ朝飯前だったのに・・・
VC++;がまるで理解できません。
どなたかコツを教えてください。

>>42
VC++の何が分からないのかを言っていただきたく。
IDE(＝開発環境)の使い方？APIでのソフト開発の仕方？MFCの使い方？
VC++ってだけでは誰にも答えてもらえないと思われ。

・・・っつかネタか？
VC++; のセミコロンって何よ(藁

>>43
あのIDEで挫折した。
おかげでBCBバリバリ(のつもり

>>45
VCのIDEってそんなに難しい？
ウィザード関係無視すりゃBCBもVCも大して変わらんと思うけど。

>>46
オレも変わらないに一票

今はなき SymantecC++ は IDDE(Integrated Development & Debugging Environment)と言っていたなぁ・・・。

>>46
フォームにボタンを貼り付けて、ボタンクリックした時の挙動を
記述しようと思ったが、まず、フォームを表示するのに手間取り、
ボタンを貼り付けるのに手間取り、クリックした時の挙動を書こう
と思った段階で、「はて、どうやったら書き込めるんじゃ？
そもそもクリックのメソッドはどうやって作るんじゃ？」となった。
ＧＵＩはＶＢから入ったクチなのだった。
今でもVC++はよく分からん。

>>49
そりゃVCが分かってないんじゃなくて
非RAD環境でのWinアプリ製作が分かってないよ。
ガイシュツだけどプログラミングWindowsあたりで勉強するべし。

>>50
プログラミングWindowsの次はどんな本がいいですか？
本屋行ってもたくさんありすぎてどれが最良なのかが
わかりません。
僕が思うにVC++が難しいというより、学ぶべき順番が分からないから
難しく感じるというのが実情だと思うんですけど。

>>51
俺あんまりWin関係の本って読んでないからなぁ(藁)
俺の場合で言えば、プログラミングWindowsを精読して
あとはずっとWinAPIのヘルプだけでやってきてる。
補助的に１、２冊ほど購入はしたけれど
基本的にはプログラミングWindowsを押さえられれば
あとは一次資料やヘッダを漁るだけで大丈夫でないかと。

>>50
勉強します。
よし、これで俺もVC++バリバリになるのだ！
仕事じゃ全く使わないから自己満足で終わっちゃうけど。

>>52
あんまり読んでなかったのか Σ(´Д｀;)

>>54
いや、本屋で目を通すぐらいはするけどさ(藁)
結局「APIヘルプでいいじゃん・・・」って思って買わないわけよ(藁)
実際のところAPIヘルプには嘘書いてあったりするから
頭から信用しちゃいけないんだけどさ(藁)
その嘘を自分でチェックするか本で情報仕入れるかの違いだと思ってる。

>>54
一個追加。
OLE関係は真面目にやるんだったら本があった方がいいと思う。
あれはヘルプから全体像把握するの大変だわ。
俺はあんまりOLE絡みの仕事は回ってこないんで調べてない。
ゆえにどんな本がお勧めかもあまり知らない(藁)
ただ、.NETが普及したらその辺は簡単になるみたいなので
今から本腰入れて勉強するべきかどうかは不明。

>>49
そこまでしてVC++覚えて何の得になるんだ？

BCB使えよ。

で、そのうちC#したらいいさ。

そういやBCBって参考書すくねーな

プログラミングWindowやったらもう普通の本は必要ないと思うけど。

MFC使えよ。めちゃくちゃ楽になるぞ。

>>60
あのクラスウィザードが楽か？

でもWIN３２知らずにいきなりMFCやると分からんとこ
たくさん出るよね。

世界標準開発環境
Visual Studio.NET (VC++7.0含む)
この使い方をマスターする、しないは
今や、死活問題。

>>56
OLEの仕組はVBの仕事の時に、VB付属のぶっとい本で必死に勉強した。
おかげでBCBでCOMをやる時には楽だった。
でも、.NETにはあんまり興味ないからどういう概念なのかさえ分かってないしなぁ。
これも勉強しといた方がいいのかなぁ。

>>57
いやぁ、Visual Studio proを個人で購入しちゃったから使わないと勿体無いし。
DirectX8.0はVCでないと使いこなせないとかって話もどっかで見たし(ガセかなぁ
ところでC#って、この先C++と置き換わると思います？

>>58
確かに滅茶苦茶少ない。
技術的な事ならDelphi-MLとBCB-MLで大体は事足りるんだけど。

>>64
.NETのコアはMSIL+CLRによるWebServiceなんだろうけど
色々とおまけがついてて何が言いたいのか
よく分からないところはあるね。
昔ActiveXが出てきたときの宣伝の仕方とよく似てる。
WebServiceによる分散OOは間違いなく次のトレンドだと思う。

OLEはCOMの概念じゃなくてフレームワークがややこしい。
というか、ややこしいというよりは、量が多い(藁)
インプレイスアクティベーションやらカスタムマーシャリングやら
構造化記憶システムやら複合ファイルやら、構想がでかかった。
その上面倒すぎてVB以外に絡みようがなかったような気がする。
一度VB用にデュアルインターフェースのOCX書いたことがあるけど
「めんどくせぇぇ！！！」の一言に尽きたね(藁)

>>65
VC++6.0におけるCOM開発では*_i.C,*.IDL,*.H,*.CPPの4個所
いじらんといかんからな。あのATLウイザードは新規作成には
入力項目がやたら冗長で、一方編集機能はほとんどないという
素敵な仕様なため、時折戦隊ヒーローの変身シーケンスの長さを
彷彿とさせることがある。スマートポインタもせめて標準的に
作成してほしい。VC6のリリースが3年前だから仕方ないって
いわれれば仕方ないか。なんだかんだで手になじんじゃってるから、
.NETでても会社ですぐに乗り換え〜なんてことにはならないのが
つらい側面でもある。

>>61
あのクラスウィザード普通だと思うけど。
きちんと理解すればＭＦＣは楽できる道具になると思う。

俺はUnixでC。
VC++やVBがActiveXコンポーネントを
量産するもんだからくだらん厨房が
ウイルスやらワームやら電話番号自動切換やら
やりやがる。どうにかならんのか？

>>68
間口の広いWinだから仕方ないんじゃない？
UnixだってGUIがWin並になれば同じ事が起きるよ多分。

つーかウイルスもワームも始祖はUNIX屋の仕業なんだが。
志の低さを責任転嫁しないように。

ＢＣＢてライブラリもＣ＋＋だったら良かったのに・・・
ソース追っててＣ++からパスカルに飛んだりするの見てると
素直にデル買ったほうがよさげ

電話番号切り替えはモラルの問題だろ。

>>71
そんなの、触ってりゃそのうち慣れるってもんだよ。

Borlandもいいもの持ってるんだから、いいかげんPascalに
しつこくこだわるのは止めて欲しいな。

なんでPascalとC++をシームレスに読むこともできない無能者の
意見を聞いて生産性の低いC++で統一しなきゃいけないの？

なんでC++にするだけで生産性が落ちるような無能者の
意見を聞いていつまでもPascal使わなきゃいけないの？

>>75-76
ケンカするなよ、同じ無能者同士なんだから．

>>77
激しく同意。

おれは、パスカルとC++とMFCが混じってて
とても面白い開発ツールだと思う>BCB
こんなもの、他探したって絶対手に入らない。

automated でオートメーションサーバが作れるのが楽でよかった。＜BCB
そのままカスタムインターフェースもサポートしてくれれば嬉しいんだが・・・。
ATLとの組み合わせは面倒くさい。

>>79
色々な言語・開発環境に馴染んでおくと
新しい言語・開発環境にも早く適応できるようになります。

そういう点でBCBは一石三鳥なツールといえそうですね。

>>81
そんなことないと思うけど。パスカルってもう普通の人はしらない
言語なんだからいいかげん捨ててほしい。

>>82
81は言語依存しないセンスを磨く場としての効用もあるという趣旨と思われ。

>>82<<バカ決定?
頼むから勝手に自分の知らない言語＝普通の人が知らない
とかまとめないでくれ。

人数と推移をみてくれな。
http://www.users.gr.jp/ml/mldata.asp
http://www.users.gr.jp/ml/mldata.zip

>>84
　おもしろいね。Delphi-MLに入ってるんだけど平日なんか多いとき５０件以上の
カキコがある。過去ログも含めためになります。

カキコってゆーなー

>>86
じゃあ2chくんな(ﾟДﾟ)ｺﾞﾙｧ

　　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
〜 〜　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎−>┘◎

>>84 でもKylixがOfficeより人数多いってのはなぁ。
だいたい一番多くても５０００人も行って無いじゃん。

>>86-88
藁ﾀ(藁

>>84
普通の人は知らないって。
絶対知らねーって。
絶対ぜったーい知らねーって。

ものすごく厨房っぽい発言だな。夏厨？

一応データを見せておくわ。
http://www.atmarkit.co.jp/fdotnet/questionnaire/2001-04/2001_04.html

普通の人が知らないといえるかもしれないが
知らないとはいえないかもしれない、微妙な数値。

LinuxとGUIクロスプラットホームRADを実現しているのは
今のところDelphi/Kylixだけな。

自分の目に見える範囲だけを世界と思わないように。

おれDelphiプログラマだけど、やっぱり普通の人は知らないと思う。
つか何を持って「普通」かはよくわからんけどなｗ

派遣会社にPG探させてもDelphi使える人ほとんどいないし、
Delphi以外でPascalなんて今時聞かない。昔は教育用言語として
はやってたらしいけど。そういや俺の高校の計算機数学も
Pascalだったな。その時のことは全く覚えてないが。

マイクロソフトはDelphiが欲しくていろいろやってたみたいだけど、
結局あきらめたのかな？

C＃はDelphiの直系だよ。

極端なこと言えばC#もJavaのライブラリ群もVCLの直系だよ

どうりでDelphi使いはＪａｖａにすんなり入れるわけか。

>>93
Pascalっ〜だけで、Delは敬遠されてるよ〜な気がする。
CP/Mの頃はPascalMT+ちゅ〜ので、泣きながら
いろいろと作っていた事はあるが、今Delでって言われると
BCBにしていまう・・・。
逝って来ます・・・・・・・・・・・・・・・・・・・・・・・・・・

>>93
>派遣会社にPG探させても
Delの仕事ってほとんど無いと思っていたのですが
最近はどうなのでしょうか？（ちなみに私はDel使い）

※このスレは下げ進行だけどレスが途切れないですね。

質問したのだから、やっぱageさせてもらいます。

つーか大学でdelphi使ってるとこないんじゃないの？
delphiがだめっていってるわけじゃないけど、世間の認知度は
限りなく低いよ。特に大学生で知ってる人は情報工学科以外では
ほとんどの人がしらなかったよ。

delは楽チンだから初心者にお勧めだねぇ。
VBから入ったら辛いけど、
delから入れば、C++に移行しやすいね。

>delから入れば、C++に移行しやすいね。
それはdelからはいる人が少ないから錯覚してるのでは？
delではじめるとデフォルトの
・はじめからフォームインスタンス化済み
・グローバルな領域のフォーム変数をみんなで使い回し
的な考えが染みついて、VB厨とあまり変わらないのができあがるよ。

もちろん本人の資質が一番重要だけど。いけるやつはVBから入っても
いけるやつになるわけだし。

>>103
ｳｨｻﾞｰﾄﾞが作るﾃﾝﾌﾟﾚなんかの影響力ってそんなにあるか？

>>103
ちゃんとしたオブジェクト指向であるかどうかは大きいと思うが・・・

>>96
C#とDelphiは設計者がおなじだからね。

乱暴な言い方をすれば、
Delphi は、C++ と VB の中間的で、
扱いやすく、処理能力も高いと思いますよ。
ランタイムもいらないし。

Delphi ver 5 は、使ったことないですが、
ver4 と比べてどうですか？
ツール類など。

>>96
そうなんですかぁ。
C#は、まだ全然、知らないなぁ。
要チェックですね。

次期バージョンVBの評判が悪い？かもしれないので、
MS対抗の、Delphi/Kylix がシェアを延ばして欲しいですね。

>>107
>Delphi は、C++ と VB の中間的で、
「Delphi は、C++Builder と VB の中間的で」とかくと全然RanbaughtじゃないYO

本命はC++Builder6/C++Kylixだね。

オレが見たことがある統計だと、BCBって結構処理速度遅いんだよね。
VC、Delが同等で、これらとVBの中間ぐらいにBCBがくる。
これは処理内容にもよるんで、これが全てだと思わないように。

>>109
コレが全てというより、むしろソレはかなり特殊な条件下の話であると思われ。

外基地>いけるやつはVBから入ってもいけるやつになるわけだし。

Delから抜けるのにかなり労力つかうのに
VBから抜けるのに簡単にいくとはとても思えない。

大半の通常アプリのVCLマンセー開発ならDel
C++ライブラリマンセー開発でGUIは適当ならBCB
VC++要求C++ライブラリマンセー開発ならVC++
VBA/VBSマンセー開発ならVB
サーバーサイドマンセー開発ならJava

こんな感じ。

左に「製品名＋マンセー」、右に「製品名」って何の意味？ >>112

ﾝ?!夏厨？

大半の通常アプリ開発ならDel
C++ライブラリを使う必要あり開発ならBCB
VC++要求C++ライブラリを使う必要あり開発ならVC++
VBA/VBSが要求される開発ならVB
サーバーサイド開発ならJava

これでいいか？

てゆーか、それじゃ技術情報じゃなく、派遣の実態じゃん >>114

>>109
俺はDelしかつかったことないんだけど、
ある程度以上のスキルがあれば、VCで作ったものはDelphiより
速くなるんじゃないの？VCLはWin32APIをきちんと使いやすくした代わりに
オーバーヘッドも大きい。MFCみたいにただラップしただけのほうが速そう。

DelでももちろんAPI直だたきできるけど、VCLで実現できないものを
つくるか、Timerみたいに処理速度がどうしても気になるとき以外使わない。

推測でものを言わないように。

＞ある程度以上のスキルがあれば、VCで作ったものはDelphiより
＞速くなるんじゃないの？
webに資料があるから、検索してから出直してきなさい。

初期起動は遅いけどな。

出直してきました
ttp://homepage2.nifty.com/Fujimaki/download/Comparison/

こういうコンパイラの最適化レベルでの高速化がBorlandが優れているのが
よくわかりました。ちなみにこれだとBCBもVC++より速い。

じゃなくてさあ、API呼出のオーバーヘッドが、MFCとVCLのどちらにあるかって
いうのは見つからなかったんだけど、VCLの方が軽いの？
普通に業務用アプリ作ってたらListViewへのアイテム登録とか
DBやファイルからの読み書き速度が問題になるでしょ。
そういうのって内部でAPI呼んでるんでしょ？

さっきのWebで、1-aのテスト以外はVCが最速でしたか
失礼

http://www.hirate.com/software/devtool/index.html

>正三角形の重心を中心に、１度から３６０度まで１度刻みに３点の座標演算をしながら
>画面に正三角形を描画する。計測内容は、描画を４００回繰り返すものと、描画をしないで
>演算だけを４０００回繰り返す２パターンを用意。
このようなテストがどれほど「そのコンパイラのオブジェクトの速さ」を反映するのか
疑問だが。
大体言語によって数値演算精度が違うんでないの？

こんなにＣＰＵが速くなってんのに、微弱な速度なんて気にする必要あるのか？

ＭＦＣソースをまるごとＢＣＢにもってきて、コンパイラオプションに、
-pr　を付けてコンパイルしてみろ。　バカっぱやくなるから。

いままでVC++が最速だと思ってました。
首をくくろうと思います・・・・。

>>120
そのベンチマークのソース、最悪。
そんなソースで調査したつもりになってるヒラテ技研さんの
技術力を疑います。

速さで負けても巷に転がってる情報量ではVCに分があり。
そもそもコンパイラの吐き出すコードの速さで優劣を決めるなんてのは
重要な性能である事は間違いないけど昔の話ではないかと。

ベンチマークオタはアセンブラで逝ってください。

>>127
ベンチマークヲタとは違うと思うが。

>>122
ヴァカ？
低スペックのＰＣ100台で稼動してる既存システムにツール追加
とかあるやろ

>>120
そのベンチマークのVCのプログラムですけど、
ループ中の

　　if (m_Check.GetCheck() == 0) {

↑これを

　　bool check m_Check.GetCheck() == 0; // ←ループの外に置く
　　if(check) { // 上記のifをこれに置き換える

↑こう置き換えたら Delphiより早くなりました。

このプログラムの計算時間の約75%は、GetCheck()に費やされてる
ようです。
>>120のページは、数値計算の実行時間を計測してるような印象
を与えますが、実際にはGetCheck()の実行時間を計測してるよう
なものです。

通常、スピードが問題視されないGUI関連の実行時間を比べて
あたかも数値計算で何倍も計算時間に差があるような書き方を
するのはフェアではないと思いますが。

訂正
× bool check m_Check.GetCheck() == 0; // ←ループの外に置く
○ bool check = m_Check.GetCheck() == 0; // ←ループの外に置く

ヒラテ技研ボコボコだな。（藁

あのー、"普通に書いて"という条件付じゃない？

実験者が「こういう結果を得たい」と思うと、
どういうわけか実験過程に不思議な力学が働くってことか？

※こういう結果＝Delphiの方が速い！C++より速い！！絶対速い！

だれかヒラテにツッコミメール投げた？

>>133
ベンチマークの宿命だからしかたないけど、こんな作為的なプログラムで
普通も何もないと思う。
(っていうか、普通は速度が重要視される処理ならGetCheck()なんてループの中に置かないでしょ)

百歩ゆずってこのベンチマークが妥当だとしても、
（>>130の指摘が本当だとしたら）
ヒラテ技研のページのなぜDelphiが早いかって考察の部分
(サブルーチンコールで引数にレジスタを使うから早いとか)は、
間違いということになるね。

自信満々の117=120にもなにかコメントいただきたいところだ。

>>137
同感、同感。
そんなことばかりやってるから、誰からも相手にされないんだよね。

やっぱ、Ｃビルダーだよ。
マニュアルなくても、プログラミング書けるし、ＶＣみたいに
ヘルプ腐ってないし。

別に自身満々でもない。
適当に推論を述べている人がいたから、指摘しただけ。

あと、ヒラテ研の人間でもないんだから、そのベンチの中身なんて
知った事ではない。

C++が遅いとか言われるとそんなに悔しいのか？
つまらない事で悔しがる子たちだな。

>じゃなくてさあ、API呼出のオーバーヘッドが、MFCとVCLのどちらにあるかって
>いうのは見つからなかったんだけど、VCLの方が軽いの？
>普通に業務用アプリ作ってたらListViewへのアイテム登録とか
>DBやファイルからの読み書き速度が問題になるでしょ。
>そういうのって内部でAPI呼んでるんでしょ？

これは気になる所だ.悔しいのだったら
こっちの方でなんらかのベンチソースでも書いてくれぬか？

VCLの方が軽いわけはないだろうが
ListViewのアイテム登録の動作が遅くて気に食わなければ
ＡＰＩでアイテム登録すればいいだけのことなんじゃないのか？

＞そんなことばかりやってるから、誰からも相手にされないんだよね。
はいはい。人から相手されても逝ってヨシよばわりされるよりかはまし。

>>140
その通り。
ＢＣＢは、ＶＣＬだけしか使えないと思ったら大間違いだよ。
ＶＣＬで組めないものは、ＡＰＩで直接くめばいい。

>>マニュアルなくても、プログラミング書けるし

そら統合環境のビルド開始ボタンの位置なんざわざわざ説明して
もらわなくてもいいが、ライブラリのリファレンス無し
でどうやってモノ作るのか本当に不思議だ。
BCBは魔法のツールってことかね？

ったくBorlandユーザってのはこんなのばっかりか？

>>140
それは君らが競争相手とみなされてないからだろ。
ウザイだけで、たいした敵じゃないしな！

>C++が遅いとか言われるとそんなに悔しいのか？
>つまらない事で悔しがる子たちだな。

別に悔しくはないが、Delの方が速いって主張は
117を起点とするものだし、コンピュータ工学的に
いって低レベルな操作が可能な言語の方がより最適化
可能で処理は高速（反面製造工数は増大）ってのが
常識だと思うぞ。

で、それを覆しかねないようなポテンシャルがDelphiに
あると頑固に主張するなら先にそれを証明するのは117の
責務だろうが。

>>143
大丈夫か?
とりあえず、落ち着いたらどう？

>ＶＣＬで組めないものは、ＡＰＩで直接くめばいい。

全角英語な奴の頭には継承だの派生だのといった
キーワードは存在しないみたいだね。

>>144
疲れるやっちゃな。

>Delの方が速いって主張は 117を起点とするものだし

117では116で適当なイメージを話している人に対して
いいかげんなこと言うなって指摘してるの。下のこれね。

＞ある程度以上のスキルがあれば、VCで作ったものはDelphiより
＞速くなるんじゃないの？

これが正しいわけない。
完全にイメージに踊らされているだけ。

>コンピュータ工学的に
>いって低レベルな操作が可能な言語の方がより最適化
>可能で処理は高速（反面製造工数は増大）ってのが
>常識だと思うぞ。

あのなー。プログラム板で見て思い出したけど
FORTRANの方が最適化は進んでいてるわな。数値計算はやいよな。

それに、DelがC++に比べて低レベルな操作が不可能かどうか
俺もしらないが、どうやら貴方も知らないだろ？
知らない所で変な主張するなよ。

>それを覆しかねないようなポテンシャルがDelphiに
>あると頑固に主張するなら先にそれを証明するのは117の
>責務だろうが。
知るかよ、調べたかったら自分で調べてそれから言えよ。

C++かDelphi、いずれが早いのかを言うのなら
体験した事や、知っている範囲でものを言いなさい。

っていうかどっちでもいーじゃん。自分が好きなほうを使えば。
なんで自分が使ってるのを人に押し付けたがるの？

ウルトラＣプロ最高！！！！

ー＋ー　　　/　　　　　lﾆ|ﾆl　　 　 ｜　　 ヽ　ノ　　　　,　 　 、　　　　　｜｜
ー＋ー　−+--- 　 ￣￣￣￣　ー十一　三l三　　ー十一,　ヽ　　　　　|｜
＿|＿　　/　--　　　 |二二|　　　 /|ヽ　　ヽ| ノ　　　　 |　　|　　　　　 　|｜
|_/　　　/　､　　　 　 |二二|　　　/ | ヽ　 ノ| ヽ　　　　/　　|　　　　　　｜|
　　　　　　　￣~ 　＿ノ　 ヽ＿　 　 |　　　 ､|　　　　　/　　､l
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（　）
　　, 円- ､　　　　　　　　　　　　　　　　　　　　/ヽ
　/　O　　円ｸﾞﾋｬｯ !　　　　　　 /ヽ、　　　　 /　 ヽ
　,, ： ,ー, O |　　　　　　　　　　/　 _,;, -'''"~~　　　 ヽ
'' ； ∴_ﾉゝ ゝ 　　　　　　　　／o　　　　O　　　　　　ヽ
　　ヽ　,;''"~"'';,　　　　　　　/　 ┌─┐　　　ノ（　　　ヽ
＿ノ| 　;;'';;'';;'';;''　　　　　　｜　 /　 　 |　　　 ⌒　　　　|
　　 ゝ、ヾ　　ヾ　　　　　 　 |　ト､　　 |　　　　　　　　 /
　／　 ヽ ヾ　　ヾ　　　　　　ヾ、　＼ノ　　　　　　　 ノ
　　　　ノ＼_ヾ　　ヾ　　　　　　／⌒ヽ、　＿＿＿／、
　　　　　　　ノヾ　　ヾ＿ ＿／　　ノ,　　　　　　　　　ヽ
　　　　　　　　　ヽ、ゝ　　　　　ノ　ノ　　　　　ハ　　　 ヽ
　　　　　　　　　　 ゝ､　　　ノ　　ノ、　　　　 ﾉ　ゝ 　 ｜ ）
　　　　　　　　　　　　 ー─一'´　　ゝ、　　　　　　　　l'´
　　　　　　　　　　　　 　 　 　 　 　 　 ）　 　 　 　 　 /

ー＋ー　　　/　　　　　lﾆ|ﾆl　　 　 ｜　　 ヽ　ノ　　　　,　 　 、　　　　　｜｜
ー＋ー　−+--- 　 ￣￣￣￣　ー十一　三l三　　ー十一,　ヽ　　　　　|｜
＿|＿　　/　--　　　 |二二|　　　 /|ヽ　　ヽ| ノ　　　　 |　　|　　　　　 　|｜
|_/　　　/　､　　　 　 |二二|　　　/ | ヽ　 ノ| ヽ　　　　/　　|　　　　　　｜|
　　　　　　　￣~ 　＿ノ　 ヽ＿　 　 |　　　 ､|　　　　　/　　､l

>それに、DelがC++に比べて低レベルな操作が不可能かどうか
APIコールはC++になるべ。SDKヘッダ中に定義された構造体で受け渡す
ようなAPIを使うために自力で再定義か？ご苦労なこった。
DelがDelの世界にいる限り低レベルな操作はできんよ。

＞あのなー。プログラム板で見て思い出したけど
＞FORTRANの方が最適化は進んでいてるわな。数値計算はやいよな。

爆笑してしまいました。

＞＞ある程度以上のスキルがあれば、VCで作ったものはDelphiより
＞＞速くなるんじゃないの？

＞これが正しいわけない。
＞完全にイメージに踊らされているだけ。

つーか99.9%正しいだろ。ほぼ正解だって。
あらゆるベンチマークで逆転事例はみたことないぜ。
※ヒラテのならもう出さなくてもいいYO。

正しいわけない、イメージに踊らされている
っておまえの盲信は修正の余地はないわけね。

ヒラテのエンジニアみたいなヘタレが作れば逆転する可能性がある、
ってのも正解だな。

>>147=117=120
おいおい、
>あと、ヒラテ研の人間でもないんだから、そのベンチの中身なんて知った事ではない。
と、中身をよく検討もせずに書いてあることをそのまま鵜呑みにした阿呆が
>適当なイメージを話している人に対していいかげんなこと言うなって指摘してるの。
もないだろ。（大藁

もっとみんなの言う事をしっかり読んで勉強しろや、坊や。

>>151
APIってＣ＋＋なのかぁ。へぇ。
Delphiって標準関数と同じようにAPI呼べるよなぁ。
VCLまったく使わずにウィンドウアプリケーション作れるし。

>>156
WPARAMとLPARAMだけで話が済むなら幸せだな。

#define 全ての型 LONG

だとか思ってねーだろうな。

>>157
あたまわりーなー。VCLがDelphiで記述されてるんだから、
一通りのWindows APIは扱えるに決まってるだろ。

デバイスドライバとかそのあたりまで行くとどうだか知らないけど、
通常のアプリケーションレベルだと、DelphiもVCも記述能力は
大差ないでしょ。

C++の問題点はヘッダーファイルだな。
自分は大して記述してないソースのクラスのヘッダーが展開されて、
コンパイル状況で何万行となってなってると、えっ、と思う。
実際コンパイル時間はDelの十倍以上。

C++逝け、とは言えないので、コンパイル問題は解決してくれ。

すごく単純な間違いが多すぎて逆に面白い>>このスレ全体

>>160
何年前の話してんだよ。

158,160,161

馬鹿揃いだな。

>>158
おまえ型宣言を.hから.pasに起こしなおす
経験もしたことのない初心者del厨ってことか？

>>160,161
差分ビルド／差分リンクとか知らないのはいいとして
1秒と10秒の相違は2chで遊ぶ時間で相殺されてるぞ。
Delphiでビルドに30分の大作でも作ったか？

×差分ビルド／差分リンク
○プリコンパイルヘッダ／差分リンク

C++で２０分コンパイルかかるのが、Delで１分。

インクルードファイルは展開されて大きくなるのは間違い無い。
今後のオブジェクト指向言語はインクルードやめてユニットするべき。
#defineが入ったらプリコンパイルヘッダにならないし。

Del厨からでかいでかいと言われるヘッダファイルを持つ
MFCライブラリソースのリビルドでも、私のヘタレマシンで
１分前後ですが、一体どのような冗長アプリケーションですかね？

というよりC++とDelで同じもの（しかも巨大）を作った
てことからして虚偽の匂いがぷんぷん。

DelからActiveXを呼ぶときは引数省略出来るが、
C++から呼ぶと引数全部要求する。
エクセルのブックオープンなんか引数１０以上ある場合あるぞ。
C++のオーバーロードのせいか。

>>インクルードファイルは展開されて大きくなるのは間違い無い。

お前のDISKの大半を占めているMP3ファイルや動画ファイルに
くらべれば相当小さいと思われ。

C++とDelで同じものじゃないよ。
C++の方がソース量１０分の１以下なのにそういう結果さ。

>>170
そらActiveXがデフォルトの引数を渡してくれるような
APIラッパーとなってるからだろ。オーバーロードは関係ない。

大きさじゃなくてコンパイル時間だよ。
インクルードで膨らませてからコンパイルは止めようよ、
って、C++コンソーシアムに言うべきか。

別なものをどういう基準で比較してんだこいつは。
つーか嘘つくなって。（なんか以前もこんなやりとりあったな。）
いまどきの標準的なマシンでVC++のコンパイル20分以上
かかるようなアプリは、相当でかいパッケージじゃなきゃ
ありえんぞ。

オーバーロードのせいじゃなくても、
とにかくC++とAXの親和性を高めろ。MSが悪いのか？

パッケージだ。構文解析からAXの呼び出しからイパーイある。
AXの呼び出しヘッダーファイルが１メガ近いぞ。（確か）

AXてなに？

ActiveX

1MBもある「ヘッダファイル」をもつActive-Xって
すごいねえ。
1Line=1メソッド/プロパティだとして1,000,000個の
メソッドとプロパティか。俺のIDEの関数ヘルプには
表示しきれんよ。（爆笑）

C++のコンパイルの遅さまで
ｳｿﾂｷよばわりしなきゃやっていけないんだ。

20分くらいかかるプロジェクトなんてざらじゃないか。
何が相当でかいくないとだ。アホっか。


関係無いけど

C#プログラミングTips
コモン・ダイアログを使う
http://www.atmarkit.co.jp/fdotnet/csharptips/007dialog/007dialog.html
もろ、Delphi&BCBだ。

あーごめん、計算間違い。一行200Byteとしとこう。
1,000,000/200 = 5000ね。それでも極大だけど

>>181
C#はDelphiと作者いっしょらしいからクラス構成が
似てても別段不思議じゃないけど。
ほんとに関係ないな。

C++でビルドに20分かかるプロジェクトがざらなのはいいんだわ。
大雑把な計算だけど、MFCライブラリの全ソースが6MB弱なわけよ。
でこれでリビルド１分だわ。20分なら6*20で120MBだろ。
でDel厨はその10倍のソースを書いたというわけ。
ソースで1GBだぜ。信用に値する数値か？

1MBかどうかは自信無い。BCB付属のofficeコンポーネントヘッダー。

Delで同様のタイプライブラリ作ったら1MBだったけど、
コンパイル時間遅くならなかったよ。

>大雑把な計算だけど、MFCライブラリの全ソースが6MB弱なわけよ。

クラスライブラリのコンパイル時間と比較するところが信用に値しない。
派生＆サブクラス使いまくりのアプリにすると、
C++では、サブクラスのヘッダーが展開されまくり。

あ、VC++使う人は、派生しないし、
STLもまともにコンパイル出来ないので、関係無かったね。悪い。

>>186
ほとんどのMFCクラスはCObject派生クラスだが・・・
なにいってんだねキミ。

VC++でSTLつかいまくってるが（バグはあるがね）
VC++の不条理でコンパイルできないことなんてなかったが
187は夢でもみてる？

>ほとんどのMFCクラスはCObject派生クラスだが・・・
>なにいってんだねキミ。

おおぼけ。CObjectからの派生じゃ、派生になっとらんだろ。
（もうちょっと派生階層あるぞ）

だからよー。
たとえばCFormViewにいきつくまでに大量に階層あるだろうよ。
使いまくりなら速度低下するんじゃないんかい？
ボケはおまえだ。

>VC++でSTLつかいまくってるが（バグはあるがね

ほとんど素で使ってんだろ。幸せな奴。

＞ほとんど素で使ってんだろ。幸せな奴。

素ですら使えんDel屋よりは幸せだな。

>たとえばCFormViewにいきつくまでに大量に階層あるだろうよ。

>CObject派生クラスだが・・・
↑
忘れたか？煽るときに文章間違えるってｶｺﾜﾙｲ

だから、C++するときにライブラリが幾つもあるってこまるんだよね。
ライブラリを越して値を渡すときにコードが発生。

なにが間違ってる？
CObject->CCmdTarget->CWnd->CView->CFormViewだぞ。

mfcする人ってライブラリが幾つもある状況を喜べるんだ。
msのライブラリはこれからｲﾊﾟｰｲになるよ。良かったね。
mfc、atl/wtl、.Net、vb付属ocx、VJ++付属．．．

＞だから、C++するときにライブラリが幾つもあるってこまるんだよね。
おまえはstdio.hだけつかってろ。

mfc　そのうち乗り換え
atl/wtl　今の主力
.Net　まだでとらん
vb付属ocx　つかうかこんなもん
VJ++付属 はあ？

>CObject->CCmdTarget->CWnd->CView->CFormViewだぞ。

こうかくべきを、「CObject派生クラスだが」と書くと、
CObject->CFormViewとなるだろうが。
逆に、（もうちょっと派生階層あるぞ） ってフォローしてやったぞ。

＞こうかくべきを、「CObject派生クラスだが」と書くと、
＞CObject->CFormViewとなるだろうが。

ならねえよ馬鹿。

煽りにまともに答えないでくれ。>>199

今年のmsセミナーで、開発言語は、VB（6）とVC++で
自由に作って下さいと逝ってたぞ。去年入ってたVJ++は死亡。
vb6 死亡
vc++/mfc .netに乗りかえられる予定
vc++/atl,wtl msはサポートせんとアナウンス

つーか話題分散させてないで派生クラスつかいまくりだと
コンパイル速度がするってネタの証明をしろよ。

修正：速度が低下するってネタの証明をしろ。

>ならねえよ馬鹿。

おまえの文章超おかしいんだなあ。煽りなんて１０年早い。

>修正：速度が低下するってネタの証明をしろ。

誰が証明を頼まれた側？「修正」ってどういう意味？（マジ質問）

リビルド(全ソースコンパイル)で20分ならまだしも、
ビルドするだびに20分かかる「ざらにある」か？

リビルドが２０分。
ビルドは速いけど、何秒かフリーズするのがやだ。

修正は203のタイプミスの修正。

派生だと速度低下ってのがそもそも根拠のない話だったのなら
別に証明せんでもいいよ。おまえのヘタレ具合が確定するだけ。

てことで寝るのでC++の問題点解決しといて下さい。C++捨てる気ないので。

＞ビルドは速いけど、何秒かフリーズするのがやだ。

どういうマシンだそりゃ。

>派生だと速度低下

これを書いたのは、VC++/mfcマンセーのやつだよ。Del側じゃないよ。

また一段とDelphiが嫌いになったよ。
無駄な時間をありがとう>del厨諸兄

500mhz、メモリ128mb。

＞vc++/atl,wtl msはサポートせんとアナウンス
つまりCOMも捨てるってMSは逝ってるわけだ。
そらすばらしい出来事だな。

なんだが知らんがこのスレにはDelphiを根拠無く必死に叩いている奴がいるな。

>>164
1秒と10秒の違いが限りなく重要なんだよ。実際にやってみれ。

ちなみに俺はPentium4マシンでHello worldするだけのサンプルを
VC++でコンパイルしてみたがその遅さにとても耐えられなかったね。

＞ちなみに俺はPentium4マシンでHello worldするだけのサンプルを
＞VC++でコンパイルしてみたがその遅さにとても耐えられなかったね。

そらP4のマーク彫られた386/16Mhzだからだよ。

どちらかというとDel厨のほうが根拠無しだと思われ。

だいたいおまえらVCLのビルドタイム加算せずに速い速いって
言うなら、C++のインクリメンタルリンクと比較しろよな。

ヒラテWebより引用

>各開発ツールで同一のプログラムを作成し、
>実行速度を計測しました。
>Windowsプログラムでは、速度的に大差ないと
>思われている方がいましたら、ぜひ計測結果を
>ご覧ください。また、世間的に「Ｃ＋＋言語が
>早い」といわれますが、まったく根拠のない話
>だということがわかります。

お前らの痛い生き様そのまんまやな。

たかだか数秒のコンパイル時間にこだわるプログラマって、
修正&実行を一時間に何十回もやるようなヘタクソだけだろ。

>>217
あいたたた…

>>218
根拠なしで叩いている奴が双方にいることで。

>>219
もちろんインクリメンタルリンクでやったよ。それでも遅すぎる。

＞もちろんインクリメンタルリンクでやったよ。それでも遅すぎる。
Hellow Worldでインクリメンタルリンクなら1秒かからんくらいだが
一体どういう基準でしゃべってるのさ。

>>222
人のことを根拠なしって言う割りには、
自分も根拠になるような話はしないんだな。

C++>>Java>>DEL>>VB>>COBOL>>VBS>>asp
<-強　　　　　　普通　　　　　　最弱->

PG板全てのスレでこの構図が成立することを発見しました。

COBOLが全てを支配する

このスレで成立してないので、>>225 図式は破綻しました。

>だいたいおまえらVCLのビルドタイム加算せずに速い速いって
>言うなら、C++のインクリメンタルリンクと比較しろよな。

ま、どっちにせよインクルード展開後、複雑な構文解析を必要とするC++と、
構文木に落とさずに前から解釈されるpascalは比較にならん。
比較しろよなとはキティの言葉。

それぞれのツールで充分なモノが作れたらそれでいいじゃん。
客にとってはDelphi使おうが、BCB使おうがVC使おうが、かわらんのとちがう？

正論はいても良いですが、スレからずれてます >>229
それとも VBシェアウェアスレに書く予定だった？

>>228
TurboPascalの時代だったらともかく、
DelphiのinterfaceはほとんどC++とかわらんだろ。
(テンプレートやインライン関数は除く)

>>225
環境と言語が混ざってるので没収試合になりました。

「>>228」っての違ってるよ。>>231
228にDelはコンパイルが早いって書いてるだから。

>>231
ん〜、何いってるの？

それにしても、このスレタイトルなのに
なぜ、Delphiが混ざってきているのだ？

C++側で必死になっている人は
VC++しか想定していないという所も
厨房臭いし。

無駄に延びてるな
もうちょっと客観的に見た意見はないのか
単なる厨房祭？
主観的意見ならほとんどの場合BCBでいいよ

我慢ならないコンパイル時間って具体的に
いったい何秒なのさ？

コンパイル時間に触れる奴は、自分の開発機のスペックも述べるように。

あのさあ、コンパイル時間で比較するのやめようよ。
実にくだらないと思うよ。

環境にもよるけど、Delphiになれている人と
なれていない人では
"我慢ならないコンパイル時間"つうのは確実に違うんだし。

しらべたければ
自分でBCBとDelphiのトライアルでもインストールして
試せばいいじゃん。

MS社ってさ、聞くところによると、
ユーザーには支持されているけどYO,
開発技術者泣かせらしいYO,
WinOSって、ユーザーインターフェイスは抜群だけど、
それで、Win向けのアプリとなると、泣きたくなるんだよね。
まぁ、最近は、VBとVC++のMFCができたから改善されたけど、
それができるまでのWinプログラマは死んでたらしい。

ましてや、WinOSや、Winアプリ、開発ツールを造るとなると・・・
我々の想像をはるかに越えるほどキツイみたいなんだよね。

>>239
トライアルってどこにあるのさ。
さがしたけど無かったよ。

MS社のNTOSは一流。IBMとDECの技術で作ったんだから。

開発ツールは今回全滅した。それだけ。

>>240
>まぁ、最近は、VBとVC++のMFCができたから改善されたけど、
「最近」って、そりゃ何年前のはなしだYO!

VC++厨房氏ね！

スレ違いでスンマソ

特に、少し前、CNETとかの掲示板とかでさ、
MS社関連の開発技術者は悲惨だったらしいよ。
まぁ、WiｎOS自体はさ、ユーザーに支持されてるから、
Win関連の商品は良く売れて良いんだけど、
WinOSは、開発技術者のことをまったくと言っていいほど
考慮されてないから、中身はぐちゃぐちゃらしい。
そら、VBは完全にユニコードだけど、
確か、WinOS事態は、「シフトJISコード」と、「ASCIIコード」
と両方が使われているらしい。
ただ、VBで開発する分には知る必要の無いことだけど。
ましてや、ユーザーには全然関係無いことだけど・・・
MS社関連の開発技術者なら・・・

そう言う事情から、俺は、ユニコードマンセーなんだけどね。
VC++より、完全にユニコードになったVBの方が優れている！
と言うわけなんだけど・・・

>>245
ネタ？

夏厨、「VB製のシェアウェア作る奴は氏ね」に戻れ。

>>241
ほんとだ、なくなっているようだ。

で、厨房祭りの結果どっちがいいって？

1がどっか行ったので結論の出し様が無い

VCでないと駄目って分野は確実にあるだろうけど
その分野が必要ないならBCBでいい
まぁ来年の今ごろはC#になってると思うが

C# Builder って出るんだろうか。
それとも VisualC# が既にRADなのかな？

「APIを組むなら、VC++」なんて古臭い考え捨てろ！
Cビルダーで全部出来るんだから。

なんのAPIだ?

VCLの上の方ではAPI呼んでるが、
ラップされてて下の方ではAPIコールが現れない。
だからクロスGUIが実現されている。
「どうせAPI呼ぶんだからラップの薄いMFC」とか言うのは、
出来の悪さを自慢してるだけ。

あらあら、今日もこんな時間に書き込みとは、
これだから、デブで、タンソクで、ハゲで、あぶらぎってる
中年オヤジに、「ヒィヒィ」逝ってる、
イカ臭い中年の女は、嫌いだね！

C++Builderはメッチャクチャコンパイル遅いよね
統合環境のメモリ消費量もスカポンタン
テキストエディタ使いにくい
入力支援機能なんかあまりの遅さに、作った奴は気が狂っているのかと思ったよ
オンラインヘルプも未だに旧形式で使いにくいし、載っている情報も少なすぎ

>>252
API組むってAPI関数だけでプログラムつくるってこと？
それならなに使っても同じじゃん。個人的にはＶＣのエディッタの
補完機能が手放せないけど。

>>256
＞入力支援機能なんかあまりの遅さに、作った奴は気が狂っているのかと思ったよ
それは、エディタオプションのコード支援機能の「識別子表示」を
ＯＦＦにすれば直るよ。　いままでＯＮにして使ってるあなたの方が
バカです。

>>258
VCのエディッタ使ったことある。はるかに性能いいよ。

補完機能に頼りすぎるのは、アマちゃんの証拠だよ。

少し、脱線するけどYO,
VBってYO,安全装置を採るとYO,
メチャ早なんだよね！
まぁ、めったに安全装置なんか採らないけどYO!

>>261
おまえは脱線禁止(；´〜｀)

ヘッダファイルを書くのって、だるくない?
事情により、C++よりもCで泣く泣く非オブジェクト指向のプログラミング
することが多いんだけど、
どうしても好きになれないのが、ヘッダファイルに
関数のプロトタイプをいちいち書くのが、ついだるくなってしまいます。

YO君は無視でお願いします

>>262
ついでに脱糞も禁止。

>>263
Cだって、Pascalと同じように下位のルーチンを前方に記述すれば
プロトタイプを書く必要はないぞ。

>>251
C#はMSがDelphiの開発者を羅値って作らせたのでRADです（ｗ

>>267
ん？VisualC# ってマジでRADなの？
だとしたら BCB から乗り換えよっと♪

>>260
道具は使ってこそ意味があるんだよ。
補完機能には自分で作った関数や構造体、クラスにも摘要される
からタイプミスが大幅に減少できる。それを使わないのはただの
ばかか、変なこだわりを持っているオールドタイプと思われ。

>>269
同意。
ドキュメントの無いコンポーネントを使うような場合は
補完機能が頼りになる。

>>268
http://www-6.ibm.com/jp/developerworks/java/001215/j_jw-csharp.html#3
C#とはRAD環境

うう、Delphiのパクリやぁ…。

>>271
パクリとはいえないか。同じ人たちが作ってんだから。（うわさだけど）

噂じゃねーよ、>271の記事読め

C++Builderマンセー派だけど、エディタはVCのほうがいい。
天と地ほどの差がある。

ヘッダのどこに宣言があるのか探すのにgrepするのは馬鹿らしいだろ？
どこにあるのか知っていても、ファイルを開いて、メソッドを探して……。
VCなら->とかやるだけで勝手に候補が出てきて、
引数や、関数の前にあるコメントまで見えるのにさ。それも瞬間的に。

もちろんBCBにもコード補完があることは知っているけど、
無駄な関数が大量にリストアップされるし、
コメントを参照しながら見比べることもできないから使い物にならない。
そのくせ殺人的に遅いから、OFFにしている。

>>273
ほんとだ。自分で貼っといてなにやってんだろ。

問題のベンチマークを出しているヒラテです。

まず、このベンチマークについて、誤解されませんよう
伝えておきますが、このプログラムは、それぞれの開発
ツールの最速値をテストしているわけではありません。

仕様書無しさんがうったえていますように、それぞれの
開発ツールにとって最善のプログラムを行っていれば、
最速値を求めるものとなるでしょうが、ＶＢを除いて
VC, BCB, Delphi 共に最速値を出そうとすれば、どれも
マシン語が扱えますので、結果的にプラットフォームが
同じであれば、同様の結果となります。

あのページで申し上げていることは、一般的にプログラ
マは、常に最速になるよう勤めて開発するのではなく、
普通に(普通とは最速どうのこうのと考えずに)プログラ
ムを使った際に、どの程度のプログラムが出来上がるか
を例えていることと、ＶＣが早いということがなんの根
拠もないということを表現したかったものです。

実際、ＢＣＢユーザーにも「こうすれば早くなる」とい
われています。しかし、私たちが表現したいのは、ある
制限や作り方を制約した上での速さではないのです。

> このようなテストがどれほど「そのコンパイラのオブジェクトの速さ」を反映するのか
> 疑問だが。
> 大体言語によって数値演算精度が違うんでないの？
もちろんです。
本当に速さだけを求めるのでしたら、このような実数値
計算を単純に開発ツールがサポートする関数で行ってい
たら速くありません。

> こんなにＣＰＵが速くなってんのに、微弱な速度なんて気にする必要あるのか？
そうです。
気にする必要はありません。これはＶＣが早いという根拠
のない事実を伝えるためのものです。

> そのベンチマークのソース、最悪。
> そんなソースで調査したつもりになってるヒラテ技研さんの
> 技術力を疑います。
各開発ツールでベストなものを作り、最速値を計っているのでは
ありません。趣旨はページにて伝えておりますが、読解力が
ないのでしょうか？

> 速さで負けても巷に転がってる情報量ではVCに分があり。
> そもそもコンパイラの吐き出すコードの速さで優劣を決めるなんてのは
> 重要な性能である事は間違いないけど昔の話ではないかと。
そのＶＣもこの先どうなるか、不安にならないのは
ＭＳオンリー開発者でしょうか。

> bool check m_Check.GetCheck() == 0; // ←ループの外に置く
> 　　if(check) { // 上記のifをこれに置き換える
>
> ↑こう置き換えたら Delphiより早くなりました。
こういう制約(こうすると早くなるのではなく、こうしない
と早くならないということ)は、速さを求める場合は必要ですが、
一般的にそういうことを気にかけて作る人はそういないという
ことです。速さを気にしないでも、それ相当に速いものが仕上
がるということは、トータル的に速いと考えています。
今のＶＣはＯＣＸに頼るところが多く、トータル的にも速い
ソフトを仕上げるとは思いません。

> どういうわけか実験過程に不思議な力学が働くってことか？
基本は、機能の少ないＶＢを基準として同様に移植しただけです。
早くすることを考えて作っていない分、ＶＣにはデメリット
だったと思います。しかし、Delphiにメリットがあったわけで
はありません。

> ベンチマークの宿命だからしかたないけど、こんな作為的なプログラムで
> 普通も何もないと思う。
詐欺的なといわれますが、どうも趣旨を理解されず、
速さの結果だけに執着しているようですね。

> ヒラテ技研のページのなぜDelphiが早いかって考察の部分
> (サブルーチンコールで引数にレジスタを使うから早いとか)は、
> 間違いということになるね。
レジストリだけでは、メモリスタックと比較しても、今どきの
コンピュータでは大差はそれほどありません。
ましてや、どのツールもＡＰＩを頼っているので、最速値を計る
目的でベンチマークを作っても意味はないでしょう。
ただ、メモリ書き込みを行うよりもレジストリを使う方が早いのは
コンピュータの構造がわかっていれば理解できると思います。

このような形で、当社のページが誤解を受けた批評をされること
に関して、また、趣旨を理解されなかったこと、非常に残念に思
います。
このサイトは、ご本人の本名が隠され、メール等も明記せずに
批評を行っていますので、いいたい放題ですね。
題名のどっちがいいかということに関して、言わせていただければ、
速さで決める問題ではないと思います。
当社は、特にDelphiだけ使っているわけでもなく、ＶＣもＶＢも
ＢＣＢもＪＡＶＡも使っています。
要は、目的に合わせて使い分ければ済むと思いますが。。

ううぉうぃ！
>>277
ほんものさんだ。

仕様書無しさんは、
何も名前欄に書かないと、デフォルトで出る名前なので
匿名という意味ですよ。

読解力の無い厨房が沢山いますので
あまり本気になって相手しない方がよろしかれ。

発言を切り貼りして、論点をずらしてるように見える…。

ヒラテの例のページだけど、
ベンチ結果の分析で、グラフィック描画や数値演算にだけ触れていて、
もっともスピードに影響している部分(GUIの呼び出し)はまったく言及なし。

あのページを読んだ人に、数値演算だけであのベンチの結果が出たような
印象を与えるような書き方をしてたでしょ。

これって、めちゃくちゃ作為的だと思うんだけど、どう？

>>281
数値演算のタイトなループの中で GUI と相互作用するようなコード
を書いてる時点で、逝って良し。

速度が重要でないケースならともかく、コンパイラ間の速度を比較す
る場合に、あのコードは論外。設計が悪い場合には、いくらコンパイ
ラががんばっても無駄だもの。

オレもヒラテさんに聞いていいかな。
仮に発表前にさ、件のソースコードのGUI呼び出し部分のボトルネック
見つけてたら、変更してた？それともそのまま？

>ただ、メモリ書き込みを行うよりもレジストリを使う方が早いのは
>コンピュータの構造がわかっていれば理解できると思います。

どうでもいいけどレジスタをレジストリと軽々と言ってしまうあたり、
ほんとにプロ集団かって疑いもちらほら。

>>見つけてたら、変更してた？それともそのまま？

まあ素直に認めて検証不十分でしたって言っちゃうほうが、
百鬼夜行の2chじゃ会社価値が傷つく度合いも軽いとおもうよ。
社員氏はもうだいぶ論理破綻してるみたいだし。

>詐欺的なといわれますが、どうも趣旨を理解されず、
>速さの結果だけに執着しているようですね。

速さを計りました、ってページで速さの評価以外の趣旨って何なの？
深遠なテーマが織り込まれてるような文面でもなかろう。

>今のＶＣはＯＣＸに頼るところが多く、トータル的にも速い
>ソフトを仕上げるとは思いません。

はあ？そりゃVBの事ですか？ VC+OCXなんてケースめったに
ないですYO。

レジスタ渡しとスタック渡しで、それほど差が出ますかね。最近の CPU は
パイプライン／スーパースケーラ／内部で x86 命令を RISC 風に変換 と、
およそ直感的に振る舞いを把握できるような代物ではなくなっているので、
レジスタだったら速いといわれても「ほんとか？」と眉唾で聞いてしまう。

個人的には、最近はプロファイラを使わないで測った結果は信用しないこ
とにしてます。Z80 の時代は遠くになりにけり……。

>VC, BCB, Delphi 共に最速値を出そうとすれば、どれも
>マシン語が扱えますので、結果的にプラットフォームが
>同じであれば、同様の結果となります。

そりゃVC、BCB,Delphi,ASMの4者の比較に過ぎず、
本来の言語パッケージ製品の評価にはならない。
代表的詭弁の例。

ヒラテ社員に聞きたいんだが
>まず、Ｃ＋＋は早いという定説に近い話は、根拠がないことがわかりました。
なんていう考察する前に、プロファイリングとかしたんかい？
>総括：大木 プログラム作成/計測：堀川・奥村
3人がかりで、何を考察したんだ？

ようするに、
　客先からVC++で受注ばかり受ける
　理由に「VC++の方が速いから｣とか言われる
　ヒラテの社員はVC++がまっとうに使えないゴミ社員ばかり
　VC++が遅いと言う結果を捏造しよう
ってことなんでしょ
そんで、客先の人がここ読んでいて、慌てて反論してみたが、泥沼にはまったと

>>277-278
言い訳すればするほど無能をさらけ出してる気がするけど。
書いた個人の問題ではなくヒラテという会社自体がそんな
レベルなんだなという印象が強くなる。

しかし、
>どうでもいいけどレジスタをレジストリと軽々と言ってしまうあたり、
>ほんとにプロ集団かって疑いもちらほら。
という感想を俺も持った。
一箇所だけならうっかりとも思えるが、繰り返し書いているかね。
ひょっとして、この言い訳はヒラテの技術でなく営業の人間が
会社の弁護のために勝手にやっているだけなのかもしれないな。

>はあ？そりゃVBの事ですか？ VC+OCXなんてケースめったに
>ないですYO。

はあ？、自分の使い方だけで物事を推し量るなYO

>>290
ここで粘着で、言語速度比較でこだわっている人間の方が
実社会で十分ｳｻﾞｲ

>>285
以前、面接官に
「DelphiってC++と比べて遅いよね」と、
制御系Cプログラマに印象だけで言われたことがある。

そういう何もわかってない奴に
勝手に決め付けられたのでムカツイタなあ。

SkyThinkSystemでだけど。

自称「ヒラテ」くんだが、
>このサイトは、ご本人の本名が隠され、メール等も明記せずに
>批評を行っていますので、いいたい放題ですね
と書いている割に、こういうところに会社名を掲げて反論しているわりには
担当者名を書かないというのはどういうわけ？
なんか、すごく不自然なんだけど。

「ヒラテ社員」を騙った偽者？
それとも論破されたときに「あれは偽者が書いた」と逃げを打つための布石？

>>292
ウザイかどうかなんて論じてないが？
話を逸らしたいみたいだね。

>>277, >>278

ﾜﾗﾀ

>>278
「作為的な」を勝手に「詐欺的」と読んだあげくに、「どうも趣旨を理解されず」ですか？

「速さを計る」を旨とするページで「速さの結果だけに執着しているようですね」ですか？
おまけに「目的に合わせて使い分ければ済む」ですか？じゃあそもそもそんなこと書く必要は
無いんじゃないですか？

「サブルーチンコールで引数にレジスタを使う」が「レジストリ」ですか？

「ご本人の本名が隠され」と言いつつ会社の名だけ書いて本名もメール等も明記しないんですか？

このような国語力と用語理解力に問題がある人を代表とする会社に、当板のスレが
誤解を受けた批評をされることに関して、また、趣旨を理解されなかったこと、非常に
残念に思います。

ところで「ヒラテ」では、結果が同じと判っている関数をループの中で何度も呼び出すのを
「普通のプログラム」と考えているのですか？

ヒラテは「通常の組み方をすれば、Delphiが速いって」っていってるけど、
例のベンチのプログラムは、あまりにDelphiよりじゃないか？

中身が return 文だけの小さい関数は inline にするとか、
構造体の引数は、const の参照にするとか、C++プログラマなら
普通にやってる最適化を一切やってないしな。

>>296
鋭くてｲｲ!

彼女にヒラテ打ち食らいました

>>299
何をしたのですか？

>>300
DelphiよりVCの方が早いプログラムが組めると言ったらいきなりです

>>301
たぶん、「デブよりブスの方が安いグラム単価で食えるな」と聞こえたんでしょう。

>LinuxとGUIクロスプラットホームRADを実現しているのは
>今のところDelphi/Kylixだけな。

>自分の目に見える範囲だけを世界と思わないように。

Qtは？

>>303
RADか？物見せて

Forteは？

>>303
KylixはQtベースじゃないの？

ヒラテ面白いなー。
技術力の無さを露呈させているのが痛い。

>>307
だとしたら、妥当なプログラムで各環境をベンチマークするものを
作ってあげたら？

で、計測結果もつけてね。

そうじゃないと、「技術力の無さを露呈している」なんて逝っている
キミの方が厨房臭くて遥かに痛いって。

>だとしたら、妥当なプログラムで各環境をベンチマークするものを
>作ってあげたら？
作為的なコードを排除すればVC+>Delphi>VBの順位で
結果はほぼ固定になりますが、これを実機再現しても
一般の方々に感心されることもなく、その結果に対
する平手のコメントも、308の口上も期待できそう
にないのでやる価値なんかどこにも無いですね。
そんな馬鹿馬鹿しい作品に何か賞品でもくれますか？

>>309
俺の元彼女のメアド公開したる

　　　　　　　　　　　　　　　　　　　＿＿
　　　　　　　　　　- - = = ≡≡≡＼ 　＼
　　　　　　　　　　　　　　- = = ≡≡＼ も＼
　　　　　　　　　　　　　　　　　- = ≡≡＼ う＼
　　　　　　　　　　　　　　　　　　　　- = ≡＼ 来＼
　　　　　　　　　　　　　　　　　　　　　　　 - =＼ ね＼
　　　　　　　　　　　　　　　　　　　　　　　　　　 -＼ え＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼　よ＼
　　　　　　　　　　　　　　　　　ｱﾌﾞﾈｰﾖ　　　　ｵｲｵｲ　　＼　!!.＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　￣￣＼　　　ｹｴﾙｿﾞ! ｺﾞﾗｧ　∬∬
　　　　　　　　　- = = ≡≡　ヽ(|||ﾟДﾟ)ﾉ　- =ヽ(　`Д´)ﾉ - =(　`Д´)ﾉ - - = ≡ソ￣（♯`Д）
　　　　　　　- - = = ≡≡≡- |￣ ヒ￣|──|￣ ラ￣|──|￣ テ￣|───□（ ヽ┐U
　　　　　　　　　　　　　- - = ≡￣◎￣　- = ￣◎￣　- = ￣◎￣　- = ≡◎−彡┘◎

　　　　　　　　　　　　　（　　ヽ　　　　　　――――　　○　　――――
　　　　 ,　⌒ヽ　　　　(　　 ＿＿　　　）　　　　　　　／/ |　＼
　　　 （　　- - = = ≡≡≡＼ 　 ＼　ヽ⌒ヽ 、　／　/　|　 　 ＼
　　　　ゝ　　　　｀　- = = ≡≡＼ も＼　 　 ） 　 　　　　|　(⌒ 、
　　　( 　　　　　　　　　 - = ≡≡＼ う ＼　　　　ヽ　　　　　（　 　 　ヽ
　　(　　　　(⌒　　　　　　　　- = ≡＼ 来＼　　　　）　　　(
___________________________________________ - =＼ ね＼__________________________________________________________
　　　　　　　　　　　　　　　　　　　　　　 -＼ え＼
　〜　　　　　　〜〜　　　　　　〜　　　　　 ＼　よ＼　〜　　　　　　　〜〜〜　　　〜
　　　　　　　　　　　　ﾄﾞｺｲｸﾝﾀﾞｰﾖ　　ｵｲｵｲ　　＼　　＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　￣￣＼　　　ｹｴﾙｿﾞ! ｺﾞﾗｧ　　∬∬
　　　　- = = ≡≡　ヽ(|||ﾟДﾟ)ﾉ　- =ヽ(ﾟДﾟ|||)ﾉ - =(　`Д´)ﾉ　 - - = ≡ソ￣（♯`Д）
　　　　　　　　　　　　 |￣ ヒ￣|──|￣ ラ￣|──|￣テ￣|───□（ ヽ┐U
　　　　　　 ﾐﾐミミミミ〜〜〜〜　ミ〜〜〜〜　ミ〜〜〜〜　ﾐミミ〜〜〜〜〜
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ｻﾞﾌﾞｻﾞﾌﾞ
〜〜　　〜〜　〜　　　　〜　　　〜〜〜　　　〜〜〜　〜　　　〜〜〜〜　〜〜〜
　〜　　　〜〜〜　　　〜〜　　〜〜〜〜〜　　　〜　　　〜　　　　〜　　　　〜　　〜
〜　　　　　　　　〜　　　　　　　　　　〜　　　　　〜　　　　〜　　　　　　〜　〜　　〜

http://www.hirate.com/company/
さすが一歩先を行く技術の会社はやる事が違いますな。

>>313
ちょこちょこ誤字が出てくるページだね。
あんまり制作を頼みたくはないな。

コンパニーですから。

>>315
コンパばかりやってるのか？（藁
トップページの表題でコレは、あまりに情けないな。

コンパニーワラッタ
CONPANY!!

http://www.hirate.com/software/index.html

Delphi関連のソフトをパッケージとして販売しているようですな。
なるほどね。

CodeWarrior for Windowsはどう？
既出だったらゴメソ。マジレス希望。
いいと思うんだけど。

(どっちでも)いいと思うんだけど。

もう収束してるスレをあげんなよ。

CodeWarrior for Windows？
いいよ。すごくいい。俺なんか毎日使ってる。

http://www.google.com/search?q=%83R%83%93%83p%83j%81%5B&hl=ja&lr=lang

http://www.google.com/search?hl=ja&safe=off&q=conpany&lr=lang_ja

>>323-324
「いづれも」とか「サーチェンジ」とかは？
「制作代金をお振込みしていただきます」というのも
日本語としておかしいな。