C++相談室 part154

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

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

テンプレここまで

**デフォルトの名無しさん** · 2021/02/01(月) 01:17:42.16

>>391
int _x=_y;
int _y=_x;
ここの二行目の右辺の_xは、b(_y,_x)の第二引数の_xではなく、一行目
で宣言した_xになっているので、b(_y,_x)の第一引数の_yになる。つまり、
int _x=引数の_y;
int _y=引数の_y;
となるので、{}の中の_x, _yは、どちらも引数の_yの値に等しくなってしまう。
これではマクロ作者が意図したことではなくなってしまう。

**デフォルトの名無しさん** · 2021/02/01(月) 01:19:32.38

>>394
まあ、それはもっともな指摘なのだが、アプリ本体では使用禁止で、
マクロでは使用可能と勝手に解釈してしまうのが一つの流儀。

**デフォルトの名無しさん** · 2021/02/01(月) 01:22:56.68

>>389
そうではなくて、ローカルスコープで使うことそのものが、file scope
で使ってないことに当たるので、規約違反と言うことになると解釈できる
気がするんだ。

なぜそんなルールにしたのかは分からんがな。

**デフォルトの名無しさん** · 2021/02/01(月) 03:22:30.15

>>405
残念だったね。インライン関数使おうね。

>>406
あなたの流儀を規格の定めであるかのように話すのは迷惑なのでやめてくださいね。

>>407
file scope で予約されてる名前を file scope で使ってないなら問題ないね。
規約違反などという解釈にはならない。気のせい。そんなルールになってない。ってことで終われよ。

**デフォルトの名無しさん** · 2021/02/01(月) 07:01:58.51

>>400
unordered_map<int, int>

**デフォルトの名無しさん** · 2021/02/01(月) 07:30:17.18

>>406
マクロ定義内の仮引数名は当のマクロ定義外の何者とも関係しないのでは…
いわゆる束縛変数

**デフォルトの名無しさん** · 2021/02/01(月) 07:38:30.21

として安全に取り扱われる

一方>>346の_xはa(x)が展開された結果が他のプリプロセッサ定義で再置換され得るなら危険
これが起きるかはプリプロセッサの仕様（規格）を見たら白黒付くが
個人的には君子なので危うきには近づかないことに死体、

**デフォルトの名無しさん** · 2021/02/01(月) 08:09:47.67

うちの若いのがあんなアホマクロ書いてたら張っ倒す
まあ、やらかしそうなのはいないけど

**デフォルトの名無しさん** · 2021/02/01(月) 09:26:53.82

>>346
そもそもそのマクロで生成される変数はファイルスコープでないから、そもそも問題外では？

仮にファイルスコープな変数を宣言するようなマクロでも、ユーザが意図せず

**デフォルトの名無しさん** · 2021/02/01(月) 11:43:32.41

仕事に情熱が持てなくなった

**デフォルトの名無しさん** · 2021/02/01(月) 11:43:38.91

>>346
アホだ

**デフォルトの名無しさん** · 2021/02/01(月) 12:06:54.06

>>414
コロナの影響だろな。
福島大爆発の影響も計り知れない。
「原爆ぶらぶら病」で検索してください。

**デフォルトの名無しさん** · 2021/02/01(月) 12:30:15.68

>>408
>file scope で予約されてる名前を file scope で使ってないなら問題ないね。
そうじゃない。
英語原文を読めば、file scopeで予約されているのではなく、file scopeで
使用するために予約されているのだ。
だから、file scope以外で使用することが禁止されている。

**デフォルトの名無しさん** · 2021/02/01(月) 12:32:18.30

>>417
日本語で言うなら、「file scope 専用」。

**デフォルトの名無しさん** · 2021/02/01(月) 12:46:40.95

>>414
ちゃんと飯を食え。
週末はちゃんち休め。

年10日は連続した休暇をとれ

**デフォルトの名無しさん** · 2021/02/01(月) 12:55:04.41

>>417
その一文ばっかりやたらこだわるけど
これが属しているセクションの名前って「17.4.3.1.2 Global names」なんだわ
グローバル名前空間の名前以外については言及してないの
ドラフトならインターネットで無料で見られるんだからこの辺の全容見てきな？

**デフォルトの名無しさん** · 2021/02/01(月) 13:14:13.18

>>417
あらゆる場所で使ってはいけないのなら、7.1.3でわざわざ1つ目と対比させるように使用用途を限定して記載した理由を説明してよ。
普通はコンパイラ実装者のために予約されている、だけで十分でしょ

