C++相談室 part158

**デフォルトの名無しさん** · 2021/11/15(月) 18:49:18.44

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

**デフォルトの名無しさん** · 2021/12/10(金) 00:28:44.05

cat >sample_cpp.cpp <<EOF
#include <iostream>
using namespace std;
struct s {
~s() {cout << "called." << endl;}
};
void func1() {
s a;
throw "hoge";
}
extern "C" void func2(void(*)());
int main() {
s a;
try {
func2(func1);
}
catch(const char* m) {
cout << m << endl;
}
return 0;
}
EOF
cat >sample_c.c <<EOF
struct s {
int dummy;
};
void func2(void (*f)()) {
struct s a;
f();
}
EOF

**デフォルトの名無しさん** · 2021/12/10(金) 00:29:59.22

gcc -g -c sample_c.c
g++ -Wall -g -c sample_cpp.cpp
g++ sample_c.o sample_cpp.o -o sample
./sample

実行結果
called.
hoge
called.

>>284-285
Cにはデストラクタがないので、メモリが開放されればOKであり、自動的に開放される
C++ではスコープから外れればデストラクタが呼ばれた後にメモリが開放される

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 01:18:14.66

JavaScript でリソースを解放 (GC で回収) するために
変数に false を代入して参照を切っているのを見たことが有って、
GC があってもこの手のバッドノウハウは要るんだなと思いました。 (小並感)

**デフォルトの名無しさん** · 2021/12/10(金) 01:52:31.83

GCが正常に機能しているという保証がそもそもないから
そもそも何が正常な動作なのかを誰も責任とらない架空の権威によって成り立っている

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 01:58:44.76

メモリ回収のタイミングが保証されないのは大した問題ではない
(プロセスが終了すればどうせ回収されるので)
のだが、外部のリソースを掴んでいるときに後始末されないかもしれないのは困るな。

**デフォルトの名無しさん** · 2021/12/10(金) 02:33:47.50

Windows10でコマンドプロンプトのGUIを提供するconhost.exeはナウくてヤングなC++のstd::basic_string_viewを使っている
Windows2000以来のconhost.exeが古いコードのままメンテ放置されているわけではないことがわかり少しだけほっこりする
以下、それらしきシンボル
TextBuffer::InsertCharacter(class std::basic_string_view<unsigned short,struct std::char_traits<unsigned short> >,class DbcsAttribute,class TextAttribute)

ま、本当はなにをしたかったというとpwsh.exeとconhost.exeが道連れクラッシュして困ってるってだけなんだが

**デフォルトの名無しさん** · 2021/12/10(金) 05:50:56.28

多人数のプロジェクトほどuniqueではなくshard_ptrが増えるのはトラブった時に誰も責任取らなくていいからって事？

**デフォルトの名無しさん** · 2021/12/10(金) 07:04:02.57

shared_ptrを乱用する職業PGよりもweak_ptrを使いこなせる厨二PGたれ
主従関係がある場合、主が従のｼｪｱﾎﾟを持ち、従が主のｳｲﾎﾟを持て

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

多くの職業PGは依存関係を親子関係で騙りたがるが、
生物学上、親は子より先に生まれ先に死ぬのだから、FIFOは成り立つがLIFOは成り立たない
ポリコレ的にはマスター/スレーブではなくプライマリ/セカンダリが望ましいとされる
ルー語の乱用をさけるならばプライマリ/セカンダリではなく主/従がなお良い
よって依存関係を主従関係で騙るのが正しい
織豊政権のように、主君の死後に従者が取って代わった例もあるから完全ではないが

**デフォルトの名無しさん** · 2021/12/10(金) 07:15:52.21

秀吉は主君信長のweak_ptrを持っていたので本能寺の変での主君の横死を的確に知ることができた

**デフォルトの名無しさん** · 2021/12/10(金) 07:35:10.03

くだらねえ
喩え話なのはみんなわかってんのに
覚えたての日本語ひけらかしてドヤるな

**デフォルトの名無しさん** · 2021/12/10(金) 08:04:47.84

ルー語の乱用を避けるのが礼儀だぞ

**デフォルトの名無しさん** · 2021/12/10(金) 08:16:32.12

>>290
そうなんだよね
リソース解放のタイミングが保証されないのは言語設計のミスだった
JavaではファイルやソケットなどのリソースはGCのときに呼ばれるfinalizeで解放すればいいよって思想だったけど
いつfinalizeが呼ばれるのか予測できないことに起因するバグが多発
ついにfinalizeが廃止されることになった

