C++相談室 part154

**デフォルトの名無しさん** · 2021/01/08(金) 17:54:00.55

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

テンプレここまで

**デフォルトの名無しさん** · 2021/01/26(火) 13:54:11.58

野菜の活〆を発明したら儲かるだろな。
放射線以外で。

**デフォルトの名無しさん** · 2021/01/26(火) 21:06:31.25

いいかげんスレ違い。

**デフォルトの名無しさん** · 2021/01/26(火) 21:46:24.92

プリプロセッサマクロだらけの“汚い”コードを否定したらC/C++の強みを失うことになる。
JavaやC#はプリプロセッサマクロが貧弱なのが玉にキズだ。

**デフォルトの名無しさん** · 2021/01/26(火) 21:51:10.66

pybind11スレがないこんな世の中じゃ～Python～
まぁマクロの塊のような代物だが。

**デフォルトの名無しさん** · 2021/01/27(水) 06:03:44.65

C++はコミュニティで発言力のある人が大抵率直にものを言い過ぎる、悪く言えば口が悪いので忌み嫌われてるとこある

**デフォルトの名無しさん** · 2021/01/27(水) 07:30:48.85

>>229
カダベリンやムスカリンが発生してたり
セレウス菌が大量にいるのは
そういう問題じゃねえぜ

**デフォルトの名無しさん** · 2021/01/27(水) 07:48:28.28

でも、Linux板なんか失敗したボランティアの住所載せて、放火しろとは言ってませんよ？？言ってませんよ？？・・・などの書き込みあるからな。
それに比べれはだいぶ良識的では？

**デフォルトの名無しさん** · 2021/01/27(水) 11:26:52.94

C/C++のプリプロセッサも貧弱すぎ

**デフォルトの名無しさん** · 2021/01/27(水) 17:43:27.13

C++例外のスタック情報がとれないのはC++の欠点。
例外でスタック情報を使えるJava/C#/Python/Perlはエライ。

**デフォルトの名無しさん** · 2021/01/27(水) 21:51:38.91

おまえは二度とC++使うな

**デフォルトの名無しさん** · 2021/01/27(水) 23:04:53.57

>>239
スタックフレーム作ればイケるってば

**デフォルトの名無しさん** · 2021/01/28(木) 09:07:27.76

>>235
例えば誰？

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/28(木) 10:23:46.51

>>239
gdb にアタッチしたことないんか？

C++23 には stacktrace が入るから
デバッガを使いこなせなくても少し楽にトレースできるかもな。

**デフォルトの名無しさん** · 2021/01/28(木) 10:52:39.05

>>223
フグは豚肉に触感似てるけどフグの方が美味い

**デフォルトの名無しさん** · 2021/01/28(木) 10:54:00.53

>>228
日本で感染爆発が起きてないのは以前からジビエが流行してたからか

**デフォルトの名無しさん** · 2021/01/28(木) 10:55:14.42

>>230-231
白菜は外の皮じゃなくて中の芯から先に食べろと言われている

**デフォルトの名無しさん** · 2021/01/28(木) 11:40:01.79

>>200
ユニコ時代だからAPLよりずっと先行ってるぞ
組み込み演算子で∩∉とか集合論の記号採用してたりアトミックな演算子は⚛++とか洒落効いてたりする
一方で古代perlのプレフィックスは緩和されてる

**デフォルトの名無しさん** · 2021/01/28(木) 11:51:37.25

∅∘∩ ⊍∪ ⊖ ⊎ ∖≅ ∈ ∉ ∋ ∌ ≡
≢ ⊂ ⊄ ⊃ ⊅ ⊆ ⊈ ⊇ ⊉ ≼ ≽.«»≠␤
他組み込みではこんな感じか
>= やらよりmずっと可読性高いと思う、エディタもvimとか高機能なのなら問題なかろう
␤文字を表示してくれるのは特に便利

**デフォルトの名無しさん** · 2021/01/28(木) 11:58:59.45

>>245
さすがにコウモリはどこの地方でも食わんだろ

**デフォルトの名無しさん** · 2021/01/28(木) 17:23:15.04

なんでプリミティブ型って継承できんの？

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/28(木) 17:29:22.44

>>250
やりたいときってあるか？

**デフォルトの名無しさん** · 2021/01/28(木) 17:41:41.73

クラスAのオブジェクトをクラスBのメンバにするときってどうやってAのコンストラクタ呼ぶの？

class B{
　A a;

public:
　B(){
　　// この辺でAのコンストラクタを呼びたい
　}
};