**デフォルトの名無しさん** · 2021/02/01(月) 13:45:48.95

仕事に情熱が持てなくなった

**デフォルトの名無しさん** · 2021/02/01(月) 13:50:50.97

https://www.learncpp.com/cpp-tutorial/keywords-and-naming-identifiers/comment-page-2/

Second, you should avoid naming your identifiers starting with an underscore, as these names are typically reserved for OS, library, and/or compiler use.

**デフォルトの名無しさん** · 2021/02/01(月) 14:08:01.06

>>373
obj& operator [] (int i) {return elem[i];}
もちろんelem[]の定義はobj elem[];
obj.shape() も実装すると便利

**デフォルトの名無しさん** · 2021/02/01(月) 14:13:00.08

>>416
「コロナでゴロゴロ病」

**デフォルトの名無しさん** · 2021/02/01(月) 15:47:43.70

>>423
そのサイトを紹介して何の証明になるの？

**デフォルトの名無しさん** · 2021/02/01(月) 16:16:30.24

>>426
https://isocpp.org/

**デフォルトの名無しさん** · 2021/02/01(月) 16:22:14.79

C++ is the only real language for expert developers.

**デフォルトの名無しさん** · 2021/02/01(月) 16:55:19.50

C/C++は好きだし比較的最強の部類だと思うけど
夢未過ぎは判断を誤るから色んな言語を適材適所に使えるようになるのが理想

**デフォルトの名無しさん** · 2021/02/01(月) 17:40:26.58

システム記述言語はアセンブラを除けばこの世にCとC++とRustしか、

**デフォルトの名無しさん** · 2021/02/01(月) 17:46:42.82

中国人のありがたいお言葉ですぞ。

**デフォルトの名無しさん** · 2021/02/01(月) 18:02:36.06

大体、この板には中国人や韓国人はほとんど来ず、来ているのはアメリカ人
やヨーロッパやアフリカが多いらしい。

**デフォルトの名無しさん** · 2021/02/01(月) 18:44:36.44

いやrustが最強でしょww

**デフォルトの名無しさん** · 2021/02/01(月) 18:47:23.23

Goは駄目なん？

**デフォルトの名無しさん** · 2021/02/01(月) 18:57:50.94

自作の構造体をsetに入れたいときって operator < さえ定義しとけば良いの？
eraseとかは全部のメンバが同じものを見つけて消してくれると思って良い？

**デフォルトの名無しさん** · 2021/02/01(月) 21:08:59.66

検索するとひろみをお勧めしてくる時点で無理だった。

**デフォルトの名無しさん** · 2021/02/01(月) 21:34:17.50

しかもチップも取るんかーい！

**デフォルトの名無しさん** · 2021/02/01(月) 22:43:42.23

>>435
erase含め、同値性は!(a<b)&&!(b<a)で判定される
全メンバ一致で同値とみなしたいなら辞書順比較する比較関数を定義すればよし

**デフォルトの名無しさん** · 2021/02/01(月) 22:46:24.33

演算子オーバーロードは地雷度高い。

**デフォルトの名無しさん** · 2021/02/01(月) 22:53:14.56

まあ、setに入れるためだけなら演算子オーバーロードするより関数オブジェクト使う方がいいかね

**デフォルトの名無しさん** · 2021/02/01(月) 23:03:45.93

C++の質問じゃないとは思うんですが、上位数ビットを0で埋めたいといった場合は
「0埋めしたいビットを0、他を1にしたもので&演算する」
であってますか？

**デフォルトの名無しさん** · 2021/02/01(月) 23:11:37.27

合ってます。

**デフォルトの名無しさん** · 2021/02/01(月) 23:17:45.03

>>442
ありがとうございます
今までは例えばQWORDの上位3バイトを0埋めしたいってとき(value << 3*8) >> 3*8って言う2命令使う馬鹿な方法でやっていました・・・

**デフォルトの名無しさん** · 2021/02/02(火) 02:08:00.00

へ椅子ブックが少し綺麗になってます。

**デフォルトの名無しさん** · 2021/02/02(火) 02:10:27.05

RedditのC++コミュは17万人、オンラインが500人以上。
凄いね。

**デフォルトの名無しさん** · 2021/02/02(火) 10:17:10.33

ビット演算の中で最速なのってシフトじゃなかったっけ？
だから下手したら>>443の方がフェムト秒レベルでは微妙に早いんじゃない？

**デフォルトの名無しさん** · 2021/02/02(火) 10:29:21.33

命令語長がマスク分だけでもQWORDに対して、シフトなら1バイト程度か