リソースは自前で廃棄してねというスタンス
GCも当初の期待ほどうまくいってない

**デフォルトの名無しさん** · 2021/12/10(金) 09:48:13.03

ファイルやソケットの開放はcloseないしデストラクタでやるのだから保証されてるぞ？
保証されないのはメモリリソースだけ

あとjavaも当初からfinalizeが呼ばれることは保証されてなかったからfinalizeで開放しなさいなんていう慣習はなかったと思うが

**デフォルトの名無しさん** · 2021/12/10(金) 10:14:08.92

JavaはJDBC周りのGCの挙動が厄介だYO
GC性善説に立つと痛い目にあう

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

>>299
JavaやC#にはデストラクタないからね
C++経験者がJavaやC#ではファイナライザーを使ったりしてたんだよ
C#ではマイクロソフト謹製標準ライブラリでさえファイナライザーでファイルを閉じるクソコードがある

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

いつまでスレ違いの話続けんの？間違いの指摘すら面倒

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

C#はファイナライザで解放でいいんだよ
Disposeパターンがそういうスタイルだから

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

>>301
それはその個人が不勉強なだけだろ…
finalizeが呼ばれないことがあるのはあまりに初歩的なチップスで、初級でない一般的なJavaプログラマがfinalizeだけでリソース開放するとかありえない。
思想って誰の思想？

メモリ解放に気を使わないC/C++プログラマがいないのと同じ

**デフォルトの名無しさん** · 2021/12/10(金) 12:27:48.66

>>304
その不勉強な個人が多すぎたんでしょ
デストラクタの代わりにファイナライザーを使う誤用が多かった
finalize廃止を決断しなければならないほどにね

**デフォルトの名無しさん** · 2021/12/10(金) 12:36:42.08

C++の轍を踏まないはずが
ざまあねえな

**デフォルトの名無しさん** · 2021/12/10(金) 12:43:00.40

>>ID:Qqc0ky4z
>>298
>JavaではファイルやソケットなどのリソースはGCのときに呼ばれるfinalizeで解放すればいいよって思想だったけど
>>301
>C#ではマイクロソフト謹製標準ライブラリでさえファイナライザーでファイルを閉じるクソコードがある
>>305
>その不勉強な個人が多すぎたんでしょ
上記発言を見ればあなたが不勉強なのはわかったよ

**デフォルトの名無しさん** · 2021/12/10(金) 16:09:36.14

vectorのaが空じゃないと思い込んでて実は空の状態で
for (int i =0; i < a.size()-1; i++)
これやると一瞬でオワるのなんとかならないかな
まあ普通はa.sizeをintやらでキャスりましょーって話だとは思うけど
そもそもsizeの型がuなのが悪いと思うんだが
uじゃなきゃ足りないくらいの要素数確保することなんてあんのか？ぁん？

**デフォルトの名無しさん** · 2021/12/10(金) 16:21:05.76

i+1<a.size()

**デフォルトの名無しさん** · 2021/12/10(金) 16:24:59.62

または、if(!a.empty()) for(...)

**デフォルトの名無しさん** · 2021/12/10(金) 16:26:11.66

>>309
てんさいかよ

**デフォルトの名無しさん** · 2021/12/10(金) 16:40:04.25

C++20にはstd::ssize()もあるぞ

**デフォルトの名無しさん** · 2021/12/10(金) 16:46:05.19

i <= a.size()-1じゃなくて i < a.size()-1？

**デフォルトの名無しさん** · 2021/12/10(金) 16:54:00.86

以下のような直感的でベタな条件式のほうがいいと思うよ
for (int i =0; a.size() > 0 && i < a.size()-1; i++)

**デフォルトの名無しさん** · 2021/12/10(金) 16:56:40.50

一見すると小学生の書いた作文っぽく見えるコードが結局のところ一番良い
厨二を拗らせたような難解なコードは避けよう

**デフォルトの名無しさん** · 2021/12/10(金) 16:58:49.17

このループ内でa[i]とa[i+1]を使ってなんかするんだろ
a[i+1]が有効なインデックスか？という条件がi+1<a.size()でこれは自然

**デフォルトの名無しさん** · 2021/12/10(金) 17:19:52.62

ああ、それなら納得

**デフォルトの名無しさん** · 2021/12/10(金) 17:20:02.15

なんで-1してるの？

**デフォルトの名無しさん** · 2021/12/10(金) 18:23:30.43

