C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

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

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

>>260
割となんでか気になるので、よかったら教えてください

**デフォルトの名無しさん** · 2021/06/10(木) 17:16:00.08

多次元配列の in-place な添字の入れ替え (transpose) って上手いやり方知られてますか？
多次元配列の各要素は一次元に配置されてると仮定して良いです (行優先でも列優先でも良いです)

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

>>266-267
ありがとうございます
とりあえず要素そのものじゃなくポインタかインデックスでやれば良いことに気づけました

>>267 >片方だけソートしたら
両方ソートするイメージでした

**デフォルトの名無しさん** · 2021/06/10(木) 20:38:48.11

>>269
縦横の二重ループで一つずつswapするしかないんじゃないかなー
gslやgmtlはそうなってた

**デフォルトの名無しさん** · 2021/06/10(木) 21:10:03.36

>>271
行列で言うと、上三角あるいは下三角の各要素を巡回して対応する要素と swap するみたいなことですよね？

多次元の場合も同じようにできますかね？
例えば3次元配列だったら、直方体を斜めに切って上三角錐か下三角錐の各要素を巡回するって理解で合ってますでしょうか

**デフォルトの名無しさん** · 2021/06/11(金) 11:50:48.69

CMakeについてもこのスレでいいの？

**デフォルトの名無しさん** · 2021/06/11(金) 12:12:28.01

ちょっと違うね
スレないんなら立てたら？

**デフォルトの名無しさん** · 2021/06/11(金) 15:24:20.00

スレ検索したらmakeスレなんて無いんだな
確かにここ10年位makefileなんて書いたことないけど…

**デフォルトの名無しさん** · 2021/06/11(金) 17:20:45.97

VSCodeで書く時は便利なんで・・・

**デフォルトの名無しさん** · 2021/06/12(土) 18:33:47.62

過去に
make 使ったら負け
ってスレがあった

**デフォルトの名無しさん** · 2021/06/12(土) 18:44:06.98

まあ今どきMakefileなんて人間様が書くもんじゃないし

◆QZaw55cn4c · 2021/06/12(土) 20:02:28.17

>>278
え？

**デフォルトの名無しさん** · 2021/06/12(土) 20:28:22.70

え？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/12(土) 20:35:26.24

立ててみた。活用してね。

ビルド自動化ツールCMake Part.1
https://mevius.5ch.net/test/read.cgi/tech/1623496111/

**デフォルトの名無しさん** · 2021/06/12(土) 20:57:53.25

cmakeってすごいよね
Makefile作れるだけかと思ってたらVisual Studioのソリューションファイルなんかも生成できて驚いた

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/12(土) 21:13:38.88

>>282
CMakeはGitHub Actionsと組み合わせると、ビルドとテストが自動化できて最強なんだよ。
コマンドラインで出来るめんどくさい仕事は自動化してほしいよね。

**デフォルトの名無しさん** · 2021/06/12(土) 21:40:08.27

AutomakeもそううだがCMakeはなんでそんなことができるのか原理がわからん……

**デフォルトの名無しさん** · 2021/06/12(土) 21:43:46.98

mesonとかautotoolsとかのビルドツール共用でも良かったかな

**デフォルトの名無しさん** · 2021/06/12(土) 21:49:00.69

ていうかそもそもVisual Studioのslnファイルの仕様とか公式に公開されていましたっけ

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/12(土) 21:52:27.12

>>286
中身見てごらん。テキストファイルだよ。

**デフォルトの名無しさん** · 2021/06/12(土) 22:04:02.95

せっかくスレ作ったのにこちらで話してる

**デフォルトの名無しさん** · 2021/06/12(土) 22:05:38.91

>中身見てごらん。テキストファイルだよ。
ﾋｴｯ…、、、ブラックスワン理論…！

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

バージョン変わるとすぐ壊れるがな。
dockerで環境揃えてmake使った方がよっぽど安定するわ。

**デフォルトの名無しさん** · 2021/06/12(土) 22:27:19.91

>>286
全部のタグを説明するリファレンスのようなものがあるかどうかは知らんけど、ある程度はドキュメント書かれているよ。

**デフォルトの名無しさん** · 2021/06/12(土) 22:33:32.97

>>286
マイクロソフトってそう言うドキュメントは結構まめに公開してるよ
https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2019

**デフォルトの名無しさん** · 2021/06/12(土) 23:44:11.11

M$にベンダーロックインされる。

**デフォルトの名無しさん** · 2021/06/13(日) 00:08:56.86

sln作らなくても最近のVisualStudioは直接cmakeプロジェクト読めるぞ

