C++相談室 part161

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

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

**デフォルトの名無しさん** · 2022/10/22(土) 22:33:36.63

>>909
ideone に動くソースを貼ってください、全然意味がわかりません

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/22(土) 22:47:49.35

>>911
時期尚早だと思う。
現状の gcc ではオプションに -std=c++20 を付けるだけではモジュールは有効にならず、
明示的に -fmodules-ts を付ける必要があるようにしてあるので、普段使いするにはまだ早いという意図を感じる。
ドキュメントにはまだ完璧じゃないと書いてあるし。
(他のコンパイラの状況は知らんけど。)

それに C++20 の段階ではモジュールの基礎の基礎が決まっただけで
標準ライブラリすらモジュールとして再編できていない。一応は C++23 でやることになってるけど
現在の C++ の規格は三年ごとに話がまとまった分を入れる、
つまり出来てない分を完成させるために期限を延長したりはせず三年後に先送りするという運用なので
C++23 がどこまで出来るものなのか全然わからん。
標準ライブラリを再編していく内にモジュール機能の問題点が発見されたりするかもしれん。

個人的に遊ぶ分には色々とやってみてわかったことはどんどん発信してほしいけど、
製品レベルのプロジェクトではやめておいたほうがいい。

**デフォルトの名無しさん** · 2022/10/23(日) 00:24:14.37

>>913
msvc2022なら、と思いましたがこちらもモジュールはオプションで試験段階のようでした
もう少しvcの更新を経てから新規の小さいプロジェクトで試してみようと思います

**デフォルトの名無しさん** · 2022/10/23(日) 06:09:10.65

MSは怪しい機能は/std:c++latestにしてるよな

**デフォルトの名無しさん** · 2022/10/23(日) 08:32:09.89

C++17のfilesystemもそうだったけど
練りきれてない未完成品を無理に入れるのやめて欲しい

バグ出ししたいんなら拡張規格かoptionalとして出してみて
標準のmandatoryにするのはしっかり固まってからにしろやって

つーかSTLもboost由来のもISO以外のところでそこそこユーザに揉まれてから来たものだろ
開拓は標準規格の役目じゃねえよ

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 10:56:19.39

完璧になるまで練ってたらいつまでも進まんから三年ごとに出来た分を規格に入れるという方針に変更されたんじゃないか。
不格好でも不完全でも今使えることが大事だというのは元々の理念だし。

未完成はともかく欠陥報告を乱発するのは良くはないけどさ。

**デフォルトの名無しさん** · 2022/10/23(日) 11:55:48.92

使ってる所だけ直せばいいライブラリと違って（だからって良いわけじゃないけど）
モジュール作り込んでからやっぱdefectでしたって言われたら困るからなあ

**デフォルトの名無しさん** · 2022/10/23(日) 12:11:50.11

ライブラリとモジュールの違いって何ですか？

**デフォルトの名無しさん** · 2022/10/23(日) 12:51:46.87

使うだけの標準ライブラリと、モジュール自作する時の仕様のつもりだった

**デフォルトの名無しさん** · 2022/10/23(日) 13:12:57.82

filesystemって未完成なん?

**デフォルトの名無しさん** · 2022/10/23(日) 13:25:59.97

C++17の時点ではfile_clockがなかった

**デフォルトの名無しさん** · 2022/10/23(日) 14:32:45.34

file_time_type があったと思うが

**デフォルトの名無しさん** · 2022/10/23(日) 14:45:23.56

あったけど使いものにならんかった

**デフォルトの名無しさん** · 2022/10/23(日) 14:59:53.65

その昔、iostreamというのがあってだな
皆阿鼻叫喚の断末魔の雄叫びを上げたもんじゃった

**デフォルトの名無しさん** · 2022/10/23(日) 16:01:34.86

printfやscanfに毒舌三昧してる人に対して持っていた、お暇な方ですねという思いが蘇る

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 17:49:58.24

ファイルシステムやらスレッドやらはシステム (OS) 側の都合があるからなぁ。
細かいことは環境依存の機能を使えという前提で
標準ライブラリを最小限にとどめるのは C の時代からの基本的な姿勢だっただろう。

