VBはVCより１００倍、効率がいい

Cはポインタが使え標準化されているからいいとします。
VCは、高度なことができる割には、MFCなどマイクロソフトに
汚染された仕様のかたまりで、効率悪いし互換性も
ないじゃありませんか?
VC使えるプログラマーなら、VB覚えると１００倍は効率よく
プログラミングできそうです。
どうせWinアプリ組むんだったら、割り切ってVBのほうが
いいのではと、最近感じています。

1は目が開いてるのにメクラに1票。
終了。

VBの欠点
�@遅い
�Aランタイムが必要
�B高度な言語のため細かい制御がやりずらい
番外：言語に直接関係ないがバカが多い。

VB7を範疇に入れるなら、�Aを除き欠点はなくなる。
とは逝ってもC#も�Aの欠点がつく。

似たようなくだらないスレ連立するVB使いの馬鹿さ加減に乾杯age

VB Vs Delphi
のほうが煽れるあげ。

>>3　の欠点は、昔のFDの時代ならともかく
マシンの高速化とCDによる配布で解決できるのでは?
�AはVCなら最初からVCランタイムMSVCRTがついているだけで、
今後さらに差は縮まってくるのではと

高級言語にありがちなことなので�Bに含めて
�B−１予約語が多い
�B−２予約語の対応がとれてない(Get/Set,etc)
�B−３バージョン上がると予約語が増える/消える

C/C++みたいに使わない予約語(というか関数)は
includeしなきゃいいってわけにはいかんからねぇ。
覚えなきゃならんことが多すぎて開発業務にはいまいち。

VBでForm使うくらいならVCでFormView使え。
VBと同じことがVBより少ない知識でできるぞ。
MFCの効率がいいとはいわんが、ソースがある分
ブラックボックスのVBより100倍ましってもんだ。

vsをVsとかく5は糞C使いに5ポインタ。

>>7
ソースがあっても、MFCに頼り、開発効率が悪く、
開発者を圧迫するVCでは意味をなさない場合がおおいのでは?

vs.だ映詩

>>5 Delphiもすぐにexeができるので、効率はいいのですが…
VC7から統一環境でVBVCでモジュールの利用が簡単になるので
VBを使っていった方がよいかと

MFCよ！MSが見捨てても俺は見捨てないぞ！

速度の遅さは、ＣＰＵの速度工場がカバー。
で、ＶＢの勝利。
じゃ、その他の違いのべよ。
ポインタはなしね。
あと、しょうもない違いとかね。

みんなBuilder知らないの？
どうせ使ったことないんだろうけど。

VBが効率良い？
VBの不効率さが見えるところまで使い切っていないだけだろ。
効率のよさが目立つ範囲でしか使えていないのね。ご愁傷様。

Builderは結構好き。
昔VB使っていたけど、Delphiが出て、
「VB並に簡単にユーザインタフェース」が作れて
コンパイラなら！！と乗り換え、
更に言語がC++になったBuilderにすぐ乗り換えました。
ちょっとツール作りたいなーって時に重宝する。＜Builder

今はVC++だけどな…

特にCstring使っているVCプログラマは、VBに近い場所にいます。

>>15
VBが不効率な部分は、ローレベルのVCで、COMやDLLにすればよし。
VCがUIを持てば非効率なだけ。
VCプログラマは、VCでしか使えないようなLIBや__cdecl関数ばかり
作らない方が今後のためになる。

On Error Goto 地獄を何とかしてください >>VB
try throw catchのほうがマシです。

UIの仕様変更に絶えられるようにしてください。

後になってVBではほぼ不可能なUIを要求して
「ちょっと直すだけで出来るよね？」なんていわれても
むぎゅ〜です。
そのUI作るために突然ローレベルな世界に。。。とほほほ。

だったら最初からVCで作っておけばよかったよ。

>>19
危険そうなところに、On Error xxx いれるだけで安定するから
効率いい。
VCだと、すぐに、不正な処理．．．、Run Time Error
○×が原因で．．．　嫌になりません?

マシとかいうレベルじゃないと思うけどなぁ。
仕事で開発言語を選定するとき、try 〜 catch が無いのは
一番最初に却下でしょう。

>>21
退廃的な思考パターンですね。
前進しましょう。

それは安定してるんじゃなくて誤魔化してるだけでしょ。
バカじゃないの?

だいたい、VBは出来ないことが多すぎる。
自分にとっては、コンソールアプリが作れないだけでも致命的。

> 危険そうなところに、On Error xxx いれるだけで安定するから
> 効率いい。
ちみ、例外処理を考えた事ないでしょ。

ちょっといい話し。

VB.NETはコンソールアプリが作れたりします。
try catchもできます。
でもVB厨房には使い切れません。

>>21さん

うーん、ちょっと驚いたけど、けっこういいかも･･･。
でも、それが普通と思っちゃただめだよ。
23さんの言うことがまとも。

