C++相談室 part154

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

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

テンプレここまで

**デフォルトの名無しさん** · 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

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

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

>>503
それはもう50年くらいずっとそうだろ。
ノーコードとか逆に俺様言語作ってるのとほぼ変わらん状態にしかならんという
しょーもない展開しか見たことない。

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

VCPKGのupdate、upgradeが常に失敗するんだけど、使えてる人いますか？
小まめにupdateしないからだろか？

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

Goは標準ライブラリが圧倒してる。

**デフォルトの名無しさん** · 2021/02/05(金) 15:18:44.78

半年に一度フルビルドみたいになってしまう。

**デフォルトの名無しさん** · 2021/02/05(金) 16:12:02.35

Goは何がクソといってまず名前がクソ

**デフォルトの名無しさん** · 2021/02/05(金) 16:36:26.85

C++は基本だから、義務教育で習得するべき。

**デフォルトの名無しさん** · 2021/02/05(金) 16:50:43.11

言語仕様がでかすぎるからC言語で精一杯
オマケで紹介される程度かな

**デフォルトの名無しさん** · 2021/02/05(金) 18:21:14.28

>>505
昔はアセンブラすら触れない奴がC言語とか笑わせるなとか真顔で言う人がいたんだぜ。

別に仕事ができるのならRustでもPythonでも何でもいいと思うぞ。

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

仕事ができるのならw

**デフォルトの名無しさん** · 2021/02/05(金) 20:48:06.29

>>512
仕事ができるならなw
できないカスがクソみたいなもん押し付けてくるから文句が出るんだよ。
rustでもpythonでもまともなコード書いてりゃ文句はないわ。
まともじゃないから文句が出る。

**デフォルトの名無しさん** · 2021/02/05(金) 21:49:13.85

というか、プログラマとしてrust(鉄さび、腐食)になるというダブルミーニングを狙ったんだと思うけど。

**デフォルトの名無しさん** · 2021/02/05(金) 21:59:53.11

お前らってド素人のくせになんでいっちょまえの口利くん？
それって不思議だわ

**デフォルトの名無しさん** · 2021/02/05(金) 22:34:33.49

Rustの名前は金属の錆じゃなくてサビ菌が由来

**デフォルトの名無しさん** · 2021/02/05(金) 22:36:07.20

Rottenでいい

**デフォルトの名無しさん** · 2021/02/05(金) 22:48:47.57

Perl6はRakuになってしまったし、Rustもいずれ「わびさび」の境地でSabiに改名されるでしょ。

**デフォルトの名無しさん** · 2021/02/06(土) 03:04:22.39

「まともなコードが書けるなら」じゃなくて、まともなコードを強制するのがRustという言語の方針だと思うが

**デフォルトの名無しさん** · 2021/02/06(土) 04:45:05.79

>>284
昔からのプログラミング/電気界隈の慣習だから仕方ないけど、2要素のミニマルなブール代数しか扱わないにも関わらずboolean型を称するのがそもそもキモい
プログラミングで使うような半順序関係は、9割booleanで書くのが一番スッキリする
一般のbool型をプリミティブにして、そこからt/fやら三要素やらに派生するのが合理的に思う

**デフォルトの名無しさん** · 2021/02/06(土) 04:50:47.70

ブーリアン革命。

**デフォルトの名無しさん** · 2021/02/06(土) 05:13:59.88

革命というか、クラスシステムでブール代数をエミュレートしてるのが現状のOOPじゃないかと
まあ言語によって可補性はマチマチだけど、全てについてスーパークラス/サブクラスなクラスを設けるのは、メインストリームの言語では大体そうだろ

**デフォルトの名無しさん** · 2021/02/06(土) 07:27:56.30

>>520
だとしたら胡散臭さ200%のカルトだな

**デフォルトの名無しさん** · 2021/02/06(土) 09:31:12.13

>>524
Java、Kotlin、Scala、C#、Ruby、Python、PHP
あたりのどれかを触ってみれば、危険な記述を言語仕様レベルで封印することのありがたさが分かる

他言語も触ってみることをオススメする

**デフォルトの名無しさん** · 2021/02/06(土) 09:34:34.84

よくわからんが安全カミソリみたいなものかね？

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

>>526
そんな感じ

まぁ、C++もマスターすれば危険な記述を避けることはできるんだけど...
プログラマーが悪意を持ってプログラムを記述しない限り安全なコードになるようにしようという試みは大切だと思う

**デフォルトの名無しさん** · 2021/02/06(土) 10:11:15.51

>>525
ありがとう、おまえさんのレベルの低さがよくわかった
文法や動作がよくわかってなくてマシンに警告してもらわなきゃ自分では判断できないんだな
アプリの内容として良からぬ事を企むという次元には程遠いわけか

**デフォルトの名無しさん** · 2021/02/06(土) 10:12:54.42

>>528
投稿した瞬間の不意打ちレスワロス

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

>>527
> プログラマーが悪vログラマーが悪意を持ってプログラムを記述しない限り安全なコードになるようにしようという試みは大切だと思う

>>528
> 文法や動作がよくわかってなくてマシンに警告してもらわなきゃ自分では判断できないんだな

この流れは大草原不可避

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

>>504
Unity とか UE はきらい？