MFC vs .NET
■ このスレッドは過去ログ倉庫に格納されています
良スレか?
MFC理解してる人が少ないから、まともな議論になってないと思うけど。
>>135 でいっているコンテナっていうのは「埋め込みコンテナ」とか「OLEドキュメント」とか
名前が色々変遷して今はなんていうのかわからないけど、ワードとかエクセルとかに
貼り付けできて編集できるやつのことだろ。
-○○○がからんできてるけど、全部見当違いのレスで話になってない。
MFCは底辺はWindows(主にGUIの)APIのラッパー + アルファで
アルファの部分が結構でかい、DVアーキテクチャとかCObject関係とか
コレクションとかFILEIOとかメッセージルーティングとかある。
この+アルファの部分は作るものによっては不要だったり、別のものを使ってもいいので
コレクションはSTL使ってCObjectなんか使わないとかでもいい。 そもそも-○○○はMFC自体がオプションになったと勘違いしてるだろ。 なんで無料のVSにはMFCがないの?
もう枯れたライブラリだから無料でも良くね? windowsフォームもオワコン
WPFもオワコン
silverlightもオワコン
.NET系は迷走そして全滅だ 元々はWinAPI共々途中で切る予定だったんだろうけど
その計画が頓挫したところからケチがつき始めたような気がするなMS >>223
そんなことなったら、C#で、attributeでdll設定して
win32apiの呼び出しできなくなるじゃん >>223
一部呼び出しはできるって感じじゃなかったっけ? >>205
Visual Studio 2005あたりから64bitのMFCアプリ作れる。共通のソース
コードで、プロジェクト構成の追加でMBCS/Unicode, 32bit/64bit全部
ビルドできる。
確か、2005はx64の追加インストールが必要で、2007以降は標準だったはず。
MFCとリソースエディタが無料のExpress版に入っていないのは昔から。
.NET Frameworkは、セキュリティホールの巣窟。最近公開されえるセキュリ
ティパッチの大半が.NET Framework絡みか、Internet Explorer関係. .NET Framework(とIE)ばかりにセキュリティ問題が多く含まれているのか、
それとも、攻撃のターゲットが.NET Frameworkメインになったから特に対策されているだけなのか。
どちらにしても、Windowsのセキュリティーホールの大半がJavaとFlashらしいが。 パッチが多いからセキュリティホールが多い
というのはある面では正しいが別の面を見逃してるよね
パッチの当たってないセキュリティーホールがいっぱいあっても
問題になってないだけなのかも知れないし マイクロVMとモノリシックVMの覇権をかけた決戦はまだか objective-cは糞だな・・・勉強して損したぜ! objective-c覚えれば、ドラクエとか作れるんじゃないの?
買わなくていいから勉強する価値はある >>235
2008spと2012だと大して変わっていなかったけど、2013だとどのへんが良くなってる?
2012IDEのスタイルが使えるようになってたら移行したいところだが。 VSみたいなGUIをウィザードだけで作ってくれる
GUI作成は.NETより楽 それって2013以前からある奴じゃなくて?
いまさらMFCをそんなに大きく変えるとも思えんが。 当初からドッキング付いてたけど昔からVSのとはレベルが違ってた。
今は追いついたの? MFC4.0あたりでも、ちょっと派生クラスにコードを書けば、リサイズ
&ドッキング可能なダイアログバーとかフツーに作れるけどな。
そこらを解説というか、そもそもMFCの情報を掲載しているサイト
自体が減っているし、残っていても何年もL更新されてないからな。 MFCスタイルだと、一時マップのあるオブジェクトをdeleteしないで自動削除にまか
せるんだった。deleteの必要なポインタ混ぜちゃあかんかった MFCのハンドルマップ方式よりもshared_ptrの方が速いかな? >>243
ハンドル自体システムが管理するメモリのポインタで、共有に関してはウィン
ドウハンドルにしろ、ファイルハンドルにしろ、内部でシリアライズ処理されて
いると思うけど? 速度に関しては、ハンドルやポインタの管理より、それら
を経由して行う他の処理の方が時間が掛かるのが一般的で、管理方法の違いに
よるアプリケーション上での差はないに等しいのでは? シリアライズという単語の使い方間違ってるし、処理が少し遅れても気にしない性格かな? MFCで作成されたとアプリと.NETで作成されたとアプリはやはり
MFCのほうが高速に動作するのでしょうか? JvavaではJITコンパイラの方が早く動作するという結果もある
マルチコアでバックグラウンドコンパイルしないとだめだけどな VS2012でMFCウィザードで一発完了で
超カッケー画面できるんだなw
生産性は.NETを超えたんじゃね?
これで.NETの優位性は全くなくなったな >>250
そのかっこいい画面のアップをお願いします(´・_・`) >>14
その条件だとすでに作成されてるから変わらない >>256
Pro. 買えよ
金がないなら、働け
職もないなら、暇だろうから互換ライブラリでも作れ 結局、今から新規開発するならC#なの?C+(MFC),VB.NETなの? 企業が開発工数とコストを水増しするためだろ
業務アプリなんてhtml5で十分じゃんね >>267
むしろHTML5で書く方が大変だと思うが… >>246-248
PIXELAの録画カードの付属ソフトは.Netで書かれているが、実用に困るくらい
遅い。 実用に困るレベルで遅いのなら言語の問題じゃないと思う 番組表、録画済一覧、視聴画面の切り替えが遅い遅い。
番組表は 1chずつ徐々に表示されて行く感じで、全部表示されないと何も
できない。
早送りのボタンを押しても数秒たたないと早送りが始まらない。
PIX-DT230-PE0 の事だけど。 >>270
ASUSのインストーラーも .Net製 だったけど、超遅かった。
コピー作業以前にインストーラー自体が遅い感じだった。 >>272
インストーラーごときで.NETのせいで遅くなるとかねーよw >>273
.Netでプログラムしている人の中に動作原理を理解していないで書いて
る人が多い可能性がある。C++だと理解してないとコーディング
出来なかったが C#やVB.Netだと出来るとか。 ・同じように使えてしまうために、配列とリンクリストの使い分けが
出来てないとか(やることによって効率の良し悪し、得意・不得意が
あるので。)。
・ジャグ配列と普通の多次元配列の効率の違いに配慮したコーディング
が出来てないとか。
・効率向上のための参照渡しと値渡しの使い分けが出来てないとか。 「C/C++のポインタが難しい」と思っている人はそうなりがちかも。 >>275
それらやったとしてもインストーラーでそんな違い出ねーだろ(´・_・`) >>275
配列がどうとか参照が値渡しとかで番組表如きのアプリが遅くなることは無いだろ >>279
番組表検索とか録画済みデータ検索で検索条件を記録できる最大数
が30個程度に固定されているようなプログラムだよ。普通、ディスク
やメモリの許す限り無制限に出来るはずなのに。 >>279
もし、.Net自体にも、>>275 のようなこと以外にも遅くなる原因が
あるとしたら何なん?
Core i3 2.5GHz + DDR3-1333 2GB x 2 + 3TB HDD + Win7-64
のマシンなんだけど。 誤:あるとしたら何なん?
正:無いとしたら何なん? >>275に書いてあるの、.NET関係ないしw
ガベコレとかJITとかランタイムのオーバーヘッドでしょ >>283
1つ目はJava特有かもしれないが、2つ目はC#も確実にあるはずで、
3つ目もあるはず。
2つ目は、あまり勉強せずにC/C++のつもりでC#をやるとなると思う。 スマン。
>>282 の訂正は蛇足だったわ。訂正を却下しますです。 あー。こうだ!!:
もし、.Net自体にも、>>275 のようなことにも遅くなる原因が
無いとしたら何なん? >>284
だーから普通に作って値渡しで困る様になんないから。
君が言ってるのは演算をずっとループして行う様なものには関係あるかもしれないけどインストーラーごときで関係あるわけがない。 >>287
そうかもしれんが、フリーソフトでもC/C++で書かれた物であそこまで
遅いものは見たこと無い。
もし、>>275 にような事が原因でないとしたら、.Net 自体が遅いか、
または、もっと変なプログラミングになっていることに原因がある
事になるが、それで納得するの? >>287
「背理法」を使って議論しているの分かってるよね?
「>>275」のようなことが原因で無いとしたら、.Net 自体が遅いか、
または、もっと変なプログラミングが原因になっているという事
になるんだよ。
「>>275」の仮定が間違っていた ---> 背理法
となる。 どっちもいや
WTL一択
マルチプラットフォームなGUIツールキットも結局新機能使おうとするとWin32で汚れるからいや >>290
>マルチプラットフォームなGUIツールキットも結局新機能使おうとするとWin32で汚れるからいや
具体的にはどういうこと? <Windows.h>が自分のコードから見えるってことじゃないかな。
さらにその中で定義されているものを自分のコードに登場させないといけない
場合があるとか。
自分もそういうの気になります。
でもこれ、そんなに気にすることなのかな?
汚れたせいで注意しないといけない部分が増えるのはあるんだけど、気分の
問題の方が多いような気もする。 >>289
あのね?インストーラーを作るぐらいでそんな遅くなる様なものだったら、.NETがこんな使われてることは無いの。分かる?
背理法と言い>>275と言いちょっと最近覚えた言葉をホルホルして使ってる様にしか見えんよ。
とりあえず何かがおかしいと思ったら多分間違ってるのは君だから一度喋る前に考えた方がいい。 >>293
やっぱ、2chはレベルが低いね、あなた見たいのが沸いてくるから。
自信過剰。 単純にそのプログラムが糞なだけでしょう
.NETのプログラムは.NET frameworkが必要だからそのプログラムが.NETだとすぐわかるだけ >>295
すぐ分かったわけじゃなく、逆コンパイルにかけてみた事があるから。 >>297
・難読化が激しかった。
・自分が当時使った逆コンパイラでは正しく逆コンパイル出来なかった。
・難読化のせいで1文字変数ばかりで、メンバ変数やメンバ関数をgrep検索
するだけでは全く解析できなかった。
・解析するためには意味解析機能を持った支援ツールが必要と判断した。
ということでそこで断念した。 >>271
番組表はキャッシュを持たずにその都度受信して表示してる
録画済み一覧もインデックスを持たずデータをその都度スキャンしてるとかでしょ
つまりはそのアプリの実装方法が糞だって事だと思う
只、遅いってのが>>271の主観で言ってるのであって他の人から見ると十分な速度かもしれないしw 香ばしい中学生がいると聞いて。
.NETが遅いなら速度の要求される処で使われる可能性皆無になると思うが、応答速度必要なソシャゲのサーバー側とかでも使われてるのをどう説明するのか >>300
最後の段落、1chあたり約1秒で 1,2,3,4,5,6,8,10 と8ch分表示
されて行くのが十分な速度に感じられる人っていますか。 >番組表はキャッシュを持たずにその都度受信して表示してる
これなら仕様通りの速度だろうね >>29
eclipse 使ったことが無いが、
・リファクタリングツールを使えば、1文字変数を修正していける?
・同じ名前の変数でも正確にどのクラスで定義された変数かを
表示できるような? 一つ一つではなく全てのメンバ変数 x を classname_x のように修正
するツールってあるのかな? 10年くらい前のスレだと思ったら4年前のスレかよw visual studio2012のvc++でプログラムを組んでみているのですが、CLRで組んだスレッドがものすごく重たいです。MFCのスレッドと比較すると、
mfc 1ループ0.15us
crl 1ループ15ms
と言った具合です。
環境はwindows7 32bitですが、もっとcrlのプログラムを早くする方法をご存じの方、おられましたらご教示下さい。
・例えば64bit環境ならば速くなるなど mfc 0.15ms
clr 15ms
に訂正します 訂正ばかりでごめんなさい。 タスクは始めて聞きました。
スレッドより、もしかすると速いのでしょうか。速くても遅くても、チェーンでつながる概念に興味を持ちました。 mfcでのメモリリーク対策にはだいぶ苦しんでいますが、速度的なメリットから、mfcがとても魅力的です。 ■ このスレッドは過去ログ倉庫に格納されています