C++相談室 part134
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part133
http://mevius.5ch.net/test/read.cgi/tech/1511509970/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
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 入れる変数の型と引数の型を確認しない奴とかいるのか
暗黙の型変換は警告を出せばいいし
どうしても見落とすのならコンパイルエラーにしてしまえばいい
あとメンバ変数もテキストの色を変えればいいからm_もいらない m_だけならまだ我慢できるけど
this->を必ず付けるルールと併用するのは本当にやめろどっちかにしろ > this->を必ず付けるルール
破門だろ
C++使うなそんなボケどもは ちげえんだよなぁ
thisというキーワードが存在してるから、その存在そのものが、それを書かねばならないような強制力を産み出してる
「存在するが、書かなくてもいい」っていうどっちつかずが、一番論争になる
その反対が「存在しないから書けない」だ
これだと単純明快だ
なんせ、書けない
「書くべきか書かざるべきか」のどーーーでもいい二択に迫られると、とたんに宗教になる キーワードが存在するのと実体が存在することの違いがそんなに大事なのか？
じゃあvtableのキーワードが存在しないことを、おまえはどう考えている？ おれがそのソースを引き継いだらまず初めにやることは一つ
｢this->｣から｢｣への全ソース一括置換 「m_」はダメで「_」ならいいってのはなんというか、合理的な理由よりも感覚・感情的なものかね。 this-> つけるほうが分かりやすくていいと思うのですが、変てこな接尾辞・接頭辞よりも m_xxx も xxx_ もなんの保証にもならんからな
this->は必ずメンバになるけど 余計な命名規約を作るくらいなら言語機能を使った方が良いわな
this->派だわ thisで明示した方が所在がハッキリして良いナリ
当職は名前空間もusingせずに明示しろ派ナリ
安易な省略はタイプ数を減らすという軽微なメリットと引き換えに可読性を落としケアレスミスを誘発するという恐ろしいデメリットを孕むナリ >>237
「m_」はいらないな
↓
ローカル変数とかと名前が被ってめんどくさい
↓
キャメルケースにはしたくない
↓
「_」だけ残る C/C++なら必然的に末尾に付けるしかない
先頭に_付けるような情弱は死ねばいい
Perl/Pythonだと先頭に付けるけどな やらんけど、前一つなら規約には引っかからないんじゃなかったけ 未定義なのは
_始まりでグローバルスコープにあるもの
_始まりでアルファベットの大文字が続くもの全て
__で始まるもの全て
1番目の_始まりなだけならローカル変数、引数、メンバでは予約されていないので使ってもよい >>238
名前に変なルールを導入するか this を付けるかの二択であれば this の方がマシというのはわかる。
わかるが、必ずつけるルールにしちゃうとかなりウザいわって話。 >>242
わかるんだが、そういうルールってすぐに教条主義に陥るからうんざりする。
技巧として使う using にまでグダグダ言うやつが絶対に出てくる。 コーディング規約はうろ覚えだけど自由度の高いBoostスタイルを薦める
publicな識別子はstdに合わせて小文字スネークケース
マクロはBOOST_から始める
インデントはスペース、一行の文字数は80文字を推奨
意味のある名前を付けることを推奨
ファイル構成に関するもの
その他細々としたもの
ライブラリごとのローカルルールがある場合もある
あとは自由
thisを付けろだとか改行の仕方だとかは一切書かれてない >>248-249
お互いにマナーを守る世界は過ごしやすいがマナーの厳守を要求し出すと途端に息苦しくなるナリ
自分にも他人にも読み易いコードを書こうという気遣いが見て取れるなら細かく突っ込んだりはしないナリ this->で必ずメンバというやつら
じゃあ必ずブロック内変数という表記もしたらどうだ 使うライブラリや開発環境の内部のスタイルに合わせるけどな。
派生クラスとかAPIのラッパークラスとか作り始めると、
どうしても内部の書き方に合わせておいた方が読みやすいし。
今でもWin32とかMFCでやることもあるけど、
そのときはm_とかpとかhとかdwとかバンバンつける。 使う側の都合に合わせろよ。 ラップしてるのに中身のスタイルが漏れてるんじゃラップの甲斐がなくね？
中身を知ってる人がちょっとした便利のためだけに薄いラッパを作る場合ならそういう選択もあるだろうけど。 コンバータにあわせろよ。C#で作ってコンバータかけた方が綺麗スッキリするんだから。 >>253
そりゃAPIに渡す構造体でdwSizeとか使われてたらそこだけは合わせざるを得ないけど自分のコードスタイルを合わせる必要はないだろ >>230
m_のmは目立つのm、
>>228
ここ構造体メンバとか、 Windows メインで作業されている方で、
valgrind を併用している方はおられませんか？
もしよろしければ使用感をお聞かせいただけませんか
operator new()/operator delete() 乗っ取りデバッグに限界を感じてしまっている状況です
（cl や bcc32/bcc32c/bcc64 では new/delete 乗っ取りができません）
いや、さっさと入れればいいのですが、仮想環境とかよくわからないし…Vine Linux 以来触ってないし… windowsならapplication verifier使えば？ 以下のURLのプログラムでSFINAEを試してみていて
https://wandbox.org/permlink/LqKmn50PaPbtohs5
BOOST_TTI_HAS_MEMBER_FUNCTIONを使えば
has_funcというメタ関数を使わずに済んで、短くできないかと試行錯誤中なのですが
うまく行きません。
どうやったらビルドが通るようになるでしょうか？ すみません、BOOST_TTI_HAS_MEMBER_FUNCTIONを使って短くする以前に元々が間違っていました。
以下の3つでオーバーロードしたかったのでした。
・funcというメンバ関数を持つダブルポインタ
・funcというメンバ関数を持たないダブルポインタ
・それ以外
それで思ったのですが多分、Boost.TTIライブラリで
〇〇というメンバ関数を持つクラス、を識別するメタ関数は作れても
〇〇というメンバ関数を持つクラスのダブルポインタ、は無理な気がしてきました。
一旦諦めようと思います。 msvcでもGCCでもビルドできるのが
どうにかできました。お騒がせしてすみませんでした。
https://wandbox.org/permlink/HDwsuoVReqJEXWsO >>263
あと２年待てばconceptできるかもよ （VBみたいな名前付き引数が実現されたら
システムハンガリアン否定論者をぎゃふんと言わせられるのに… システムハンガリアン発祥の会社が何か作ったら否定論者がぎゃふんと言うのか？
おまえの頭の中は論点先取だか循環論法だかがグルグル回っているようだな ↑
想像してごらん全ての人々が
dwRet = ::WaitForSingleObject( hHandle = m_hThread, dwMillisecond = m_hTCTmo )
と書く世界を、 ごめ
誤: m_hTCTmo
正: m_dwTCTmo
見れば間違いがﾜｶﾙのがハンガリアンの極めて良いところ 一分間で間違いに気づいてはいるものの
そもそもの書く瞬間にはどうやら人智を用いても気付けないらしいから
IDEにエラー出してもらった方が早いんじゃあねえの
実は人間の集中力を超えたところにある方法論で、実践するとストレスが溜まるっぽいから、機械任せにした方がいい
それに、書いてる最中は変数の型まで考えたくない
見て分かることは、機械任せにすれば見なくても分かるから、
今のご時世、人間の有限の集中力を目視チェックなんかに使いたくない
脳みそのリソースはもっと別のところに使うべきだ
つまりは、書いてる最中は脳みそが「それが正しい」と思い込んでるから、
間違いは自分自身では絶対に分からない
これがバグを作り込む
hだったかdwだったかを脳が自動的に混同してるから、その分だけ余計に脳のリソースを使っている
「なんで書いている最中に自分自身で気付かないのか」、これ、とても重要だよ 変数名と型が一致してるという保証がゼロだからシステムハンガリアンなんて無駄以外の何物でもない
無駄というか悪 >>272
俺のレスもプログラムも表現と意図が一致してるという保証がゼロ、
まで読んだ その場合、やめられる方だけやめればいいな
つまりハンガリアンを。 >>272
そういう事言い出すと「関数名と機能が一致してる保証がゼロ」や「クラスメンバの隠蔽が完璧である保証がゼロ」などといくらでも難癖を付けれるナリ
ヒューマンエラーを理由に不要と結論付けるのならあらゆるコーディング規約が不要という結論になってしまう、これはいけない
命名規則は可読性の向上に結びつくものでなければならない、規約を違反する事で起きるトラブルはプログラマ側の責任、それは分かるよね？ ヒューマンエラーが起きる部分は極力排除して機械任せにできる部分は機械任せにすればいい
ハンガリアンを導入する理由はもはや無いな。可読性悪いし。 >>278
いや、ハンガリアンは可読性はよくなる方だよ
整合性維持に難があるだけで 可読性ぐらいテンプレートによる高度なメタプログラミングに慣れた諸兄なら
ハンガリアンごとき目を慣らして解決できるはずなんじゃ… >>276 >>282
両者は共存不可能な対立概念ではないけどね。
細かいことを言わせてもらえば、
「ハンガリアンとポリッシュ」か「ハンガリーとポーランド」と
並べてくれた方が座りがいい気もするけど…。
「ハンガリアン記法とポーランド記法」だとあまり気にならない不思議。 >>266
名前付き引数イディオムとenable_if<is_same<...>::value>が最強と言うことだな
※プログラマが、使用者が型を間違えないようにと気を使うのが正しいなら、間違えたらコンパイルエラーになるこれが最強だろ？ >>277
ちげえんだよんぁ
可読性じゃねえんだよ
>>268を見てみろよ、
読む時じゃなくて書く時のヒューマンエラーだ
なんで入り込んだのか全く分からんようなミステイクだ
プログラミングが工業的生産の一種なら、その手のヒューマンエラーは無い方がいい
で、改めて>>268を見てみると、「可読性」があってプレフィクスの間違いに気付いてはいるものの、
そもそも書く段でなんで間違えたのか、それが全く分からない
他人はおろか本人すらも自覚できない謎の理由でプレフィクスを間違えてる（これがヒューマンエラーなんだけどな）
なんで、後だしジャンケンだと、「プレフィクスが最初から無ければ、間違いも発生しえなかった」、とも言える
もしかすると、書く時に間違える／読む時に間違える の比率を考えると、ハンガリアン記法は書く時に間違えやすいが読むときに間違いにくい……のトレードオフなだけかもしれん
要するに、可読性と生産性のトレードオフだけなんじゃあねえのか？
それに、読む時のヒューマンエラーと書く時のヒューマンエラーをわざと混同してるのはいただけない void func(int a)
{
//aが何型かわからない
//アホかおまえは
} template <typename T>
void func(T lpszA)
{
//lpszって書いてあるからTはLPSTR型だな
//アホかおまえは
} >>288
func()が常に1画面に収まって1万行の関数とかでありえないという根拠は
>>289
テンプレート定義時の引数に対して引数内容固有の命名が難しいのは
ハンガリアンに限ったことではないからハンガリアンに対する批判になんね
テンプレート批判論者には考える力がないのかね… ごめ
×：テンプレート批判論者
○：ハンガリアン批判論者 テンプレートに対してはハンガリアンは全くの無力だよなあ
一貫性の観点からやっぱりハンガリアンは無い方がいいわ .>>290のレスを見てテンプレートの実体化時までハンガリアンが無力なことにされてはかないませんなあ… そもそも関数が長い場合は型情報を持たすのもありだよな
システムハンガリアンをやめさせようとして先に関数を短くしなきゃだめだなと追う結論に至って放置した //１万行の最長不倒関数を書く
//アホかおまえは void func(int lpszA)
{
//lpszって書いてあるからLPSTR型だな
//アホかおまえは
} >>295
「1画面に収まらない」を都合よく無視しないように システムハンガリアンはDWORDをintに型名変更するだけでその変数名全部終わるからなしかも一瞬で >>299
dwをiに置換するだけだからリファクタリングが楽っていう意味？ まったく逆だ
dwからiに全部置換していかないと変数名の意味を為さなくなるからシステムハンガリアンは愚かさ甚だしいと云うておる アンパンマン調で例えるなら型名変えるだけでメンテ百倍みたいな 組み込み型はいいけどクラスはどうすんのさ
意味の分からないサフィックスを付けられても困るぞ ハンガリアン！新しい型だよ！
有難う！デザパタ娘ちゃん！
メンテ百倍！ハンガリアン！ そもそもDWORDをintに変えることが滅多にない dwとか書かれてもDWORDの定義を知らないと意味不明だし
やるなら符号の有無とサイズが分かるように書かないと意味ないでしょ >>298
おまえは間違いなく１万行と書いた
その史実を誤魔化すことはできない
「ありえないという根拠は」という問いを反論として用いるのは
俺が「ありえない」と言った（事実と違うが）ことが
おまえが「ありうる」と思っているのと違ったからだろう
いずれにせよ「アホかおまえは」にふさわしいハチャメチャだな >>308
俺も使う
ただし名前そのものをポインタっぽくするだけで
ハンガリアンのプリフィックスとしてではない ハード直叩きのドライバ屋はデータバスやレジスタの幅を間違えると大変だから
物理層の実装ではハンガリアン使うこともあるよ >>313
むしろそれはアプリケーションハンガリアンじゃね？ 間違えると大変だからハンガリアンを使ってはならないんだよ
偽の情報に頼るんではなくて元を逐一確かめないと 今勉強してるんだけどC++ではポインタを使わずに参照で書くのがデフォルトなの？ >>315
不一致が存在しない事が保証されてれば問題無いんやな
そういう事ならつまり変数宣言とプレフィックスが全て一致してるかチェックするスクリプトとかがあれば満足って事でええんか？ >>316
ポインタも必要に応じて使うけど、メモリ管理の煩雑さとミスの危険性を避けるために参照やスマートポインタやコンテナ、イテレータなど他に適切な物がある時はなるべくそちらを使うのが流儀かな。 >>316
デフォ・・・まあ、そう言えなくもないか
参照でもポインタでもどっちでもいい用途には参照
ポインタでしかできないことはNULLに++や絶対番地指定
参照でしかできないことは一時オブジェクトやコピコン類 書き込むときは参照ではなくポインタにしろと言ってた人がいた。
理由を聞いたら「なんか書き込んでる感がない」だった。 グーグル規約だと書き込む引数は参照ではなくポインタにしろってなってる
でも標準ライブラリが普通に参照で書き込んでるので意味ないかなと思う 好きな方使えとしか言いようがない
ただ参照はnullポインタが無いという特性はある >>322
自分もその人の気持ちは理解できた。
func(a, &b);
と書かれていると、bに結果を書き込んでいる感があるし。 レスサンクス
cからだからポインタで書いちゃいそうだわ ローカルで宣言したunique_ptrを他のメソッドに渡してデータをつめたいばあいってどういう引数で渡せば良いの？
unique_ptr<Hoge> ptr(new Hoge);
hogehoge(ptr);
Hogehoge::hoge(const unique_ptr<Hoge>& ptr){
ptr->aaa = 123;
}
これでいける？
なんかウェブサイトみてると&&二つとかあったりするの見かけて混乱してきた &&は所有権ごとぶん投げる時に使う
渡した後も呼び出し元で使うんだったらそれて合ってるぞ ■ このスレッドは過去ログ倉庫に格納されています
