VC2015 デスクトップアプリを作りたい

質問

Visual Studio 2015をインストールしました。（Win10マシン）
C++での「新規作成」の指定が分かりません。

デスクトップアプリケーションを作ろうと思っています。（大量のCSVを読み込むようなもの）実行環境はWin7です。
VS2015を起動し、「新規作成」「プロジェクト」「テンプレート」「Visual C++」「Windows」と開きました。
この中に27種くらいのテンプレートがあるのですが、どれがデスクトップアプリケーション用のテンプレートなのか良く分かりません。
どれを選択した良いかご指導ください。

ちなみに、BCBのように、フォームにコントロールを貼り付けて開発するイメージでいます。

回答No.1

catpow · ベストアンサー

>>デスクトップアプリケーションを作ろうと思っています。（大量のCSVを読み込むようなもの）実行環境はWin7です。

デスクトップのアプリを作りたいのであれば、言語選定を間違っていますよ。
Visual Studioの主力言語は、C#で、２番手がVB.NETです。

言語としてC++を選ぶのは、すでにC++で作られた過去アプリのメンテ用か、ハードやＯＳに近い部分の処理を行うとか、特別にスピードが要請される時です。
感覚的には、Cが使えるのに、アセンブラを使っているような感じですね。

手軽さ、開発しやすさを考えたら、C#にすべきです。
（マイクロソフトもこんな考え方をしているようです）

ちなみに、CSVを読み込むような処理は、"CSVHelper"というパッケージがNuGetから取得できます。
これを使うと、とても簡単にCSV処理を作ることができます。

とはいえ、BCBの経験のみで、初めてVC2015を使ってC#で開発するとなると、いろいろと勉強することが多いのは確かです・・・。

ちなみに、Visual StudioでのC++は、ちょっと前から、C++からC++/CLIに変わりました。
言語的にかなり大きな変更がされています。
私がC++/CLIを使ったプロジェクトでは、画面まわりはすべてC#で、通信まわりとか、過去のソースとのしがらみが大きい部分のみC++/CLIでしたね。

なおC++でデスクトップアプリを作るなら、Visual C++ ->全般->空のプロジェクトとか、MFC、ATL、CLRなど、色々と好きなのを選べると思います。どれがいいか、調査されて、選ばれればいいと思います。
（C#なら、とりあえずは、Visual C# -> Windows フォームアプリケーションでOK。簡単にフォームアプリが作れます）

なにせ、デスクトップアプリをゼロからVS＆C++で作ったことないので、・・・・。

お礼

catpowさん、回答ありがとうございました。

Windowsの比較的簡単なアプリケーションを作成するのに、C++がその座を降りてしまった、ということで、ややショックを受けています。
確かにC＃などの話題が多くなって来ているとは承知していましたが・・。

私のアプリケーション作成の目的は、自分の職場での利用です。
業務パッケージからエクスポートしたCSVなどテキストファイルを読み込んで何らかの処理をする。
あるいは業務パッケージにインポートするファイルをC++で作る、といった利用形態です。

残念ながら、C#やVBが生産性が良い、と言われても今更切り替えるのはしんどいことです。
私は今までBorlandを使ってきましたが、手持ちのコンパイラが古くなったので、今後のことを考えるとマイクロソフトに移行した方が良いかな、と思い、今回の質問になった訳です。
（以前、VS2008をチラッと見たとき、BCBと同じような感覚で出来そうだ、と思ったことがありました）
マイクロソフトのC++開発環境が、新規アプリケーションを作成するには適さないような方向に向かっているのなら、やはりこのままBorlandでやっていこうか、とも思います。
もう少し、VC++での開発について検討してみて結論は出すことにします。

回答No.5

wormhole

>あくまでも私個人としてこの開発環境を導入するものであり、出来上がったアプリケーションを一担当者として使うものです。

個人的判断ではなく会社の担当部署に確認された方がよろしいかと。
私的な時間に私的なアプリケーションとして開発して業務で使用するというのでしたらライセンスの問題はないでしょうけど(会社として私的アプリケーションを使用して良いかどうかという問題はあるとは思いますが)

