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 ハンガリー人まだ絶滅してないのか。
stringはnull terminatedでないからpszはおかしい。
psz2もnull terminatedの保証がないからc_strを使うべき。
うまくいったらstrdupも調べとこうな。 >>162
char* psz2 = &(*psz)[0]; って
char* psz2 = psz->c_str(); と同じなのかな?
いずれにせよ delete psz; は出来る(するべき?)だけど、
delete psz2; は出来ないんじゃないかな。 必要ないところでnew/delete使う人は根本からして何も分かってない >>162
お前はstringがただの配列だと思っているのか？
このトンチキ野郎！ >>162
弁護士の唐沢です
しっかり「char* const」と「const char*」の違いを認識しなさい
const char*は参照先の定数を変更しない事を保証する宣言であり、char*は参照先の定数を変更できる為、const char*で保持するアドレスをchar*にコピーする事は言語仕様により禁止されています。それは分かるよね？
最初に宣言したポインタを間違えて別アドレスで上書きしないようにconstで固定したいのなら、char* constを使うようにしましょう。とりあえずとりいそぎ >>162
strdupという手があるが何がしたいのか今一つ分からない
const char* asdf = "asdf";
char *p = strdup(asdf);
std::cout << p << std::endl;
delete p; >>167
データは連続しているので同じになる
16文字まではスタックを使い、それ以上の長さになるとヒープにコピーされる
実装ではメンバの配列には何かしらのエスケープ文字が入る
ちなみにmsvcでは実装の都合上free(&str[0])で強引に解放できる 補足
スタックとヒープを使い分けるかどうかは実装依存
gcc、clang、msvcでは行われている
したがって短い文字列でnewを避けるためにstringを使わないというのは意味が無い >>171
strdupで確保した領域をfreeでなくdeleteするのは正しいの？ >>175
弁護士の唐沢です
mallocとdeleteは併用厳禁です。freeを使用してください >>176
良くねえだろ ぼけ
>>179
開放はpublic的なニュアンスだよな >>162
ぶっちゃけた話、 strcpy が一番短いと思う。 >>182
strdup という答えが出てるのに何言ってるの？ >>183
strdup は C++ の仕様の範囲内ではないので……。
POSIX と MSVCRT に有るからほとんどの場合に十分といえば十分なのかもしんないけど。 >>166
接頭辞を見ればデータ内容の属性がﾜｶﾙというメリットは他に代え難い
ttp://local.joelonsoftware.com/wiki/間違ったコードは間違って見えるようにする
あといちいちthis->xと書くよりも、すすんでm_xと書きましょう strdup()だと明示的に開放コードをどっかに書かなくてはならなくて必ず忘れるので
せっかくC++なのでスマポ的にwrapすると良いと思う ホワイトボックスなCでは許せるが
ブラックボックスなC++の流儀には全く合わない
それがstrdup >>173-174 教えてくれてありがとう。
返されるアドレスは等しい値なのか、という単純な質問だったんだけど、
読み直してみたら分かりにくい質問文だと思っていた次第。
それにしても &(*psz)[0] って結構ややこしいのね。
オーバーロードされた[]演算子が返すcharへの参照、
に対してアドレス演算子&を作用させた結果、て感じかな。 すみません、たくさんレスありがとうございます。
_strdupにしてみたら期待の動作ができました。
ありがとうございました。 また質問してすみません。
msvc(vs2017)だとコンパイラをC++17にしても以下のプログラムで
C2664 'void (T *&)': 引数 1 を 'hoge *' から 'hoge *&' へ変換できません。
となってしまうのですが、コードにバグが有るでしょうか？msvcのバグでしょうか？
GCCやClangではコンパイルできます。
#include <memory>
struct hoge {};
template <class T>
inline void safe_delete(T*& p) {
if (p) {
delete p;
p = nullptr;
}
}
int main() {
std::unique_ptr<hoge, decltype(&safe_delete<hoge>)> sp{new hoge(), safe_delete<hoge>};
return 0;
} (T *&)
そもそも、ポインタ・参照を、同時に使えるのか？ new hoge()は変数じゃないから、代入できない。 >>165
独習C++ はいいですね、特に演習問題「std::stringを再実装する」を絶賛します
これが書けるようになったらC++初級者をかたってもいいかもしれない、もしかすると解答は載ってなかったかもしれないけれども >>185
どこから引用したのか知らんけど、そのページ読んでないだろ…
システムハンガリアンはまるで役に立たないって書いてあるぞ。 >>194
（システム）ハンガリアンってそんなに悪いものなんですかねえ
いや、win32api がバンバンハンガリアンしているので、そんなもんか、と思っていましたが >>195
OOPともTMPとも型推論とも相性が悪いからね。
MS自身ももう使うなって言ってる。 嫌いだからハンガリアン意地でも使わなかった
dwやらszやらせっかくのフリーフォーマッとが台なしだよ >>191
それは「ポインタ変数の参照」で、たしか便利に使えた気がしますが…
明日にでもちょっと書いてみます、今日は疲れました… >>195
システムハンガリアンは弊害ばかりだろうけど、アプリケーションハンガリアンは適切に使えば有益だよ。 mとかいらなくねってなって削ったら_から始まるようになった データの属性としてサイズとか型そのものを明示したいときはシステムハンガリアンするしかないし、
よってWIN32APIがシステムハンガリアンを使って定義されるのは全く正しい
問題なのはアプリケーションハンガリアンすべきときと
システムハンガリアンすべきときが区別できない香具師が適当に使うと
被害甚大だということやがな… 今時システムハンガリアンは無いだろ
20年前で時間が止まってるのかよ >>205
なぜシステムハンガリアンが有り得ないのかkwsk
DWORDを渡すABIがある日突然気まぐれにUSHORTに変わったりしたら困りはしまいか ググればいいだろ
積極的批判
システムハンガリアンを使っているソースコードを修正してデータ型を変更した際、同時に変数名も変更するコストがかかる。変更を怠ると、たちまち不整合となり、保守の障害となるだけで一利もない。
C++やC#のような言語では型付けが存在するためにシステムハンガリアンを使用することによる利点はない[3]。
移植性を阻害する。
総称型、メタプログラミングとの相性が悪い。
消極的批判
いわゆる良書と呼ばれるようなC++本で、現在[いつ?]システムハンガリアンを採用している例が皆無。
かつてWindows API/MFCにおいてハンガリアンを全面的に採用していたMicrosoft自身が、.NET Frameworkではハンガリアンを禁止[1]している。 型なんてマウスオーバーなりすれば表示されるだろ
変数名に書いておかなきゃわからないとかメモ帳で書いてるのかよ >>190
デリータはポインタが指す先のリソースを後始末するのが仕事であって、
ポインタが無効になるという処理は unique_ptr の側でやってくれるので、
ヌルを代入する必要はない。
むしろ unique_ptr 内で管理しているものをデリータが勝手に弄るのは好ましくないので、
参照で受けるのはやめてさしあげろ。
私なりに仕様を読んでこの場合をエラーにする根拠は発見できなかったが、
エラーになってくれる方がありがたい場面だと思う。 デリータに渡されるのは左辺値と限らないからだろう。 N3337 だと 516 ページの説明がデリータの要件だと思うんだけど、
デリータ d の型が D で ptr の型が unique_ptr<T, D>::pointer のとき式 d(ptr) が valid であることと書いてあって、
ptr が rvalue か lvalue かってのは特に指定がない。 (どこかに書いてあったりする？)
この説明で言ってる ptr が変数名なのだとしたら暗に lvalue とほのめかしてるようにも思えなくもないし、よくわからん。
わからんことは避けて通りたい。 私なりの見解としては未定義だと思ってる。
未定義ならばやったらエラーになる方向にしてくれる方がありがたいという思い。 >>206
ABIにシステムハンガリアン関係ないだろ…
APIを指してるとして、呼び出し側はリファレンスマニュアルなりIDE機能なりを利用して引数の型情報も
システムハンガリアンが付いている仮引数名と同時に参照しているはずだよね？情報重複してるけど本当に必要？
仮引数名のシステムハンガリアンの有無に関わらず、APIのシグネチャは用意に変更してはならないものだけど、
そもそも仮引数名はシグネチャじゃないからシステムハンガリアンがついていたって何の保証にもならないよ？ 重複する情報をコンパイラの支援なく一致させ続けることが出来るだろうか。 いや、できない。
って話よね。
まあ世の中にはそういうのを検査するツールとかもあるんだろうけどさぁ、
そういうツールを導入できる環境ならまともな IDE だって使えるだろう。 >>210
>>211
レスありがとうございます。
shared_ptrだと行けるのでなんかすればコンパイル通るのではないかと
思ったのですがだめなんですね〜。
普通に使う用とカスタムデリータに使う用と二種類用意してやり過ごしてみたいと思います。
template <class T>
inline void safe_release(T*& p) {
if (p) {
p->Release();
p = nullptr;
}
}
template <class T>
inline void custom_deleter(T* p) {
p->Release();
// p = nullptr; no meaning
} >>207
藻前はレスをきちんと読んでいないのではないか
>システムハンガリアンを使っているソースコードを修正してデータ型を変更した際、同時に変数名も変更するコストがかかる。（>>207）
に直接対応する元レス>>206は、
>データの属性としてサイズとか型そのものを明示したいとき（>>204）
について述べているのでデータ型変更時のコストを言い立てても批判にならない
消極的批判については、アプリケーションハンガリアンすべきときと システムハンガリアンすべきときが
区別できない香具師の的外れな批判がｸｿｳｾﾞｰからそうなったのかもしれん、
（ちな両者を区別できない香具師への警戒も>>204で言及済み >>214
十分賢いIDEが人間のミスを完璧に排除してくれるんならそうかもしれんが
システムハンガリアンをしてはいけないという積極的理由にはやはりならないのであった
それとも「間違ったコードは間違って見えるようにする 」（>>185）の効能を全否定する？
APIの定義は変わらなくとも、それを利用するソースコードがころころ変わり得るわけで、
byStrLength
にある日だれかがDWORD型の値を突っ込んだとしたら…
こういうケースを考えたら、「接頭辞を見ればデータ内容の属性がﾜｶﾙというメリット（>>185）」は
ありえないぐらい賢いIDEでも使わないと他に代え難いと思うがどうか、
>>198
>嫌いだからハンガリアン意地でも使わなかった
おk ようやく建設的な議論に着手できる、 あり得ないくらいバカなプログラマのことなんか考慮してない マウスオーバーで変数の型を確認できたり、縮小変換に警告を出してくれたりする程度のありふれた機能が、ありえないぐらい賢いとな
お前さんはメモ帳でコーディングしてるのか >>220
emacs にもそんな機能がほしいと思うことがあります システムハンガリアンでミスを減らせるなんて事はない
むしろ害悪 >>221
俺のemacsには搭載されてるんだが
環境構築もプログラマの腕のうちだからな >>221
有るよ。
irony-eldoc や company-mode を入れろよ。
Emacs こそ最強の IDE だろうが。 今時システムハンガリアンを使うやつはあり得ないくらいのバカだということが決定しました >>218
間違ったコードは間違ったように見えるようにする、について、
あなたが指し示した引用元が言及してるのはアプリケーションハンガリアンについてなんだけど…
システムハンガリアンについては否定的意見。
ちゃんと読んだの？ >>223 >>224
thanks a lot!! >>218
APIの仮引数にシステムハンガリアンをつけたことで、間違ったAPI呼び出しが間違ったように見えるのはいつ？
APIのリファレンスなり宣言文なりを自分のコードと見比べたときでしょ？その時必ず型情報も見てるよね？情報重複してるよ？
あとIDEが自動でミスを排除してくれるなんて書いてないよ？ちゃんと読んで 入れる変数の型と引数の型を確認しない奴とかいるのか
暗黙の型変換は警告を出せばいいし
どうしても見落とすのならコンパイルエラーにしてしまえばいい
あとメンバ変数もテキストの色を変えればいいから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できるかもよ ■ このスレッドは過去ログ倉庫に格納されています