きっと21が作ったVBソースには、そこらじゅうに
　On Error Resume Next
があるんだろうな。(藁

>>20
設計次第ですね。VBで不可能なUI(コントロール)があるから
ActiveXが存在して、商売が成り立っています。
汎用性がある部品にしなければもったいない。
すべてをVCだけでやろうとするから、無駄な労力が
必要になると思うんです。１００倍効率的な部分を
うまく利用すべきだと思います。

効率が100倍...同じ時間働いてVC使うより100倍仕事できる?
一年に3日だけ働けばいいのか。そりゃいいや。

VBはVCより１０００倍、バカが多い。
>>1とかはいい見本だ。
この手のネタスレは他に腐るほどあるんだからそこでやれ。
これにて、
−−−−−−−−−−−−− 終了 −−−−−−−−−−−−−
以後、sageでやってね。

「このリストボックスのアイテムなんだけどさぁ〜、
ｘｘｘなアイテムはイタリックにしてほしいんだよ。
これぐらいすぐだよね。じゃあ明日までによろしく〜」
泣き。。。

あーVCだったらOwnerDraw属性にしてWM_DRAWPAINTでDrawTextだけなのに
いまさら別コンポーネント探している間もねーしな。

どーしてくれるんだゴラァVB！

>>26
実際の業務で使えるまでにはあと２年ぐらいかかりそうだね。
Ｃ＃モナー。

>>28
アプリケーションの目的が達せられれば、
極端な話、プログラムはどうでもいいことがあります。
いかにソースが汎用性や保守性にすぐれていても、
それが芸術品であっても自己満足でしかないこともあります。
また、それにかかるドキュメントや、コメントの負担も考えなければ．．．

すまんWM_DRAWPAINTではなくWM_DRAWITEMの間違いだわ

>>32
UIによっては逆のパターンも結構あるでしょう。
効率の悪い部分にはまってしまうと、クライアントの要求にすぐに
応えられないことを隠していません?

何度も使う可能性があるのならばActiveXしても良いが
普通は一回こっきりだ

ActiveXを作ること自体は簡単だが
安定した環境を作成するのがかなり困難になる
特にサードパーティー製が入ると・・・
デバグできないし

ゴラァVB！、なんでunsignedのパラメータがあるメソッドを持つ
interfaceをImplements出来ねぇんだよ。
なんで戻り値はHRESULT必須なんだ？

最後の最後で「for eachできるようにして」っていわれて
_NewEnumとIEnumXXXを実装しようとしたらはまったぞ。
しょうがないからためなくていいものをコレクションにためてから
_NewEnumで渡すはめになったおかげで
すんごく効率悪すぎるコードになったじゃねぇか。

できないこと多すぎ。
できないことを出来ると信じて探していると効率悪すぎ。

>>36
おまえなら、32の例はどう効率よく対処する？
「できない」って言うのが、お前のいう効率か？

VBのことは殆ど知らないがVBってOOPできるの？
OOのことを殆どしらない人間に限ってVBプログラマなんだよね。
OOP自体できないのか　できるけど使わなくて済むような用途でしか
VBは使われてないのか。どっち？

>>34
28じゃないですけど、VBでは「On Error Resume Next」に限らず、
本来であれば必要の無いコードを 沢山、沢山 書くことを
強要されるので、それが 非合理的→非効率→苦痛 につながって
いくのではないでしょうか。

>>40
今はできない。
そのうちできる。(今年の終わりぐらいには)

>>39
そこに至るまでの効率と比較しなければ意味がありません。
サンダー産のlistboxも、もとは同じコントロールなのですから
細かいところで競っていてもしかたありません。

>>40
なにをもってOOP可能というかわからないけど、
とりあえずそれらしいこととして

一応、クラスという概念はある。
継承もできるし、ポリモフィズムもできる。
クラスメンバのPrivate化と公開メソッド提供によりデータ隠蔽もできる?

どもほとんどVB厨房は、そんなことを気にしていない。

賢明なVCプログラマならVBで簡単にActiveXコントロールを
作成できるのはご存じですよね。
コントロールのサブクラス化です。

問題の答えになっていない。0点。>>43

今考えても、それまでの工数はVCでもVBでも変わらないぞ。
あの追加要求が出た時点で出戻りになったんだぞ。
いままでの効率なんか吹っ飛ぶくらい。

結局、その場限りのOCXを徹夜で組んだよ。あーすんげー効率わりー

41>>
VBも使い方次第です。
VCも割り込みレベルで、完璧にエラー処理できるか?
と言われれば困りますよね。VXDをVCでやると非効率ですよね。

懸命なVCプログラマは、コントロールをVBでつくっても
出来る範囲はやっぱりVBの範囲ということを理解している。

VXDをVBでやるともっと非効率です。っていうか、できねぇじゃねぇか。
それより、エラーと割り込みってどういう関係があるんだ？

懸命なプログラマなら、VBはクライアントの要求に答えきれない
ということを知っている。

>>46
まあ、気持ちはよくわかる。
VBもVCもCもインラインも、うまくつかわなきゃ!!

「自分のリソースを無駄なところに使うのはもったいない」
↑これが本音

外部設計者が悪いと言えばそれまでなのだが．．．

風呂入って、メシ食って、テレビ見てきます。
次はテレホタイムです。
それまでに効率の無さ以上に効率的なところを具体的に上げるように。

＞懸命なプログラマ
なんか雰囲気でてるなあ。

VBはよく使うクラスが何もしなくても使えると考えるべきかな。

s/懸命/賢明/
すまん。

賢明なプログラマなら、自分のリソースを確保するために
VBであれCであれ、うまく利用します。

アセンブラで１クロックを競うようなプログラムから
VBSのようなスクリプトまで、
他言語の良さも、ぜひ味わってください。なかなかいいですよ。
私は、アセンブラからC、C++へと移行したので
ポインタ(単にアドレス)の概念や、OSの動作を
最近のVCプログラマが知らないことに驚きます。
この板のスレでは、結構マジレスが多かったので
感謝しています。
おつき合いありがとうございました。

効率はいいよ。
多分。
インターフェース作ることにかけては、ＶＢの右に出る者
はないんじゃないかね。

ただ他の面でも使えるというのは嘘だと思うよ。

勝手に終わらせてる。マジレスしてた彼、帰って来てガッカリだぞ

確かにVBでもできるものはVBでやったほうがいい。
馬鹿にでもできる仕事はわざわざ優秀な奴にやらせるより
馬鹿にやらせておいたほうがいいのと同じこと。
逆に難しい仕事は馬鹿には無理だから優秀な奴にやらせる。
VBとVC++の使い分けなんてそんなもんじゃないの？

それにしてもVB使いは、何をこんなに焦っているのでしょう。

M$に正式に切り捨てられたことでパニックになっているのかなぁ。

2chに書き込んでも、余計にパニックになると思うんだけどね。

>59
VBもVCも目くそ鼻くそを笑うレベルだ。
VBで「こんな仕様できねー」というのも
VCでもったいぶって毎回API呼ぶのも変わらん。

＞５６
激しく同意。Ｃやっただけでポインタわっかてるとかぬかす
馬鹿多すぎる。生の世界でそれを体験しなきゃ。

別に切り捨てられてはいないだろ。
移行が大変そうなだけで

アホ学生ばっか。

ま、.netでは
VB＝C#
こんな論争もなくなるね。

やれやれM$の日本征服は成功したようだ。
みんなM$の手のひらでしか思考してない。

ぷろぐらまーはえむえすにふしぎなおどりをおどらされている

なんか短時間で育ってるね。
ポインタ以外でVBとVCの比較ね。DLLを使うとか無しで
あくまでも純粋な環境ということで。

1)実行速度が遅い−クリティカルなアプリでは致命的です。
　CPUの速度が上がっても比較するとVBはやはり遅い。
2)突っ込んだデバッグができない−原因不明のバグが出た場合、
　奥まで追っかけられない。
3)カスタマイズし難い−一般的はI/Fは簡単に使えるが、ユーザ指定の
　I/Fになると、とたんに敷居が高くなる。
4)マルチスレッドが使えない−デフォルトではサポートされてなかった
　ような。。。実はされてる？
5)文字列の扱いが面倒−特に1Byte文字は最悪。Win上に限定すれば快適。
6)継承が使えない−クラスモジュールはサポートされてるのに、片手落ち。
7)予約語がウザイ−ガイシュツなので省略。
8)開発環境の移動が面倒−いろんなことをフルパスで覚えているので、
　別PCに環境を移動するのが面倒。
9)実行前に保存−実行中にハングすると保存してなかったコードがパー。

なんかいろいろあるな。きりが無いのでこの辺でやめ。

VBがVC++より100倍効率良いなら、DelphiやBCBなんて100000倍くらい効率
良いんじゃないか?
このスレに上がってる「VBだと○○出来ない」は全部出来るしね。

VC++に出来てDelphi、BCBに出来ない事なんて探す方が難しい。
(せいぜいドライバの作成ぐらいか?)

だいいち、WindowsとIEとOfficeのバージョンキチンと合わせないと動作保証
出来ないような言語でよく仕事してられると思う。

>69

8)VCもあんま変わらん。プロジェクト名変えたいときどうする？
9)100 SAVE "xxxx"入れとけ

>>70
超同意是認.
ドライバだって本当はActive-X程度の手間でできなきゃおかしい.
OS-9を見習え.
やっぱりM$はOSと開発環境を分離しろ.

>>71
プロジェクト名変えたいってどんな場面？

パスの変更は複数人でやっていると頭がパニックになる。
ん？フルパスでおぼえていたか？

100 SAVE "xxxx" ってな〜に〜？

>>70
＞VBがVC++より100倍効率良いなら、DelphiやBCBなんて100000倍くらい効率良いんじゃないか?

　　　　(ﾟДﾟ)　(ﾟДﾟ)
　　　(ﾟДﾟ)　　(ﾟДﾟ)　　　　(ﾟДﾟ)(ﾟДﾟ)(ﾟДﾟ)　　　???????
　　　(ﾟДﾟ)　　　(ﾟДﾟ)　　　　　　　　　　(ﾟДﾟ)　　??　　　??
　　(ﾟДﾟ)　　　　　(ﾟДﾟ)　　　　(ﾟДﾟ)(ﾟДﾟ)　　　　　　　??
　　(ﾟДﾟ)　　　　　(ﾟДﾟ)　　　　(ﾟДﾟ)　　　　　　　　　??
　(ﾟДﾟ)　　　　　　　(ﾟДﾟ)　　　(ﾟДﾟ)　　　　　　　　　??
　(ﾟДﾟ)　　　　　　　(ﾟДﾟ)　　　(ﾟДﾟ)
(ﾟДﾟ)　　　　　　　　　(ﾟДﾟ)　(ﾟДﾟ)　　　　　　　　　　??

