アカウント名:
パスワード:
自分ではやりませんが、人がやっている分にはスルーする事にしています。
ただ、
Windows界隈ですが、変数名ではなく型名にハンガリアン記法（っぽい）定義がされているのが、よくあります。
符号無し32ビット整数である DWORD に対して、それのポインタである LPDWORD が定義されているわけです。これだと頭が混乱するので、素直に DWORD * と書いて欲しいわけです。
ポインタ値を“ポインタ返し”関数があったとします。たとえば以下のようなものです。
void hoge (void **p);
これをマイクロソフト流に書くと、
void hoge (LPVOID *p);
となります。この辺で、かなりイラっときます。
文字列ポインタは、マルチバイト文字かワイド文字か、constの有り無しで、以下のように定義されています。
LPSTRLPCSTRLPWSTRLPCWSTR
ときどき LPCWSTR * なんてのが出てきます。この辺で、殺意を覚えます。
素直に、
char *const char *wchar_t *const wchar_t *
って書いてくれれば、混乱しなくて済むのに。
それは、ターゲット環境によってtypedef const char *LPCSTR;とtypedef const char __far *LPCSTR;を定義し分けなければいけなかった時代の名残なのです。今となってはまさに「もうやらなくていいコーディングテクニック」ですね。
HANDLE が void* なのか struct { ... } _HANDLE, *HANDLE; なのかとかの違いを再コンパイルだけで通せるようにするためのものですから。 TCHAR が char なのか wchar_t なのかもコンパイルスイッチ依存で LPTSTR とかを使う場合が多いように思いますけど、そんなに LPSTR とか使いますか?
# そして printf_s() の呼び出しを軒並み wprintf_s に変えたりすることに。
char か wchar_t をコンパイルスイッチで切り替えて、どちらでもコンパイルが通るように保守すること自体が、（今となっては）無理があると思うのです。
私はデータ型のサイズをいつも意識に入れながらコードを書くので、TCHARがマルチバイト文字なのかワイド文字なのかを“意識せずに”コードを書くのは、私には無理です。なのでT〜系の文字型を使ったことはありません。
MFCと決別してQtを使い始めてから、T〜系の文字列型は必要なくなったので char か wchar_t を意識して書き分けます。普段のGUIアプリならそれでいいのですが、まれに要件の制約でMFC等を使わざるを得ない場合は、“文字セット＝Unicode文字セットを使用する”にして、 wchar_t * を使います。それでも char * が必要なときは FunctionNameA() の用にサフィックス(?)付きで使います。
そんなわけで、T〜系の文字列型は「もうやらなくていい昔のコーディングテクニック」だと思うです。
それがいつまでもポインタである保障が無いことに気がついていませんね. そのデータは現在の実装で, たまたまポインタを使っているにすぎません.
将来的に例えば整数のidに変わった場合, ソース中の全ての接頭文字をpからiに変えるのですか? それは無駄/バグの元になると思いませんか? 変えないとすれば, 実態と表現の食い違いをゆるすことになり, ルールを根本から否定すると思いませんか?
＞きっとそれまでにはプログラムが使われなくなるに100カノッサ。
・・・2000年問題
接頭文字をpからiに変えるなら、LPSTRがポインタでなくなる時点でLPを変えなきゃね。
>いつまでもポインタである保障が無いこと
ということは、少なくともJavaとかでハンガリアンする奴の正当性は全く無いってことだな。型的にも値的にも「ポインタ(参照)がそうでなくなること」は絶対にないので。
いや、いるんですよ。JavaだのRubyだのでもハンガリアる奴がorz
＃rubyは変数に型こそないが「全てがポインタ(参照)だ」なのだから結局は同じこと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
ハンガリアン記法とか (スコア:0)
Re: (スコア:3, 参考になる)
char szHogeHoge[64]のようなシステムハンガリアンを使うことについては、僕も大嫌いですが。
Re:ハンガリアン記法とか (スコア:1)
Re:ハンガリアン記法とか (スコア:2)
自分ではやりませんが、人がやっている分にはスルーする事にしています。
ただ、
Windows界隈ですが、変数名ではなく型名にハンガリアン記法（っぽい）定義がされているのが、よくあります。
符号無し32ビット整数である DWORD に対して、それのポインタである LPDWORD が定義されているわけです。
これだと頭が混乱するので、素直に DWORD * と書いて欲しいわけです。
ポインタ値を“ポインタ返し”関数があったとします。たとえば以下のようなものです。
void hoge (void **p);
これをマイクロソフト流に書くと、
void hoge (LPVOID *p);
となります。この辺で、かなりイラっときます。
文字列ポインタは、マルチバイト文字かワイド文字か、constの有り無しで、以下のように定義されています。
LPSTR
LPCSTR
LPWSTR
LPCWSTR
ときどき LPCWSTR * なんてのが出てきます。この辺で、殺意を覚えます。
素直に、
char *
const char *
wchar_t *
const wchar_t *
って書いてくれれば、混乱しなくて済むのに。
Re:ハンガリアン記法とか (スコア:1, 参考になる)
それは、ターゲット環境によって
typedef const char *LPCSTR;
と
typedef const char __far *LPCSTR;
を定義し分けなければいけなかった時代の名残なのです。今となってはまさに「もうやらなくていいコーディングテクニック」ですね。
Re:ハンガリアン記法とか (スコア:1)
HANDLE が void* なのか struct { ... } _HANDLE, *HANDLE; なのかとかの違いを再コンパイルだけで通せるようにするためのものですから。
TCHAR が char なのか wchar_t なのかもコンパイルスイッチ依存で LPTSTR とかを使う場合が多いように思いますけど、そんなに LPSTR とか使いますか?
# そして printf_s() の呼び出しを軒並み wprintf_s に変えたりすることに。
Re:ハンガリアン記法とか (スコア:1)
char か wchar_t をコンパイルスイッチで切り替えて、どちらでもコンパイルが通るように保守すること自体が、（今となっては）無理があると思うのです。
私はデータ型のサイズをいつも意識に入れながらコードを書くので、TCHARがマルチバイト文字なのかワイド文字なのかを“意識せずに”コードを書くのは、私には無理です。なのでT〜系の文字型を使ったことはありません。
MFCと決別してQtを使い始めてから、T〜系の文字列型は必要なくなったので char か wchar_t を意識して書き分けます。普段のGUIアプリならそれでいいのですが、まれに要件の制約でMFC等を使わざるを得ない場合は、“文字セット＝Unicode文字セットを使用する”にして、 wchar_t * を使います。それでも char * が必要なときは FunctionNameA() の用にサフィックス(?)付きで使います。
そんなわけで、T〜系の文字列型は「もうやらなくていい昔のコーディングテクニック」だと思うです。
Re:ハンガリアン記法とか (スコア:1)
それがいつまでもポインタである保障が無いことに気がついていませんね. そのデータは現在の実装で, たまたまポインタを使っているにすぎません.
将来的に例えば整数のidに変わった場合, ソース中の全ての接頭文字をpからiに変えるのですか? それは無駄/バグの元になると思いませんか? 変えないとすれば, 実態と表現の食い違いをゆるすことになり, ルールを根本から否定すると思いませんか?
Re:ハンガリアン記法とか (スコア:1)
参照箇所は全修正だから、変数名を変更して未修正の箇所をコンパイラに指摘して貰う方が安全だと思う。
# 特に、void * を使っている場合、注意が必要。（警告潰しのためにキャストしている馬鹿が多い）
notice : I ignore an anonymous contribution.
Re: (スコア:0)
きっとそれまでにはプログラムが使われなくなるに100カノッサ。
冗談はこれくらいにして、ポインタという機能の振る舞いを変えなければ、
それが整数のidに変わったからといってなんら問題は起こらないとはず。
ポインタという機能の振る舞いを変えてしまうくらい言語仕様が変更に
なってしまうのなら、これは相当ひどい言語だと思う。その時には
「こんな言語を選択してしまったことが一番の間違い」といわれるだろう。
Re: (スコア:0)
＞きっとそれまでにはプログラムが使われなくなるに100カノッサ。
・・・2000年問題
Re: (スコア:0)
接頭文字をpからiに変えるなら、LPSTRがポインタでなくなる時点でLPを変えなきゃね。
Re: (スコア:0)
>いつまでもポインタである保障が無いこと
ということは、少なくともJavaとかでハンガリアンする奴の正当性は全く無いってことだな。
型的にも値的にも「ポインタ(参照)がそうでなくなること」は絶対にないので。
いや、いるんですよ。JavaだのRubyだのでもハンガリアる奴がorz
＃rubyは変数に型こそないが「全てがポインタ(参照)だ」なのだから結局は同じこと。
Re: (スコア:0)
>そのデータは現在の実装で, たまたまポインタを使っているにすぎません.
いやいや、ありないから(笑
LPDWORD等で利用されているLPはlong pointerの略で
Microsoft的にハンガリアン記法として利用しているものだから
未来永劫、ポインタであることに違いはありません。
これが変更された場合、ハンガリアン記法である意味そのものがなくなってしまいます。
typedefの結果現在の型が偶然そうなっているだけなんだという、論点は理解できますが
この議論でたまたまポインタになっているというはあり得ません。
Re: (スコア:0)
間違ったらエラーになるようなケースが大半ですんで、だからそれよりもっと重要な情報を入れたくなる。