>だから余計に出来上がった実行ファイルも大きくなるのでしょうね。

MFCのスタティックライブラリとリンクしてるからですよ。

お礼

wormholeさん、コメントありがとうございます。

＞個人的判断ではなく会社の担当部署に確認された方がよろしいかと。
はい、私が自部門のためにプログラムを作っていることは、システム部が非公式に認めてくれています。
本当は「勝手なことはしないでくれ」と思っているかも知れませんが、各部門の要求に対応しきれないので、自前でやってくれるなら、それでも良し、と黙認してくれているようです。
私の係だけが使う（他部門に転用など出来ない）専用プログラムですから、システム部も優先順位を上げにくいのでしょう。
それでも、もし将来システム部のお世話になることがあるとするなら、マイクロソフトの開発環境にしておいた方が良いかもしれない、という思いもあり今回の質問になったのです。

ただ、C#でノウハウ積み上げる時間もないし、マイクロソフトはあきらめて、BCBを続ける方が良さそうな気になって来ています。
色々ありがとうございました。

回答No.4

wormhole

>先ず明示しなくてはいけなかったのですが、私がインストールしたのはVisual Studio Communityです。

五月蠅いかもしれませんが業務利用には条件がありますので、それは確認してください。

> 「MFC」は、プロジェクトのC++の中にありました。（Windowsの中にはありませんでした）
>これを指定しアプリケーションの種類を設定すると、「Connected Services Packageは正しく読み込まれませんでした」というエラーが出ます。
>これがどの様な影響を与えるか分かりませんが、そのまま続行すると、このプロジェクトの初期設定が完了したように思えます。

プロジェクトのテンプレートの配置に関しては私の間違いだったようです。
Visual C++→MFC
でした。
発生したエラーについてはわかりません。

>ただ、CPPソースが10個も並んでいます。恐らくこれはおかしい状態だと思います。

何をもって「おかしい状態」と判断されたのかはわかりませんが、プロジェクトのテンプレートから作った初期状態ならそれで正常です。
また起動したさいに「VC++の開発画面のようなフォームが起動されました。」というのもプロジェクトのテンプレートで作られるひな形のコードが、そのようなコードになっていたからです。

>この後、フォームの上に、ボタンやラベルなどのコントロールを配置したいのですが、ソリューションエクスプローラやプロパティの画面は出ていますが、フォームやコントロールの一覧は出ていません。

申し訳ありません。
MFCだと「BCBのように、フォームにコントロールを貼り付けて開発する」といったことはできなかったです。
またVisual Studio 2015のVisual C++プロジェクトテンプレートには「BCBのように～」なデスクトップアプリ向けのものはないようです。
C++/CLIでUniversal Windows Plathome向けでよければありますが(ただこれデスクトップアプリケーションといっていいのかどうか・・・)

>取りあえず、これをこのままビルドする（スタティックライブラリ）と、10Mにもなる巨大な.exeファイルが出来上がります。

MFCのスタティックライブラリとリンクすれば、そのような巨大なexeになります。

お礼

wormholeさん、本当にありがとうございます。

業務利用の制限については確認しました。
あくまでも私個人としてこの開発環境を導入するものであり、出来上がったアプリケーションを一担当者として使うものです。
従って問題ないと理解しています。

＞何をもって「おかしい状態」と判断されたのか
私のイメージでは、真っ白な何もないフォームが表示される、ということでソースファイルは一つであろう、と考えたのです。
ファイルも使わなければTreeViewも使わない、SDKで言えばメッセージループだけのプログラム、そんなプログラムならソースファイルも一つだろう、という考えがあったのです。
でも、MFCではこんなに沢山のソースファイルが標準で組み込まれてしまうのですね。
だから余計に出来上がった実行ファイルも大きくなるのでしょうね。

ちょっと想像していたのと違っていました。
また、コントロールを貼り付け、それのイベントにソースを書き込む、というスタイルではない、ということで残念でした。
上にも書きましたが、VC++2008を見たときに同じように出来そうだ、と感じたので、思い込んでしまったのかも知れません。

