リンクフリーを近日中にとりやめる予定です

すでにリンクを貼っていただいている方、ご一報頂きたくお願い申し上げます。


ごく少数ですが、リンクをお断りする場合があります



ブログ内 風景光景カテゴリー

続編記事などをご希望の方は こちらへどうぞ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

[未掲載分] 車輪の再発明 (4)

元来、好ましい意味で用いられない「車輪の再発明」。



筆者は、そのような行為を肯定的に捉えている。
なぜならば、新しい技術や文化が芽生えるきっかけは、一見無駄と思われることへの挑戦である・・・


お知らせ
活動休止にともない、この記事を事前に予約投稿してあります。
トップ記事の固定を目的としています


この題目は2012年暮れ頃に掲載しようと下書きし、諸事情により掲載却下とした分です。
前話、車輪の再発明 (3)にひきつづき、利用環境を OS はWindows , CPU は Intel 製、いわゆるウィンテル機を前提に綴ります。

前回、「アプリを開発するアプリ」として Visual Studio を取り上げた。
たしかに、統合開発環境に依存せずとも、OS (Windows) に付属している「メモ帳」などでソースコードを書いてアプリを作成することもできる。それは、「建設現場で近代的な手法を一切用いずに建てる」ようなもので、莫大な時間を要する。

ほか、Visual Studio などの統合開発環境を利用するメリットはデバッグ作業が効率的になることだ。
ここで言うデバッグ作業とは、簡単に言えば、動作チェック。アプリが想定した動きをしない場合や頻繁にエラーで停止する場合にソースコード内の不適切な箇所を潰してゆく作業。
「デバッグ作業が楽」というのは、ある程度の段階に進むまでは実感できない。プログラミングを学習、とくに入門書を読みながらあれこれ試している段階のヒトにとってピンと来ないのは当然である・・・

まずは前回の補足。

ここから前回の補足 ---
(1) もっと簡単な方法もある。
いわゆる Hello World! 、つまり「文字を表示するだけの単純なアプリ」を組むだけならば、他の手段もある。
なるべく、導入コストをかけたくないというのであれば、「WTL」というライブラリを導入するのも良い。