出典忘れたけどsizeが符号無しなのは標準委員会も失敗だったと考えてるらしい（？）

**デフォルトの名無しさん** · 2021/12/10(金) 20:12:16.24

まあ、そうでなきゃssize_tなんて恥ずかしいもの後付けしたりしないし

**デフォルトの名無しさん** · 2021/12/10(金) 20:26:39.77

>>314
二回余計な比較にクロックを喰われる

**デフォルトの名無しさん** · 2021/12/10(金) 21:01:58.48

最近このスレやばない？
intじゃなくてstd::vector<...>::size_typeでいい
>>310は明らかに間違ってる
1引くケースは大抵サイズ2以上がよくある事前条件なので普通事前に弾く
ループ内や別スレッドでvectorが変更されないケースならループの外で1引いた方が速い
今回ssize_tは無関係

**デフォルトの名無しさん** · 2021/12/10(金) 21:13:20.54

>>322
どこがヤバイの？
普通に動くし

**デフォルトの名無しさん** · 2021/12/10(金) 21:27:52.13

>>323
列挙したところ。普通にレベルがやばい。
>>310はwhile(!a.empty())と書いてるのかと思ってたので俺の勘違い。
何が普通に動くの？

**デフォルトの名無しさん** · 2021/12/10(金) 21:33:24.42

>>324
いや、間違えてるとか言われてたからな
頭の中で動かしてみて問題なく普通に動くだろうと
ってなんでお前そんなにエラそうなの？エラが張ってる民族か？

**デフォルトの名無しさん** · 2021/12/10(金) 22:00:02.92

>>325
聞かれたから答えたけど会話にならんな・・・この辺で

**デフォルトの名無しさん** · 2021/12/10(金) 22:00:16.81

どうしたらいいかご意見を聞かせてください！٩( ᐛ )و

class hogeにおいてメンバ変数unique_ptr<toge>toge1を所有しております。
vector<hoge> vHogeを運用するとき、hogeのインスタンスをプッシュバックしようとすると、削除された関数ですというエラーメッセージが帰ってまいります。
おそらくtoge1がユニークポインタであり、ムーブ以外の移動が不可能だからだと思うのですが……このままプッシュバックさせるのに何か方法はありますでしょうか？

健作でtoge1にshared_ptrを使う、hogeのコピーコンストラクタにmemcpyを使う等の解を見つけました。
私ごとですが、shared_ptrは循環参照で失敗した哀しい過去があり、恐怖感があります。
またmemcpyでユニークポインタをメモリコピーする場合の機序がイマイチわかりません……
ムーブを経由させずにどうやってユニークポインタを再確保出来る証拠でしょうか……？