環境依存だからこそ標準で吸収しておいてくれという気持ちもあるし、
現状が良いとも思わんけど…… なんというか……
C++ ってそういうもんだろと思って納得してるから不満には感じないな。

**デフォルトの名無しさん** · 2022/10/23(日) 20:20:25.05

iosteamはいかにもC++初心者がやりそうな「オペレータをオーバーロードできるから
見た目イカすちょっとシャレた表記法にしようぜ！！」っていう厨二スピリット全開だったからな
でてきた時点で「あ、これはクソなやつだ」ってわかったよ

**デフォルトの名無しさん** · 2022/10/23(日) 20:43:19.02

C with classesを始めようとして
たとえばと始めたことをずいぶん後になって
鬼の首を取ったようにキリッ

**デフォルトの名無しさん** · 2022/10/23(日) 22:04:42.81

演算子チェーン自体は別に悪いもんじゃない
iostreamがクソなのはそこじゃない

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

でも競プロで何も考えずにcin >> N >> M;とかできるでしょ

**デフォルトの名無しさん** · 2022/10/23(日) 23:18:01.98

なにかとiostream叩かれやすいけど
よく聞いてみると大した批判ではないよね常に
聞くに値するiostream批判ってお目にかからないね

**デフォルトの名無しさん** · 2022/10/23(日) 23:21:04.29

iostreamが本当にクソならイカした再実装はあるだろう?
まさかcstdioとか言わんでくれよ

**デフォルトの名無しさん** · 2022/10/23(日) 23:23:02.52

まあstd::cout << foo << bar;がつい最近まで規格上未定義動作だったのは擁護のしようがないけどな

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 23:33:00.12

iostream が設計された当時は I/O のための専用の言語機能が
必要という論調があって、 Bjarne Stroustrup 氏はそれに抵抗して
当時の C++ の範疇でライブラリを作ったという経緯がある。

ここで抵抗しなければ入出力用の文法が (ライブラリとしてではなく)
言語機能として導入することになっていたかもしれないと思うと
iostream にある粗くらいは許せてしまうなぁ。

少なくとも printf みたいな型チェックがガバガバなのは C++ 的に
放置できなかったし、バッファリングと書式化をまとめつつ拡張やカスタマイズが可能で
I/O 以外も含めてストリームというインターフェイスを一般化するというのは
当時としてはこれ以上考えられない素晴らしいデザインだと思う。

ひとつこれは (iostream 設計当時でも) どうにかできただろうと思うのは
書式の変更 (マニピュレータを使うなど) をしたら陽に戻すまではそのままというのが良くなかった。
スコープを抜けたらリセットできるような方法が標準で欲しかった。
(boost にあったような気がするが名前を忘れてしまった……。)

**デフォルトの名無しさん** · 2022/10/23(日) 23:47:22.83

ステートはクソで出来るだけ無くすべきっていう現代の常識が当時はなかったからな
書式をストリームのステートにしてしまったのは今思えば大失敗だがあの時代は自然な設計だったんだろうな

**デフォルトの名無しさん** · 2022/10/23(日) 23:48:05.17

>>934 foo, bar がどのように定義されていたらその式が未定義動作になるの？

**デフォルトの名無しさん** · 2022/10/23(日) 23:48:47.26

批判する者にその資格が無いってパティーン多々あるよな
iostream批判するやつだって
じゃあどんな素晴らしい入出力ライブラリを用意したの？
実装したの？どこの誰がどれだけ使ってるの？っていう
タダ飯喰らいがかーちゃんのご飯批判してるようなこと

**デフォルトの名無しさん** · 2022/10/23(日) 23:55:56.29

未定義じゃなくて、引数の評価順が未規定だったって話では？

**デフォルトの名無しさん** · 2022/10/23(日) 23:56:39.14

>>937
何だろうと未定義(C++17以前)。なぜなら一つの式の中でstd::coutを2回変更してるから
(a+=1)+=1とか++(++a)とかも同じ
この大欠陥が見つかったせいで、式の中の評価順は基本コンパイラの好き勝手にしていいというCからの伝統を一部諦める羽目になった

**デフォルトの名無しさん** · 2022/10/24(月) 00:00:00.66

