C++相談室 part161

**デフォルトの名無しさん** · 2022/05/21(土) 21:23:29.59

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

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/21(土) 21:24:45.56

>>1
乙

**デフォルトの名無しさん** · 2022/05/21(土) 21:44:08.96

C（ちんちん）+（ぷら）+（ぷら）

**デフォルトの名無しさん** · 2022/05/22(日) 00:57:58.97

おいおいまだ続けんのかよ！

**デフォルトの名無しさん** · 2022/05/22(日) 03:20:20.13

ODRってC++処理系の仕様？
処理系はODRの記述を含まない仕様だけあればその通り作ったら
合理的な手間で検知可能な範囲のODR違反コードをエラーにする
ふるまいになるというのが当然で、つまりODRは仕様の結果であってODRを仕様に含めるのは論理的に冗長という印象

どっちかというとODRは正しく動くためにプログラマーが従わねばならないルール、という認識やったわ、
この観点ではinlineがODRの例外というのは例外も糞もなくてそんなプログラムは書いたらあかんからODR違反
コンパイラが合理的な手間でそれを検出できなかったり、それがあってもコードの動きに破綻が無いこととは関係無い
的な、

**デフォルトの名無しさん** · 2022/05/22(日) 09:08:20.74

ちんちん！シュッ！シュッ！シュッ！

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 09:12:58.50

>>5
One definition rule は仕様に項目がある。
https://timsong-cpp.github.io/cppwp/n3337/basic.def.odr

インライン関数は同じアドレスを持つ (事実上統合することの要求) というのも仕様にある動作。
https://timsong-cpp.github.io/cppwp/n3337/dcl.fct.spec

no diagnostic と書いてある部分については (可能であれば処理系も検出するけど) どちらかというとユーザに対する要求というニュアンスはあるかも。

**デフォルトの名無しさん** · 2022/05/22(日) 19:47:14.24

有料無料関係なしで最高のIDEってなに？

**ハノン** ◆QZaw55cn4c · 2022/05/22(日) 19:52:14.59

>>7
＞インライン関数は同じアドレスを持つ (事実上統合することの要求)

それはもうインラインではないですね…
そうではなくて、extern なインライン関数をリンクする際には、同一のアドレスであるべき、という意味でしかないでしょう、つまり私の実装案

https://mevius.5ch.net/test/read.cgi/tech/1649979572/996
＞実装的には inline のついた関数定義が外部にリンクされる可能性があれば、すなわち extern な iniline 関数があれば、リンクのためのコード体を、各所に inline に展開されるコード体とは別に（こっそり）用意しておく、見たいな感じで十分に実装可能ですね

を支持する内容であり、extern な　inline 関数において定義を持たないコンパイル単位にでは inline の指示があっても inline しなくてもいいといっているに等しいですね‥‥

