C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/10/05(金) 23:22:01.95

「ハンガリアン記法を使うと、コードの断片からでも何かを発見できる。」

2018/10/05(金) 23:25:38.27

C#では、メンバ変数 aaa をアクセスする時には、必ず、
「this.aaa」
とするらしい。これは、C++で、ハンガリアン記法を使った場合の、
「m_aaa」
に該当する。this. と m_ では、後者のほうが短く便利。

m_ も、this. も付けない場合、たとえば、コンストラクタで
同じ意味の仮引数を使いたい場合に、何らかの別の名前を
考えなければならなくなる。

2018/10/05(金) 23:26:32.77

サイズ変更してキャパシティ変更になったらデリートかかる可能性が高いのでそういうことを一応管理しないといけない。

2018/10/05(金) 23:28:00.34

>C#では、メンバ変数 aaa をアクセスする時には、必ず、
>「this.aaa」
>とするらしい。
mjd？
いつから？次の元号から？？

2018/10/05(金) 23:29:24.93

一般的に言われているシステムハンガリアンのデメリットはg、s、mには当てはまらない。
iとかdwとかlpszみたいな糞接頭辞とは分けて考えたほうがいいと思うよ。

2018/10/05(金) 23:31:13.38

個人的には、以下のような命名規則は大いに役立っており、
コード全体を見ずにコードの断片を見るだけで、何も考えずに
コーディングが出来ることが多くなる。おかげでずいぶん楽になった。

char *pszText;
char szText[256];
CString strText;
char **ppszText;

「sz」は、0終端文字列。s = string、z = zero。
p は、ポインタ、str は、CString。
pp は、ポインタへのポインタ。

2018/10/05(金) 23:36:17.35

m_がついててもそれがメンバである保証が何もないからなあ。無駄なだけ

2018/10/05(金) 23:39:57.45

>>980
個人的には、i や dw は滅多に使わない。
lpszは、自分では使わない。pszは使う。
なぜなら、lpsz の「l」は、16BIT時代から32BIT 時代へ移行したときの産物だから、
今は時代遅れなので。

ところで、dwRead と書くと、宣言を見返さなくても、読み込みバイト数を表す DWORD 値だと
分かって便利。dwWrite だと、その書き込み版となる。変数名が規則変化するのでとっても便利。

たとえば、「text」という変数名だと、CString 型なのか、0終端文字列なのか、
0終端が付いてないような特殊な文字列なのかが分からない。
ところが、ハンガリアン記法を使うとそれらが明確に区別できる。

0終端文字列を配列で持っているのか、それとも、そのアドレスをポインタで
持っているのかも、sz か、psz かで区別できる。

このことはバグの少ないコーディングにとても役立つ、。
頭を使わなくても機械的にコーディングできてしまうことが多くなるから。

2018/10/05(金) 23:46:52.35

命名のプレフィックスに関する個人的な熱い想いはカプセルの内側に隠蔽すると良い
そういう意味で「m_」は比較的どうでも良い

2018/10/05(金) 23:50:11.62

>>982
それを言うならあらゆるシンボル名が正しくそれを示している保証なんてないと思うよ。

>>983
そういうのはoopやtmpと相性が悪いんで…

2018/10/05(金) 23:51:01.17

こういう話だけは食い付きがいい
さすがﾄﾞｶﾀ

2018/10/05(金) 23:52:25.87

そうだよ。だから最低限にしないといけない
無駄なものをつけるのはいらんバグを増やすだけで悪

2018/10/05(金) 23:54:14.41

個人的にはCのライブラリ関数名に「g_」がついていないのを遺憾に思う

2018/10/05(金) 23:54:47.79

今時ハンガリアン使うアホがいたとは驚きなんだがw
もう絶滅したと思ってた

2018/10/06(土) 00:00:43.80

>>985
>そういうのはoopやtmpと相性が悪いんで…

どういう意味？

2018/10/06(土) 00:06:22.53

OOP == オブジェクト指向プログラミング
TMP == テンプレート/temporary

2018/10/06(土) 00:07:22.53

何で相性が悪いのかが分からぬ。

2018/10/06(土) 00:11:20.65

いかにハンガリアン否定派といえども
いざ実際ハンガリアンで書かれた変数名を見たら体が反応してしまうということなんだろＪＫ
鍛錬が足りん

2018/10/06(土) 00:14:20.26

ずっと前に、ハンガリアン記法で書かれた比較的大きなソース・コードを見て
とても分かりやすかったので自分もそれに習っただけなんだよね。

2018/10/06(土) 00:23:46.06

実際みんなが叩いてるから叩いてるってやつはいるだろうな
俺も別に悪くはないと思うよ
自分から進んで使おうとは思わないが

2018/10/06(土) 00:28:00.98

型が殖える度に変数名のプレフィックスがどんどんどん殖えていくなんてコーダー側からしたら不毛なだけ
いざ型名変えたいと思っても後ろを振り向くのが怖くなる

2018/10/06(土) 00:33:38.42

でも、BOOL 値の変数の先頭に b を付けたりすると、ミスを発見するのに大いに役立つ
事があるよ。

2018/10/06(土) 00:36:41.02

読む側にとってはな
書く側は細心の注意を払わないといけない
簡単に後戻りできないからな
メンテ効率最悪なんだよ

2018/10/06(土) 00:38:54.48

次はpart139でいいのか？

2018/10/06(土) 00:42:40.48

ハンガリアンは、集団にその命名方法が周知されていないといけないので、周知するところから始めないといけない。
周知できればコスト低減できるが、それまでのコストをどうみつもる？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 8時間 40分 40秒