**デフォルトの名無しさん** · 2021/06/13(日) 03:39:36.78

新しいプロジェクトするならmesonを試したいなー

**デフォルトの名無しさん** · 2021/06/13(日) 10:14:32.44

GYPには期待したんだがもう先がないな。

**デフォルトの名無しさん** · 2021/06/13(日) 13:41:01.17

メンバの構築 (コンストラクタの呼び出し) を後で行いたい
なんでこれしきのことができないんだろうか

「ポインタ使え」はナシね
これしきのことにポインタて笑って感じなんで

**デフォルトの名無しさん** · 2021/06/13(日) 13:44:02.04

C++では、デバッグモードと本番モードの切り替えってどうやるのが普通ですか？
今は、実行時に渡す環境変数で切り替えてます

**デフォルトの名無しさん** · 2021/06/13(日) 14:05:32.61

ビルド時にバイナリ自体を分けるのが多いような

**デフォルトの名無しさん** · 2021/06/13(日) 15:41:03.56

>>297
他の言語の多くは参照型がデフォなんだから、同じことをC++でやりたいのなら他の言語の参照型に相当するポインタを使うのは当たり前じゃん。
どうせポインタよく分からないとかスマポも知らずにポインタめんどくさいとか思ってるからポインタ使いたくないんでしょう？このスレで笑われるのは君の方だよ

**デフォルトの名無しさん** · 2021/06/13(日) 16:45:02.61

まあスマポが他の言語みたいにスマートでもなんでもないゴミみたいな記述法だからなw

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 17:11:16.17

>>298
デバッグモードというのは具体的に何をするモードのことを言ってるの？
一般的に C++ 関連の用語として言うときのデバッグとリリースの違いはコンパイル時のプロジェクトを分けて
実行バイナリ自体が異なるものになるくのが普通だし、
Visual Studio とかを使ってたらリリース版とデバッグ版はそのように分かれるようになってる。

そういう運用の仕方についての質問ではなく、たとえば
「いざというときに現場でデバッグに使えるモードを仕込んでいるけど
　そのモードへの隠しスイッチはどうあるべき？」
みたいな切り替え方をどうすべきかだけの質問なのかな？

もしそうなら環境変数でもコマンドラインオプションでも自然だと思う。

**デフォルトの名無しさん** · 2021/06/13(日) 17:15:24.12

>>301
言語の成り立ちや目的が違うからな
そう思う人は他の言語を使えば良い

**デフォルトの名無しさん** · 2021/06/13(日) 17:23:14.98

「スマート」がなんで「記述法」にかかるんだろう。記述法にそんなもんあるのか？

**デフォルトの名無しさん** · 2021/06/13(日) 17:33:42.92

C++標準としては「NDEBUGマクロで切り替えろ」じゃないの

**デフォルトの名無しさん** · 2021/06/13(日) 17:58:03.62

>>297 std::optional で。ポインタ使うのの何が嫌なのかわからないけど。

**デフォルトの名無しさん** · 2021/06/13(日) 17:58:55.99

>>298 それで切り替えできてるならいいじゃないの。人の数だけある「普通」とかどうでもよくない？

**デフォルトの名無しさん** · 2021/06/13(日) 18:41:43.91

>>300
ポインタは参照型じゃなぁぁぁぁい！ｗ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 18:42:59.35

>>308
だから「相当する」という語が付いてるんだろ？

**デフォルトの名無しさん** · 2021/06/13(日) 18:47:32.61

>>299,305,307
ありがとうございます

**デフォルトの名無しさん** · 2021/06/13(日) 19:00:04.06

C++に関係したフォーラムや掲示板で、一番人が多いとこってどこですか？
海外のサイトでも可です

このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

**デフォルトの名無しさん** · 2021/06/13(日) 19:51:51.12

多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
意味的に一緒かというよりは、実際そういう実装になってるのか知りたいです

かけ算の数が小さくなる工夫みたいのってされてるんですか？

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/13(日) 20:00:41.15

>>312
CPUに合わせた最適化はされてるよ。例えばx86 CPUではメモリーアドレッシングという計算が得意。まあ、コンパイラが吐くアセンブリを見るといいよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 20:15:02.56

>>311
質問なら Stackoverflow とか Teratail とか。

**デフォルトの名無しさん** · 2021/06/13(日) 20:28:49.46

>>313
ありがとうございます
> 多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
というのは大体どんな処理系でもそうで、
> かけ算の数が小さくなる工夫みたいのってされてるんですか？
ここは処理系による高速化がされてるということですね