**デフォルトの名無しさん** · 2021/01/28(木) 17:48:00.82

>>252
メンバのコンストラクタの方が先に呼ばれる。だからそこでは既にAは構築済み。
どうしてもBのコンストラクタ内でAのコンストラクタ呼びたいなら、メンバ変数はポインタで持つ

**デフォルトの名無しさん** · 2021/01/28(木) 18:07:20.07

>>243
gdbはおいとくとして、Visual StudioってC++例外のスロー位置を追跡できたっけ？

**デフォルトの名無しさん** · 2021/01/28(木) 18:50:38.47

>>252
初期化リストを使う
B() : a(hoge, piyo)

**デフォルトの名無しさん** · 2021/01/28(木) 18:54:30.61

あとで再初期化したくなること多いから、結局コンストラクタの実装を別の関数に分離すること多いよね。
コンストラクタの種類が増えたら使いまわしたくなるし。

**デフォルトの名無しさん** · 2021/01/28(木) 19:24:37.48

>>243
デバッガ使いこなせないとか話にならんだろ・・

**デフォルトの名無しさん** · 2021/01/28(木) 19:28:49.13

デバッガやシンボルがない環境でもスタックトレースできたほうが良いと思うけどね。
後発言語の生産性の高さはこの辺の充実ぶりにあるでしょ。

**デフォルトの名無しさん** · 2021/01/28(木) 19:42:24.27

他プロセスと連携するシステムにはデバッガを当てにくい事が多い。
タイミング依存の不具合を追跡する場合、デバッガがまったく役に立たない。

**デフォルトの名無しさん** · 2021/01/28(木) 20:25:47.81

>>258
その手の生産性と成果物の効率はトレードオフでどっちを重視するかが違うだけでしょ

**デフォルトの名無しさん** · 2021/01/28(木) 20:36:13.14

デバッガ使いこなすとか言って悦に入ってる人と会話が噛み合わないんだが。

**デフォルトの名無しさん** · 2021/01/28(木) 20:36:14.66

>>258
だよね
むしろデバッガをアタッチできる環境ならスタックトレースはなくてもなんとかなる
ユーザー環境でスタックトレースがテキストファイルに落ちるようになってるとトラブルシューティングがしやすい

**デフォルトの名無しさん** · 2021/01/28(木) 21:29:31.41

>>261
ここほとんどアマチュアの人だから許してやろうやｗ

**デフォルトの名無しさん** · 2021/01/28(木) 21:48:11.74

>>261, >>263
悪いがプロだよ
IDEの機能を使いこなせてない初心者が、先に学ぶべきことから逃げて言語だけでどうにかさせようとするような
(いつものことだが)はちみつのミスリードに釘を刺しただけだ

**デフォルトの名無しさん** · 2021/01/28(木) 21:51:13.66

>>261
あと、流れを読む限り俺の発言が気に入らなくてファビョってるのは君の方だよね、俺1行しか書いてなかったし(しかも大した内容じゃない)w
何が気に障ったんだ?

**デフォルトの名無しさん** · 2021/01/28(木) 21:51:23.69

いやごめん、俺は流れは一切追ってなくて他意はないよ
茶化したかっただけ
気にしないで

**デフォルトの名無しさん** · 2021/01/28(木) 23:50:09.41

発狂やないかｗ
Perlの人かな

**デフォルトの名無しさん** · 2021/01/28(木) 23:53:15.94

>>253,255
じゃあ、Bを構築してしばらく経ってからわかる情報を使ってAを構築したいとき、Aのインスタンスをメンバとして持つのは不可能ということですか？
ポインタで持つ以外の方法はない (想定されてない？) のでしょうか

constなメンバ変数を初期化するときも近いことを思います

**デフォルトの名無しさん** · 2021/01/29(金) 00:10:27.15

>>268
そういうコンストラクタ制約を持つクラスはけっこう多い。
WindowsのC++向けGDI+ライブラリのクラス群はまさにこれが当てはまる。
広範に存在している以上は受け入れるしかない。
今時は標準でshared_ptrなどの共有ポインタクラスを使えるので、さほど問題にならないでしょ。

**デフォルトの名無しさん** · 2021/01/29(金) 00:19:48.35

>>268
Aに引数なしのコンストラクタ、コピーorムーブ代入演算子があるなら、後で作って代入でもいいけど
まぁ特に理由なければ(スマート)ポインタで持った方が無難だし楽

constはどうしようもない

**デフォルトの名無しさん** · 2021/01/29(金) 00:22:16.89