>>940
foo, bar の評価順が未規定だった件を未定義動作と勘違いしてるのか。
https://cpprefjp.github.io/lang/cpp17/expression_evaluation_order.html

cout に対する操作は関数呼び出しの内外の順序付けが入るから未定義動作にはならないよ。

**デフォルトの名無しさん** · 2022/10/24(月) 00:02:05.10

>>940 (a+=1)+=1 も ++(++a) も未定義動作にはならないよ。必ず a が 2 増えて、 a への参照が得られる。

**デフォルトの名無しさん** · 2022/10/24(月) 00:24:37.42

>>940
<<は左から評価じゃね？

**デフォルトの名無しさん** · 2022/10/24(月) 00:26:04.46

もっというと同じ2項演算子が複数でてきたら左から評価では？
数学と同じ

**デフォルトの名無しさん** · 2022/10/24(月) 00:43:11.90

cout<<a<<b;
の場合、左結合なので、評価順序は、
(cout<<a)<<b;
となるが、aとbの中に関数や演算子が書いてあるような場合、
それがいつ評価されるのは実装依存だったような気がする。つまり、
operator<<(operator<<(cout,a),b);
みたいに評価はされることは決まっているが、aとbの評価が、aが先かbが先かは
決まってない、というような話。もっと言えば、cout自体の部分が式や関数になって
いる場合も、cout,a,bの評価順序が決まって無いかも。

**デフォルトの名無しさん** · 2022/10/24(月) 00:45:03.87

>>945
もっというと、
x+y;
の場合、xとyのどちらが先に評価されるかも決まってない。

**デフォルトの名無しさん** · 2022/10/24(月) 00:54:22.51

未規定の動作(unspecified behavior)と未定義動作(undefined behavior)は違うよ

**デフォルトの名無しさん** · 2022/10/24(月) 01:00:58.84

>>945,946
なるほど言わんとしてることは分かったが
左から順に評価するのが当たり前なのでは？
つまりcout, a, bの順

**デフォルトの名無しさん** · 2022/10/24(月) 01:15:48.16

>>948
実は、x86などでは、スタックが、メモリーアドレスの大きい方からから小さい方
に成長するようになっているので、引数は右側から左側に評価した方が効率が良い。
そのため、逆さまに評価する処理系があっても不思議ではない。

**デフォルトの名無しさん** · 2022/10/24(月) 01:33:32.70

ちょっと前までの規格では単一式(≒セミコロンとセミコロンの間)の中の評価順は基本的にコンパイラが好き勝手に弄る事が許されてた
例えばa[++b]=cとかはヒトの常識的にはbをインクリメントしてからa[b+1]にcを代入するけど、別にa[b+1]にcを代入してからbを増やしたって構わない(この前のどっかでa[b+1]を参照してればその方が最適化したら効率的かもしれない)
そんな感じで最適化に都合がいいように評価順には寛容すぎるほど寛容だったんだが、カオスを防ぐためのルールがあって、それが「単一式で同じオブジェクトを2回変更したら未定義」というもの
例えば(a+=1)+=1はどっちの1を先にaに足してもいいが、そういう自由度がある時点で未定義というルールになっていた
もっと分かりやすい例だと(a+=2)*=3は最初のaが1なら常識的には9になると思うけど、評価順ルール的には3を先に掛けてから2を足して5にしたっていい
9か5の二択で済むこれはマシな方で、ポインタが絡むと収拾がつかなくなるから、同じもん2回以上書き換えたらもう知らん未定義じゃってのがCとちょい前までのc++の規格の趣旨だった

で、この話をさっきのiostreamに持ち込むと、operator <<はconstメンバー関数じゃないので、cout << foo << barはcout << fooと、(cout<<fooの戻り値==coutの参照) << barの2回のcoutへの変更を順序は不確定な単一式でやってることになる。つまりさっきのaと同じように未定義動作って事
(cout <<fooを先に実行しないと戻り値確定しないからこっちが先に決まってるのでは？と思うだろうけど、規格の文言上はcout <<fooの戻り値を「予測」して<<barの適用を先にやったって構わないのである。そんな病的なコンパイラがたまたま実在しなかったから今まで問題にならなかったんだろうけどね)