**デフォルトの名無しさん** · 2021/02/02(火) 12:37:23.36

>>446
CPUの世代やアーキテクチャによって違うが、
Latencyが、Shiftの方がandより少し遅いことがある。

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/02(火) 12:49:48.88

>>434
Go は GC が前提にあるから少し制約が強いけども、
OS のカーネルを書くのでもない限り思ったより足かせにならないという評価はあるみたいだね。

**デフォルトの名無しさん** · 2021/02/02(火) 13:08:50.07

Goはクソすぎるから駄目だ
何が駄目といってまず名前が駄目

**デフォルトの名無しさん** · 2021/02/02(火) 13:45:57.34

GoはPC初心者用
昔でいういわばBASIC

**デフォルトの名無しさん** · 2021/02/02(火) 18:03:08.15

バレルシフタと単純ゲート
レイテンシも糞もねえだろ

**デフォルトの名無しさん** · 2021/02/02(火) 18:11:36.53

でもその縛りプレイが大好きな変人も居る

**デフォルトの名無しさん** · 2021/02/02(火) 22:23:15.74

operator ==も定義しておくとなお良い
==のために<が2回呼ばれるのもアホらしいと感じるはず…
結局std::rel_opsを使って全部定義するという結論に落ち着く

**デフォルトの名無しさん** · 2021/02/02(火) 22:25:04.30

インテルのやつはバレルシフタじゃない気配がする…
シフト結果をテーブル化した方が速かったことｇ

**デフォルトの名無しさん** · 2021/02/02(火) 22:28:35.48

あるいは最大限バレルシフタにしようとしているがパイプライン1段に収まっていないだけかもしれん…

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/03(水) 00:25:34.21

>>443
gcc, clang, msvc で最適化最大で試してみたら and をとるように最適化されたぞ。
主要コンパイラがそのように最適化するということは (前後の状況によるかもしれないけど)
たぶん and のほうが効率的ってことなんだろう。

**デフォルトの名無しさん** · 2021/02/03(水) 00:38:50.10

ビットシフトは64bit整数でのコンパイラ解釈が信用できないからAND演算子使うのが確実だと思うけどどうかな。

**デフォルトの名無しさん** · 2021/02/03(水) 00:51:08.70

>>458
落ち着いてよく考えてみよう
お前がC++で作った成果物のうち、お前自身が書いたコードの割合なんてごくごく僅かに過ぎない
仮にそんなレベルで互換性が当てにならないような環境があったとして、お前が直接書いていない他の99%のコードがまともに動くと本気で思うか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/03(水) 00:54:51.58

0xffffffffff とか書いてたら桁数を正しく書けてるか不安になる……

今の C++ だと桁区切りも入れられるけど、
どう入れたら意図がわかりやすいかようわからんし、
シフトで表現するのもありな選択だと思う。

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

>>458
具体例をお願いできますか？

**デフォルトの名無しさん** · 2021/02/03(水) 01:20:23.24

コンパイラがちゃんと32bit整数への丸め警告を出してくれるならいいが、しれっとコンパイルされたらお手上げ。

**デフォルトの名無しさん** · 2021/02/03(水) 02:47:38.99

>>462
丸めって暗黙の型変換のことですか？
シフト演算は特に関係しないと思いますが……

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

>>460
0x0000'ffffull

**デフォルトの名無しさん** · 2021/02/03(水) 06:29:42.77

unsigned long long x = (0x1ULL << 32) - 1ULL;
ならちゃんと動く（と思う）が
unsigned long long x = (0x1 << 32) - 1;
とかだとｲﾏｲﾁ不安が…

**デフォルトの名無しさん** · 2021/02/03(水) 06:38:54.06

>>465
下の方はイコールの右辺にintしか出てこないのだから、intが32bitの環境なら32bitでしか計算されないだろう

**デフォルトの名無しさん** · 2021/02/03(水) 10:23:38.02

丸めと暗黙の型変換は違うものでは？

**デフォルトの名無しさん** · 2021/02/03(水) 11:47:09.95

丸めや打ち切りは浮動小数点数の概念やね

**デフォルトの名無しさん** · 2021/02/03(水) 13:02:19.58

ビットシフト記述は自然すぎてソースコードに埋もれてしまう。
64ビットマスクのAND記述は見た目がどぎついので、かえって人間の注意を引くことができる。

**デフォルトの名無しさん** · 2021/02/03(水) 14:45:43.48

なにいってんだこいつ

**デフォルトの名無しさん** · 2021/02/03(水) 15:50:32.48