(2) 日本語版の MSDN ライブラリではいくらかの情報が省かれている、抜け落ちている。
「// メイン メッセージ ループ:」とコメントがある下に
GetMessage 関数が使われている。
while 構文 で囲われた部分、アプリが終了するまで GetMessage(&msg が繰り返される。
慣れないうちはこのままでも、良いだろう。
現に、入門用の書籍やその類のWebサイトでも「while(GetMessage(」のまま紹介されている。
実戦段階ではGetMessage の戻り値・返却値を確認するように修正するのが賢明である。

なぜならば、少し古めのMSDN ライブラリを漁ってみると以下の注意書きがあった。
最近の日本語版 MSDN ライブラリではこの記述が見当たらない

If the function retrieves a message other than WM_QUIT, the return value is nonzero.
If the function retrieves the WM_QUIT message, the return value is zero.
Warning Because the return value can be nonzero, zero, or -1, avoid code like this:

while (GetMessage( lpMsg, hWnd, 0, 0)) ...
The possibility of a -1 return value means that such code can lead to fatal application errors. Instead, use code like this:

少し古めの日本語版では以下の通り
戻り値
WM_QUIT 以外のメッセージを取得した場合、0 以外の値が返ります。
WM_QUIT メッセージを取得した場合、0 が返ります。
エラーが発生した場合、-1 が返ります。たとえば、hWnd パラメータで無効なウィンドウハンドルを指定した場合や、lpMsg で無効なポインタを指定した場合は、エラーが発生します。拡張エラー情報を取得するには、GetLastError 関数を使います。

警告 GetMessage 関数は、0 以外の値、0、-1 のいずれかを返します。したがって、次のようなコードは避けてください。

while (GetMessage(lpMsg, hWnd, 0, 0)) ...

このようなコードを作成すると、GetMessage 関数が失敗して -1(0xFFFFFFFF、つまり TRUE)が返った場合、ループが持続し、致命的なアプリケーションエラーを発生させる可能性があります。

MSDN ライブラリでは、その問題に対処したメッセージループも紹介されている。

おおざっぱに言えば、GetMessage 関数の戻り値の型に注意を払う必要がある。
通常、BOOL 型 なので戻りは TRUE か FALSE。
BOOL 型 は ブーリアン型 で、人間でいうところの「はい」「いいえ」の返事を確認するのに使われる。
※ 詳しく知りたいヒトは 「windef.h」というファイルを開いて typedef を見ると良いでしょう。

「いいえ」の返事に相当するのは「FALSE」と考えると良い。
「false」の意味を調べると「間違った」「誤った」などなど。
例えば、「うまく出来た?」の問われた時、「間違った」「失敗した」は「いいえ」の旨となる。
FALSE は ゼロなのだが、TRUE は ゼロ以外とされていて、多くの場合「1」 と定義されている。

アプリが終了する時、WM_QUIT というメッセージを送る。この時に「ゼロ」か「ゼロ以外」の返事を期待しているとする。
BOOL 型 に従えば、FALSE を意味する「0」かTRUE を意味する「1」が戻ってくると勘違いするヒトがいてもおかしくはない。
しかし、
「~~ 0 以外の値、0、-1 ~~」の部分に記されているように実際には「-1」が戻ってくることもある。
「-1」が戻ってきた際の対応も、GetMessage の後に追加しておくのが良策。

たいてい、「-1」が戻ってくる場合はアプリが異常終了する例が多く、致命的なバグ ( 欠陥 )がどこかに潜んでいるものだ・・・

このように、日本語版 MSDN ライブラリでは、GetMessage 関数の戻り値に関する記述が省かれている。
英語で記されたサイト等を閲覧するが苦手なヒトもいるだろう。
しかし、このような、原文(英語版)に載っていても日本語版で省かれている情報は見落としがち。これらを見落として「うまく進まない」と悩むのはモッタイナイ。
力をつけたいヒトは原文を漁ることも近道である・・・
--- 前回の補足はここまで

ここから筆者の雑感 ---
手厳しいことを記す。
この題目のきっかけとなったブロガーさんから感じたことがある。
「C/C++ 言語を理解する」ことと「Windows 上で動くアプリを作る」ことはイコールではない。
それは「自動車の構造に詳しくなる」ことと「自動車をうまく運転する」ことくらい、根本的に異なる。
ここでは話の対象をウィンテル機に絞っているが、コンピュータのOSは数多あり、Windows はその中のひとつに過ぎない。
筆者の私見かもしれないが、手順としては「ウィンドウ(やダイアログボックス)を表示させる」ことが先、次に「何の言語で組むか」ではないだろうか。
「Windows 上で動くアプリを作る」という基礎的な段階で右往左往するようであれば、Visual Basic (もしくは VB.Net) や C# 、Java などの選択肢がある。

C/C++ 言語に興味を持つヒトの中には「アプリが高速に動くらしい」との話を鵜呑みにしているのではないかと感じることがある。もちろん、はじめてプログラミングを習うのにC/C++ 言語から入るヒトもいる。
筆者の想像であるが、ほかの言語でアプリ作成をある程度経験を積んだが、実行速度面で不満が生じる。やがて、「高速さ」に誘われて、C/C++ 言語に挑もうとするのであろう。

アプリを動かす機器の特性を十分に理解し、ほどよく最適化された実行ファイルを生成する等の条件が整えば、「C/C++ 言語で組んだアプリが高速に動く」は間違っていない。しかし、実際は、C/C++ 言語 で組んだアプリが Java で組んだモノより遅い事例もあり、ハードウェアの特性を理解するのも容易ではない。

ウィンドウを表示したり、マウスのクリックに応答する部分といった「ユーザとやりとりする部分」を考えた場合、C/C++ 言語 では、Visual Basic や C# に比べ手間がかかるのは否めない。
ズバり言ってしまえば、お手軽ではない。Visual Basic や C# であればウィンドウの処理やメッセージへの応答などを意識せずにアプリを作れる。

「高速さを求めるあまり作業に多くの時間を費す」こと、全てが無駄とは言わない。しかし、どこかで線引きが必要。
なかには、ウィンドウが表示される仕組み、クリックしたらメニューがポップアップされる仕組みを学びたいヒトもいるだろう。
その辺の情報は多くの先人が触れており、書籍を漁るなり、ネット検索で多くの情報がみつかる。これらの技を習得するのはある程度経験を積んでからでも遅くはない。

多くのヒトにとって重要なのは「自動車の構造を知る」ことよりも、「自動車を使って何をするか」である。まずは、完走できること、目的地にたどり着くことが優先課題・・・

不慣れな段階において完走を目指すなら、別のアプローチを模索するのも良いだろう。
古くから用いられている例だが、
ウィンドウを表示させる部分、ボタン等のユーザとやりとりする部分を Visual Basic や C# で組み、
速度が求められる部分を「DLL」( = 動的リンクライブラリ 、Dynamic Link Library の略 ) として作成し、実行時に呼び出すといった手法もある。
想像するのが難しいかもしれない。簡単な図で現すと、以下のような感じだろうか・・・



実生活の場で例えるならば、「専門的な作業が得意なスタッフを抱える」と「専門的な作業は外部委託する」といった違いのようなもの。
外部委託する利点としては、委託先の内部状況を気にする必要が無い。
仮に、自ら専門的な作業を行うとして、あまり得意でない作業ならば、常に間違いが起こらないように気を配ったり、出来上がりの精度も不満が残ることだろう。

※ 32ビット版、64ビット版のOSごとに別々の DLL を作成する必要がある。
※ 高速さを求めるならば DLL 部は C/C++ 言語 やアセンブリ言語で組むのが望ましい。

--- ここまで筆者の雑感

さてさて、Visual Studio の使い方に戻ろう。
リハーサル用と本番用

Visual Studio の操作画面をよく見ると、ドロップダウンリストで「Debug」となっている部分がある。



このドロップダウンリストで、「Debug」版と「Release」版といった、作成するアプリの構成を切り替えが可能。
Visual Studio に不慣れな段階でアリガチなのは、Debug と Release の切り替えずに進んでしまう!?!?



ところで「Debugって何??? 」「Debug と Releaseって何が違うの??? 」が
Debug と Release の違いをここで述べると長くなる。
簡単に言ってしまえば「リハーサル」用と「本番」用の違い。

「Debug 」や 「Release」という表記、名称は絶対的なモノではない、ユーザが自由に変更できる。
ここでは慣例に慣例に従い、そのまま用いる。
例えば本番用として、異なる設定の実行ファイルをビルドすることも可能。つまり、複数パターン作成するのもアリ。

もうひとつ、切り替えを忘れそうな箇所がある。
対象プラットフォームの切り替え
初期状態では「Win32」となっている。
実際のところ、32ビット版、64ビット版のOS が両方出回っている段階では「Win32」のままでも構い。
なぜならば、32ビット版のアプリでも64ビット版のOS上で動くから。ただし、64ビット版のOS上では64ビット版のアプリの方が性能を発揮する。
かつて、16ビット版のアプリから32ビット版のアプリへ切り替わってきたように、いずれ「Win32」という選択肢が消えるのかも・・・

64ビット版のOSに対応したアプリを作りたい場合、



「Win32」が表示されているドロップダウンリストをクリック。
「構成マネージャ」をクリック。



構成マネージャのダイアログボックス右側、
「アクティブ~~プラットフォーム」のドロップダウンリストから「<新規作成>」をクリック。



新しいプラットフォームを選択するダイアログボックスの中から「x64」を選択する。



※ 64ビット向けのアプリを作る時は、後で述べるプリプロセッサの定義に要注意。
2014年1月25日付けの記事でも触れたように、64ビット版を現す語句として、「EM64T」「amd64」や「IA64」などもあります。一般的な PC 、つまり、Intel 製 CPU や AMD 製 CPU を搭載したプラットフォームを対象とするならば「x64」でOK。

ところで、Visual Basic や C# ではプラットフォームが「Win32」ではなく、「Any CPU」等になっている。



「Any CPU」 とは「32ビット用、64ビット用に関係なく動くアプリ」を作成すること。
この辺も、動作させたいプラットフォームに合わせることで、より効率的に動くアプリが作成されることだろう・・・

プロジェクト毎の設定
Release 版 ( 本番用 ) のアプリは初期設定のままビルドしても、ある程度高速に動きます。
少し設定を変更することで、実行速度が上がるかもしれません。
基本的にはプロジェクトを作成するごとに設定する習慣をつけるのが良いでしょう。

個別設定を行うには、キーボード操作ならば、[Alt]ボタンを押しながら[F7]を押す。
マウスを用いるなら、操作画面メニューの「プロジェクト」 -> 「プロパティ」。でも良いのだが、昨今の風潮として操作画面メニューが省略されてゆくようだ・・・



Visual Studio の左側ペイン「ソリューションエクスプローラ」から、プロジェクトファイルのアイコンを右クリック。



コンテクストメニューの一番下、「プロパティ」をクリック。



ダイアログボックス左側ペインのツリービュー、「構成プロパティ」の「C/C++」を選択。
[全般]の中で、[警告レベル]が変更できます。

警告レベルを高く設定するのは C/C++ 言語に慣れてからで良いでしょう。警告レベルを高く設定することで、不具合のもととなる箇所を潰せる確率が高まります。
逆に、不慣れな段階では警告レベルを高くしないほうが無難です。プログラミングを学習中のヒトは教本に載っているコードなどを丸ごと打ち込んだり、何れかのWebサイトにあるサンプルコードを貼り付けることもあるでしょう。
出回っているサンプルコードの中には、古めルールに従ったコード、つまり、現在のルールと異なる部分が多く残っています。古いコードをそのままビルドすれば大量の警告が出ます。大量の警告と対峙しているうちに挫折してしまうヒトが出てくるのも当然。



Release 版のアプリならば、左側ペインのツリービュー、「C/C++」の[最適化]も変更。
最適化については「実行速度」を上げる、もしくは「ファイルサイズ」を小さくするの方針を設定できる。
※今回は省きますが、「実行速度」優先に設定しつつ、「ファイルサイズ」を小さくする方法が幾かあります。

「インライン関数の展開」を「拡張可能な~~」に切り替えることで実行速度の向上を期待できます。ただし、全般的にファイルサイズが大きくなります。



左側ペインのツリービュー、[プリプロセッサ]に関しては要注意。
これは Visual Studio 2008 での例です。
プラットフォームを「x64」に切り替えた直後、初期状態ではビルド・コンパイルに失敗するヒトが多いかも。

ちなみに、筆者は「x64」の設定として
WIN64;_WIN64;_X64_=1;DBG=0;_NDEBUG;_MT;_UNICODE;UNICODE
を加えています。置き換えではなく、「WIN32;NDEBUG;_WINDOWS」を残し、その後に「;WIN64;_WIN64; ~~ ;UNICODE」を付け加えます。
64ビット版のアプリを作る場合でも、Windows 95 や NT 以来 OS ( Windows ) に備わっている諸々の機能を使いたい場合は「WIN32」や「_WINDOWS」などのシンボルを定義する必要があります。

少し古めの教本やサンプルコードでは、文字列処理に絡む箇所でエラーが生じるかもしれません。
_UNICODE;UNICODE;
を外すとエラーが減るかもしれません。
それでも、文字列に絡むエラーが生じる場合もあります。サンプルコードで日本語の文字列が含まれていて、いわゆるユニコードではなくシフトジス、Shift_JISを想定したサンプルコードがビルドできない場合、プリプロセッサで定義しているシンボル
_UNICODE;UNICODE; を _MBCS; へ変更するとうまくゆくこともあります。
_MBCS; を定義することでマルチバイト文字セットを扱えるようになります。ただし、時代の流れから言えばマルチバイト文字セットは旧式。それよりもユニコード対応のコードを組めるのが望ましい・・・

ほかにも、左側ペインのツリー[コード生成]の[バッファ セキュリティ チェック]など速度向上を期待できそうな項目があります。・・・どの項目を変更すれば良いのか、筆者なりの見解もあるのだが・・・いろいろ試して最適な設定を探ることが上達への近道となるだろう・・・



もうひとつ・・・
左側ペインのツリー[リンカ]の[全般]にある[出力ファイル]という項目がある。
通常ここは、
~~$(ProjectName).exe
となっている。
筆者は Debug 版と Release 版を区別するため「.exe」の部分を「_d.exe」に変更する。

通常は、プロジェクトのフォルダー内に「Debug」と「Release」いったフォルダーが作成され、その中にアプリ本体、すなわち実行ファイルが作成される。
ときには、Debug 版のアプリと Release 版のアプリを同じフォルダーに作成したいこともある。
既に述べたように、Visual Studio 等の統合開発環境を使っているうちは、Debug 版と Release 版の切り替えには苦労しない。統合開発環境が使えないとなると、あちこちフォルダーを移動しながら切り替えることになる。手間が増える。

出力先の設定例としてRelease 版では
$(SolutionDir)$(ProjectName).exe
Debug 版 では
$(SolutionDir)$(ProjectName)_d.exe
と変更すれば、Debug 版のアプリと Release 版のアプリを同じフォルダーに作成できる。

長くなりましたので続きはまた後日・・・

本日も最後までご覧いただきありがとうございます。

「つまらなかった」「判り辛った」という方もご遠慮なくコメント欄へどうぞ

テーマ : プログラミング
ジャンル : コンピュータ

コメントの投稿

非公開コメント

検索サイトからお越しの方へ
検索サイトからお越しの方は、ブラウザのアドレス欄vitalaboloveおよび、fc2.comが含まれているかご確認ください。
含まれていない場合、偽サイトを閲覧なされている可能性があります。

偽サイトは、当ブログの文字部分や画像部分が有害サイトへのバナーと置き換わっているようです。
プロフィール

Author:Vitalabolove
ご訪問ありがとうございます。
店長を任されておりますVitalaboloveです。

コメントはお気軽に。
今のところリンクフリーですが、あと数日でとりやめます。

画像データ、文言の引用は事前連絡くださるようお願い申し上げます。事前連絡の際は、左下、メールフォームを経由をご利用ください。

最新記事
カレンダー
07 | 2017/08 | 09
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -
カテゴリ
ランキング
いつも応援いただきありがとうございました。ただいま休養中につきランキングへ参加していません・・・

フリーエリア
内緒話などはおきてがみをご利用ください。
月別アーカイブ
メールフォーム
掲載された記事について、ご不明な点はここからお問い合わせください

名前:
メール:
件名:
本文:

最新コメント
最新トラックバック
スパムと思われるトラックバックは削除しました
QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。