>>73
100 SAVE "Progam1.bas"
110 REM ｺﾚﾊProgram1ﾃﾞｽ
120 GOTO 100
････････
というように使うってことかも！？

戻ってきたら、終わってんじゃねぇよゴラァ！
VBで痛い目にあったネタはまだまだあったのに。もういい寝る。

>>69

2)突っ込んだデバッグができない
　実は禁断の技があるんよ。プロジェクトのコンパイルオプションでデバッグシンボルを出力するようにして、VisualC++のIDEでVBで作った.EXEや.DLLをデバッグするということもできる。結構つっこめたりする。その気になればSoftICEでVBコードをデバッグするということもできます。

4)マルチスレッドが使えない
　実は密かに使えます。CreateThread APIでスレッドプロシージャをAddressOfで指定するという禁断の技もあります。IDEがマルチスレッドコードに対応していないので、ほとんどデバッグ不能ですが。

5)文字列の扱いが面倒
　これねー、はまるんよ。日本人の私はUnicode反対です。

6)継承が使えない。
　Implements文は？ CallByNameで非効率なポリモフィズムという技もありますよ。

>>76
2), 4)　あんた，随分と無茶なことしてるな．

>76
実際、いきつくところまでいってしまわれたようで。
マルチスレッドな部分はCで書くよ。

76みたいな人はVB厨房とは呼ばない。
76の言っていることがさっぱりわからない人は
VB厨房決定。
そっと胸に手を当てて考えてみてください(w

でも個人的にはそこまでするか？って感じです。
よっぽどVBを愛しているか、VBしか使っちゃダメな
環境なんですかね。

OS と 会話する必要がない/出来ない/そんなこと判るかぁ ってヤツは
一生 VB で満足したまま逝ってよし。
別次元でも、VB プログラマが IIS とかでシステム組んだ日にゃ、
「iMode ってクッキー使えねぇからツカエネェー」なんてほざくんだよ。
Response.Redirect なんてのも多用しすぎ。
RFC の存在くらい知っておけ！！
＃ Response.Transfer の話題は時期早々(突っ込み防止)

76さんの痛い目にあったネタ、きぼんぬ。

なんで、ＶＢとＶＣ間でくだらないこだわりで板ばさみ状態なのに
Ｂｏｒｌａｎｄのを使わないんだ？

ここで挙げられているVBの問題は全部解決するし
ＶＣにはないＶＢの利点は全部継承できるわけだし

GUI開発のためなら、Ｖｉｓｕａｌなんとかっていうのは
一切必要ないんですけど

頭悪いってＭ弗の開発環境"だけ"使っている
君らの事を指すんじゃない？

>>82
なぜこのタイミングで秘密をばらす？
VBを完璧に潰してからでも遅くはあるまい。

>>80 時期早々(突っ込み防止)

時期尚早 「（名・形動）［文］ナリそれを行うにはまだ早過ぎること」
のことか？
日本語くらい知っとけ！ 焼き付け刃！

>>84
「付け焼き刃」だろ？って突っ込んで欲しそうなので書いておこう。

>79-82
自分も79とおんなじことするVB使いだが(Threadはさすがにやらない。というか
知らなかった。今だ”Win32マルチスレッドプログラミング”って本の猿真似)。
DelphiもC++もやれるのでひそかに>>82には賛成する。
じゃなんでVBかって言うと専門学校出たての新人を会社が採用しちゃうから。
VB主体の方が採用後まだ伸びるんよ。専門レベルで凝り固まったのだめね。
これが大卒だとまた違うから不思議だな、どうなってんの。？

最近ふと思ったんだがVBけなすやつって専門以下の学生なんじゃない？
専門て良くわからんが、VBクラスとかC/C++クラスとかあって何か
VBクラスよりC/C++クラスの方が上みたいな感覚があるとか???。
Cクラスのやつが俺ってポインタ判るんだぞやーイみたいにね。
もしそうなら”専門レベルで凝り固まったの”がだめなのもわかるが...。
誰かこの辺教えてくれない？

VBはVCより100倍効率がいいってのはそれほど否定はしないが、
VBでできたものは、VCでできたものより100倍クソ。

プログラマの経験・能力とライブラリなどの資産の蓄積に
よってその倍率は逆転するんでないかい？

それが出来る技術的リーダー・アーキテクトが必要だけど・・・

#最近DelphiがVBに比べ作業効率が3倍程よく、運用効率が6倍程
#高いと実感しています。タコVBプログラマが作ったプログラムが
#あまりにもひどかったもので・・・

>>86
大卒でも専門でもあんまり関係ないんじゃないかな。
大卒でもトンデモなヤツもいるよ。

ところで、この板VB厨房荒らしにこないね。
厨房封じのためage

VB? tcl/tk で全部解決だゴラァ！！

板じゃなかったスレだった。

この人↓
http://www.mitene.or.jp/~sugisita/family/papa/vb/
http://www.mitene.or.jp/~sugisita/family/papa/vb/api_comct.html

VBでオーナードローやらんでも、素直にVCでやったほうが楽では?

　そいえばBASICの「Ｂ」は、ビギナーズの「Ｂ」ですよね。

　しかし、スタンダードインストラクションコードにはなり
ませんでしたね。　私はウイリアム・ゲイツがはじめてＢＡ
ＳＩＣ売ったあたりから使ってますけど（笑）

　ＡｃｔｉｖｅＸがでるまでゲイツはＶＢをＭＳ開発環境の
中核（統合言語）にしたかったみたいですけど、いまはぐち
ゃぐちゃって感じですね。

Beginner's All-purpose Symbolic Instruction Code

Philips Automatic Sequence Caluculator

Philipsって誰やねん

>ところで、この板VB厨房荒らしにこないね。
VB厨房はこのスレでの会話が理解できないので
恐れおののいて書き込み出来ません。

せいぜい、>>92のリンク先でダウンロードして
「どーだ、すげーだろ」と厨房仲間に自慢するだけです。

>>97
アホ。
だいぶ前から登場してたぞ。

ソノシートに入っていた4Kベーシック...
アルテア、パチパチ。
テレタイプ、ガタガタ。

ＶＢいいよ、うんいい、最高
１００倍効率いい。
だからＶＣの１００分の１の金額で受注してね。

>>79
私もそこまでしてVBなんか使いたくないです。
クライアントや上司がVBをご指名してくるんですよ。
VBなら簡単にできるという、おかしな神話を信じている人が多くて。
簡単になんていっても、Windowsの仕組みやインタフェースが
一筋縄ではいかないものなので結局、汚れたコードになるんですよね。
だから最初から汚れ向き言語の方がやりやすいです。

「これ、VBならすぐだよね。じゃあこんなに人月いらないじゃ〜ん」なんて
値切られる理由にされますし。
その点は>>100さんの意見は遠からずというところです。とほほほほ。

VCのIDEでVBコードをデバッグしたのは業務でよくやります。
マルチスレッドの件は実験的にやっただけです。
むかしMSJに「VBでデバッガを作る」という記事があったので、
ちょっと実験しただけです。

>>82
Borlandっていいんですか？
むかしSDKなしでもつくれるよ〜んと言われて
チャレンジしたら裏切られた覚えがあって
（具体的には忘れた。BorlandからMSが悪いというような、
言い訳じみた理由をかえされたことは強烈に覚えている）、
「亜流はダメだね」という結論になってます。（すまん >Borlandファン)

