アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
MFC/ATL は含まれない (スコア:3, すばらしい洞察)
Re:MFC/ATL は含まれない (スコア:2, すばらしい洞察)
そういう本に触れてプログラミングを始める人にとっては、戸惑いの種になるんじゃないかなー、と。
今後、Express Edition ではじめる(=MFCを使わない) VC++ プログラミング、なんて本も増えるとは思うんですが。
Re:MFC/ATL は含まれない (スコア:1, 参考になる)
Windows独自の拡張を重ねてきたC++は、もはやフツーのC++のソースコードには見えません。フツーのC++の入門書には、
BOOL WINAPI DllMain(HINSTANCE hInstance・・・なんて説明はどこにもないわけです。Express Editionが対象とするような初心者にとって、C++は高すぎる壁です。
その点、C#とVBはWindows独自拡張部分を言語仕様の中に織り込んでしまってますから、入門書の記述と実際のソースコードが一致します。実用上もえらく便利で手軽です。
もちろん速度等の理由でC++を捨てることは当分できませんが、ハードウェアの進化によりそのうち解決するはずの問題です。いずれはWindows上のアプリケーションプログラミングの大多数はC#やVBによって書かれるようになるのでしょう。
Re:MFC/ATL は含まれない (スコア:4, 興味深い)
確かに、一部のコードでは速度が要求されることがあると思いますが、その場合、そのモジュールだけをC++/CLIで記述して、他の部分は、C#やVB(当然C++/CLIも)のような比較的保守性の高い(かどうかは人によりますけど)言語で書けば、全体的にも見通しの高いプログラムが作成できると思います。
ただし、MSは、C++を見捨てたわけではなくて、むしろ、VC++8からは、OpenMPがサポートされてことや、デバッガが格段に使いやすくなったなど、C/C++プログラマにとってもうれしいことはたくさんあります。
Re:MFC/ATL は含まれない (スコア:0)
やはりC/C++程度はできる人にプログラム書いてもらわないと
せっかく受注した仕事を赤字にしてしまうばかりか、顧客の信頼を失ってしまいますし
こんなの納品していいの?と思えるような物が上がってきた日には泣きたくなる事が多かったです。
ビジネスロジックも含めてですけど、
VB等の高級言語はプログラマの考える力を確実に削いでますよ
いや、元々考える力が乏しい人でもある程度書けるように見えるのが難点ですか
Re:MFC/ATL は含まれない (スコア:2, 興味深い)
OS や VB、C# のコンパイラを作るのに(たぶん) C/C++ を使っている以上、それに代替する何かが生まれるまで、開発は続けられると思います。主流にするつもりはないでしょうから、細々とした改良にとどまる可能性はありますが。
# いや、まあ、gcc/bcc を使って Windows をコンパイルする手もあるでしょうが(^^;
> Windows独自の拡張を重ねてきたC++は、もはやフツーのC++のソースコードには見えません。フツーのC++の入門書には、
> BOOL WINAPI DllMain(HINSTANCE hInstance・・・なんて説明はどこにもないわけです。
いや、それは API なんで。OS に依存するのはある程度やむを得ないことで、言語レベル云々の話ではありません。API を呼ぶ限り、C# であろうが VB だろうが、全部、このスタイルで呼びます。ただ、それぞれの言語に標準添付されているライブラリやら中間コードの実行エンジンなりが隠蔽しているだけです。
VC++ でそれにあたるものは MFC であるわけで、だから MFC があれば、あなたの言う「入門書の記述と実際のソースコードが一致」するようになったはずです。
Re:MFC/ATL は含まれない (スコア:0)
すぐにWindowsの複雑怪奇なC++コードとどっぷりつきあうことになるわけで。
Re:MFC/ATL は含まれない (スコア:1)
「Windowsの複雑怪奇なC++コード」って何ですか?
他のコメントにもあるけど、API と混同してませんか?
ちょっと複雑なことをしようとすると API を呼ばなければならないのは、C++ に限ったことではないと思いますが。
Re:MFC/ATL は含まれない (スコア:0)
まあ「MS独自拡張」であるところの
Managed C++ はすでにステでしょうけど、
VS2005 のMSの大本命は C++/CLI です。間違いない。
既に ECMA での標準化がすすんでるわけですが、
ゆくゆくはISO-C++ に続く新しい C++ 標準を
目指してるのではないですかね。C言語系の偉い人たち
がごっそり関わってるし。ターゲット環境であるところの
CLI は既に ISO 標準だし。
Re:MFC/ATL は含まれない (スコア:0)
私にはそうは思えないのですが、どんな部分にそれが現れているか教えてくれませんか。あなたのあげたDllMainの例がそれだとすれば、それは言語とAPIやクラスライブラリをごっちゃにしているのではないかと思います。
MSがC#やVBを推しているは、プログラマの裾野を広げようとしているためだと思います。もしそうなら、それは今後もC++をメインとしていく事と矛盾しないのではないでしょうか。
#最近のVSでは、for( int i=0; i<10; i++ )で、iのスコープがforブロックの内部にならないのは直ってるのかな?
Re:MFC/ATL は含まれない (スコア:2, 参考になる)
結構前から直っているというか、直す(正しいC++規格準拠にする)オプションがありますよ。
ただし、デフォルトではスコープはforブロックの外に続くようになってます。
MFCのソースにはそれに依存した記述が沢山あるために、
デフォルトを規格準拠に変えられない、という噂です。
Re:MFC/ATL は含まれない (スコア:0)
Re:MFC/ATL は含まれない (スコア:2, 参考になる)
Re:MFC/ATL は含まれない (スコア:2, すばらしい洞察)
Re:MFC/ATL は含まれない (スコア:1, おもしろおかしい)
orzとも書きますが。
Re:MFC/ATL は含まれない (スコア:0)
Re:MFC/ATL は含まれない (スコア:0)
Re:MFC/ATL は含まれない (スコア:0)
まぁ、wxWidgets使うならwx-devcpp使った方がいいと思うけど。