いう方向性の話は、(スラドの人々なら恐らく判りきってるんで)わざわざ言及するまでもないと思います。Winの世の中にはcygwinかVC++か(象徴的に言えば)という選択肢しかないわけじゃないんで。別にC(++)に話を限定しないとならん謂れもないですよね、この文脈だときっと。#蛇足だが(というかどこまでが蛇足だかも微妙だが)VBやRubyやPerlや...ならどうなんだろう?>でも、cygwinやmingwでしかコンパイルできないソースを書いても、一般的には「Win32上のプログラミング」とは呼べないでしょう。これは他の人も指摘しているように、ヘンですね。逆にいえば、Win32上としか言いようがないけどもVC++でもBCでもない(笑)世界も、メジャーなものだけでも沢山あるわけで。いやDelphiには最近はKylixが有りますが、Delphiそのものは(それ自体もTargetも)やっぱりWinモノだし。>GTKやqtなども(俺はWin32上でGTKを使ってますけど)あくまでも「UNIX環境ですでに慣れ>たAPI群のレイヤをWin32上に構築する」という逃げ道でしかありませんね。そんな事を言い切ってしまったら、「クロス」プラットフォーム環境を作ろうと努力してる諸兄が悲しむでしょうね。APIは全く知りません。GTKなら開発できます」って>条件で挑んだら、普通は確実に不採用だと思いませんか?G7氏が採用担当だと、喜んで採用するのかもしれませんが。;-)これ困るんですよね。Win経験ってのが逆に、コテコテのVC++でAPIでMFCで「しか」知らない奴を募集してるかのように誤解されるかも知れない(というか、されがちな)現状が、ね。ま、例えばDelphi屋が欲しければDelphi屋と書けばいいんですが、それもまた困るんですよね。Delphi馬鹿しか欲しくないわけじゃないことが(業種によっては)多いでしょうから。Winをターゲットに仕事できる人が欲しい、というだけで。OSを指定したいだけなのに、言語&ライブラリ(やAPI)環境まで指定したかのように思われるのは、ちょっと辛いです。幅が欲しいなあというか。APIそのものがどれだけ必要か、ってのは、作るソフト次第だとも言うでしょう。ちなむと俗に業務ソフトとか言われるものにAPIがさほど沢山必要になることはあんまり無いはずですね。そのくせ業務用クライアントとしてご存知のようにWinは独壇場であるわけで、じゃあそこで動く巷の無数のクライアントアプリがどんな内部構造をしているのか、をちょっと想像して頂けると幸いです。俺なら、必要最小限とLazyとがキーワードかな。Win32のことも「必要最小限」知ってればいい、くらい。しても必要になったら、なった時点(Lazy)にNetなり書籍なりで、がーっと情報集める「力」がある人。道具の選定も、使えるものを最小限知っているとか、必要になったら見つける(見分ける)「力」があるとか。FREEや非FREEの「巷の既存ライブラリ」ってのも結構有り、そういうのを(うまく沢山)使うと、これも「API叩き」とは違う雰囲気を醸し出せるわけです。使い勝手も美しさもパフォーマンスもイケてるライブラリ(と言語(^^;:つまり(V)C++に限らないのです)を日常的に使ってると、API叩きなんかには「戻れません」ね。健全な技術の肩の上に乗るのならば。APIを間接的に呼ぶのまで勘定に入れたら、「どんな」言語/ライブラリを使っていたってAPIを使ってることになっちゃうんで無意味です。Coward俺も欲しいです。fileが使えますよ。多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。service.閉じるスラド処理中...。