>>465
やっぱり、32BITの時が一番プログラミングし易かったな。
64BITになると、64BITと32BITを区別して書く必要が出てきて、
書くのが面倒になった。

**デフォルトの名無しさん** · 2021/02/03(水) 19:12:23.88

そう？ポインタサイズくらいしか違いなくない？

**デフォルトの名無しさん** · 2021/02/03(水) 21:29:02.90

まじめにC/C++標準型size_tを使っている人には32bitと64bitの処理切り分けが地味に辛い。

**デフォルトの名無しさん** · 2021/02/03(水) 22:36:28.54

>>465の下の方のやつは符号拡張されたりする気がするorz

**デフォルトの名無しさん** · 2021/02/03(水) 22:40:25.83

>>424
> obj& operator [] (int i) {return elem[i];}
> もちろんelem[]の定義はobj elem[];

objは行列クラスで、elemはobjのメンバで行列要素を格納する一次元配列、で合ってますよね？
class obj{
　array<int, ?> elem;
public:
　obj& operator [] (int i) {return elem[i];}
};
ということですか？

**デフォルトの名無しさん** · 2021/02/04(木) 03:22:45.38

>>473
size_t は、型名が長いし _ も含んでいるし、打つのが辛い。
それにコードに締める長さも長くなるので画面が狭くなるし。

**デフォルトの名無しさん** · 2021/02/04(木) 04:17:06.60

>>473
まじめに、て別にsize_t使ってたら偉いわけじゃない
サイズを表したいけどいちいち考えたくない場合の選択肢だぞ

**デフォルトの名無しさん** · 2021/02/04(木) 11:32:06.33

size_t型はSTLを使う人なら避けて通れない。

**デフォルトの名無しさん** · 2021/02/04(木) 11:40:48.70

>>471
それ本来そこにあった問題に気付いていないだけだったと思うぞ

**デフォルトの名無しさん** · 2021/02/04(木) 11:44:02.03

>>475
class obj{
　array<obj, ?> elem;
public:
　obj& operator [] (int i) {return elem[i];}
};

**デフォルトの名無しさん** · 2021/02/04(木) 12:06:17.02

>>480
それってarrayのarrayとかvectorのvectorとか配列の配列として行列を作るのと同じですよね？
一次元配列に要素を格納しておいて[][]でアクセスするのは不可能なんでしょうか
row majorやcolumn majorを自由にできる、等の理由でそちらの方が好ましいのですが

**デフォルトの名無しさん** · 2021/02/04(木) 12:29:12.61

一次元配列を内包しているクラスのoperator[](int y)が、下記のようなクラスを返すようにすればできる。

class Row {
vector<int>& 一次元配列への参照
int 列数
int y
int& operator[](int x){ return 一次元配列への参照[列数*y+x]; }
};

でも自分ならoperator[]は使わずもとのクラスにindex(x, y)みたいな関数を用意して対処すると思う。

**デフォルトの名無しさん** · 2021/02/04(木) 13:10:42.29

malloc とか new で確保したメモリ領域を使うように
vector ( または array ) をインスタンス化するにはどうすればよいですか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/04(木) 13:13:43.37

>>481
こういう雰囲気で他のクラスをひとつ間に入れることでなんとかなる。

https://wandbox.org/permlink/ZXI1nkkCLRJQPtAJ

だけど俺も >>482 の言う通り operator[] にこだわらずに適当なメンバ関数でやる方法を推すわ。
実態として二引数なのだし、記法のためだけに余計な定義をするの馬鹿らしいと思う。

提案としては hoge[i, j] みたいな感じで二引数のインデックスを受け取れるようにする案は出てるんだが、
現状ではこのときのカンマは普通にカンマ演算子として解釈される。
前準備として、 C++20 からはブラケット内でのカンマは非推奨にするという変更が入っている。
https://timsong-cpp.github.io/cppwp/n4861/depr.comma.subscript

**はちみつ餃子** ◆8X2XSCHEME · 2021/02/04(木) 13:20:29.03

>>483
ある時点で確保済みのメモリの上にオブジェクトを構築するには
std::uninitialized_default_construct を使う。

でも std::vector 自体を適当なメモリの上に構築できても
std::vector 内で使うメモリは std::allocator で確保しようとするから、
必要ならアロケータを定義する必要がある。

**デフォルトの名無しさん** · 2021/02/04(木) 15:40:11.75