どちらの方法でも、実行する場合の注意点があればなんでも教えていただければ幸いです(^O^)/
また上記以外の方法も、もし存在するならば教えていただけると嬉しいです(´；ω；`)

先にお礼申し上げます。ありがとうございます。

**デフォルトの名無しさん** · 2021/12/10(金) 22:05:57.88

>>326
もとはといえオメェが勘違いしたからだろこのヒトモドキが

**デフォルトの名無しさん** · 2021/12/10(金) 22:09:42.92

>>327
再現コードをどこかに貼って。伝わらない。
>>328
煽ってるだけじゃんｗだから会話にならないんだよｗ

**デフォルトの名無しさん** · 2021/12/10(金) 22:20:49.71

>>322
普通事前に弾くとかドヤ顔で言われてもそんなの200も承知の助なんだよ
ああいう不測な組み方で死にかねない爆弾抱えるデメリットに比べたら
unsignedなことによるメリットなんて実質ほぼないカスみたいなもんだからsizeがunsignedなのは設計ミスではって話

**デフォルトの名無しさん** · 2021/12/10(金) 22:23:19.44

申し訳ございません( ✌︎'ω')✌︎
遅れましたがこれです。
プッシュバックでエラーががが

struct Toge{
int a=0;
};
struct hoge {
std::unique_ptr<toge> toge1;
};

int main ()
{
std::vector<hoge> vHoge;
hoge hoge001;
vHoge.push_back(hoge001);
}

**デフォルトの名無しさん** · 2021/12/10(金) 22:24:50.14

大文字になってしまった……
struct Toge >>> struct toge
と思っていただければ……

**デフォルトの名無しさん** · 2021/12/10(金) 22:34:31.10

vHoge.push_back(std::move(hoge001));

**デフォルトの名無しさん** · 2021/12/10(金) 22:36:13.76

vectorに突っ込んだらもうhoge001は使わないんだったらvHoge.push_back(std::move(hoge001));

コピーさせたいならhogeにこんなコピコンとコピop=を定義しとけばいい
hoge(const hoge& other) : toge1(new toge(*other.toge1)){}
基本はmoveだけど時々コピーもしたいくらいなら特殊関数じゃなくてclone()みたいな関数にしておく
どれがいいかは本当の用途と目的で選んで

**デフォルトの名無しさん** · 2021/12/10(金) 22:37:31.61

>>332
コンパイルエラーを直してください
https://ideone.com/RxQYii

>>330
承知してるなら弾け
今回の用件はsize_type使えばいいだけなのでunsignedかどうかは関係ない

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 22:52:51.98

>>327
> hogeのコピーコンストラクタにmemcpyを使う等の解

これについてはダメ。
設計上の話ではなく言語仕様での保証がない。
そんなのがまかり通ったらスマートポインタの意味がない。

型が trivially copyable の要件を満たすときだけ memcpy でのコピーが許されている。

**デフォルトの名無しさん** · 2021/12/10(金) 23:02:05.91

>>335
オメェが直して差し上げろよ
本人それで困ってんだからよ

**デフォルトの名無しさん** · 2021/12/10(金) 23:18:01.33

>>337
なんだか煽ってばかりですね。質問内容は明快にしないといけないので。

**デフォルトの名無しさん** · 2021/12/10(金) 23:22:36.91

ああ言えば上裕
オメェそっくり

**デフォルトの名無しさん** · 2021/12/10(金) 23:40:14.88

>>335
いや関係大ありだから
ないって言い張るならsizeがunsignedなメリット挙げてみなよ、ないでしょ

**デフォルトの名無しさん** · 2021/12/10(金) 23:41:07.01

>>333
>>334
お風呂に入っており返信が遅くなりました。
なんてお礼を言ったらいいか、std::moveで解決しました。
自分の知識不足ではありますが、素早い返信に感謝でございます(〃ω〃)
生成したユニークポインタはベクターに移せれば使い捨てのでムーブで良さそうです。
std::moveについて調べてみます！

>>336
ありがとうございます。
メモコピーで解決するというページがあったのですが、正直機序がわからず不安でした（笑）
シェアードポインタかムーブで対応したいと思います。
有難うございました。

**デフォルトの名無しさん** · 2021/12/10(金) 23:49:32.55

>>308
普通は範囲forじゃないの？
性能とかで差分あったっけ。

**デフォルトの名無しさん** · 2021/12/10(金) 23:57:06.57

>>340
関係ないでしょｗ vectorの要素指定に必要な型はsize_typeだからｗ

**デフォルトの名無しさん** · 2021/12/11(土) 00:02:57.69

>>343
ふ～ん、で？
sizeがunsignedなメリット挙げれるの？挙げれないの？

**デフォルトの名無しさん** · 2021/12/11(土) 00:09:02.31

>>344
同じ人かなｗ最初から最後まで関係ないとしか言ってないよｗ関係ない話をする意味はないｗ

**デフォルトの名無しさん** · 2021/12/11(土) 00:11:05.65

はい逃げたねお疲れさまー
てかまあこんな頭の固いジジイ追い詰めなくても
>>319-320あたりで結論出てるからもういいんだけどね
sizeも漏れなく頭の固いクソジジイが設計ミスしたんだろうなぁ
間違いを認められるだけコイツよりまだマシだけど

**デフォルトの名無しさん** · 2021/12/11(土) 00:13:11.51

わいも寝るんで逃げさせてもらうわ、ほな

**デフォルトの名無しさん** · 2021/12/11(土) 00:13:27.97

>>346
煽るだけで根拠も出せてない無関係な話をしてるのはそっちでしょｗ話が終わらなくなるなら普通はしないｗ
頭が硬いのは君だよｗ

**デフォルトの名無しさん** · 2021/12/11(土) 02:16:25.58

>>341
もう見てないだろうけど、>>331のケースだと
わざわざstd::move()で右辺値にキャストしなくても
vHoge.push_back(hoge());
で良いと思う。
hoge hoge001;とするから左辺値になってしまってstd::move()が必要になるけど、
引数で直接hoge()とすれば右辺値だからstd::move()しなくても右辺値参照のpush_backが呼ばれるはず。

**デフォルトの名無しさん** · 2021/12/11(土) 03:09:07.14

emplace_backっていつ使うんだっけ？

**デフォルトの名無しさん** · 2021/12/11(土) 03:48:00.02

>>350
今でしょ･･･
>>349なんてしなくても
vHoge.emplace_back();
で良い話だった。

**デフォルトの名無しさん** · 2021/12/11(土) 08:31:56.16

>>349
ありがとうございます！
エンプレイスバックでも確認できました。

本当に根本がわかってなかったにでお恥ずかしい話ですが、ユニークポインタはmove出来ることは知っていても、インスタンスごとmoveするという考えに至りませんでした。
右辺値の言葉だけは知っていた状態です……
moveが引数の領域を右辺値に変換するので、インスタンスのメンバ全てが一時的に右辺地に変換され、その結果ユニークポインタの移動も許可されるという考えで良いのですかね？

皆様ありがとうございます

**デフォルトの名無しさん** · 2021/12/11(土) 08:39:15.08

gccのヘッダファイル見るとpush_backがemplace_backに置き換えられてた

**デフォルトの名無しさん** · 2021/12/11(土) 11:16:33.01

質問する方はそもそも何を知りたいのか、どうしたいのかを明確にせず
回答する方はよく分からずに回答してる感じだな(はちみつ餃子以外)

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

本人じゃないとありえんようなクソレス

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

俺ははちみつ餃子じゃないよ
分かってる人は全員そう思うと思う
このスレやばい

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

>>354
おまえさんの対話力が、ここの平均以下ってことだな
僅かなエスパーもできないアスペっぽいやつが
取り残されるのは仕方のないことだ

**デフォルトの名無しさん** · 2021/12/11(土) 11:41:55.96

ここをサポセンか何かと勘違いしてね？

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

上司や客に言われたことを自分も誰かに言いたいのかな

**デフォルトの名無しさん** · 2021/12/11(土) 11:53:10.78

>>357-359
3連投しないで1つにまとめてね

伝わらない人がいるのでハッキリ言うと、、、
質問したい人はもう少し明確に質問してほしい
回答する人はもう少し正確な回答をしてほしい

現在このスレのレベルはかなり落ちている

**デフォルトの名無しさん** · 2021/12/11(土) 12:03:14.48

>>360
あんたに連投がどうのと指図される筋合いはないし
質問者がどうして欲しい
回答者がどうして欲しい
と、やたら依頼心の強いやつだな

頼み事をする態度を知らんのか

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

僕だけは特別！

**デフォルトの名無しさん** · 2021/12/11(土) 12:08:44.64

>>361-362
見るに堪えないだけだよ。当たり前のことを要求してるだけだし、ID変えてまで一体何が気に障るのやら・・・

**デフォルトの名無しさん** · 2021/12/11(土) 12:14:57.20

簡単なコードが提示できないんだけどコンセプトで以下のようなエラーがでる

> C7608: アトミック制約は定数式である必要があります。

アトミック制約ってなに？

**デフォルトの名無しさん** · 2021/12/11(土) 12:19:25.86

１つの内容を理由もなく複数のレスに分けて投稿する奴はもれなくバカなのでスルー推奨

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

>>364
C++20はまだやる気ないので知らないけど、仕様は以下みたい。参考まで。
https://timsong-cpp.github.io/cppwp/n4861/temp.constr.constr#temp.constr.atomic

**デフォルトの名無しさん** · 2021/12/11(土) 13:18:37.47

多分atomic は、OS に割り込まれない、interrupt disable みたいな奴だろ。
割り込み禁止区間

1. 割り込み禁止
2. atomic に処理したいもの
3. 割り込み許可

**デフォルトの名無しさん** · 2021/12/11(土) 13:41:40.82

>>367
それはリアルモードOSでの話
最近の OS ではユーザーが OS の企みを阻止することは不可能

**デフォルトの名無しさん** · 2021/12/11(土) 13:49:58.55

無関係でスレ違いかつ「内容まで間違った」ことを垂れ流し続けるのはやめてくれ

**デフォルトの名無しさん** · 2021/12/11(土) 15:00:10.16

一般にアトミックと割り込み禁止は異なる概念、
マルチコアのアーキテクチャーなら割り込みを禁止したからといって
複数回のバスサイクルをアトミックに遂行できるとは限らない

つなみに割り込み禁止という手段でOSに割り込まれないことは実現はできるが
強力すぎるので普通はそれはしない
やったらリアルタイムOSならリアルタイム性の前提が根底から覆るし、
非リアルタイムOSでも割り込み禁止したタスクAとは本来無関係（独立に実行して良い）なタスクまで
プリエンプション停止によって止まってしまう弊害があるから

**デフォルトの名無しさん** · 2021/12/11(土) 15:12:24.61

リードモディファイライトぐらいなら今日日のCPUが命令を備えているのでOSにも対応するAPIがあり、
それを実行したらリード、ライト、リードの3バスサイクルがアトミックに実行される
もっと凝った処理をアトミックにしたい場合は

1. クリティカルセクション（セマフォとかでも良い）にENTER
2. atomic に処理したいもの
3. クリティカルセクション（セマフォとかでも良い）からLEAVE

となり、1と3はやはりOSにお世話いただく

**デフォルトの名無しさん** · 2021/12/11(土) 15:16:22.95

>>363
出た、当たり前のことを要求だとよ
自分の要求は通って当たり前と思っている真性のやつｗ

**デフォルトの名無しさん** · 2021/12/11(土) 15:18:53.32

>>371
クリティカルセクションとイベントを使って書いていたことがありましたが、スタベーションに悩まされて止めてしまいました…

**デフォルトの名無しさん** · 2021/12/11(土) 15:26:46.48

>>373
なんでatomicに処理するごときでイベントが出てくるのかわからん……
1で待っているタスクBが居るなら、アトミックな処理を終えたタスクAが3を実行した時点で
OSがタスクBに自動的に通知する（ていうか起こす
不必要に凝りまくった（そして間違った）排他制御をしているのではないか、

**デフォルトの名無しさん** · 2021/12/11(土) 16:00:21.52

セマフォでも大丈夫なん？

**デフォルトの名無しさん** · 2021/12/11(土) 16:48:16.25

U6KjSVaUだけまともだけど、CriticalSectionが同期機構として存在するのはWindowsだけ
アトミック制約と無関係でC++固有でもないのでスレ違いなのは同じだけど…その辺の話をするならせめて↓でしてくれ

標準C++で単にatomicな話なら
https://cpprefjp.github.io/reference.html#atomic-operations
標準C++でスレッドを対象とした話なら
https://cpprefjp.github.io/reference.html#thread-support
プロセスまで含むならboostになるけど
https://www.boost.org/doc/libs/1_78_0/doc/html/interprocess.html

**デフォルトの名無しさん** · 2021/12/11(土) 17:02:39.01

>>376
迷惑なんでコテハンにしていただけません？

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

何が迷惑なのか理由の説明がないが、コテハン付けたいならお前だけ勝手につけとけｗ

**デフォルトの名無しさん** · 2021/12/11(土) 17:13:56.24

template <typename T, typename Allocator = std::allocator<T>>
using vec = std::vector<T, Allocator>;

auto v = vec(0, 0);

ってgccだと動いてclangだとコンパイル通らないけどclangのバグ？

**デフォルトの名無しさん** · 2021/12/11(土) 17:17:46.16

勘違いしてた
セマフォでも一人に限定すれば問題ないか

**デフォルトの名無しさん** · 2021/12/11(土) 17:36:33.78

そもそもそもそも

アトミック制約って原子制約のことでしょう
排他制御のatomicとは全く無関係に

単にconstexprじゃないbool値をrequiresしてませんか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/11(土) 17:38:45.13

>>379
バグというか C++20 対応が不十分なんだと思う。

① 元々は実引数から型引数にあてはまる型を推論するのは関数テンプレート (メンバ関数テンプレートを含む) でしか出来なかった
② C++17 コンストラクタの実引数からクラスの型引数を推論できるようになった
③ C++20 からエイリアステンプレートを挟んでも推論できるようになった ← これがまだ出来ない

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

>>381
たしかにこれの最初のサンプルのdraw関数みたいな事をrequiresしてる。
https://cpprefjp.github.io/lang/cpp20/concepts.html
ただ上で言うdraw関数はconstexprなんだけどな・・・

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

>>382
わかりやすかったありがとう
まだmake_hogeみたいな不格好なヘルパ関数が役に立つこともあるのね

**デフォルトの名無しさん** · 2021/12/12(日) 02:33:53.10

NFTアートとNFTゲームとGameFiとブロックチェーンゲームに
提供する側・作る側として参入しよう。
（むりなら参加する側でもいい）
DAOとPlay-to-Earn(遊んで稼ぐ)が世界の未来になる