という話がrangesのパイプでoperator|のチェーンの検討をしてるときに発覚してみんな真っ青になって慌てて評価順のルールが見直されたっていう、まあアホ臭い話でした
幸い病的な最適化コンパイラが生まれる前だったから規格文言だけの話で実害はない

**デフォルトの名無しさん** · 2022/10/24(月) 01:59:23.78

aが1のとき(a+=2)*=3が5に成り得たと書いているがほんまかいな?

**デフォルトの名無しさん** · 2022/10/24(月) 02:10:09.65

9か5かってのは説明上の話で、実際は未定義で鼻から悪魔だから9でも5でも0でも-1でも42でも4394967295でもどんな可能性もあった
今の規格では必ず9になった

**デフォルトの名無しさん** · 2022/10/24(月) 02:11:12.04

https://ja.cppreference.com/w/cpp/language/eval_order
スカラーオブジェクトに対する変更にしかUB関係なくね？

**デフォルトの名無しさん** · 2022/10/24(月) 02:19:24.78

operator<<が触ってるcoutのメンバ変数やグローバル変数にスカラーオブジェクトが一切含まれてなければ関係ないけど普通はそんなはずは無い

**デフォルトの名無しさん** · 2022/10/24(月) 07:45:35.99

テキストがバラけたり変数の並び順を変えられなくてi18n対応が困難になるのがiostreamの一番の問題かな

**デフォルトの名無しさん** · 2022/10/24(月) 08:12:37.76

>>950
実際どっちが正しいかは知らんが説明がよくわからん。
cout << foo << bar の例えに (a+=2)*=3 を持ってくるのは正しいのか？

**デフォルトの名無しさん** · 2022/10/24(月) 09:31:36.65

>>950
> それが「単一式で同じオブジェクトを2回変更したら未定義」というもの

C++11 より前のシーケンスポイント（副作用完了点よるルールの話だとしても関数呼び出しの前後には
シーケンスポイントが入るので cout の operator<< で未定義動作が起こるような話にはならない。

**デフォルトの名無しさん** · 2022/10/24(月) 09:49:55.97

>>950
「rangesのパイプでoperator|のチェーンの検討をしてるとき」とか言ってるから
本気で C++17 改定前の話をしてるっぽいなぁ。

> それが「単一式で同じオブジェクトを2回変更したら未定義」というもの
ここから間違い。 C++11 以降は "sequenced before" の順序関係に基づくルールになっていて、
そんな大雑把なルールではない。

> 例えば(a+=1)+=1はどっちの1を先にaに足してもいいが、そういう自由度がある時点で未定義というルールになっていた
C++11 時点で代入式の値取得は代入より後になると規定されているよ。
https://timsong-cpp.github.io/cppwp/n3337/expr.ass#1
> In all cases, the assignment is sequenced after the value computation of
> the right and left operands, and before the value computation of the assignment expression.

関数呼び出し前後に順序関係もある。
https://timsong-cpp.github.io/cppwp/n3337/intro.execution#15
> When calling a function (whether or not the function is inline), every value
> computation and side effect associated with any argument expression,
> or with the postfix expression designating the called function, is sequenced before
> execution of every expression or statement in the body of the called function.

**デフォルトの名無しさん** · 2022/10/24(月) 23:16:53.41

どなたか、clangコンパイラのソースコードで、main()関数がどのソースファイル
にあるか分かりませんか？

**デフォルトの名無しさん** · 2022/10/24(月) 23:38:51.20

grepで始めよう
新しい検索を

**デフォルトの名無しさん** · 2022/10/24(月) 23:50:22.01

>>960
もちろんgrepはしていますが、
test用のソースコードなどに大量に出てきてしまうのでどれか分からないのです。
探しているのですが、むしろ、clangコンパイラ自体のmain関数は存在して
無いのではないかと思えてしまいます。

**デフォルトの名無しさん** · 2022/10/25(火) 00:20:05.85

>>961
grepでtestっぽいのを除外していけば見つけられると思うけど、
スマホでgithub見た感じdriver/tools/driver.hppじゃね

**デフォルトの名無しさん** · 2022/10/25(火) 00:20:30.61

まちがえたdriver.cppね

**デフォルトの名無しさん** · 2022/10/25(火) 15:32:20.93