7.1.2.4
(略）外部リンクをもつインライン関数は、すべての翻訳単位で同じアドレスを持たなければならない。
外部インライン関数内の静的ローカル変数は、常に同じオブジェクトを参照する。
externインライン関数の本体内の文字列リテラルは、異なる翻訳単位で同じオブジェクトを指す。

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 20:04:27.44

>>9
見かけ上は同一に見える (アドレスを取らずに呼び出すときに限ってインライン化できる) ことを保証するという意味だよ。
インライン化できる条件を整えておきたいということと矛盾しない。

**デフォルトの名無しさん** · 2022/05/22(日) 20:07:42.95

>>8
俺が通ってる外国のコミュニティでその質問が出ると毎回Visual StudioでFA?って回答が帰ってくる
ネタで言ってるのか本気で言ってるのかは知らない

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 20:15:45.42

>>8
人によって使いやすさって違うからアドオンとかドキュメントの量とかが重要になってくるんだよ。
いくら潜在的に良い出来栄えであってもちょっとしたカスタムを全部自分で書かなきゃならないようでは面倒くさすぎる。
どこをどういじればいいのかいちいちソースコードを見ないとわからないのではダルい。
なんだかんだ不満があってもユーザ人口の多いものは全体としては良い選択になりがち。物量重要。

**デフォルトの名無しさん** · 2022/05/22(日) 20:19:45.26

vs以外だとIDEっていうよりエディタとコマンドでやってるイメージ
ボーランドとか死にかけだしなあ

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 20:25:35.21

>>13
LSP が現れたせいで処理系と統合された開発環境の価値が薄れた感がある。

**デフォルトの名無しさん** · 2022/05/22(日) 20:37:44.89

>>11
ググった感じだと海外では無料版が多いように感じたｗ

>>12
日本も海外もEclipseとかが人気みたいなのでEclipseから使っていきます

レスサンクスです

**デフォルトの名無しさん** · 2022/05/22(日) 20:39:19.63

>>10
つまり >>9 に同意する、ってことでしょう？

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 20:50:26.55

>>16
>>9 の
> 定義を持たないコンパイル単位にでは inline の指示があっても inline しなくてもいいといっているに等しい
が結論だとしたらそう。同意する。
むしろ定義を持つ翻訳単位でもインライン化しなくていい。

だから残る inline の意味は ODR の例外として機能するって部分になるわけ。

**デフォルトの名無しさん** · 2022/05/22(日) 22:42:48.81

>>17
なるほど。私の元の主張に反するのですが、規格上はそのように誘導されてしまうのですね…‥（呆然）

**デフォルトの名無しさん** · 2022/05/22(日) 22:53:10.16

www.youtube.com/watch?v=uaUmAUMvs2o

**デフォルトの名無しさん** · 2022/05/28(土) 13:34:18.53

C++入門書でオススメがあったら教えてください

**デフォルトの名無しさん** · 2022/05/28(土) 13:51:21.59

昔からC++を使ってる人が多いから最近の入門書なんて誰も知らん
https://cppmap.github.io/learn/books/

**デフォルトの名無しさん** · 2022/05/28(土) 14:07:22.40

>>21
多謝多謝！

**デフォルトの名無しさん** · 2022/05/28(土) 15:19:08.43

禿本の５、来ないね・・・

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/28(土) 15:44:53.73

C++ はそれなりに歴史が長いから仕様も変わってるし思想や習慣の変化もある。

上述で私は「inline は ODR の例外の意味！」と主張したけどさ、 D&E を読むと (inline 指定導入初期の判断としては)
「コンパイラによるインライン化の判断がザコなので指定できるようにした」
という意味のことを書いてあって、大元はやっぱりインライン化の指定なんだよね……。

色んな事情が絡むし、単純に C++ が巨大なのでどうせ一冊でちゃんとした理解にはならないと思う。
適当なやつをどれから読み始めてもいいんじゃないかね。
まあ、あまり古い奴は避けた方がよいだろうというのが最低限の基準かな。

**デフォルトの名無しさん** · 2022/05/28(土) 16:12:25.28

C 言語でなぜかC++のコメント行がいつの間にか許されている不思議

**デフォルトの名無しさん** · 2022/05/28(土) 16:25:05.55

なぜかってC99でサポートされたからではなくて？

**デフォルトの名無しさん** · 2022/05/28(土) 17:21:17.26

違うでしょうなあ。

**デフォルトの名無しさん** · 2022/05/28(土) 19:31:09.65

> いつの間に

情弱からはこう見えるようだな

**ハノン** ◆QZaw55cn4c · 2022/05/28(土) 20:36:31.97

>>24
ふむふむ。なかなか一筋縄ではいかない大人の事情ってのがてんこ盛り、ってことですね
私もそろそろ C++ をやり直そうかな‥‥

**デフォルトの名無しさん** · 2022/05/31(火) 21:24:16.90

このコードがコンパイルできないんだけど、なんで？
struct hoge {
std::map<int, std::unique_ptr<struct hoge>> m = {};
void x() {
struct hoge &r = *this;
r = *(m.begin()->second.get()); // ここがまずい
}
};

**デフォルトの名無しさん** · 2022/05/31(火) 21:37:16.47

コピーコンストラクタが呼ばれて、最終的にmapのunique_ptrがコピーできないってことか。。。
C++98の人間だし10年以上離れてたから最近のC++まったくわからんわ・・・

**デフォルトの名無しさん** · 2022/05/31(火) 21:49:44.41

>>30
あたりめえだろ
バカかお前

**蟻人間** ◆T6xkBnTXz7B0 · 2022/05/31(火) 22:00:19.02

rは*thisの別名。
*thisの所有物を*thisにコピー。だめ。
*thisよりも高位じゃないと。。。

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/31(火) 22:30:18.12

根拠。
https://timsong-cpp.github.io/cppwp/n3337/container.requirements#tab:containers.allocatoraware

コンテナを代入するとき、コンテナの要素の型は CopyAssignable であり、
コンテナに対して CopyInsertable であることを要求する。

**デフォルトの名無しさん** · 2022/05/31(火) 23:45:41.75

>>(前スレ)695
のFFTで2^(2^34)-1を計算する奴
https://ideone.com/xSaa6x
を倍速で動くようにしたったわ……！
↓↓↓
https://ideone.com/q0O74K

オリジナルが2200秒なところを962秒で計算完了
出力結果は一致
メモリ消費量はオリジナルと同等（完全in-place、sinテーブルは1GB（計算時間と誤差が劣化するがシュリンク可能））

**デフォルトの名無しさん** · 2022/05/31(火) 23:48:59.95

さすがに天才の漏れも三角関数って何だっけというあたりからスタートしたので
日数がかかってしまったが、いまやバッタフライ演算を完全に理解したから
純アルゴリズム的には最善の実装になっていると言える（希ガス、

（参考）
基礎からの周波数分析（9）－「高速フーリエ変換（FFT）」
https://www.onosokki.co.jp/HP-WK/eMM_back/emm140.pdf

あとはメモリアクセスの時間局所性を改善して1000倍にする、

**デフォルトの名無しさん** · 2022/06/01(水) 00:23:05.24

こういうのに燃えてるような人が日本を支えていたのかもな

**デフォルトの名無しさん** · 2022/06/01(水) 07:38:09.36

過去形でワロタ

**デフォルトの名無しさん** · 2022/06/01(水) 08:08:59.08

スペアナ以外に使い道あるのか

**デフォルトの名無しさん** · 2022/06/01(水) 09:38:46.33

>>37
アホか
数論変換も知らんゴミが夏休みの自由研究やってるだけ

**デフォルトの名無しさん** · 2022/06/01(水) 10:00:14.05

>>36
漏れや希ガスというタイポや、バタフライ演算とかいう大学２年の信号処理の課題で出る程度のアルゴリズムを自信満々に書いちゃうあたり、かわいそうな人なのかな

**デフォルトの名無しさん** · 2022/06/01(水) 10:09:19.65

その辺はタイポじゃなくて20年近く前の2ch語なのじゃ……
イタいことには変わりないが

**デフォルトの名無しさん** · 2022/06/01(水) 10:31:05.57

41がむしろ異常にみえる