2016-06-19 4 views
-1

I持って次のC++コード:LPSTR LPCTSTR説明

#include "stdafx.h" 
#include <atlstr.h> 

int _tmain(int argc, _TCHAR* argv[]) 
{ 
    CString OFST_PATH; 
    TCHAR DIR_PATH[MAX_PATH]; 

    GetCurrentDirectory(MAX_PATH, DIR_PATH); 

    OFST_PATH.Format(DIR_PATH); 

    CHAR *pOFST_PATH = (LPSTR)(LPCTSTR)OFST_PATH; 

    return 0; 
} 

私はプログラムの最後でpOFST_PATHの値が "C" である理由を理解したいですか?変数OFST_PATHのキャスト(LPSTR)(LPCTSTR)は、そこに書かれた全体の経路に何をしましたか?次のウィンドウで見ることができるように変数をデバッグの際

は、値は次のとおりです。

​​

+0

LPCSTRやCstringなどのこれらのマイクロソフト固有の突然変異のすべてで自分の心を汚染するのを避けることで自分自身を賞賛します。代わりに 'char *'や 'std :: string'のようなC++の標準型に従ってください。 –

+0

私はあなたに完全に同意しますが、私はそれらを使用するように制限されています:/ – Raz

+0

それは残念です。過去に受け入れられない職場環境に直面して、私は仕事を変えることで問題を解決しました。この種のコードは私の目を傷つけ、長期的な脳の損傷を恐れる。 –

答えて

7

CStringLPCTSTRは両方それがある(UNICODEが定義されている場合wchar_tである、TCHARに基づいており、あなたの場合、私はargvの値であなたのデバッガに伝えることができます)。これを行うと:CStringLPCTSTRへの変換演算子を持っているので、大丈夫作品

(LPCTSTR)OFST_PATH 

。しかし、UNICODEを定義すると、LPCTSTRLPCWSTR、a.k.a. wchar_t const*となります。 utf16文字の配列を指しています。その配列の最初の文字はL'c'(これはワイド文字のバージョン'c'です)です。 L'c'のバイトはメモリ内で次のようになります。0x63 0x00。これは文字 'c'のASCIIコードで、その後にゼロが続きます。だから、あなたはあなたのCStringLPCTSTRに、それは、しかし、有効なのですあなたの次の変換変換するとき:有効ではありません

(LPSTR)(LPCTSTR)OFST_PATH 

LPSTRchar*なので、のようにwchar_t const*を扱っています。デバッガでは、char*と表示されている場合、nullで終わる狭い文字列が検索されていると想定しています。そして、最初の文字のバイトの値が何であるかを上から覚えていれば、それは文字 'c'のASCII値であり、その後にゼロが続きます。したがって、デバッガはこれを文字 'c'だけからなるヌル終了文字列と見なします。

ストーリーのモラルは、彼らが何をしているのか、そしてそれが適切かどうかを理解していないと、Cスタイルのキャストを使用しないことです。

+0

ああ、私は画像を見ることができませんでした。公平になるために、彼はなぜそれが価値があるかを尋ねなかった。 :) –

+0

さらに進んで、C++でCスタイルのキャストを使用してはいけません。特に 'reinterpret_cast <>'を使用しているときに、C++スタイルのキャストを理解していないと、C++スタイルのキャストを使用しないでください。 – franji1