つまり、大抵は
> 2*y*z + 3*z + 4
に相当する部分を自分で (書いた関数とかマクロで) 計算して a に加えるよりは、a[2][3][4] とアクセスする方が速いんですかね？
>>272の、多次元配列の添字の入れ替えを in-place でやりたいという話で、こういう疑問に行き当たりました

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 20:44:32.87

>>315
それを自分で判断できない知識レベルならコンパイラに任せたほうが確実に良いよ。

「早すぎる最適化は諸悪の根源」とか「実測せよ」というよく知られた格言がある。
仮にちょっとした書き方で高速になるのだとしてもそれによって全体が読みにくいコードになってたら
改善するのが大変になって結果的にあまりよくないコードになってしまいがち。
処理速度が足りないのなら足を引っ張っているのはどこなのか
完成したプログラムを測定してから問題個所を改良すべきというのが先人の教え。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/13(日) 20:51:49.27

>>315
どうやれば高速化するかは、実際のコードで実測とアセンブリみないと解析できない。掛け算の代わりに足し算で計算できる場合はそうした方が早いかもしれない。
x86 アセンブリの場合、MOD eax, [ecx+ebx*2]のように一語でアドレス参照できる場合がある。
高速化手法には、他にもSIMDもあるし、マルチスレッドもある。

**デフォルトの名無しさん** · 2021/06/13(日) 21:02:57.88

>>297
C++11だとnewでメモリだけ最初に確保しといて、も一回 new で
そのメモリ指してコンストラクタ走らせるってやり方？
ポインタ遮蔽するような template書けば良さそうだけど。

◆QZaw55cn4c · 2021/06/13(日) 21:06:50.91

>>308
イコールとはいいませんが、ニアリーイコール、同じようなものですよ‥‥

**デフォルトの名無しさん** · 2021/06/13(日) 21:08:32.23

>>318
わざわざ自分で書かなくてもvectorがちょうどそんな動作してるよね

**デフォルトの名無しさん** · 2021/06/13(日) 21:43:42.51

>>317
ありがとうございます

in-place だと
○ 作業用メモリが必要ない
○ 全要素の半分だけ一回ずつ訪れれば良い
☓ 要素アクセスは自分で書いた関数なりマクロなりで行う必要がある

out-place だと
☓ 作業用メモリが必要
☓ 作業用領域にコピーして元の配列に戻すので各要素を二回ずつ訪れる必要がある
○ 要素アクセスは高速

て感じなので、やってみてどっちが良いか決めます

**デフォルトの名無しさん** · 2021/06/13(日) 22:27:55.12

俺がC++をこよなく愛する理由のひとつがとにかく長年の積み重ねのおかげで
コンパイラが激烈に賢いことだ
他の、たとえばJavaやらそれから派生したKotlinなんかでコード書いてて
「こんぐらいはコンパイラが最適化してくれるっしょ」とかルーズに書いて
実際に展開されたバイトコード見て絶望したことは数えきれない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/13(日) 22:41:11.48

Java の場合は JVM の側で最適化したりするからバイトコードはそんなに頑張らないらしいよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/14(月) 02:15:01.87

makefile (GNU Make) の使い方の質問はどのスレで聞いたらよいんですかね？

**デフォルトの名無しさん** · 2021/06/14(月) 07:14:11.60

>>297
普通に破門
おまえはポインタを使うなではなくC++を使うな
二度とこの世界に戻ってくるな

**デフォルトの名無しさん** · 2021/06/14(月) 08:03:40.16

CMakeのスレ使えば？

**デフォルトの名無しさん** · 2021/06/14(月) 08:09:35.27

>>297
誰もメリット感じないから実装しないんだろ。
ポインタに対するメリットは？

**デフォルトの名無しさん** · 2021/06/14(月) 08:35:37.07

みなstd::unique_ptrを思いついているが質問の仕方が気に食わないのでわざと回答しない

**デフォルトの名無しさん** · 2021/06/14(月) 08:43:01.39

「これしきのことにポインタ」とか言ってるくらいだから>>297にとってポインタのハードルがものすごく高いんだろう。

**デフォルトの名無しさん** · 2021/06/14(月) 10:09:52.82

ｗ

**デフォルトの名無しさん** · 2021/06/14(月) 10:36:17.05

そうは言っても、コンストラクタでしかプロパティ設定できない不親切なクラスを仕方なく使う羽目になることは結構あるでしょ

**デフォルトの名無しさん** · 2021/06/14(月) 10:44:09.11

RAII分かってるならそもそもコンストラクタ呼び出した後に2phaseでメンバ構築やろうなんて思わないから、質問の意図がわかんねーんだよな