このコードでfunc(a)だけがコンパイル通らないんだけどどう対策すれば綺麗な感じになる？
ユニバーサル参照の受け取りのとこでT=int&がstd::integralを満たさないのが原因なんだけど

integral_or_lrefコンセプト作るしかない？

#include<utility>
#include<concepts>
template<std::integral T>
void func(T&&);

int main(){
int a=0;
func(0);
//func(a);
func(std::move(a));
}

**デフォルトの名無しさん** · 2022/10/25(火) 15:33:30.00

超初心者＋わかりにくい文章で、ごめんなさい。
今までは、.NetFramewor4.72でWinFormを使って実装していました。

今、.Net6.0 の WinFormで実装する必要が出てきたので

.Net6.0 で実装しています。
.NetFramewor4.72 でWindowsBaseの参照の追加で使えていた
System.Windows.Threading.Dispatcher が

.Net6.0 では、「依存関係」の「COM」で設定しようとしても、
WindowsBaseが表示されず、WindowsBaseを設定できなくて
System.Windows.Threading.Dispatcherが使えなくて、困っています。
同じような課題を諸先輩方は
どのように解決されましたか？

**デフォルトの名無しさん** · 2022/10/25(火) 15:37:45.19

>>965
C#はこっちで
https://mevius.5ch.net/test/read.cgi/tech/1639965805/

**デフォルトの名無しさん** · 2022/10/25(火) 15:39:23.68

CLIはこっちか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/25(火) 15:54:18.45

>>964
参照を剥がすのを入れるのが常道じゃないかな？

template<class T>

requires std::integral<std::remove_reference_t<T>>

void func(T&&);

**デフォルトの名無しさん** · 2022/10/25(火) 16:15:10.24

>>966
大変失礼しました。
アドバイスありがとうございます。

**デフォルトの名無しさん** · 2022/10/25(火) 18:06:59.76

そういうとき脳死でstd::decay使っちゃうけどあんま行儀良くないかな

**デフォルトの名無しさん** · 2022/10/25(火) 18:13:31.96

>>962
ありがとう。関数名が main() ではなく、
clang_main()
なんですね。
cmakeすると、これがすぐ呼び出されるような main() 関数が
作られるようです。
cmakeがどういう仕組みでそうやっているのかは分かりませんが。

**デフォルトの名無しさん** · 2022/10/25(火) 18:15:07.22

>>962
古いWzEditorのgrepを使ってるんですけど、除外フォルダが指定できないんです。
何かいい方法は有りますかね。

**デフォルトの名無しさん** · 2022/10/25(火) 20:38:52.33

どっちかってーと　リンカで実行時のエントリポイントを細工してるんじゃないのかな？

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

追加質問です。
llvm のソースの中に、以下の様に、
配置 new に似ていてもそれとは違うような new 演算子の使用方法が
有りますが、分かる人いますか？例えば、
new (2) CatchReturnInst(CatchPad, BB, InsertBefore);
は、配置 new の new (p) T(引数列) に似ていますが、
p の位置は、アドレスを指定することになっているのに、
「2」という整数値を指定しています。

llvm-project-main/llvm/include/llvm/IR/Instructions.h
の
class CatchPadInst : public FuncletPadInst {・・・}
の中の
　static CatchPadInst *Create(Value *CatchSwitch, ArrayRef<Value *> Args,
　　　　　　　　　　　　　　　const Twine &NameStr = "",
　　　　　　　　　　　　　　　Instruction *InsertBefore = nullptr) {
　　unsigned Values = 1 + Args.size();
　　return new (Values)
　　　　CatchPadInst(CatchSwitch, Args, Values, NameStr, InsertBefore);
　}

class CatchReturnInst : public Instruction {・・・}
の中の
　static CatchReturnInst *Create(Value *CatchPad, BasicBlock *BB,
　　　　　　　　　　　　　　　　 Instruction *InsertBefore = nullptr) {
　　assert(CatchPad);
　　assert(BB);
　　return new (2) CatchReturnInst(CatchPad, BB, InsertBefore);
　}

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/26(水) 01:03:41.11

>>974
placement new だろ。

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