>>268
「Bを構築してしばらく経ってからわかる情報」を返すヘルパー関数を作って初期化リストの中で呼べばいいじゃない

**デフォルトの名無しさん** · 2021/01/29(金) 07:49:13.10

データメンバをconstってあんまりやらないな
publicに晒すとかじゃなきゃメンバ関数を
constにするだけで足りるから

あ、staticメンバのconstはよくやるけどね

**デフォルトの名無しさん** · 2021/01/29(金) 08:02:53.38

>>251
ある
実装は同じunsigned longでも意味が違うから別クラスとして扱いたいときとか
private継承できたらﾅｱ……
現状（C++03）はプリミティブ型と同じ演算子（のうちの当座のアプリケーションで使うやつ）をいちいち実装したクラスを作って
NDEBUGマクロで実装を切り替えるみたいな涙ぐましい努力が要る

**デフォルトの名無しさん** · 2021/01/29(金) 08:05:13.74

訂正orz
誤： private継承
正： public継承かつoperator unsigned long()はprivateかつunsigned longからの構築はexplicit

**デフォルトの名無しさん** · 2021/01/29(金) 08:08:37.91

メンバをconstにして代入演算子を定義せずにいるとデフォルトの代入演算子をが定義できないとコンパイラに文句を言われる俺環、

**デフォルトの名無しさん** · 2021/01/29(金) 09:20:50.39

>>273
それ、継承できたとして式の中で混在しても区別されないんじゃね？
テンプレートの型引数で区別するような使い方くらいしか思いつかないが。

**デフォルトの名無しさん** · 2021/01/29(金) 12:20:22.74

メンバ変数のconstはポインタ型ならすることあるけど、値で持つメンバ変数はあんまり意味なくない？
constなくても勝手に外部から書き換えられないように、ちゃんと隠蔽しとけばいいだけでしょ

**デフォルトの名無しさん** · 2021/01/29(金) 12:35:16.78

>>277
class内の処理においても変更しないつもりだ、変更されることはない、と明示することで意識しておかなければならないことを少し軽減できるのだから、無駄ではないと思う。
手間をかけずにconstにできるならしておけばいいし、逆に無理して複雑なことをしてまでconstにする必要はないという程度のことかと思う。

**デフォルトの名無しさん** · 2021/01/29(金) 12:55:03.34

>>278
たしかにconst付いてればコンストラクタで設定した値がずっと変わらないことが
明示的になるから無意味ではないか

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/29(金) 14:10:30.45

>>273
そういう用途なら opaque alias という提案だけは出てるけど
どう見てもグダグダなんで、場当たり的な方法のほうがマシだと思うよ。

**デフォルトの名無しさん** · 2021/01/29(金) 16:04:20.47

>>251
3値のboolean作るときってboolean継承すべき？

**デフォルトの名無しさん** · 2021/01/29(金) 16:07:44.73

>>256
言いたいことは判るが
コピーコンストラクタやムーブコンストラクタが勝手に使われるから
デフォルトに任せてると何が起こるかは判ってた方が良い

**デフォルトの名無しさん** · 2021/01/29(金) 16:10:21.66

>>259
COMサーバーというかDX用にフィルタ書いてると訳判らなくなった

**デフォルトの名無しさん** · 2021/01/29(金) 16:56:37.48

>>281
3値のbooleanを作って何するの？
boolへのポインタにしてtrue / false / nullptr の3値でなんとかならんか？

**デフォルトの名無しさん** · 2021/01/29(金) 17:20:59.69

boostにtriboolってのがあるな

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/29(金) 17:23:22.91

>>281
仮に真偽値型を継承可能であったとして、三値型が真偽値型を継承するのはおかしいだろう。
場合によって柔軟な判断が必要な場合はあるものの、
継承は is-a 関係を表したいときに限ったほうがよろしいというのが一般的な設計原則だと思うが。

**デフォルトの名無しさん** · 2021/01/29(金) 17:25:47.23

nullableか、DBのフィールド値？

**デフォルトの名無しさん** · 2021/01/29(金) 18:57:54.24

はちみつ餃子「スタックトレースできないならデバッガ当てればいいじゃない」

**デフォルトの名無しさん** · 2021/01/29(金) 19:41:08.91

典型的な円楕円問題だな

**デフォルトの名無しさん** · 2021/01/29(金) 19:56:26.71

テンプレートを使えば、クラス継承に依存しない記述が可能。
iostreamが黒歴史扱いである現実を踏まえての話。