**デフォルトの名無しさん** · 2021/06/14(月) 11:25:21.25

>>290
++

**デフォルトの名無しさん** · 2021/06/14(月) 11:30:58.26

>>311
stackoverflow

**デフォルトの名無しさん** · 2021/06/14(月) 11:33:34.30

> このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

知ってるがお前の態度が気に入らない
というケースならいくつか思い当たるな

**デフォルトの名無しさん** · 2021/06/14(月) 11:36:44.15

>>312
>多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると
> *(a + 2*y*z + 3*z + 4) を

*(a + 4 + (3 + 2*y)*z)
くらいのことはやってるよ

**デフォルトの名無しさん** · 2021/06/14(月) 11:40:50.95

>>315
そういう話ならいちいち掛け算してるかとかその回数がとかよりも
メモリキャッシュに乗ってるかどうかの効率の方が多きい

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/14(月) 17:34:14.74

前後の命令の依存関係によっては多少高コストの演算でもパイプラインに隠れて全体としては
それほど時間がかからないということも有りうる。
命令ひとつの実行コストだけでは評価できないから結局のところやってみてから計測するのが
手っ取り早いって話になる。

**デフォルトの名無しさん** · 2021/06/14(月) 18:10:27.40

>>312
現代の普通のコンパイラであれば当然最適化が行われる

コンパイル時に決定可能な部分はコンパイル時に決定するし、
ループ内で変化がない部分はループの外で計算する
のが普通

a[i][j][k] で一番ループの内側がkであれば
a[i][j]まではループの外で行うし
a[1][2][k] のような固定値であればa[1][2]まではコンパイル時に計算する

メモリアクセス順は非常にパフォーマンス的には重要で
a[i][j][k] を3重ループでアクセスする場合
ループの外側からi,j,kとするべき

言語上のいわゆる配列は最適化されやすいので普通は気にしなくていいが、
vectorやMatなど、外部定義の [] は基本的には遅いと思っていい

コストが小さいとはいっても確実にコストは発生する
速度が非常に重要な場合では
SIMD化、キャッシュ化、ループアンロールなどで最適化すべき
その場合も、データ構造、アクセス順、アルゴリズムなど上位層の最適化が終わってから

**デフォルトの名無しさん** · 2021/06/14(月) 22:36:37.28

vectorの[]だって配列へのアクセスしかしてないけどな。
インライン展開されるし範囲チェックもしてない

**デフォルトの名無しさん** · 2021/06/14(月) 23:49:54.30