>>971
ごめん、tools/driver/driver.cppだった。321行目あたりにmainあるけどこれじゃないの？
>>972
msysとかgit bashとかwslのgrepを使う、じゃダメ？vscodeでも除外設定はできるけど

**デフォルトの名無しさん** · 2022/10/26(水) 01:53:26.73

>>975
以下の様に、new (Us) CatchReturnInst(引数列)は、
Userクラスの operator new(Size, Us) を使っていて、
で、Usには、アドレス値ではなく、Use 型の個数を入れるようです。
通常の operatoe new()では、第二引数はアドレス値です。

class CatchReturnInst : public Instruction {・・・};
class Instruction : public User,
public ilist_node_with_parent<Instruction, BasicBlock> {・・・};

void *User::operator new(size_t Size, unsigned Us) {
return allocateFixedOperandUser(Size, Us, 0);
}

void *User::operator new(size_t Size, unsigned Us, unsigned DescBytes) {
return allocateFixedOperandUser(Size, Us, DescBytes);
}

void *User::allocateFixedOperandUser(size_t Size, unsigned Us,
unsigned DescBytes) {
・・・
uint8_t *Storage = static_cast<uint8_t *>(
::operator new(Size + sizeof(Use) * Us + DescBytesToAllocate));
・・・
}

**デフォルトの名無しさん** · 2022/10/26(水) 01:56:10.10

>>976
>ごめん、tools/driver/driver.cppだった。321行目あたりにmainあるけどこれじゃないの？
そのサイトは、mirrorサイトで「legacy」とされ、だいぶ古いバージョンなんです。
最新バージョンのソースでは、driver.cpp には clang_main()しかないと思います。
cmakeすると、buildフォルダに、
int main(int argc, char *argv[]) { return clang_main(argc, argv); }
のような一行の関数が出来ます。

**デフォルトの名無しさん** · 2022/10/26(水) 02:33:27.35

>>978
(1) 本当の clang の main() 関数本体 :
(llvm-project-main/clang/tools/driver/driver.cpp):

int clang_main(int Argc, char **Argv) {
・・・
・・・
}

(2) clang_main() を呼び出す main() 関数 :
(llvm-project-main/build/tools/clang/tools/driver/clang-driver.cpp):
↑
build は、cmake の destination ディレクトリです。

int clang_main(int argc, char **argv);

int main(int argc, char **argv) { return clang_main(argc, argv); }

↑本当にこんな風に一行の関数になっています。恐らく、cmake が
生成したものと思われます。

**デフォルトの名無しさん** · 2022/10/26(水) 09:07:24.21

>>978-979
なるほどすまんかった。
たまたま古いソースをみてたからmainを見つけられたんだね。勉強になりました。

**デフォルトの名無しさん** · 2022/10/26(水) 09:39:06.48

>>968
やはりrequiresを1行足すしかないか...

template<allow_ref<std::integral> T>
void func(T&&);

とでも書きたかったけど、コンセプトを受け取るテンプレートが書けないっぽいから諦めた

**デフォルトの名無しさん** · 2022/10/27(木) 02:01:40.47

clangのソースで、CPUのマシン語を生成している場所を調べていて、
X86AsmPrinter クラスや X86MCInstLower クラスがそれに強く関与していることが分かって
きました。
X86AsmPrinter クラスや X86MCInstLower クラスは、お互いに参照されてますが、
この2つのクラスは、いずれも「作られている場所」が見つかりません。
「作られている」とは、new X86AsmPrinter や、X86AsmPrinter a;、
new X86MCInstLower や X86MCInstLower b; のようにしている場所です。
どなたか分かりませんか？

**デフォルトの名無しさん** · 2022/10/27(木) 02:32:01.95

>>982
すみません、多分、以下の部分ですね。
これで、new X86AsmPrinterしたアドレスを、getTheX86_32Target()やgetTheX86_64Target()
が返した Target クラスのシングルトンのインスタンス xxx に対して
xxx.AsmPrinterCtorFn = アドレス;
のように記録しているようです。

extern "C" LLVM_EXTERNAL_VISIBILITY void LLVMInitializeX86AsmPrinter() {
RegisterAsmPrinter<X86AsmPrinter> X(getTheX86_32Target());
RegisterAsmPrinter<X86AsmPrinter> Y(getTheX86_64Target());
}