私の思うような使い方が出来ないことは、お二人の方から指摘されましたので、VC++2015を使うことはあきらめようと思います。
お手数をかけてしまったことをお詫びするとともにお礼申し上げます。

回答No.3

catpow

No.1です。

会社の業務利用だと、コンパイラを変えるのは良くても、言語を変えるのはなかなか大変でしょうね。

ちなみに、以前のプロジェクトでメンテ対応のソフトの中に、Visual StudioのC++で開発されたフォームアプリがありました。
画面は変更せず、ロジックのみの修正なので、私も「直感で、なんとか修正できるだろう」と思って始めたのですが、全然判らず、ネットで使い方を調べたり、足りないＳＤＫを追加インストールしたりと、苦労した覚えがあります。

このＣ＋＋の面倒さに比較すれば、Ｃ＃のフォームアプリは楽ですよ。
たぶん、直感で触ってみて、フォーム上に、ラベルやボタン、テキストボックスを表示するアプリがBCBやDelphiと同じ感覚で、あっという間に作れると思います。

ただし、ボタンを押した後のイベント処理に記述するロジックは、やはりＣ＃を知らないと、書けないでしょうね・・・。

なお、Ｃ＃の生産性が良いのは、C#のどんどん改善される言語仕様や、マイクロソフト提供の膨大な.NET Frameworkの活用もそうですが、世界のプログラマが登録してくれたパッケージが使えることです。
これらはVisual Studioから呼び出すNuGetによって簡単に利用できるようになります。

ただし、「どこの誰が作ったのか知らないそんなネットで拾ったパッケージ（フレームワーク）なんか危なくて業務で使えるわけないだろう！！」という先輩や上司がいるかもしれません。
そうなると、Ｃ＃の生産性はかなり阻害される気がします。

私は派遣プログラマで、いろんな会社を渡りあるいていますが、最近のプロジェクトは、「開発言語はＣ＃。フレームワークには、何使ってもいいよ。」
という前提のものが続いています。
なので、NuGetから持ってきたパッケージを利用することで、すごく効率がアップしています。

とはいっても、いくら開発が楽になるからといっても、会社やプロジェクトの方針には逆らえませんからね。

それでは、がんばってください。

回答No.2

wormhole

C++でデスクトップアプリケーションということでしたら
Visual C++→Windows→MFC→MFCアプリケーション
になるかと思います。

またVisual C++のコンパイラはC++/CLIとしての機能はありますがコンパイラオプションに /clr を指定しないと機能しませんし、Win32アプリケーションやMFCアプリケーション等のプロジェクトでは意図的に指定しない限り /clr は指定されません(/clrが必要になるのは.NET Frameworkが絡んでくるときですし、.NET Frameworkを使って良いのでしたらC#やVB.NETを使う方がいいです)

お礼

wormholeさん、ありがとうございました。
せっかくレスをいただいたのに、思うようになりませんでした。
先ず明示しなくてはいけなかったのですが、私がインストールしたのはVisual Studio Communityです。

「MFC」は、プロジェクトのC++の中にありました。（Windowsの中にはありませんでした）
これを指定しアプリケーションの種類を設定すると、「Connected Services Packageは正しく読み込まれませんでした」というエラーが出ます。
これがどの様な影響を与えるか分かりませんが、そのまま続行すると、このプロジェクトの初期設定が完了したように思えます。
ただ、CPPソースが10個も並んでいます。恐らくこれはおかしい状態だと思います。
この後、フォームの上に、ボタンやラベルなどのコントロールを配置したいのですが、ソリューションエクスプローラやプロパティの画面は出ていますが、フォームやコントロールの一覧は出ていません。
取りあえず、これをこのままビルドする（スタティックライブラリ）と、10Mにもなる巨大な.exeファイルが出来上がります。
これを起動すると、真っ白で何もないフォームが表示される、と想像していたのですが、VC++の開発画面のようなフォームが起動されました。

結局、シロートの直感で操作してみようと思った自分がバカだったのですが、「取りあえずやってみよう」ということでは、まったく手が出ない、と言うことが分かりました。
フォームの上に、1個のボタンと1個のラベルを配置したい、という極めて初歩的なことさえ出来ませんでした。