素人質問ですみません
クラスのメンバ関数は常に外で実装しますか？それとも、短いものはクラス宣言内に書きますか？
混在させて良いものかと迷っています(クラス宣言内に書くとinline指定になる事は知っています

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 00:02:19.94

>>341
どっちでもいいようになっているんだからどっちにするかは個別の判断による。
具体的条件を示してくれたらどちらが好ましいかの意見は言えるよ。

**デフォルトの名無しさん** · 2021/06/15(火) 05:05:22.97

template<class T, size_t N> using myarray = std::array<T, 2*N>;
としたときに、関数 hoge を
template<class T, size_t N> void hoge(myarray<T, N>);
と
template<class T, size_t N> void hoge(array<T, N>);
でオーバーロードすることってできますか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:32:07.52

>>338
高コストという文言の意味がよくわからんが
レイテンシが大きい命令はパイプラインを乱すぞ

**デフォルトの名無しさん** · 2021/06/15(火) 05:35:15.36

>>343
２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
だとすると無理だと思うな

std::array<int, 1> a;
hoge(a);
と呼び出したとき、N==2となるべきかN==1となるべきかの根拠がないから

やってみてないけど
つーか、おまえさんはやってみたのか？

**デフォルトの名無しさん** · 2021/06/15(火) 05:40:17.26

>>345
> ２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
すみません。そうです

まだ試してないです
無理そうだなって思うんですが、昔「オーバーロード関数は機械にとってはそれぞれ別名関数だ」って話を聞いて、じゃあもしかしたら行けるかもと思った次第です

**デフォルトの名無しさん** · 2021/06/15(火) 07:12:05.86

すぐ試せることを自分で試さずに5chで聞くの良くないよ

**デフォルトの名無しさん** · 2021/06/15(火) 07:54:52.19

>>341
templateのクラス書いてると、長くても中に入れちゃうから、でかいのバーンって
そのままヘッダに入れても抵抗はないけど、templateでない場合でかい関数は普通に外に書くな。

**デフォルトの名無しさん** · 2021/06/15(火) 08:01:18.68

>>341
外

templateやstaticのように実装をヘッダファイルに書く場合も
ヘッダファイルの中でプロトタイプと実装に分ける
さらに実装は別ファイルにしてヘッダファイル内で#includeする

宣言だけからなるアウトラインを残したいから

**デフォルトの名無しさん** · 2021/06/15(火) 08:19:37.29

>>343,345-347
試して無理でした
言い方合ってるかわかりませんが、>>343のやり方ではオーバーロードと関数テンプレートの差がないからでしょうか

コンパイラに myarray を array と別の型だと思ってもらって、hoge をオーバーロードするテクってありますでしょうか

**デフォルトの名無しさん** · 2021/06/15(火) 09:04:05.70

>>350
継承でいけるんじゃね

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/15(火) 09:47:07.09

>>350
using で作った別名と元の型を区別する方法があるかという意味でなら方法は無い。
using は「別名」を作っているだけであくまでも同じ存在。

オーバーロードできるように型を分ける方法があるかという意味でなら >>351 が提案しているように継承を使うのが簡単な方法。
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> {};
みたいに書いて継承しつつ特になにも付け加えなければ事実上の別名でありつつ異なる型でもある。

**デフォルトの名無しさん** · 2021/06/15(火) 10:24:24.93

template<class T, std::size_t N> class myarray : public std::array<T, 2*N> { using std::array::aray; };
コンストラクタも継承しとかないと使いにくくて困るぞ

**デフォルトの名無しさん** · 2021/06/15(火) 10:25:47.44

std::array<T, 2*N>::arrayか
この件のみ動作確認しないポリシーなんでやりづれえ

**デフォルトの名無しさん** · 2021/06/15(火) 15:04:54.99

>>349
迷惑なやつだな

**デフォルトの名無しさん** · 2021/06/15(火) 15:40:54.02

>>351,353-354
なるほど
ありがとうございます

> この件のみ動作確認しないポリシー
てどういういみでしたっけ？

**デフォルトの名無しさん** · 2021/06/15(火) 15:43:28.83

コンストラクタさえ継承しとけば、元のクラスとほぼ同じ使用感で使えるんですかね？
試しきれないので未知の困難に直面しそうで結構不安です

**デフォルトの名無しさん** · 2021/06/15(火) 15:44:46.76

>>355
何が？

**デフォルトの名無しさん** · 2021/06/15(火) 16:21:53.57

>>356
多分、自分で確認もせず書き込むようなやつには同じく動作確認なんかしてやらねーよ、ってことだろ

**デフォルトの名無しさん** · 2021/06/15(火) 18:25:24.86

どうでもいいけど変数テンプレートの四則演算って推論の邪魔するような

**デフォルトの名無しさん** · 2021/06/15(火) 20:42:15.88

>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これはやりすぎだろ
#include先に何書いてるかわからんから結局読まなきゃならん
空行とコメントで上下に分ける方がマシ

**デフォルトの名無しさん** · 2021/06/15(火) 21:00:10.82

それは非テンプレートなクラスでも一緒だと思うけど

**デフォルトの名無しさん** · 2021/06/16(水) 06:00:46.73

>>361
その論法はヘッダファイルそのものを否定する考えだな

**361** · 2021/06/16(水) 21:17:19.71

結局読まなきゃならないのは一緒だよ、当たり前
それでも、何か所にも同じのを書くのが嫌だから#includeなんじゃないの？
俺は一か所からのみ#includeするのを否定してる

**デフォルトの名無しさん** · 2021/06/17(木) 05:36:20.94

何か所にも同じのを書くのが嫌なら
テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？

**デフォルトの名無しさん** · 2021/06/17(木) 10:01:25.56

まぁヘッダのインクルードの仕方はそれぞれだからなぁ
自作ヘッダ内では一切インクルードしない(それの前に必要なヘッダをすでにインクルードしてる前提)ってのもある

ただその戦略なら、テンプレートがインスタンス化される直前にその実装が書かれたやつインクルードすればいいだけなんだが

**デフォルトの名無しさん** · 2021/06/17(木) 10:28:32.50

多分同じ奴だと思うが、数スレ前から多次元配列を自力でどうこうしようとしてる奴、悪いこと言わんから外部ライブラリ使うとけ
今の時代、行列とかテンソルの計算は並の人間が書いた C/C++ じゃ絶対に Python (NumPy) その他に敵わんと思う

まあ C/C++ の多次元配列ライブラリも群雄割拠で何が何だか全く分からないんだが
STL に多次元配列が中々入らない理由もこれかな