**デフォルトの名無しさん** · 2021/01/29(金) 21:24:08.77

とりあえずiostream批判しとけば訳知り顔ができた気に浸れる浅はかなやつ

**デフォルトの名無しさん** · 2021/01/29(金) 21:35:39.96

c++ニワカあるあるだよなｗ
iostreamとりあえず批判奴ｗ

**デフォルトの名無しさん** · 2021/01/29(金) 21:39:11.47

iostreamは使いもしないメンバ変数を継承することを強要される悪い手本でしょ。

**デフォルトの名無しさん** · 2021/01/29(金) 22:16:38.63

何も説得力を示さずに突然「悪い」と言い出す

**デフォルトの名無しさん** · 2021/01/30(土) 01:56:51.26

iostreamはクソなのは正解だが別に批判するようなことでもない
なぜなら使わなければいいだけの話だからだ

**デフォルトの名無しさん** · 2021/01/30(土) 02:06:50.03

無理にクラス継承を使わずオーバーライド関数とそれを使うテンプレート関数を充実させたほうが幸せになれる。

**デフォルトの名無しさん** · 2021/01/30(土) 02:41:04.49

別に無理して継承を使っているわけではない
どっかの馬の骨が気に入らんからといって
あれを使うなこれを使うなと言われるほうが無理そのものだ

**デフォルトの名無しさん** · 2021/01/30(土) 02:53:37.72

例えば、ファイルに書き込む処理があったとする。
ファイルハンドルとして有名な型としては、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)
{
WriteBuffer(o, "write test1");
WriteBuffer(o, "write test2");
}

**デフォルトの名無しさん** · 2021/01/30(土) 03:53:39.52

ドヤってるところすまんがそれオーバーライドじゃない

**デフォルトの名無しさん** · 2021/01/30(土) 04:01:05.04

ﾌﾟｹﾞﾗ

**デフォルトの名無しさん** · 2021/01/30(土) 05:45:11.84

フリー関数とクラスメンバでは、インテリセンスが効くか効かないかの違いもある。

**デフォルトの名無しさん** · 2021/01/30(土) 05:52:17.44

そんなあなたに名前空間

**デフォルトの名無しさん** · 2021/01/30(土) 06:06:53.60

クラスの場合、名前空間を書かなくても、インテリセンスが効く。

**デフォルトの名無しさん** · 2021/01/30(土) 06:47:43.00

コンストラクタの初期化リストで
class A{
　int x;

public:
　A(int x) : x(x) {}
};
みたいにしたとき、ちゃんとメンバのxがコンストラクタの引数のxで初期化されますよね？
メンバの x と同名の引数の x が同一のスコープに同居しているようで紛らわしいかなと思ったのですが、こういう書き方を避ける慣習はありますか

**デフォルトの名無しさん** · 2021/01/30(土) 07:04:07.72

自分は普通にその書き方してる
避ける人も居るっぽいけど好きなようにすればいい

**デフォルトの名無しさん** · 2021/01/30(土) 09:09:49.20

iostreamマンセーバカってのは型安全ならどんな仕様でも良いと思ってるカスが多いからな。
型安全は評価する一項目に過ぎないってのに。

**デフォルトの名無しさん** · 2021/01/30(土) 09:29:38.23

iostreamは整形のための情報をわざわざ状態として持たされるのがクソ
当時は状態が邪悪だっていう考え方が一般的じゃなかったからしょうがないけど

**デフォルトの名無しさん** · 2021/01/30(土) 09:38:20.91

でも状態もってなかったら記述が煩雑になりすぎない？
HTMLのマークアップとまでは言わんまでも

**デフォルトの名無しさん** · 2021/01/30(土) 09:59:20.80

整形設定を記憶する変数インスタンスをiostreamインスタンスと分離すべきって話でしょ。
必要に応じて差し替えできるように参照渡しするか、逆にiostreamを参照渡しするとか色々やれたはず。

**デフォルトの名無しさん** · 2021/01/30(土) 10:06:40.70

というか他のオブジェクト指向言語だと整形情報がFormatterクラスとかに分離されているのが普通だし。

**デフォルトの名無しさん** · 2021/01/30(土) 10:32:05.24

FORTRANのFORMAT文が好きな人をどうこうしようとは思わない

**デフォルトの名無しさん** · 2021/01/30(土) 10:40:52.47

初歩的な質問なのですが、stringクラスの内部バッファはデストラクタで破棄されるため自分では一切管理しなくていいという認識で良いのでしょうか？