それとDelphiも、昔、Pascalオタクに虐められたトラウマがあってダメです。しくしく。

MFCがもうちょっとマシにオブジェクト指向なら…って思うけど、
みんなそう思ってるからわざわざ書くことでもないか。

ＶＢ...それは安い
ＶＢ...それはガキのおもちゃ
ＶＢ...それはゲイツの（＾¬＾) よだれ〜

>>101
OWLの頃の話かなあ。

　ま、Delphi/C++Bで困ることは、たまーに定義されてないWindowsAPIがあったりするのと
ヘルプがクソなのと、IDEエディタがイマイチヘボいくらいかなあ。

　付属のWindowsAPI日本語ヘルプは助かるけど、アレってMSDNにも入ってるのかな？

　まァ、Delphiは標準PASCALやTPとは別物っつーくらいの仕様なので、トラウマを
克服する意味で使ってみては如何かと。

昔からC+SDKで開発やってた人は、MFCがWIn32APIのラッパーみたいな
感じで好きだという人もいるよ。

関係ないけど、VC++が嫌われる&難しいと言われるのは全てAppWizard
のせいだと思う。あれ使わない方が効率良いし。

VB好きでしたWin3.1の頃

ＶＣちょっと触ったけど、ややこしいからさぁ、俺はこう思った。
「そのうちＣ言語も、アセンブラの後を追っていくかも知れないな、フッ(-_-)F」

>>106
FD 2 枚であれが出来たときはたまげたなぁ。
なにもないウィンドウ１つ作って、resize や iconic して感動した。
今の VB デカ過ぎ。

VBと聞いただけでそのソフトには拒否反応を示します。

>>101
おいおい、自分の目の節穴さを吐露してどうしたいんだ？

それで人のアドバイスを自分の理由不明な思い込みで
覆い尽くして無視して自分自身を納得させたいのかな。

言いか悪いかぐらい自分で判断しろよ。

まあ、M�jの開発者なんて大体の所
よい開発ツールなのか悪い開発ツールなのか
見る目を持ってないから使いつづけて
土壺にはまってるやつが大半（ｗ

Borlandのものを理由があって、否定してVC++を使うやつは
理解できるが、単に無知なだけでVB/VC++を併用して開発してるヤツは
かってに自滅して死んでくれって。

