| スレッド |
＞そうなんですが、VCLってマルチスレッド非対応でしたよね？
＞複数のTThread派生クラスから、フォーム上のコントロールとかを
＞アクセスするときにとても面倒でパラメータすら渡せなかったような
＞記憶があるのですが。今どうなってるのは知りませんが。
私の場合は標準のスレッド用のクラスは使いません。
APIでスレッドを作成した後、クラスのポインタを引数に渡し、
クラスポインタからメンバ関数をコールバックさせます。
あとは好き勝手に動けます。
MFC,VCL両方可能です。ただし動作は保証されません。
自分できちんと同期をとらないと危険です。
| あ〜たしかに |
>そうなんですが、VCLってマルチスレッド非対応でしたよね？
ええ、そういえば非対応でっせ。
内部的な動作の一部では対応してますが
フォームへのアクセスなどは CriticalSection とか
Synchronize とか使わないとかな〜りやばいことになりますね。
マルチスレッド化して欲しいものですが
なんか Object Pascal が言語レベルでサポートしてしまいそうな
雰囲気がありまっせ。
>ツール選定の決定権を持つ人が「C++なんだからなんでもできるはず」とかいう
>勝手な思いこみを持っていて、なおかつVC++拒否症だったりすると、大規模な
>ロジェクトを頓挫させかねません。
まぁ会社とかだと VC++ のほうをまず「使う」と言い出すでしょうね
一応 OS メーカの純正品だし。
BCB 率先して使っているなんてのは「崖からダイヴ」と見られますね。
まぁなんでもかんでも VC++ というのも困りもので
BCB が大きな「競争」相手になってくれればいいものだが
まだ力およばず。BCB4 がどうなるか。
でも やっぱりヲレは MFC には戻れない。
BCB ではできなくて VC++ がないとできないって何があるかな
BCB でも MFCもATLもサポートされたし
・・・・？
IDL も(たしか)コンパイルできるしリソースもコンパイルできるし
足りないのは M$ のサイトから落としてくればいいし
VC++ 特有の IDE 補助がなくなるのか。
まぁでも VC++ の使用はアンチM$派のヲレにはすこ〜し
耐えられん。すぐメモリ不足になるし。
アンチM$派とはいっても必要に駆られて Windows アプリ作
ってるが。
| 同じく |
非常にためになるので続けて欲しいです。
| すげぇ（笑） |
ＣＪ告発掲示板は無くなってもこの掲示板は存続して貰いたい（笑
| RE:M$のライセンス |
おしい、おしいよダンナ。
最近、MSDN_LIBのVC6版を見る機会があったので、みてみました。
VC6 STD コード配布権 ○(New!)
なんか新鮮でしたねぇ（笑
VS97時代は、VB/VCともにコードは再配布「不可」ですよん（だからどうした）
VCでもヘッポコアプリ作ってる方は多いですよぉ。たとえば某テキスト文書ソートツール。
DOS人間ならこんな１行入力したことあるわねぇ。
type hoge.txt | sort > hoge2.txt
20MB程度のテキストでもK6-233で１分くらいで処理してくれる。（実験値）
で、これより「ヘッポコ」なDialog Based のテキストソータが500円。
＃2MBでも同環境で5分以上かかってた。
| そうなんです |
＞まぁ実際 BCB だけじゃできないことがかなりあるので VC++ は
＞持って使えるようにしとかなきゃならんが。
こう思ってる人が多ければいいんですけどね。
ツール選定の決定権を持つ人が「C++なんだからなんでもできるはず」とかいう
勝手な思いこみを持っていて、なおかつVC++拒否症だったりすると、大規模な
プロジェクトを頓挫させかねません。
ので、正しい認識を持って、目的に合わせて選定できるなら何使ってもいいと
思うのであります。
＞TThread の派生クラス書いてインスタンス化するだけっす。
＞MFC の CThread とほとんど機能は一緒ですが
＞プロパティの類が整備されておりまする。
そうなんですが、VCLってマルチスレッド非対応でしたよね？
複数のTThread派生クラスから、フォーム上のコントロールとかを
アクセスするときにとても面倒でパラメータすら渡せなかったような
記憶があるのですが。今どうなってるのは知りませんが。
| M$のライセンス |
話のスレッドを少し乱しますが、ログの最初から読んでてVBとVCの
ライセンスについて、疑問に思ったのでカキコします。
僕は、Borland派なのでM$製の言語製品は持ってませんが、友達が
持っているVB,VC(ともにVer.5のLeaning Edition)のライセンス
を読むと、
VC…作成したプログラムの販売不可
VB…特に記載無し
となっていたように思います。なんか、これ間違っていると思いま
せんか？逆だと思うのですが...。
確かに、ここの掲示板のカキコにもあったように、VBはちょっとし
た小物やコンバータを作るには有効だと思いますが、特にLeaning
Editionは学習が目的ですし、これで本格的なアプリケーションを
作成されても処理速度の面などで問題があるので、こっちを「作成
したプログラムの販売不可」にすべきだと思います。そうすれば、
VB製粗悪シェアウェアは減ると思います。
能率などの面でVBを使って商用アプリケーションを開発している
企業等は当然ProfessionalかEnterprise Editionを持っている
と思いますし...。
逆に、VCの方はとりあえず１通りC言語を習得しなければならな
く、ある程度の技量は必要になるので別にシェアウェアを作って
もいいと思うのですが。
| たしかにねぇ |
>そうそう、VC++だと、IDEがアドオンのインターフェース
>を提供してるのでRADツールに匹敵するようなサードパーティ
>のウィザードやBoundsCheckerのような拡張デバッガ、CASE
>ツールまで統合できたりします。
BCB とか Delphi とかも拡張性に関してはなかなかのもので
アドインもたくさんありまっせ。
IDE 上で Susie-plugin を使って画像読み込み
なんてのとか。
だいたいがコンポーネント自体がアドインみたいなもので
IDE と同じプロセス上で
実行時に取り外したり付けたりしてまっせ。
VCL でアドインを書いて、IDE も VCL で動いている以上
かな〜りイカレたアドインもあるようです。
しかも書くのは以外と簡単。
>初期投資さえ惜しまなければ総じて生産性・保守性の面で有利
>だと思っています。
保守性の面では VC++ の方が数段上を言っているとは思うが
生産性の面ではどうだか。
大規模アプリケーションは VC++ の方が作りやすいかもしれな
いですがそれは「生産性」よりも「保守性」のおかげでっせ。
あと、人によりますが、VC++はお世辞にもなじみやすいとは思えません。
いままで VC++ 使って悩んでいた人が BCB を手にしたら
ポコポコとアプリを作り出したってのはかなり目にしていまする。
まぁ実際 BCB だけじゃできないことがかなりあるので VC++ は
持って使えるようにしとかなきゃならんが。
>＃ただ、マルチスレッドアプリケーションを書くのが
>＃まず大変だったりするけど＞BCB
TThread の派生クラス書いてインスタンス化するだけっす。
MFC の CThread とほとんど機能は一緒ですが
プロパティの類が整備されておりまする。
>これこれ。これは大変便利だと思いました。
>マルチスレッドとかでメンバ変数へのアクセスに排他
>制御が必要な場合でも外からは「=」だけでアクセス
>できるように見えるのはいいと思いました。
VC++ のバージョン何だったかは忘れましたが
Microsoft のコンパイラにはすでに同様の
機能が付いていまする。
ただし MFC 等での利用は見られませんぜ。
可搬性は失われるとしても便利ならば使いたいものです。
| そういえば |
ライブラリの中までステップインしたらPascalコードが出てきて
驚いたことがあったっけ(笑)
＞__property によるメンバのアクセス制限とかは
＞使うとクラスの動作を明確にできるので
＞楽ですぜ。
これこれ。これは大変便利だと思いました。
マルチスレッドとかでメンバ変数へのアクセスに排他
制御が必要な場合でも外からは「=」だけでアクセス
できるように見えるのはいいと思いました。
＃ただ、マルチスレッドアプリケーションを書くのが
＃まず大変だったりするけど＞BCB
＞ちなみに Windows メッセージへの応答マクロは
＞言語拡張のためにああいう形になったわけではなく
＞本質的には MFC のそれとかわりませんぜ。
本質的にはそうなんですが、ヘッダに変なマクロ埋め込
まなきゃイカンというのが個人的にイヤなだけで。
MFCのMESSAGE_MAPマクロは、ウィザードの吐いたコード
から書式を類推しやすいですよね。
そうそう、VC++だと、IDEがアドオンのインターフェース
を提供してるのでRADツールに匹敵するようなサードパーティ
のウィザードやBoundsCheckerのような拡張デバッガ、CASE
ツールまで統合できたりします。
初期投資さえ惜しまなければ総じて生産性・保守性の面で有利
だと思っています。
＃要は目的によって使い分ければいいだけなんですけどね
| コンポ |
> ではそのコンポーネントはどうやって書くの？
> というと、ほとんどがDelphiで書かれてるわけですよね。
そうっすね、80% ぐらいが Pascal でありまする。
Pascal でかかれていても前述の通り BCB には Pascal コンパイラが
付いてきているのでソースがあればたいていはつかえまっせ。
C++ でもかけますが Delphi で使えなくなってしまうんじゃ
なかったかと思います。
| DelphiとC++Builderの違い |
インプライズさんは、Delphiを「Pascalで自己記述した」開発系として販売しました。
C++Builderは、DelphiにC++の言語解析と、MFC/OWLのライブラリをつけたものと考えてOKです。
派手なオンラインウェアを作るのに役立つサイト：
Ｍ＄系なら http://www.codeguru.com/
ボーランド人なら http://www.torry.ru/
こゆことを書いていけば某せあ協会に匹敵するBBSになりますよね多分。
| うむぅ |
# この話題だけしていていいのか(笑)
>しかも言語拡張がアレなモンだから、マクロが意味不明。
言語拡張は、まだまだ 使いやすい方向へ
拡張されたとおもいまする。
__property によるメンバのアクセス制限とかは
使うとクラスの動作を明確にできるので
楽ですぜ。
あとは RTTI を効果的に使っていたり try ... catch による
エラー処理を一貫して使っていたり。
ちなみに Windows メッセージへの応答マクロは
言語拡張のためにああいう形になったわけではなく
本質的には MFC のそれとかわりませんぜ。
>ただ、BCB上でのVCLについてあれこれ書くと、決まって反MFC派は「Delphiなら…」
>とか「Delphiの方が…」等と言い出すもので、「じゃあBCBのレゾンデートルは？
>自己完結してないの？」といいたくなってしまうわけであります。
流石に Delphi のライブラリを使っているだけあって
自己完結できないようです。
それでも Pascal を使わずに C++ で書くのは
「Pascal をかけないから」でしょう。
あるいは C++ で書いた資産を使いたいという
ことからかもしれませんぜ。
BCB には なぜか Object Pascal のコンパイラもついてくるので
BCB といったら「C++ しか使えない環境」という訳でもなく
Pascal で書きたければ書くことができますぜ。
IDE のコード管理支援は C++ に対してのみだけど。
| それそれ |
＞ヲレのつかってる BCB3 Pro だと関数呼び出し履歴でるけどなぁ
＞BCB1 はたしかに最悪で使い物にならなかった。
あ、そうだったんすか。さすがに改善されましたか。
私は仕事上しかたなくBCB1の頃にやってたんですが、その仕事が片づいてからは
触ってもいません。まあ、かなりヒドイ目にあったので２度と関わりたくないと
いうのもありましたが(^^;
＞オブジェクトインスペクタのこと？あそこにない
＞イベントはイベントハンドラを自分で書くか
＞サブクラス化して自分でイベントを作るかのどっ
＞ちかですぜ。
おうおう、それですそれです。
「なんでそんなの自分で書かなきゃイカンの？」みたいな感じはありました。
しかも言語拡張がアレなモンだから、マクロが意味不明。
＞そういう不都合を改善したコンポーネントと言われるものが
＞無数に再利用可能な形でインターネット上にありまする。
ではそのコンポーネントはどうやって書くの？
というと、ほとんどがDelphiで書かれてるわけですよね。
いや、前の書き込みではMFCとの対称でVCLと書きましたが、同じVCLでもDelphiは
そんなにヒドイとは思ってないんですよ。
ただ、BCB上でのVCLについてあれこれ書くと、決まって反MFC派は「Delphiなら…」
とか「Delphiの方が…」等と言い出すもので、「じゃあBCBのレゾンデートルは？
自己完結してないの？」といいたくなってしまうわけであります。
| そうそう |
>それは否定しません。が、C++Builderは独自の言語仕様の拡張と標準
>仕様のすりあわせが全くダメなのが気になります。
実際のところ私もそう思いまする(汗)
もともと Object Pascal でかかれたライブラリを
無理矢理 C++ で利用しようとしたために
いろいろと不都合がでているようだし
なれりゃ楽だけど。
すなおに Delphi つかってりゃ問題なしなんだが。
>あと、C++BuilderはIDEとしての機能が低すぎます。
>個人的に許せないのが、デバッガが全く使い物にならないことです。
>スタックフレームすら辿れないでどうやってデバッグしろと言うのか、
>開発者に直接訊いてみたい気分になりました(^^;
あれ〜
ヲレのつかってる BCB3 Pro だと関数呼び出し履歴でるけどなぁ
BCB1 はたしかに最悪で使い物にならなかった。
BCB3 もバグ多いけど。
BCB4 に期待する。
>ウィザードがお粗末なのもマイナスポイントですね。ウィザードで
>追加できるイベントハンドラが少なすぎます。
BCB ではウィザードでイベントハンドラは追加できづ。
オブジェクトインスペクタのこと？あそこにない
イベントはイベントハンドラを自分で書くか
サブクラス化して自分でイベントを作るかのどっ
ちかですぜ。
そういう不都合を改善したコンポーネントと言われるものが
無数に再利用可能な形でインターネット上にありまする。
| VCLとMFC |
＞ヲレは API をラッピングしただけで
＞結局は API 知らないとほとんどなにもできない
＞ＭＦＣ は嫌いぢゃ。Document/View も
APIをカプセル化してるという面を善ととらえるか悪ととらえるかは、
開発者のスキル、経歴、経験、個人的趣向に大きく依存するものと思い
ますので、一概には言えませんよね。
＞オブジェクト指向という点においては
＞ＭＦＣよりＶＣＬの方がかなりわかりやすい
＞構造してまっせ。他の人の書いたソースの
＞流用性の高さとかもあるし。
それは否定しません。が、C++Builderは独自の言語仕様の拡張と標準
仕様のすりあわせが全くダメなのが気になります。
特にイヤらしいのがスタティックなVCLオブジェクトを作れないこと。
あと、C++BuilderはIDEとしての機能が低すぎます。
フォームのインスタンス変数が勝手に勝手な名前でグローバルに作られて
たり、複数の実体を作るにもムダに苦労したり。
個人的に許せないのが、デバッガが全く使い物にならないことです。
スタックフレームすら辿れないでどうやってデバッグしろと言うのか、
開発者に直接訊いてみたい気分になりました(^^;
ウィザードがお粗末なのもマイナスポイントですね。ウィザードで
追加できるイベントハンドラが少なすぎます。
それらとは別に、インクリメンタルリンカに致命的なバグがあって
役に立たない（信用できない）というのは開発効率を下げる要因と
してはかなり大きいと思います。
| ヲレは |
ヲレは API をラッピングしただけで
結局は API 知らないとほとんどなにもできない
ＭＦＣ は嫌いぢゃ。Document/View も
なじめなかったし。ヲレはそれで昔
VC++ にいぢめられた。
しか〜も VC++ 立ち上げとくと
簡単にメモり不足になるのよ、開発環境
たるものが。ゲイツ製ソフトだと思って
あきらめてるけど。
C++ Builder とか Delphi のＶＣＬは
首を傾げたくなる動作も多いけどライブラリの
ソースが(ヲレにとっては)わかりやすいから
動作知りたかったライブラリソース読め、って
感じかな。
オブジェクト指向という点においては
ＭＦＣよりＶＣＬの方がかなりわかりやすい
構造してまっせ。他の人の書いたソースの
流用性の高さとかもあるし。
でも結局ゲイツ窓用ソフト開発なんて
吐き気する部分もあるから
さっさと X の方に移行しよっと。
| lcc-win32 |
BCCがあまりにもアレなのでLCCに乗り替えた人間ですが、
コレはコレで標準ライブラリが勝手なことしたり、結構アレなのでリンカと
ライブラリはMSDNからSDKをダウンロードして使ってますが〜
ライセンスにふれるのかなぁ:-)
| lcc-win32 |
私はそれを使って一つフリーソフトを公開しています。
エディタやコンパイラは2バイトコードに対応してなかったので注意が必要です。
＃1年前の話だからもう対応してるのかな？
WinSockにも対応してるし、VCを買う金の無い人はこれで十分なソフトが作れますよ。
しかもVCより小さいコードを吐くのが魅力 :-)
| 本当にフリーなC/Fortran コンパイラ しかもうぃん３２用 |
http://www.cs.virginia.edu/‾lcc-win32/
英語がわかんないとわけわかんないです。
本当にやる気のある人だけDLしましょう。合計4MB位。
| プログラミング言語なんて |
自分が好きな言語を使ったらいいのではないでしょうか。
所詮、手続き型言語なんてどれも似たようなもの。
実務（会社）で使われている言語は、限られているかもしれないけど、
世の中には、たくさんのマイナーな言語が存在します。
それでも気に入らなければ、自分で処理系を設計したら？
| プログラマが幸せになるには |
言語、OS云々よりまず管理職や顧客と技術者たちの知識のギャップを埋めるのが先だ
#とはいえ興味のない奴に何を言っても無駄なんだけどね(泣き)
| 現実はどうなんでしょう？ |
私は、Y2K問題が世間で問題視される前も現在も稼働中システムのY2K対応の
仕事はしたこと無いのです。
＃関わっていれば、2000年までは失業しないでも済むかもしれないが(^^;)
どれくらいの人数規模やどんなツールを使って行っているのでしょうか？
開発時に外部のＳＥ、プログラマを大勢使い、現在のメンテナンス要員だ
けで対応するのは、ほぼ不可能だと思いますけど、そんなこと無いんでしょ
うか？
開発時のソフト会社自体が存在していないこともかなりあるはずです。
会社は残っていても関係した社員が既に退社していたり、または、自分
で作成した設計書や仕様書を見てもわからないこともあるんじゃないか
と思います。
| 素人がすいません |
素人の私がこのスレッドに書く事をお許し下さい。
ＣＯＢＯＬのＹ２Ｋ問題ですが、私なりに理解致しました。
ｐｈ氏のご好意により本ＨＰの最初の画面にリンクがありますので
お時間があれば内容を一読して頂ければ幸いです。
私はハード屋ですので何も言えませんが、ソフトウェアを職業に
されている方々のご苦労をお察し致します。
| あのさ |
＞質問です
＞投稿日 3月6日(土)18時33分 投稿者 岡星 早苗 削除
＞これからの時代はＶＢやＣ＋＋などでしょう。
解ったから、こんな事書いている暇があったらメール書けよ。
＃はてさて
| 一応、ソフトウェア職人です |
個人的にはVC++をメインに使っています。MFCバリバリです。
MFCは、良くも悪くもWin32APIをカプセル化したモノなので、Winの内部処理を
多少なりとも知っている人にとっては大変便利であるし、Win32APIがバージョン
アップされるたびに追加される〜Ex等という煩雑な派生APIの非互換部分を吸収
してくれたりするので、大変便利です。
が、世の中のプログラマが皆そうとは限らないのは言うまでもなく、最近では
Win32の内部まで意識しなくて済むRADツールの方に人気が流れていますね。
私も仕事上仕方なくC++Builderを使ったことがありますが、MFCに比べてクラス
ライブラリの設計に不明瞭な点が多すぎると思います。
例えば、OnCloseなどのイベントをオーバーライドしたとき、自分の追加した
コードがデフォルトイベントより先に実行されるのか後に実行されるのかわから
なくて困ったことがあります。
また、ウィンドウメッセージに対するイベントを追加しようとしても、意味不明な
マクロを手書きでヘッダに埋め込まなければならなかったり、チェックボックスを
プッシュボタン型にしたかっただけなのに結構な量のコードを書かされたりと、
RADツールと言う割にはVC++よりも生産性の劣る部分が目立ちました。
で、VBの話。
私はVBはインタフェース設計においてはかなり高い生産性をもっていると思います。
個人的には、VBではインタフェースのみ用意し、ボタンクリックなどのイベント
ハンドラにVC++などで書かれたOCXをコントロールするコードを書くようなスタイル
ならば生産性と保守性を両立する手段としてかなり有効だと考えています。
もちろん、OCXの設計がトンデモないと破綻しますが、設計思想としてインター
フェースとプロセスを分離するというのは全てを一つでやろうとするよりも
有効であると思います。
オブジェクトコンポーネントに対する操作（プロパティの出し入れ、メソッドの
実行など）に関する部分は、（VBScriptやVBAを知っている人ならわかると思い
ますが）VBやBASICの言語仕様に左右される部分は少なく、この部分に限って言えば
他の言語と大きな差異はないので、GUI設計が楽な分だけ生産性が向上するという
考えです。