C++相談室 part154

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

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

テンプレここまで

**デフォルトの名無しさん** · 2021/01/31(日) 17:15:05.39

>>380
「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.」
「file scopeを持つ識別子として使用されるために予約されている」
だべ？
block scopeを持つ識別子として使用されたら、話がおかしいと思うが。

「この自動車は、仕事で使うために予約されています」
の場合、その自動車を私用で使えば、規則違反だよね。

**デフォルトの名無しさん** · 2021/01/31(日) 17:15:45.54

int _x; //こんなのがあっても
#define b(x,y) {int _x=x; int _y=y; f(_x,_y); g(_x,_y); } //ブロックスコープで保護されるだろうが

**デフォルトの名無しさん** · 2021/01/31(日) 17:19:07.49

>>382
でも、_ が最初に来る名前をアプリが使っちゃいけない、というのは伝統的にそういう
ことが一番の目的だと思うぞ。
もう一つは、コンパイラの内部でこっそり使う場合があって、それと知らないうちに
衝突する可能性が僅かにあるため。
なぜこっそり使うかと言うと、絶対に衝突しないようにコンパイラ側を
書こうとするとコンパイラ作りに手間がかかるから。
もし、アプリ側が命名規約を守ってくれていれば、コンパイラ作りが楽になる
ことがある。

**デフォルトの名無しさん** · 2021/01/31(日) 17:20:06.45

>>384
b(_y,_x)
と書いたらどうなるか考えてみたらしだんご。

**デフォルトの名無しさん** · 2021/01/31(日) 17:25:17.52

>>385
おまえさんはコンパイラ屋か？
そうだとして同業者は__builtin_va_argのように注意深くやってるぞ
自分らのエゴのために客に制限をかけるようなことを
でかい声で叫びまくるのはやめてくれ

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

>>387
まあ、本当はコンパイラ内部でこっそり使う場合、絶対に衝突しないような
もっと変な名前を使っているから大丈夫なんだ。
起動時の TickCounter の値を変数名の一部に入れたりとかね。

**デフォルトの名無しさん** · 2021/01/31(日) 17:37:15.73

>>383
ローカルスコープで同じ名前の別変数を定義するのは「その自動車を私用で使う」ことには当たらないって言ってるの

**デフォルトの名無しさん** · 2021/01/31(日) 17:42:24.07

ヘッダーファイルに書くか、ソースファイルに書くかの違いも大きい。
ヘッダーファイルに書くときは名前衝突に対する細心の注意が必要。

**デフォルトの名無しさん** · 2021/01/31(日) 17:45:15.36

>>386
{int _x=_y; int _y=_x; f(_x,_y); g(_x,_y); }
どうなるって言いたいんだ？

**デフォルトの名無しさん** · 2021/01/31(日) 17:51:16.48

C/C++の場合、スコープだけ意識するのは不十分で、ヘッダーかソースかで厳格さを変える柔軟性が必要。
ヘッダーに書くと影響範囲が大きいから。

**デフォルトの名無しさん** · 2021/01/31(日) 17:57:13.23

テンプレートなんか普通にヘッダに内容全部を書くが
マクロでバカやるやつがいなければ平和だよ

**デフォルトの名無しさん** · 2021/01/31(日) 17:58:49.95

ローカルスコープでも _x が禁止だというなら >>346 のマクロ a 定義内で _x を使っていい理屈もわからんよな。

**デフォルトの名無しさん** · 2021/01/31(日) 18:55:26.91

std::pair<>を継承してquadを作る場合どうなりますか？

**デフォルトの名無しさん** · 2021/01/31(日) 18:58:05.19

std::regexが意外と使える子に成長してますが、標準化委員会では捨て去る提案まで出てるそうで。

**デフォルトの名無しさん** · 2021/01/31(日) 19:37:14.68

std::regexはプロパティが貧弱なので結局、従来の正規表現ライブラリ使う羽目になる。
std::regexと互換性のあるインターフェースを持つ正規表現クラスを提供するよう呼びかけるのが現実的。

**デフォルトの名無しさん** · 2021/01/31(日) 19:51:04.44

順序付き pair って自分で順番に格納するのと2要素のsetにするのどっちが良いですか

**デフォルトの名無しさん** · 2021/01/31(日) 20:39:53.24

pairはSTLのアルゴリズムの恩恵を得るための物。
自宅の郵便受けを豪華にしたところで、郵便事業には何の関係もない。ただの趣味の世界。

**デフォルトの名無しさん** · 2021/01/31(日) 21:08:09.18

set< pear<int, int> > で、ある数を含む pear を高速に検索する方法ってある？

**デフォルトの名無しさん** · 2021/01/31(日) 21:47:36.00

set<int, vector<pair<int,int>*>>
元の集合に１億個程度のペアが入ってるとすると、住所録めいたものをあらかじめ生成しておく

配列でやっても速そう
list[m].empty()
こういうリストで空っぽかどうかわかればいいわけだ
vector<vector<pair<int,int>*>>>;

それならドでかい二次元配列に入れた方がラクかもしれない

連想配列でも出来る
map<int ,vector<pair<int,int>*>>>

静的な話だったが動的つまり追加と検索が交互に起こるとおそらく話は違ってくる

全部試して早かったモンが高速である、程度の他愛ない結論に落ち着く

**デフォルトの名無しさん** · 2021/01/31(日) 22:01:19.63

構造体にしろよバカども
読みにくいだろ

◆QZaw55cn4c · 2021/01/31(日) 22:54:08.94

>>333
>>339
では _x ではなく x_ にしようっかな‥‥

**デフォルトの名無しさん** · 2021/01/31(日) 23:01:41.96

googleスタイルガイドはそちらを推してるな

**デフォルトの名無しさん** · 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)みたいな関数を用意して対処すると思う。