>>479
いや、全て32BITは、それに全て統一することで速度とメモリ効率と実用性の
バランスが取れていた。
ところが64BITだと実用上、表せる値の範囲はオーバースペックで
変数のメモリに占めるバイト数が8バイトと余りにも効率が悪い。
なので、多くの数値は32BITとし、必要な部分だけ64BITにするという
面倒な選択を強いられる様になった。
アドレスが64BITなので、それを整数型に入れるためには32BITの整数では
不足するので引きつられて整数も64BITを必要としがちになり、大混乱
が生じている。
(また、メモリーもアドレスを32BITより多くを必要とするアプリは非常に稀。)

**デフォルトの名無しさん** · 2021/02/04(木) 16:48:02.49

>>482
ありがとうございます
ストラウストラップの「プログラミング言語C++」に「行列クラスの設計」なるセクションがあったのを覚えてるので、そちらではどうしていたかも見てみます

**デフォルトの名無しさん** · 2021/02/04(木) 17:07:22.68

unique_ptr<Hoge[]> p(new Hoge[4]{a, b, c, d});
みたいな定義と同時に代入は出来るのですが
(各要素毎に Hoge(a), Hoge(b), Hoge(c), Hoge(d) になりました)

unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4);
だと引数無しのデフォルトコンストラクタが無いといけないし
(そもそも引数無しのデフォルトコンストラクタ作りたくない)

unique_ptr<Hoge[]> p = make_unique<Hoge[]>({a, b, c, d});
とか
unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4){a, b, c, d};
とかはコンパイル出来ませんでした

引数無しのデフォルトコンストラクタがあれば
unique_ptr<Hoge[]> p = make_unique<Hoge[]>(4);
p.reset(new Hoge[4]{a, b, c, d});
だとうまく逝きますが効率が悪い気がします
make_unique は使ってはいけないのでしょうか？

**デフォルトの名無しさん** · 2021/02/04(木) 17:51:26.68

>>487
485も見てねー

**デフォルトの名無しさん** · 2021/02/04(木) 17:52:07.72

まちがえた。484

**デフォルトの名無しさん** · 2021/02/04(木) 20:56:33.92

配列のunique_ptrは色々と中途半端で使いづらいからオススメしない

**デフォルトの名無しさん** · 2021/02/04(木) 22:14:32.91

>>488
unique_ptr<Hoge[]> p;
p.reset(new Hoge[4]{a, b, c, d});
でよいのでは？

**デフォルトの名無しさん** · 2021/02/04(木) 22:20:26.07

>>486
32bitアプリでも今どきなら64bit整数を使える処理系は多いだろ
そもそもアドレスを整数型に入れるっていつの時代の人よw

**デフォルトの名無しさん** · 2021/02/04(木) 22:47:34.63

>>493
アドレスを整数に入れるのは過去の話じゃないぞ

**デフォルトの名無しさん** · 2021/02/04(木) 22:51:09.67

intptr_t整数型を使ってたのっていつの時代？

**デフォルトの名無しさん** · 2021/02/04(木) 23:24:48.23

uintptr_tならいつもお世話になっております

**デフォルトの名無しさん** · 2021/02/05(金) 00:01:41.63

この手合いのボケを量産するのはC++の害だな

**デフォルトの名無しさん** · 2021/02/05(金) 01:35:15.82

むしろCの害

**デフォルトの名無しさん** · 2021/02/05(金) 01:52:47.05

Rubyって結局勉強しないままPythonの時代になってしまったな

**デフォルトの名無しさん** · 2021/02/05(金) 04:42:48.12

同様にC++を勉強しないままRustの時代になる

**デフォルトの名無しさん** · 2021/02/05(金) 09:51:39.70

>>488
https://www.it-swarm.jp.net/ja/c%2B%2B/new演算子よりもstd-makeuniqueを使用する利点/826350881/amp/
https://ja.stackoverflow.com/questions/24876/make-uniqueの利点

**デフォルトの名無しさん** · 2021/02/05(金) 13:28:24.98

c++やらずにrustとか馬鹿量産するだけにしか思えんな。

**デフォルトの名無しさん** · 2021/02/05(金) 14:10:32.07

それ言ったらノーコードがどうたら言ってる奴らはもっとやばそう

**デフォルトの名無しさん** · 2021/02/05(金) 14:17:08.86

ノーコードていってノードツリーみたいなのでフロー管理するやつ
よくゲーム系ツールにありがちだけど、サンプルみたいな単純な処理ならともかく
こみいったフローになってくるとノード間の接続線がものすごいことになって
とても管理しようという気になれない、まさに見た目どおりのスパゲティプログラムに