**デフォルトの名無しさん** · 2021/01/30(土) 11:17:24.76

アロケータによるけど、普通は管理しなくて良いのでは？

**デフォルトの名無しさん** · 2021/01/30(土) 12:47:13.80

>>308
状態持ってても無駄に煩雑(複雑ではない)

**デフォルトの名無しさん** · 2021/01/30(土) 12:57:10.51

iostream 型安全なのはいいけど、char/signed char/unsigned char ぜんぶ文字扱いするのはやめて欲しかった。

**デフォルトの名無しさん** · 2021/01/30(土) 13:18:35.30

単項プラスで。

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/30(土) 13:18:38.04

>>309
入出力を直接的に司るバッファクラス (basic_streambuf) と
書式制御を司るストリームクラスを分離したデザインになっているし、
必要に応じて差し替えることも出来るよ。

iostream においてそれがわかりやすいか、良いデザインであるかは別として、
ちゃんと分離したデザインになってる。

◆QZaw55cn4c · 2021/01/30(土) 14:53:52.50

>>304
私は馬鹿なのでメンバ変数とコンストラクタ引数を x, _x というふうに書き分けています、馬鹿が感染るかもしれないのでお勧めはしません

**デフォルトの名無しさん** · 2021/01/30(土) 15:08:20.24

C++でのメンバ変数は、標準的には m_xと書く。

**デフォルトの名無しさん** · 2021/01/30(土) 16:04:40.96

>>319
何処信者だよ
ダッサw

**デフォルトの名無しさん** · 2021/01/30(土) 16:41:05.48

MicrosoftとAdobeがその書き方多いですね。

**デフォルトの名無しさん** · 2021/01/30(土) 17:13:12.28

なお、_x は、命名規約上、禁止。先頭が _ の名前はコンパイラなどの
システム予約なため。

**デフォルトの名無しさん** · 2021/01/30(土) 17:14:26.98

そうだったっけ？

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/30(土) 17:19:55.79

>>304
>>318-319
命名規約の方法論は色々なのでプレフィクスを付けるルールが定めてある場合もあるし、
むしろ一致させていくようにしているものもある。
私自身は、少なくともメンバに値を設定するだけの単純なコンストラクタである場合には
名前を一致させていくスタイルで書く。

C++ を使う上でのガイドラインとしてよく参照されているのはグーグルのスタイルガイドで、
データメンバの名前は最後にアンダースコアを付けるようにルールを定めている。
https://google.github.io/styleguide/cppguide.html#Variable_Names

その一方では C++ の設計者である Stroustrup は型やスコープを変数名に含めるのは好ましくない
(しかし部分的に便利な場合もあることは認めている) と書いている。
https://stroustrup.com/bs_faq2.html#Hungarian

どちらの習慣が圧倒的優勢ということはないと思う。

>>322
グローバル変数としてはアンダースコアで始まる名前は予約されているけど、
そうでない場合には問題ない。

ただし、

・アンダースコアで始まって大文字が続く名前
・アンダースコアが連続 (名前の先頭部分以外でも) する名前

は名前の種類やスコープにかかわらずどこでも予約されている。

**デフォルトの名無しさん** · 2021/01/30(土) 17:30:01.20

互いの信仰を侵害してはならないがチーム内では統一されている必要がある
規約の背景は明確である必要がある

**デフォルトの名無しさん** · 2021/01/30(土) 18:08:50.99

>>317
まず、FILE*とostreamが一対一対応していないのがダメ。
せっかくC言語でファイル、パイプ、標準IOがFILE*型としてで統合化・抽象化されていたのに、
C++でostreamとfstreamで分離される劣化が起きた。

**デフォルトの名無しさん** · 2021/01/30(土) 18:30:25.89

ios_baseで統一する形に変わっただけ
それをFILE*がどうたらと駄々こねるのは
頭が堅すぎる実年齢に無関係の老害だ

**デフォルトの名無しさん** · 2021/01/30(土) 18:36:35.02

パイプ処理をostream系で書く奇特な人ってどのくらいいるの？

**デフォルトの名無しさん** · 2021/01/30(土) 18:41:09.24

pythonは定数がないから全部大文字の変数は定数のようにみなしましょう的な談合がある。

**デフォルトの名無しさん** · 2021/01/30(土) 19:00:34.72

定数というか型もない

◆QZaw55cn4c · 2021/01/30(土) 19:09:23.04

>>322
束縛領域が狭いローカル変数とかには、_x を使ってもいいのではないか？と考えていますが‥‥