template <class AsmPrinterImpl> struct RegisterAsmPrinter {
RegisterAsmPrinter(Target &T) {
TargetRegistry::RegisterAsmPrinter(T, &Allocator);
}
private:
static AsmPrinter *Allocator(TargetMachine &TM,
std::unique_ptr<MCStreamer> &&Streamer) {
return new AsmPrinterImpl(TM, std::move(Streamer));
}
};
/// TargetRegistry - Generic interface to target specific features.
struct TargetRegistry {
・・・
static void RegisterAsmPrinter(Target &T, Target::AsmPrinterCtorTy Fn) {
T.AsmPrinterCtorFn = Fn;
}
・・・
};

**デフォルトの名無しさん** · 2022/10/27(木) 02:43:40.35

なんかコンセプト以前にテンプレートにもあまり慣れてなさそう

**デフォルトの名無しさん** · 2022/10/27(木) 02:44:18.56

間違えました。
xxx.AsmPrinterCtorFn に登録しているのは、new X86AsmPrinterの
アドレスではなく、
RegisterAsmPrinter<X86AsmPrinter>::Allocator(・・・)
のアドレスのようですね。
そして、このAllocator (==関数)を呼び出すと、new X86AsmPrinter
を行なえるようです。

**デフォルトの名無しさん** · 2022/10/27(木) 08:37:49.38

関係ないけどあんまりnewせんほうがええよ
それしかないと思ってるならちょっと古い感じ

**デフォルトの名無しさん** · 2022/10/27(木) 22:03:08.74

あんまりデータメンバに直アクセスしないほうがええよ
あんまりグローバル変数使わんほうがええよ
あんまりSendMessageを直に使わんほうがええよ
あんまりナマポ使わんほうがええよ
あんまりアセンブラ使わんほうがええよ
あんまりC++使わんほうがええよ

ラップしろってことだろうけど
一切離れたやつはもうC++使いじゃない

**デフォルトの名無しさん** · 2022/10/28(金) 00:40:37.68

>>986
イリノイ大学のclangやLLVMの開発者に言ってください。
コンパイラでは最先端かも知れませんが。

**デフォルトの名無しさん** · 2022/10/28(金) 08:56:31.64

可変長テンプレートはじみて使ったけど便利だなこれ

**デフォルトの名無しさん** · 2022/10/28(金) 09:06:12.57

threadがあんなに使いやすくなっているのは
ひとえにtemplate-parameter-packのおかげ

**デフォルトの名無しさん** · 2022/10/29(土) 23:34:49.08

>>950の話は終わりかな?
レスついたけど反論がないようだけど

**デフォルトの名無しさん** · 2022/10/30(日) 03:51:06.75

5ch始めたばかりなのかな？

**デフォルトの名無しさん** · 2022/10/30(日) 11:42:15.05

気になるじゃん

**デフォルトの名無しさん** · 2022/10/30(日) 15:52:08.41

仕事ハネた後のヨレヨレ状態で見てるから
長文()を読もうとすると寝落ちしかねない

**デフォルトの名無しさん** · 2022/10/31(月) 13:27:29.89

VC++ や GCC で <cstddef> をインクルードすると、
std の明⽰的修飾、using 宣言、using 指令がなくても
size_t が使えるのですが、これは C++ 標準の仕様ですか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/31(月) 13:53:23.25

>>995
いいえ。未規定です。
std 名前空間内で定義されることは当然に保証された動作ですが、
グローバルには定義されてもされなくてもかまいません。
逆に言えばグローバルに定義されていることはありうると想定する必要があります。
(なので自分が定義する名前がそれに衝突しないようにするべきです。)

**デフォルトの名無しさん** · 2022/10/31(月) 13:55:26.92

size_tを知らんでもsizeofは使える？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/31(月) 14:17:38.34

>>996 の根拠
https://timsong-cpp.github.io/cppwp/n3337/headers#4

**デフォルトの名無しさん** · 2022/10/31(月) 14:31:14.54

C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/

**デフォルトの名無しさん** · 2022/10/31(月) 14:31:53.89

立てました

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 162日 17時間 8分 25秒