自滅して死んでくれていいんだが、
自分の愚劣さを棚に上げてここで愚痴らないでくれナ(ﾟｗﾟ

おっと、開発ツールにまで
クライアントが口出ししてくるつらい環境だったんよな。

110では厳しい事言い過ぎた
ﾜﾙｶｯﾀ----------------(W

まDel中毒患者の戯言ってことで

>>105
同じこと思ってる。
// TODO: この位置で CREATESTRUCT cs を修正して Window クラスまたはスタイルを
// 修正してください。
こりゃないよなー。オーバーライドさせてよって思うの俺だけ？。これクラス設計がなってないのかな。
Wizardが派生元とサブクラス作ってくれて、サブクラスのソースに必要なメソッド
だけ書けば好いってのはだめ？。派生元を完全に仮想関数にできないからVCの軽さが
なくなるのかな??それにプロジェクトが似たようなソースだらけになるし...。
じゃその分DLLかなんかで外だしして...。ってこれVBって言わない。???

Borlandって迫害されている宗教みたいだね。Macも同じところ有るけど。

迫害というか商売が下手なんだよ。大風呂敷広げることを嫌いすぎる。
IBMも然り。

けどBorlandユーザーはマイノリティーであることに誇りを持つ（藁
ってDOSのころから変わんねェ―
（スマンCP/M80のTPから染まってる奴の戯言なんでsage）

Delphiは好きだしVBも悪くはない。BCBは使ったこと無いからわかんないが
VCLならすぐに飛びついちゃいそう。javaもいい、心売ってWFCにしたってかまわん。
MFCだけやだって言う俺は変？

>>116
M$が作ったＶＣＬなら俺もやだ。

>>112
引用個所はまさに基底のPreCreateWindowをオーバーライドしている所
なんだがな。デフォルトのオーバーライド実装をさらに
変えたいんならソースのココんとこいじってね、というコメントなのだよ。
今となっては大昔に設計されたMFCの古さは否めないが、せめてMFCの
ヘッダなりソースなりを読んで理解してからものを言おうね。

C++とWinMainが相性悪いなっと思って
最初に書いた雛形をいつまでも使い続けて
WinMainを見ないようにしている人間は僕だけですか？

ごめん、よく考えたらここはそんな話題じゃなかった
頭から読んでるうちにVBの話題だということを忘れていた
でも返事聞きたいから残します

ソース読まなきゃならんつうのはまぁいいけど、
MFCの場合あまりにそれが早い段階でやらないといけないのが
つらい。元クラスの実装一通り見ないとだめだし。
そこまでやっても素人目からすりゃちょっと変わった程度にしかならんとか。
C#に移行するのは単にMFC捨てたいからだと思ってるが。

###############################################

ハッキリ言おう

MSはVB使ってないぞ。

###############################################

>>121
甘いな。今MFC#を作ってるに決まってる。

>>118
違うって!!
>デフォルトのオーバーライド実装をさらに
>変えたいんならソースのココんとこいじってね
”ソースのココんとこいじってね”って発想がどうにかしてるって言いたいの!!!!。
ooのどこに”ソースのココんとこいじってね”って発想があるんわけ???
オーバーライド実装って何の為にあるのかなーーーー。勉強しなおしてね。(はあと。

>>122
VB開発チームはVBのツール(APIビュワーなど)でちょこっと使ってます。
あと、Officeの開発チームもアドオンでVBAのコードをちょこっと
書いてます。MS社内では他のスクリプト言語は使用禁止なのかも。(藁

たぶんVCL#になると予想

ヘジルの作ったクラスライブラリなら使いたい。
今はデルラーだけど、C#になら移行するかも。

俺はBorlandが.NET対応を発表したら考える。
その手段が提供されていないならクローズドな仕様
ってことだから俺も手は出さない。

>>112
PreCreateWindowはオーバーライドすることが多いから
勝手にAppWizardがオーバーライドの面倒までみてくれているんだろう。

大概オーバーライドすることになるので
最初からオーバーライドしてあるのは便利だと思った。
便利ならばよし。

何がクローズドだよ（ｗ

BorlandはどちらかというとVCLだけでいいのに
ActiveXにもフル対応してるだろ

.NETも安定してニーズがあれば実装するに決まってる
何のためにMSは.NETの仕様を公開していると思うんだ？

あと、Ｌｉｎｕｘ対応も出来たしね。

>>128
未来の見えないメクラには手を出してくれなくても結構、さようなら

SDKも統合環境ただじゃないだろうし、Windowsでしか
動かなければJava開発者がなだれ込んでくることもなかろう。

>あと、Ｌｉｎｕｘ対応も出来たしね。
何時したっけ？

VB6で開発しています。
全部のフォームに同じボタン（たとえば画面をプリントアウトするボタン）を
つけたいのですが、これって全フォームにせこせことコーディング
しなければいけないのでしょうか？
後々ボタンの絵が変わる可能性もありますし、
ボタンが増える可能性もあります。
VBのプロはどうやってこの問題を解決しているのでしょうか？

>>132
VB6なら悪恥部X根吐露ー琉があるじゃないか。

悪恥部越苦す。

>関係ないけど、VC++が嫌われる&難しいと言われるのは全てAppWizard
>のせいだと思う。あれ使わない方が効率良いし。
激しく同意。はじめてWinのプログラム組んだときにAppWizardの吐いた
コードみて死にそうになったよ。
Win32APIで書いたら大した事は無かった…

>>134
悪くて恥ずかしい部分を苦しんで乗り越えるってことか？

>>132
ＭＤＩフォームを使いなされ。
共通部分はＭＤＩフォームに乗せて、子フォームをとっかえひっかえすれば
いいんじゃよ。

>>130
.NETの仕様はどこで公開されてるんですか？

パッケージソフトや普及しているフリーソフト、シェアウェアの類
でVBで書かれたものなんてほとんどないでしょ？
VBなんて使ってるのはドキュソプログラマしかいないような
ドキュソ会社のデータベース系業務アプリばっかりでしょ？
そういう世界の住人ならVC++なんて知らなくていいんだよ。

つまりドキュソ会社がもっとドキュソなユーザを
食い物にしてる。と言うことでいいですね？

個人的な独断と偏見としては、
・VB
○簡単な作業なら素早い開発が可能。
×少し難しい作業になると途端に面倒。
・VC
○何でもできる。高速。
×MFCの設計があまりすっきりしていない。WTLに移行する気あり？
×非ドキュメントビュー構造アプリが作りにくい。
・BCB
　×プロパティアクセス用に拡張構文がある・・・
　×グローバル変数をばらまきすぎる。

つー感じです。
私は「仕方なく」VCを使っています。

VC＋＋ならまだ分かるが、純粋Cってあんまり使い道がない。

純粋Cてナニ

＞１４３
そんなものも知らないのかおまえは。ここで懺悔しろ。

ナニナニ （・∀・）？
ﾊﾂﾐﾐなの。純粋Ｃ。

ベタCのこと言ってるのかな？
ベタCも方言っぽい気がするけど。

VBからDLLを使うには、Cもいいんじゃない。
DLLメインも要らないし、オーバーヘッドも少ないし。
と、ここに書いても意味ないか?

>>136
のりこえたところで、苦労は報われません。

しかしＶＢって糞な言語だったなー。

>>149
既に過去形かいっ！

え？まだあったの？

ドキュンはVB好きだよなぁ

VB.NETはいままでのVBと全然違うものなんだからおとなしくC#の勉強するのが
正しい選択。クソVBをやらずに良かったと思うよ（藁

C#見てると、ウンコなVBディベロッパを切り捨てても、
Javaの開発者を取り込んだほうがマイクロソフトにも都合が良かった
んだと思う。
VBの生産性に関する話も考えてみればJavaと比べたらそんなに
変わらないと思うしな。
VBしかやってないやつは早いとこC#を覚えて.NETとまではいかなくても
次のバージョンの開発ツールに備えておくのが身のためだ

１は馬鹿決定

>1
VBで何を作るの？それをまず教えてくれ。
VBで早く安く作れるメリット、それを生かせる部分ってもう既に
なくなってきてる。WebアプリのCOMぐらい？それにしたって、
Javaやアプリケーションサーバーっていう代替があるしな。

Officeのマクロ言語でいいんじゃないか？VBの落ち着くところは。
それも代わるかもしれんがな（藁

まず、VBがマイクロソフトと共にあるものだってことを忘れるな。
彼らの戦略次第でどうにでもなるもの、へたしたら直ぐにチョン
になるものだってことだよ。
そのためにもVBオンリーで仕事をする(それも消極的な意味で)なんて
のはやめた方がイイ。絶対に。

あぎょ

>>157
あぎょ？

>>157
笑

>>157
あぎょかいな。
新しいね。

つうか・・・VBで処理速度が足りない部分をDLLで実装って
マヌケだよな。

VBか……Windowsだけで満足できるならそれもいいかもね。
VCか……なんて下手な設計してやがる。

なんか、もっとまともなやつで組みたいな。JavaかRubyかSmalltalk。

オレはMIXED LANG（画面周りをVB+クリティカルな部分をC/C++）
で開発するって奴を見ると、心底ブァカなんじゃないかと思う。
VCならCFormViewでいいじゃん。

>>163
その時の最適な組み合わせでやりゃーいいんじゃねーの。

>>163
CFormView で自分の思い通りに作れないんだよ。
CreateWindowで作らしてくれれば良いんだけどよ。
所詮そんな時間はねーってことだ。

>>165
同感。
＃世の中には、納期を圧縮しないとペイしない仕事があるんだよ。

>>163
VBしか氏らんヤツと組む時はしょうがないと思ふ。。。
そう打算でやるしかないのです。仕様がないです。仕様がないです。

VBができると思っているやつでFormとかコントロールのイベントに
ガリガリ処理書いているやつはたぶんだめ。
画面から値取得と処理系をきっちり分離できればそこそこいける。
COMとか使わないならVBでもそこそこいけるはず。
特にデータベース関連はVBのほうが工数は少なくてすむ・・と思う。

>165
思い通りに作れないとかCreateWindow()でやらせて
くれればとかアナタ全然わかってませんね。
ボタン並んでるだけのヘタレなメニュー画面に思い通りも
何もないと思いますが。

169続き

あーそれからわざわざ複数言語で書く、ということが
馬鹿げているということであって、VBで事足りる案件なら
VBでやればよい、ということですので誤解なきよう。
つーか本当に納期圧縮できる？画面部ならどっちで
書いても大差ないと思うんだけど。
素のDLLにしたときのインターフェース定義だとか
それが嫌でDLLをACTIVE-X化する場合の手間とか
双方の結合時の型チェックが甘くなるとか
ネガティブ要素しか思いつかない。

95%がVBのコードで、残り5%程度の大量ローカルファイルI/O
（CSV出力）とかの部分だけ切り出すんならわからないでもない。
メソッドもプロパティも数個で済みそうなレベル。
でも画面はVB、内部処理はDLLでっていう大胆な設計方針を
持ち出す人にはそろそろ死んでもらいたい今日この頃。

ＶＢはＶＣの１/１００しか細かいことはできない。
まあ、作って１本だけ売れる適用業務アプリ専用言語だね。
はっきり言うとエンドユーザー向けの開発言語もどき。
何か異論ある？

でもおれＶＢしか出来ないからＶＢで良いや。

>>172
異論はないけど、それがどうしたの。

>>169
へ？
その程度の画面で良いの？
な〜んだ。
じゃあ、別にC ビルダー or MFC で十分ですね。

それに、そんな物を無理矢理他の言語とくっつけて作ろうとする
バランス感覚のなさが問題って事か。

馬鹿だから読違えちゃったかも　すまぬ　鬱だ

ＶＢ単体でも不安定なのに多言語と組み合わせる、なんて度胸要るよね。

パッケージ系に関して言えばVBなんぞまず使用されません。
遅いし、ヘボ画面しか作れんし。

VBしか知らんやつは、事あるごとに「VBみたいに…」「VBだったら…」
などと抜かすので即死んでもらいたいです。

混合言語の話だったのに、いつの間にかVB叩きに変わってるな(w

>>176
EXE 二個作って。
実処理は全部VCで作りました。
VBは、画面を表示するだけ。
張子の虎状態だった。
んで、VBは落ちるけど、VCの方は問題なく動いてるから
業務に差支えなかった ...

まあ、多言語とは言わないかな　このレベルじゃあ。
メモリマップとかメッセージで同期取ったりしてました。

実験用のCGIをVBで作ろうとしたけど
一日調べてあきらめました。不可能ではないようですが・・・
VCにしました。VCは普段つかわないので使い方を
思い出すのに苦労しました。

VBってさコマンドラインのプログラムかけるの？

VBってうんこ

この間、面接で「VB出来ますか？」って聞かれた。
で、「VBってプログラムなんですか？」って質問した。
すると、技術担当が「VBは違うよね、ゴメソ」って答えた。

大手制御系プログラム開発メーカーにて・・・

＞181
できるよ！

>>180
VBでCGIやるならとりあえず標準出力用のクラスを作っとくだけで多少はラクになる。

　まぁ、確かにVBで書くと簡単なものはサクッと出来上がるのだが、
プログラミング言語とはいろんな意味（記述能力、処理速度等）で
認めたくはない…
　プロトタイプ用ツールとしては認めてはあげますが…(藁

>>180
　正気とは思えませんが、VBでCGIとは…

＞パッケージ系に関して言えばVBなんぞまず使用されません。
＞遅いし、ヘボ画面しか作れんし。
国が作ってるパッケージには、メンテのしやすさを考慮して
VBで作ってあものがありますよ。具体名は言えませんが。
言わなくてもわかりますよね？

結論。VBは、「ダメ」。

プラントの制御とかはVBなどもってのほかですが、
事務処理だったらVBで十分でしょう。事務処理レベル
であればAPI使えば結構なこと出来ますし。

VBを頭から否定する人は何を使ってもダメな奴だと思
うのだが。開発にはC・C++、内部事務処理はVBを使ってい
るようです。

アセンブラを頭から否定する人は何を使ってもダメな奴だと思
うのだが。

特定の事務処理分野で大いに頑張ってください。>VBプログラマ

C/C++プログラマは特定以外の事務処理分野とそれ以外の
大多数の分野で大いに頑張っていきたいと思います！

＞191
まったく、ソノとおり。

＞192
そうです。VBは汎用機のCOBOLプログラマが乗り換えるのに
最適ですよ。

言語なんてしょせん道具なのに。。。
道具は使う人の腕次第。

良い職人は道具を選ぶという話もあるが。

>>195
同感。
＃良い職人は、悪い道具でも何とかするもんです。

悪い道具(VB)にかまってる間に、良い道具を使ってる
連中に大きく引き離されるぞ。

競争社会に通じる話ではないな。

>>197
客先の指定で、悪い道具を使わざるを得ない事もあるんだよ。
＃メンテナンスが出来ないとかな。

>>198
そういう風にVBしてきた客が、納品後のメンテナンスを自分自身で
やるケースはあいにく見たことがない。

>>198
客先の指定、、、って憂鬱だね。
営業が積極的にVBの仕事を探し回ってるとしたら、
やっぱり会社はジワジワと沈んでいくだろうなぁ。

間違い訂正。
×VBしてきた客が
○VBを指定してきた客が

>>199
VBを指定するほどに訳けが分かってないわけだから、
自分でメンテするわけ無いじゃん。
そもそも、VBのソースを自分でメンテするといっている場合は、
他の会社に投げるって言う意味だし。

とりあえず、ＶＢで作ると安く上がるってのがねー。
やる気が起きないと言うか、なんというか。
でも、自分用のツールを作るのは便利だけどね。まじで --;

>>202
かくして不幸の環は広がるわけか。
※つーか荷担すんな。いい加減。

１９８です。
>>199
うん、それは認める。
＃でも、最初から「良い道具」を使わせてくれる場合は、ほとんど
＃ないな．．．残念ながら。

>>200
＞やっぱり会社はジワジワと沈んでいくだろうなぁ。
それどころか、Ｎ８８ＢＡＳＩＣおんり〜で食ってる会社も
知ってるぞ．．．もちろんジワジワ沈んでるんだが、まだ倒
産はしてないらしい．．．。

>202
決め付け君はうざいんだよね(w

アロエリーナにちくったのお前だな？
アロエリーナにちくったのお前だな？

>>207
さりげないダメージを与えてないので不可です。

って怒られるよ(w

>>1
VC使える人間が効率化を考えるならBCBを選ぶでしょう。

C#が出てからならそちらを選ぶでしょう。以上。

いつまでも言語の奴隷になってな。
言語を使いこなすよりも言語を作れよ、ばかたれが。
Cがどうの、C++が、VBがどうのなんて志が低く過ぎる。
おまえら逝ってヨシ。どうせバカなんだから。
そういうｵﾏｴは何様かって？余計なお世話だよ。
バカは疑問を持たずに言語を使ってシコシコ仕事してりゃ
いいの。うひひひひひひひひひひ。
野球の評論家とたいしてかわらんな。（藁

４月バカだよ。少しキツイかったかい？

>>210&211
このスレの中ではおまえが最も低能に見える。

＞キツイかったかい？
その文章の乱れ方も、エイプリルフールだから？

>>211 キツイかったかい？
変換ミスならともかく、タイプミスだもんな。
お前の組んだプログラムってバグバグ？（藁

２１０だ。
ほんとだ。頭が疲ているとミスが多くなるな。自分でも
笑ってしまったよ。
ささいなことでも指摘してくれると脳にイイ刺激になる。
お前らもガンバレ。んじゃよ。

>>215
じゃ、ついでに指摘(w

>頭が疲ていると
頭が疲れていると

>>196
どんな職人だ、そりゃ。
職人は客先に行っても自分の道具を持ってくだろ、普通。
大工が家の改装頼まれて、そこんちの日曜大工道具セット使うか?

# 喩がわりいよ。

高級言語に文句を言ってるなら、素直にアセンブラ使いなさい。
処理速度が遅いだの、機能がどうだの言わないでいいでしょ。

「弘法、筆を選ばず」ってのは、優れた人は、良い筆が無ければ無いで、
それなりの物を書くことが出来るってこと。
どれでもいいから使える状況なら、一番適した道具を使うのが当然。
どれを使えば良いのかを的確に判断出来るってのも優れていればこそ。
野球のイチローなんかは恐らく、どんなバットででも其れなりの結果は
残せるだろう、しかし、彼の道具に対する拘りは半端じゃない、それは
道具の良し悪しが、どれほど結果に影響するのかを知り尽くしてるから
でしょう。
プログラマーとして使用言語に拘りをもたないというのは、恥じる事は
あっても自慢する事ではないと思う。
別にVBで書く事が悪いと言ってるんではなくて、VBが最高の選択である
のならばVBで作るべきだし、VCで作るのが良いのであればVCで作るべき
ということ、要は目的に照らした積極的な採用であれば良いと思う。

>一番適した道具を使うのが当然。
で、それを考慮してWindowsでDelphiしか使わない
俺は逝ってよしですか？

>>220
　全ての状況で、自分が一番使いやすい物がデルファイなら、
それで問題ないと思うよ。
　僕は状況によって、色々変えちゃうけどね。

　色々と他の開発言語を使わずにデルファイ最高って
言ってるだけじゃぁ駄目なんでしょうけど。
　（たぶん、大丈夫そう

>>220
それってさ、問題に一番適した道具じゃなくて、
ただおまえに適した道具なだけだろ？
だから、逝ってよし！

Delphiしか使ってないのならもっと使い込んでやれ。
少なくともヘルプは全部目を通せ。

VCLソースもTObject,TComponent,TWinControlなど
主要な所は目を通しとけ。

>>217
道具を選べない状態でも、一定の結果を出す必要がある仕事じゃない
のかい？＞我々の仕事は。
＃もちろん、客先の希望や要望を無視して「自分の道具」のみを使え
＃る立場の人もいるだろうけどね。

ｵﾚは逝ってよしなのか、大丈夫そうなのか、どっちかなあ。（ｗ

>Delphiしか使ってないのならもっと使い込んでやれ。
>少なくともヘルプは全部目を通せ。

ヘルプは全部目は通ってるかも。

>VCLソースもTObject,TComponent,TWinControlなど
>主要な所は目を通しとけ。

全部目を通せるくらいにはなってないなあ。
そこまで上級者には成れそうにもないよ。

> 道具を選べない状態でも、一定の結果を出す必要がある仕事じゃない
> のかい？＞我々の仕事は。
> ＃もちろん、客先の希望や要望を無視して「自分の道具」のみを使え
> ＃る立場の人もいるだろうけどね。

自分の道具を使える立場を作っていくのが
戦略ってものじゃないかな。

たいそうなことはいえないが

単なる簡単な業務アプリを作るのに
わざわざ指定がVBってのなら、
どうせ、ひどい仕事なんだろうから受ける必要も無いし。
(って思いません？VC使いの人？)
受けなくても生きてける状況を作るのは大切じゃない？

共同開発でC++の時とかデルファイで出来ない事を
やる必要がある時は、もちろんやり方を変えるよ。

戦略こそが最重要とも思わないけど、
そこそこは重要かなとは思う。

ｵﾚ頭固すぎるかな。BCBは使えるよ。標準Cなんかには準拠しないけど。

ところで、VBやVCの人もmonazillaにきてくださいな.（ｗ
http://www.geocities.co.jp/SiliconValley-Oakland/9028/

＞自分の道具を使える立場を作っていくのが
＞戦略ってものじゃないかな。
自分で、自分の仕事内容を全て決定できる立場なら、戦略的に話を
する事も可能だけど、会社員の場合は難しいんじゃないの？
＃このご時世で、営業が苦労して取ってきた仕事を「ＶＢ？、アホ
＃か」の一言で蹴れる人なら、ＯＫかも知れないけど。

いや、そもそも、どうして営業の人間が
つまり技術のことに通じていない人が
開発ツールの選定から行なってそれで仕事を取るわけです？
客や営業は出来ることが出来たらいいだけで
開発ツールは関係ないっすよね？

仕事とってきて、技術的な打ち合わせは営業やSEと
密に取る必要があるわけで、
その際に、「このやり方じゃ効率悪いのでこっちにします」
とか技術者として言わなければいけない場面は多々ありますが

それの一つとして「開発ツールがこれだと
こういうデメリットメリットがあるからこっちをお勧めします」
ってやり方で客なり営業ナリに納得してもらわなければ
仕事自体全く機能しなくないです？

>自分で、自分の仕事内容を全て決定できる立場なら、戦略的に話を
>する事も可能だけど、会社員の場合は難しいんじゃないの？
自分の仕事をある程度決定できないと
仕事自体が効率悪すぎないっすか？

とはいえ、VBの引継ぎ仕事なんかだと
VBでやるしかないって状況はわかってます。
そこを無理してデルファイでやったりなんかはしませんよ。

こんなこと言うと、仕事がなくなるのかなあ。この業界。(´Д｀)

ま、現実世界の生き残り論はおいといて、ＶＢは仕様的にクズ。
それで作られたプログラムもクズ。
だから、やっつけのクズプロジェクトにはＶＢがお似合い。

>>224
職人的な仕事ではあるが、道具と職人(大工とか)の関係に
例えるのは折れらの現実とズれてるだろって点だけなのよ。
折れが言いたかったのは。

自分の道具を持ち込める大工がうらやましいわ、つーか。
大工は大工で「2x4なんざやってられっかい」なんて
思ってるかも知んないけどさ。

age

やっつけのクズでも俺ならVBは嫌だな。

適材適所の話。テキストファイルをごりごり処理するような奴だと
最近はruby使うなぁ俺。
あとDBはdelphi天下って話はあるが、rubyも結構ヨイんじゃないかと
最近思ってる。RDBの相手をするのは型のない言語のほうがヨイような気が。
まぁドライバとかの環境がまだまだ(窓だと特に)なんで
いまのところ思っているだけだけど。

GUIは今のところ(=最大瞬間風速)、delphiでキマリでしょ。
API使わなくても(笑)やれることの範囲が
高度だったり高速だったりするんで。

あとさ、契約形態でも変わんない？

俺、フリーのＰＧなんだけど、
ジョブ受け持ちかえりＯＫなＶＢの案件を複数やってるけど
結構おいしい。あと、個人的に客んとこの保守なんかやってる
けど小遣い稼ぎには抜群だね。
逆に、出向で時間拘束される場合はVC or JAVAでお願いって感じかな。

ＶＢ技術者ってのは世の中に余りまくってるから開発メンバー揃えるのは楽だね。（ｗ

>>233
ふーん？そういうもんなんか。
まぁ言語を問わず、客はそのソースを自分で維持
しきれなくなったら、こっちに投げてくるわけだからして(笑)。

というわけで先日(つーか1年かかったが(笑))、
投げられたVCの仕事をやっていたりした。
＃C++にヘタに染まった似非OOPなソースだったよ(T_T)


お。帰省したら実家にKylix優待の手紙が来てたぜ。わーい。

>>235
ま、フリーとプロパーのＰＧだと立場と環境が違うからね。

フリーの場合、効率って言うのも重要なんだけどそれほど
気にしていない＞俺の場合ね。

どっちか言うと、クソ案件でもマルチタスクで他の仕事が
できる状態だったらＯＫ。

まだこんなことやってるの？
「VB要らない」でみんなあきたんじゃないの？

けっこう楽しんでたんじゃないのかな・

もう、飽きた

じゃあ、そろそろ2chから卒業しようや。

ああっ、はああん…、ご、ご主人様、申し訳ございません････。我慢できなかったんです。はああ、いいいっ！！お尻の穴･････気持ちいい･････」
右手は前からクリトリスを摘み上げ、後ろに回した左手は可愛らしく息づくピンクの肛門を弄り回していた。
「はああ････出ます、皆様に見て頂きたくて４日間も溜めていました･････。あうんっ、あふうっ、はあっ、出ます、出るっ、ウ、ウンコ、ウンコが、ああっ！！」
ごぎゅるるるううっ！！ごろろっ！ぐりゅぐりゅうっ、ぐりゅ、ぐりゅうっ。
ごろぐろろっ！！ ひときわ下品な音が下腹部から発せられると、恍惚とした表情で涎を垂らしながら、喘ぎだした。
「いひあああっ！蟲がああぁ！！暴れてるうっ！わたしの中で、おおおおっ、うおうっ、き、気持ちいいいっ！！駄目っ、もうっ！！ウンコ、ウンコ、見て、ウンコ、いっぱい見て下さいいっ、あおおおおおっっ！！！」
ぶぼぶぶうううっ！！ ぶふううっ！！びぶりぶりぶりぶびいっ！！ぶふり、むりむりむりむりっ、ぶひ、ぶびびっ！！ぷふううっ、ぶじゅび、じゅびじゅびじゅびっ、じゅじょろろろっ、ぶりぶびびびぃっ！！
ピンクの肛門がぱっくりとその口を開くと、部屋中にオナラの音を響かせ、極太の便塊がまるで生き物のように、その身をうねらせながら這い出てくる。
時々ドロドロに腐った軟便が悪臭を放ちながらブチュブチュとひり出される。
「はひっ、はひいっ、気持ちいいっ、ウンコ気持ちいいっ！！いっぱい、いっぱい出ちゃうっ！！やああん、止まらないよぉ、御主人さまぁ、見てぇ、もっと、もっと見てぇ！！御主人さまぁ！！イッちゃいますぅっ！！あおおおっ、イクウッ、う、ウンコ、ウンコでイキますうっ！！」
じょろっ、じょぼぼっ、じょおおおおおおおーーーーーっじょぼぼぼぼ、びちゅっ、びじゃびじゃびじゃっ！！
大量の大便を放出しながら絶頂を迎えた。 脱糞と露出の快楽に、全身をぶるぶると震わせるとそのまま放尿する。
小便は放物線を描くと、撒き散らされた大便の海に降りかかり、液状の大便と混ざり合い、溶け合っていく。
「きゃああああっ！！あああああっ、うううっ、あああん！んああっ！！ご、御主人さまぁ！！い、いたいっ、あんっ、ああんっ、はあん･･････ぷはああっ････。美味しいです･･･おチンポ舐めるの大好きです。お願いします。お口でもおマンコでもお尻の穴でも、どこでもいいからおチンポ入れて、いっぱい射精して下さい。濃い精液が大好きなんです。お願いしますぅ、早く中に吐き出して下さい…。」
ずぶぶぶぶっ！！じゅぶっ、ずちゅちゅうっ！！ ずっ、ずっ、ぐりゅ、じゅるるる！！じょぶっ、ずぼっ！！
きゃふううっっ！！チンポおっきい！！マンコ、もっと、もっといっぱいにして！！こね回して下さい！！いいのぉ、すごくいいのぉ、グチャグチャにかき回されてぅ！んおおおっ、もっとぉ、もっとぉっ！！」
ぶちゅちゅううっ！！じゅちゅ、ずるずるずるっ！ぶじゅぶじゅぶじゅっ！！じょぶっ、ぐじゅっ、ずぶぶぶちゅっ！！
ひぎいいい！！ちんぽが、お尻犯してるぅ！！！ウンコまみれのおケツ、チンポでほじくられてるのぉ！！あひいっ、ほおおおぅっ！！もっとぉ、ウンコと精液でお腹の中いっぱいにしてぇ！！はひっ、かふううっ！おマンコとおケツのチンポが中で擦れ合ってるのぉ！！いいのぉ、ちんぽいいのおぉ！！うひいいいいっ！！」
どぴゅうっ！！ぶぴゅううっ！じゅぶっ、ぶりゅりゅりゅりゅ！！どくんっどくんっ、ぼぴゅ！ぶぴゅ、どぷ

なんていうのかな、VBにはプログラミングする楽しみが無いよ。
もぐら叩き作るのにはいいかもしれないけど。

【かちゅ〜しゃHP】
http://yasai.2ch.net/test/read.cgi?bbs=win&key=992356600

【お約束】
・質問する時は過去ログ、【FAQ】を確かめてからにしてね。
・板が�d�jときの書き込みは控えてね。
・罵り合いはやめてちょ！

http://yasai.2ch.net/test/read.cgi?bbs=win&key=993179444
【参考リンク】は>>2
【FAQ】は>>3

VBは他と比べて簡単すぎなので、VBで作られたアプリケーションとかにはあんまり金を払いたくないな。
VBだけしか知らない人って、OSとかの知識が無さそうなので、発注したくないです。
そんな生半可なアプリケーション使いたくない。

防止sage

業務アプリでは、生産性と開発効率が受けてCよりVBの方が多くなってきている。
ただ、VBが簡単すぎてソースが最低なヤツも多い。
まあ、Cでもひどいやつはひどいが...
VBしか知らないやつでも、クラスモジュールを中心とするオブジェクト指向プログラミングが
できれば発注しても良いと思う。
プロパティやメソッドを実装できないやつは逝ってよし。
次期VisualStudio.Netで、どのくらいVBユーザーがついてこれるか楽しみだ。

>プロパティやメソッドを実装できないやつは逝ってよし。
さすがにこれは、、、こんな奴いるの？

>VBしか知らないやつでも、クラスモジュールを中心とするオブジェクト指向プログラミングが
>できれば発注しても良いと思う。

言語をひとつしか知らないヤツって、たいてい勉強不足だから、
VBしか知らなくてしっかりしたプログラムを組めるヤツって
すげー少ないと思う。

ＶＢもＶＣもケースバイケースってことで。
ま、俺はＶＢつかったことないけど

ＶＣは一応Ｃ＋＋だから他のプラットフォームと互換性は有ってほしいよな。
ＶＢはWindows用の言語って事で良いけどよ。
ＶＣはダイアログとかがトリッキーすぎる。

クライアントユーザーやエンドユーザー向けのソフト使ってたら、
「技術的に」何を使っているかは、全然聞かれないことが多いけどな。

それよりも、テクニカル・サポートを充実しろ！
と言う、要望の方が高いな。

パソコンショップでも、低価格も重要だが、多少割高でも、
初期設定する所に人気がある。
まぁ、大半が選択制だがな

>>250
脳足りんは帰って、もっと勉強してください。
アホの相手は疲れるんで。

>>250
他のプラットフォームとの互換性なんて作れるわけねーだろ。
LinuxのGUIを利用して作ったプログラムがMacと互換性あるんか？
だからVBしかできない奴はって馬鹿にされるんだよ。

>さすがにこれは、、、こんな奴いるの？
いるんだなこれが...オール標準モジュールなやつ
某外注に頼んだらひどいプログラムだった。それでうん百万!!
みなさんも、外注に頼む時は気をつけましょう。

ちょっとフォロー
VBのプログラマ人口ってやっぱ多いから、MFCより全然優秀なクラスなどを作ったりする
優秀な人も多いです。
自分も結構VB5からは認めてるし...

>>254
意味不明です。VBプログラマ人口が多いのと、MFCより優秀な
クラスの作成のつながりがわかりませんが？

>>254
何がいいたいかわからんが、MFCはAPI関数をラップしてるだけなんだから
windowsと他のosが同じ名前の同じ機能の関数を提供しない限り、
互換性なんてもてるはずが無い。だれかが同じ名前の関数で
ラップしない限り。でもそんなの無駄でバカなことだろーが。

マシンも速くなってきた事だしJavaでSwingやろうよ(´ｰ`)y-~~

>>257
JBuilderを起動するといきなり100MBメモリを持っていかれる
あれを見てJava＠クライアントサイドは無謀だと思った
動作もなんかもっさりしてるし

　

うちは768MBほど積んでるので100Mなんて屁でもないよ(´ｰ`)y-~~

>>260
一般ユーザー向けマシンのデフォのメモリが64MBぐらいなんだから
100MBも持っていかれたら売り物にならん。

>>260
俺は１２８MBだぞ、ごらー
そんなもん動かしたくねーzおー

Java VM はＯＳのエミュレータみたいなものだから、ＯＳから確保した
量と実際に使っている量は別だよ。仮想メモリ 100MB は分かったけど
物理メモリはどれほど消費してるもんよ？ 95MB はスワップアウトされ
てるかもしれないだろ。

>>263
いつかスワップインされるんだから結局一緒
だいたい起動時に95MBもスワップアウトしてたらその時間がでかい
Javaはサーバサイドではいいんだけどね
PCのクライアントサイドはやっぱ辛いよ

スワップっていわれるとたっちゃうじゃないかよ・。

なんかビンボ臭いが集まってきちゃったな(;´ｰ`)y-~~

↑ビンボ臭い奴ら

今見てる案件はＶＢだけど…
下請けの下請けくらいなんだけどさ、（ﾜﾗ
よくこんなのを…っていうくらい、UI痛いよ。

でもま、これで食えるなら良いか、ってかんじだな。
俺がこのソフト使う訳じゃないし。
仕様が腐ってても、俺が設計したんじゃないし。

効率はいいかもしれないが、設計は腐る、に１０００VB。