[過去ﾛｸﾞ] C++相談室 part154 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
254: 2021/01/28(木)18:07 ID:IHrlZHr2(1/5) AAS
>>243
gdbはおいとくとして、Visual StudioってC++例外のスロー位置を追跡できたっけ？
255(1): 2021/01/28(木)18:50 ID:Hqj+H5f7(1) AAS
>>252
初期化リストを使う
B() : a(hoge, piyo)
256(1): 2021/01/28(木)18:54 ID:IHrlZHr2(2/5) AAS
あとで再初期化したくなること多いから、結局コンストラクタの実装を別の関数に分離すること多いよね。
コンストラクタの種類が増えたら使いまわしたくなるし。
257: 2021/01/28(木)19:24 ID:q3mIN91/(1/3) AAS
>>243
デバッガ使いこなせないとか話にならんだろ・・
258(2): 2021/01/28(木)19:28 ID:IHrlZHr2(3/5) AAS
デバッガやシンボルがない環境でもスタックトレースできたほうが良いと思うけどね。
後発言語の生産性の高さはこの辺の充実ぶりにあるでしょ。
259(1): 2021/01/28(木)19:42 ID:IHrlZHr2(4/5) AAS
他プロセスと連携するシステムにはデバッガを当てにくい事が多い。
タイミング依存の不具合を追跡する場合、デバッガがまったく役に立たない。
260: 2021/01/28(木)20:25 ID:eBfsAdOM(1) AAS
>>258
その手の生産性と成果物の効率はトレードオフでどっちを重視するかが違うだけでしょ
261(3): 2021/01/28(木)20:36 ID:IHrlZHr2(5/5) AAS
デバッガ使いこなすとか言って悦に入ってる人と会話が噛み合わないんだが。
262: 2021/01/28(木)20:36 ID:yp+dwtvR(1) AAS
>>258
だよね
むしろデバッガをアタッチできる環境ならスタックトレースはなくてもなんとかなる
ユーザー環境でスタックトレースがテキストファイルに落ちるようになってるとトラブルシューティングがしやすい
263(1): 2021/01/28(木)21:29 ID:oPlwADge(1/2) AAS
>>261
ここほとんどアマチュアの人だから許してやろうやｗ
264: 2021/01/28(木)21:48 ID:q3mIN91/(2/3) AAS
>>261 >>263
悪いがプロだよ
IDEの機能を使いこなせてない初心者が、先に学ぶべきことから逃げて言語だけでどうにかさせようとするような
(いつものことだが)はちみつのミスリードに釘を刺しただけだ
265: 2021/01/28(木)21:51 ID:q3mIN91/(3/3) AAS
>>261
あと、流れを読む限り俺の発言が気に入らなくてファビョってるのは君の方だよね、俺1行しか書いてなかったし(しかも大した内容じゃない)w
何が気に障ったんだ?
266: 2021/01/28(木)21:51 ID:oPlwADge(2/2) AAS
いやごめん、俺は流れは一切追ってなくて他意はないよ
茶化したかっただけ
気にしないで
267: 2021/01/28(木)23:50 ID:g6qVZG7L(1) AAS
発狂やないかｗ
Perlの人かな
268(3): 2021/01/28(木)23:53 ID:RfcrpqT0(1) AAS
>>253,255
じゃあ、Bを構築してしばらく経ってからわかる情報を使ってAを構築したいとき、Aのインスタンスをメンバとして持つのは不可能ということですか？
ポインタで持つ以外の方法はない (想定されてない？) のでしょうか
constなメンバ変数を初期化するときも近いことを思います
269: 2021/01/29(金)00:10 ID:ZIYbfTXe(1/4) AAS
>>268
そういうコンストラクタ制約を持つクラスはけっこう多い。
WindowsのC++向けGDI+ライブラリのクラス群はまさにこれが当てはまる。
広範に存在している以上は受け入れるしかない。
今時は標準でshared_ptrなどの共有ポインタクラスを使えるので、さほど問題にならないでしょ。
270: 2021/01/29(金)00:19 ID:SRnp44iw(1) AAS
>>268
Aに引数なしのコンストラクタ、コピーorムーブ代入演算子があるなら、後で作って代入でもいいけど
まぁ特に理由なければ(スマート)ポインタで持った方が無難だし楽
constはどうしようもない
271: 2021/01/29(金)00:22 ID:MWSZTtHp(1) AAS
>>268
「Bを構築してしばらく経ってからわかる情報」を返すヘルパー関数を作って初期化リストの中で呼べばいいじゃない
272: 2021/01/29(金)07:49 ID:/axUqcOX(1) AAS
データメンバをconstってあんまりやらないな
publicに晒すとかじゃなきゃメンバ関数を
constにするだけで足りるから
あ、staticメンバのconstはよくやるけどね
273(2): 2021/01/29(金)08:02 ID:1V7SRlCX(1/3) AAS
>>251
ある
実装は同じunsigned longでも意味が違うから別クラスとして扱いたいときとか
private継承できたらﾅｱ……
現状（C++03）はプリミティブ型と同じ演算子（のうちの当座のアプリケーションで使うやつ）をいちいち実装したクラスを作って
NDEBUGマクロで実装を切り替えるみたいな涙ぐましい努力が要る
274: 2021/01/29(金)08:05 ID:1V7SRlCX(2/3) AAS
訂正orz
誤： private継承
正： public継承かつoperator unsigned long()はprivateかつunsigned longからの構築はexplicit
275: 2021/01/29(金)08:08 ID:1V7SRlCX(3/3) AAS
メンバをconstにして代入演算子を定義せずにいるとデフォルトの代入演算子をが定義できないとコンパイラに文句を言われる俺環、
276: 2021/01/29(金)09:20 ID:koPyq8om(1) AAS
>>273
それ、継承できたとして式の中で混在しても区別されないんじゃね？
テンプレートの型引数で区別するような使い方くらいしか思いつかないが。
277(1): 2021/01/29(金)12:20 ID:c2S2Mocm(1/2) AAS
メンバ変数のconstはポインタ型ならすることあるけど、値で持つメンバ変数はあんまり意味なくない？
constなくても勝手に外部から書き換えられないように、ちゃんと隠蔽しとけばいいだけでしょ
278(1): 2021/01/29(金)12:35 ID:2DekME/2(1) AAS
>>277
class内の処理においても変更しないつもりだ、変更されることはない、と明示することで意識しておかなければならないことを少し軽減できるのだから、無駄ではないと思う。
手間をかけずにconstにできるならしておけばいいし、逆に無理して複雑なことをしてまでconstにする必要はないという程度のことかと思う。
279: 2021/01/29(金)12:55 ID:c2S2Mocm(2/2) AAS
>>278
たしかにconst付いてればコンストラクタで設定した値がずっと変わらないことが
明示的になるから無意味ではないか
280: はちみつ餃子 ◆8X2XSCHEME 2021/01/29(金)14:10 ID:heeNhc25(1) AAS
>>273
そういう用途なら opaque alias という提案だけは出てるけど
どう見てもグダグダなんで、場当たり的な方法のほうがマシだと思うよ。
281(2): 2021/01/29(金)16:04 ID:5pIDnM+S(1/3) AAS
>>251
3値のboolean作るときってboolean継承すべき？
282: 2021/01/29(金)16:07 ID:5pIDnM+S(2/3) AAS
>>256
言いたいことは判るが
コピーコンストラクタやムーブコンストラクタが勝手に使われるから
デフォルトに任せてると何が起こるかは判ってた方が良い
283: 2021/01/29(金)16:10 ID:5pIDnM+S(3/3) AAS
>>259
COMサーバーというかDX用にフィルタ書いてると訳判らなくなった
284(1): 2021/01/29(金)16:56 ID:RxAp4EkX(1) AAS
>>281
3値のbooleanを作って何するの？
boolへのポインタにしてtrue / false / nullptr の3値でなんとかならんか？
285: 2021/01/29(金)17:20 ID:ADFs+h5F(1) AAS
boostにtriboolってのがあるな
286: はちみつ餃子 ◆8X2XSCHEME 2021/01/29(金)17:23 ID:t7wU8l8M(1) AAS
>>281
仮に真偽値型を継承可能であったとして、三値型が真偽値型を継承するのはおかしいだろう。
場合によって柔軟な判断が必要な場合はあるものの、
継承は is-a 関係を表したいときに限ったほうがよろしいというのが一般的な設計原則だと思うが。
287: 2021/01/29(金)17:25 ID:GtDK4kd8(1) AAS
nullableか、DBのフィールド値？
288: 2021/01/29(金)18:57 ID:ZIYbfTXe(2/4) AAS
はちみつ餃子「スタックトレースできないならデバッガ当てればいいじゃない」
289: 2021/01/29(金)19:41 ID:rAmh2V0K(1) AAS
典型的な円楕円問題だな
290: 2021/01/29(金)19:56 ID:ZIYbfTXe(3/4) AAS
テンプレートを使えば、クラス継承に依存しない記述が可能。
iostreamが黒歴史扱いである現実を踏まえての話。
291: 2021/01/29(金)21:24 ID:WFMo+mcm(1/2) AAS
とりあえずiostream批判しとけば訳知り顔ができた気に浸れる浅はかなやつ
292: 2021/01/29(金)21:35 ID:nnAlz0gZ(1) AAS
c++ニワカあるあるだよなｗ
iostreamとりあえず批判奴ｗ
293: 2021/01/29(金)21:39 ID:ZIYbfTXe(4/4) AAS
iostreamは使いもしないメンバ変数を継承することを強要される悪い手本でしょ。
294: 2021/01/29(金)22:16 ID:WFMo+mcm(2/2) AAS
何も説得力を示さずに突然「悪い」と言い出す
295: 2021/01/30(土)01:56 ID:SJAC6oP5(1) AAS
iostreamはクソなのは正解だが別に批判するようなことでもない
なぜなら使わなければいいだけの話だからだ
296: 2021/01/30(土)02:06 ID:OHt9F1SU(1/8) AAS
無理にクラス継承を使わずオーバーライド関数とそれを使うテンプレート関数を充実させたほうが幸せになれる。
297: 2021/01/30(土)02:41 ID:PJvUkb6d(1/5) AAS
別に無理して継承を使っているわけではない
どっかの馬の骨が気に入らんからといって
あれを使うなこれを使うなと言われるほうが無理そのものだ
298: 2021/01/30(土)02:53 ID:OHt9F1SU(2/8) AAS
例えば、ファイルに書き込む処理があったとする。
ファイルハンドルとして有名な型としては、int型、FILE*型、iostream型、Win32APIのHANDLE型などがあげられる。
これらを派生クラスに閉じ込めて抽象化するよりも、関数名が同じになるオーバーライド関数を作ってテンプレート関数から呼んだ方がはるかに楽。
int WriteBuffer(int fp, const char* buffer);
int WriteBuffer(FILE* fp, const char* buffer);
int WriteBuffer(ostream& fp, const char* buffer);
int WriteBuffer(HANDLE fp, const char* buffer);
template<typename FILE_OBJECT>
void WriteContent(FILE_OBJECT o)
{
省3
299: 2021/01/30(土)03:53 ID:ULcRPxme(1/2) AAS
ドヤってるところすまんがそれオーバーライドじゃない
300: 2021/01/30(土)04:01 ID:PJvUkb6d(2/5) AAS
ﾌﾟｹﾞﾗ
301: 2021/01/30(土)05:45 ID:SLqQC90z(1/5) AAS
フリー関数とクラスメンバでは、インテリセンスが効くか効かないかの違いもある。
302: 2021/01/30(土)05:52 ID:OHt9F1SU(3/8) AAS
そんなあなたに名前空間
303: 2021/01/30(土)06:06 ID:SLqQC90z(2/5) AAS
クラスの場合、名前空間を書かなくても、インテリセンスが効く。
304(2): 2021/01/30(土)06:47 ID:budoESfZ(1) AAS
コンストラクタの初期化リストで
class A{
int x;
public:
A(int x) : x(x) {}
};
みたいにしたとき、ちゃんとメンバのxがコンストラクタの引数のxで初期化されますよね？
メンバの x と同名の引数の x が同一のスコープに同居しているようで紛らわしいかなと思ったのですが、こういう書き方を避ける慣習はありますか
305: 2021/01/30(土)07:04 ID:ULcRPxme(2/2) AAS
自分は普通にその書き方してる
避ける人も居るっぽいけど好きなようにすればいい
306: 2021/01/30(土)09:09 ID:PHKUCpSE(1) AAS
iostreamマンセーバカってのは型安全ならどんな仕様でも良いと思ってるカスが多いからな。
型安全は評価する一項目に過ぎないってのに。
307: 2021/01/30(土)09:29 ID:vDjChjwr(1) AAS
iostreamは整形のための情報をわざわざ状態として持たされるのがクソ
当時は状態が邪悪だっていう考え方が一般的じゃなかったからしょうがないけど
308(1): 2021/01/30(土)09:38 ID:2pTx0la6(1) AAS
でも状態もってなかったら記述が煩雑になりすぎない？
HTMLのマークアップとまでは言わんまでも
309(1): 2021/01/30(土)09:59 ID:OHt9F1SU(4/8) AAS
整形設定を記憶する変数インスタンスをiostreamインスタンスと分離すべきって話でしょ。
必要に応じて差し替えできるように参照渡しするか、逆にiostreamを参照渡しするとか色々やれたはず。
310: 2021/01/30(土)10:06 ID:OHt9F1SU(5/8) AAS
というか他のオブジェクト指向言語だと整形情報がFormatterクラスとかに分離されているのが普通だし。
311: 2021/01/30(土)10:32 ID:PJvUkb6d(3/5) AAS
FORTRANのFORMAT文が好きな人をどうこうしようとは思わない
312: 2021/01/30(土)10:40 ID:hVJYorL3(1) AAS
初歩的な質問なのですが、stringクラスの内部バッファはデストラクタで破棄されるため自分では一切管理しなくていいという認識で良いのでしょうか？
313: 2021/01/30(土)11:17 ID:SLqQC90z(3/5) AAS
アロケータによるけど、普通は管理しなくて良いのでは？
314: 2021/01/30(土)12:47 ID:EWZvTk3z(1) AAS
>>308
状態持ってても無駄に煩雑(複雑ではない)
315: 2021/01/30(土)12:57 ID:8FYOnD7D(1) AAS
iostream 型安全なのはいいけど、char/signed char/unsigned char ぜんぶ文字扱いするのはやめて欲しかった。
316: 2021/01/30(土)13:18 ID:SLqQC90z(4/5) AAS
単項プラスで。
317(1): はちみつ餃子 ◆8X2XSCHEME 2021/01/30(土)13:18 ID:4OMKN/Z4(1/2) AAS
>>309
入出力を直接的に司るバッファクラス (basic_streambuf) と
書式制御を司るストリームクラスを分離したデザインになっているし、
必要に応じて差し替えることも出来るよ。
iostream においてそれがわかりやすいか、良いデザインであるかは別として、
ちゃんと分離したデザインになってる。
318(1): ◆QZaw55cn4c 2021/01/30(土)14:53 ID:L1O2TNoD(1/2) AAS
>>304
私は馬鹿なのでメンバ変数とコンストラクタ引数を x, _x というふうに書き分けています、馬鹿が感染るかもしれないのでお勧めはしません
319(2): 2021/01/30(土)15:08 ID:S5wIZr5N(1/2) AAS
C++でのメンバ変数は、標準的には m_xと書く。
320: 2021/01/30(土)16:04 ID:0ahE8ZR3(1/2) AAS
>>319
何処信者だよ
ダッサw
321: 2021/01/30(土)16:41 ID:SLqQC90z(5/5) AAS
MicrosoftとAdobeがその書き方多いですね。
322(2): 2021/01/30(土)17:13 ID:S5wIZr5N(2/2) AAS
なお、_x は、命名規約上、禁止。先頭が _ の名前はコンパイラなどの
システム予約なため。
323: 2021/01/30(土)17:14 ID:2r/QlSUC(1/2) AAS
そうだったっけ？
324: はちみつ餃子 ◆8X2XSCHEME 2021/01/30(土)17:19 ID:4OMKN/Z4(2/2) AAS
>>304
>>318-319
命名規約の方法論は色々なのでプレフィクスを付けるルールが定めてある場合もあるし、
むしろ一致させていくようにしているものもある。
私自身は、少なくともメンバに値を設定するだけの単純なコンストラクタである場合には
名前を一致させていくスタイルで書く。
C++ を使う上でのガイドラインとしてよく参照されているのはグーグルのスタイルガイドで、
データメンバの名前は最後にアンダースコアを付けるようにルールを定めている。
外部ﾘﾝｸ[html]:google.github.io
その一方では C++ の設計者である Stroustrup は型やスコープを変数名に含めるのは好ましくない
省10
325: 2021/01/30(土)17:30 ID:2r/QlSUC(2/2) AAS
互いの信仰を侵害してはならないがチーム内では統一されている必要がある
規約の背景は明確である必要がある
326: 2021/01/30(土)18:08 ID:OHt9F1SU(6/8) AAS
>>317
まず、FILE*とostreamが一対一対応していないのがダメ。
せっかくC言語でファイル、パイプ、標準IOがFILE*型としてで統合化・抽象化されていたのに、
C++でostreamとfstreamで分離される劣化が起きた。
327: 2021/01/30(土)18:30 ID:PJvUkb6d(4/5) AAS
ios_baseで統一する形に変わっただけ
それをFILE*がどうたらと駄々こねるのは
頭が堅すぎる実年齢に無関係の老害だ
328: 2021/01/30(土)18:36 ID:OHt9F1SU(7/8) AAS
パイプ処理をostream系で書く奇特な人ってどのくらいいるの？
329: 2021/01/30(土)18:41 ID:OHt9F1SU(8/8) AAS
pythonは定数がないから全部大文字の変数は定数のようにみなしましょう的な談合がある。
330: 2021/01/30(土)19:00 ID:0ahE8ZR3(2/2) AAS
定数というか型もない
331(2): ◆QZaw55cn4c 2021/01/30(土)19:09 ID:L1O2TNoD(2/2) AAS
>>322
束縛領域が狭いローカル変数とかには、_x を使ってもいいのではないか？と考えていますが‥‥
332: 2021/01/30(土)20:32 ID:PJvUkb6d(5/5) AAS
data_
size_
333(3): 2021/01/31(日)03:18 ID:6QCY/vGM(1) AAS
>>331
実は#defineマクロの中で使われるケースがあってね。
_xが、アプリの中で使われてない事を前提にしないとマクロが作れない
場合とか。
334(2): 2021/01/31(日)06:52 ID:gXTMTlGe(1/8) AAS
HTTPサーバーのサンプルで、関数型言語がCを凌駕して、C実装の作者が？？になってるやり取りをどこかで見たのですが、わかる方いらっしゃいませんか？
おそらくC++は簡単に勝てるはずなんですが。
335: 2021/01/31(日)07:27 ID:fCVb5Gn/(1/11) AAS
dmrが？
336: 2021/01/31(日)09:14 ID:bSEeGU13(1/3) AAS
>>333
c++実装者がユーザから参照可能な形でそれやってるの見たことあるの？
337(1): 2021/01/31(日)09:22 ID:fCVb5Gn/(2/11) AAS
>>333
#define A(_x) (std::cout << #_x)
int main()
{
int _x = 5;
A(_x);
std::cout << _x;
}
何か問題でも？
338(1): 2021/01/31(日)10:19 ID:BqL9JwJS(1/3) AAS
ひどいな
外部ﾘﾝｸ:qiita.com
339(2): 2021/01/31(日)10:23 ID:BqL9JwJS(2/3) AAS
>>331
_で始めると激しくコンパイラ依存になる
340: 2021/01/31(日)10:50 ID:BqL9JwJS(3/3) AAS
>>334
Erlang?
341(1): はちみつ餃子 ◆8X2XSCHEME 2021/01/31(日)10:57 ID:+XHxoAeu(1/5) AAS
>>339
繰り返すが言語仕様上はグローバル変数ではない名前の頭がアンダースコアで始まるだけなら問題ない。
現実に出来が悪いコンパイラがたくさんあるのであれば仕方がないが、
少なくとも俺はそんなのに遭遇したことはない。
342: 2021/01/31(日)11:04 ID:fCVb5Gn/(3/11) AAS
>>338
DLLのビルドに使ったコンパイラと
そのDLLを使うアプリをビルドするコンパイラが違っても動くんだぞ
ABIの指定は仕方ねえだろ
343(1): 2021/01/31(日)11:29 ID:2WBeknRq(1/2) AAS
>>334
これか？
サーバーじゃなくてパーサー部分だけだけど
外部ﾘﾝｸ:blog.8arrow.org
344: 2021/01/31(日)12:10 ID:gXTMTlGe(2/8) AAS
>>343
それです。
ありがとうございます。
345(1): 2021/01/31(日)13:12 ID:ZnRwde8F(1/13) AAS
>>341
英語サイトでも、説明の仕方が誤解を招くようなものがありまして、もしかしたらそれは誤解かも知れません。
外部ﾘﾝｸ:stackoverflow.com
「Here's what the C standard says (section 7.1.3):
1. All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
2. All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.」
訳：
1. アンダースコアで始まって直後に英大文字が続くか、または、アンダースコアが連続して
続く識別子は、いかなる使用も予約されている。
2. アンダースコアで始まる全ての識別子は、通常または、タグ名前空間における
省14
346(6): 2021/01/31(日)13:18 ID:ZnRwde8F(2/13) AAS
>>337
それは問題ではないんだけど、
#define a(x) { int _x = 1; _x = x * 2; printf("%d",_x);}
のようなマクロが有ったとすれば、
int y = 5;
a(y); // 10 と表示される。
と
int _x = 5;
a(_x); // 2 と表示される。
347(1): 2021/01/31(日)13:42 ID:Rr91L/mp(1) AAS
int と自作クラス A の pair を priority_queue に入れようと思ったら pair<int, A> に対する less の定義(？)が要るって言われました
int だけに基づいてソートしてくれたら結構なんですが、最も簡単な書き方はどんなですか
また、自作クラス A は array を継承しているのですが、less の定義も引き継ぐ方法はないのでしょうか
348: 2021/01/31(日)14:05 ID:WjHCKOmN(1/3) AAS
いろんな見解があってややこしいから、安全側に倒して「_で始まる名前は一切使うな」でいいと思ってる
コンパイラ実装するような奴以外はそれで困らんやろ
349: 2021/01/31(日)14:10 ID:gXTMTlGe(3/8) AAS
【HOW】予約済みの席に座る方法【TO】
350(1): 2021/01/31(日)14:15 ID:WjHCKOmN(2/3) AAS
>>347
using Aitem = std::pair<int, A>;
using Aqueue = std::priority_queue<Aitem std::vector<Aitem [](const Aitem& lhs, const Aitem& rhs){ return lhs.first < rhs.first; }>
Aqueue your_queue;
351(1): 2021/01/31(日)14:54 ID:bSEeGU13(2/3) AAS
>>345
ファイルスコープとローカルスコープは違うよ。
あと、今議論中なのはアンダースコアひとつで始まるメンバ変数についてなんで、アンダースコアの連続がアウトなのは誰でも知ってるし、餃子も324で書いてる
352: 2021/01/31(日)15:06 ID:gXTMTlGe(4/8) AAS
盛 り 上 が っ て ま い り ま し た ↑
353: 2021/01/31(日)15:07 ID:gXTMTlGe(5/8) AAS
SRELLって知ってますか？
上下前次1-新書関写板覧索設栞歴
あと 649 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.046s