C++相談室 part165

2023/10/31(火) 07:37:38.52

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2024/09/05(木) 18:17:57.29

shared_ptrを使いたくなったら設計を見直すべき

2024/09/06(金) 07:27:10.33

>>440
それは無理があるんじゃないのかね。
データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。

設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。

2024/09/06(金) 11:54:45.03

>>440
マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある
言ってる意味がわからないならお前は経験不足

2024/09/06(金) 22:35:55.77

recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする

2024/09/07(土) 11:45:08.02

C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ

2024/09/07(土) 11:58:09.00

>>444
生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。

スタック変数専用仮引数とかあればもっと安全になるのになぁ。
仮引数の種類はもっとあっていいと思う。

2024/09/07(土) 16:26:14.57

>>445
考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？
特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね
生ポ受け取る場合暗黙のキャストも効かないし

2024/09/07(土) 20:17:38.39

>>442
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……

>>439
自己参照ではないが前方宣言が必須の例、
class TreeNode;

class TreeNode {
　　std::shared_ptr<TreeNode> m_pLeft;
　　std::shared_ptr<TreeNode> m_pRight;
public:
　　TreeNode();
　　...
};
　　

2024/09/07(土) 20:21:44.33

んまー前方宣言が必須というのは言い杉やったかもしれんorz
TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて
専用の領域をまとめて確保して、
木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが
その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば
前方宣言は不要、

2024/09/07(土) 21:38:34.24

>>442
使わざるを得ないは言い過ぎじゃね
同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？
競技プログラマか何かか？

2024/09/08(日) 00:33:39.65

shared_ptrの内部的な参照カウンタとかはともかく
保持しているオブジェクト自体はアトミックでもなんでもないでしょ
ってなんか勘違いしてる?

2024/09/08(日) 01:27:17.93

持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw

2024/09/08(日) 01:32:50.82

そこでRustですよ！

2024/09/08(日) 12:52:42.06

でたｗ
布教ﾏｿw

2024/09/10(火) 11:29:59.05

>>447
お前の理解はshared_ptrの一面だけだな
ようするにunique_ptrの延長でしか見てない
shared_ptrがどうしても欲しくなるのは
オブジェクトのリリースタイミングが非決定的であるとき
これは一般的にマルチスレッド環境

お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが
例えば動的可変multi producerなqueueの場合確実に安全なqueueの解放タイミングを知るにはリファレンスカウントのような制御が必要となる
当然この場合コピーすれば安全なんて寝ぼけたことにはならない

2024/09/10(火) 13:20:49.36

x 対して

2024/09/10(火) 15:36:50.97

それで自己参照ってのは結局何のことを指して言っていたんだい

2024/09/10(火) 15:39:03.70

あ、相互参照が先か
>>435>>436の言うところの

2024/09/11(水) 12:14:54.12

(*this)
↑
自己参照

2024/09/11(水) 12:19:01.05

木のノードはstd::vector<>で確保する
と言われて、だよねってなる人はnewもほとんど必要ない

2024/09/11(水) 12:22:29.60

木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る
良くある行きがかり順のイテレータはスタックを使って作る

2024/09/11(水) 15:12:04.16

でvectorの拡張で破綻すんだろ？

2024/09/13(金) 16:29:50.66

move禁止

2024/09/13(金) 19:59:43.80

move禁止したらvector使えないし

2024/09/17(火) 12:59:42.12

それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな

2024/09/17(火) 16:24:30.60

何がしたい
あほでしょ

**447** (ﾜｯﾁｮｲ d763-HdVQ) · 2024/09/21(土) 20:05:42.93

何やら集中砲火を浴びている>>442 やが
マルチスレッド状況でshared_ptr<T>を超有効活用できる手が一つあったわ；；；

スレッド間の共有オブジェクトをポインタpで保持する際の問題点は、
そのポインタを知っている複数スレッドの間でpが指すオブジェクト*pへのアクセスを悉く排他制御せなばならない点やが
逆にpを知っているスレッドが任意の時刻につき1つだけなら、オブジェクトのアクセスに対して排他の必要が無い
それでいてスレッドへのデータの受け渡しに関してコピーの手間は減らせる

例:
なんちゃらWorkerスレッドオブジェクトをshared_ptr<Worker>のキューで保持しておく
スレッドfooが使うときWorker1をshared_ptr<Worker>としてpopする（←これは排他が要る
スレッドbarが使うときWorker2をshared_ptr<Worker>としてpopする（←これは排他が要る
...
（スレッドfooやbarはWorker1、2をそれぞれ独占的に使用できる） ←重要
...
スレッドfooが使い終わったWorker1をキューにpushする（←これは排他が要る
スレッドbarが使い終わったWorker2をキューにpushする（←これは排他が要る

**447** (ﾜｯﾁｮｲ d763-HdVQ) · 2024/09/21(土) 20:13:25.63

ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、

2024/09/21(土) 20:35:47.52

std::vector<TreeNode> nodes;
ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない
std::vector<std::shared_ptr<TreeNode> > apNodes;
ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる

2024/09/22(日) 08:21:05.99

それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは

2024/09/25(水) 13:57:54.93

>>466
>>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ
生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ

おまえはそれ以上のクソレスにクソコード
でもお前の勝ちだ
クソコードに2週間かけた情熱に免じて親切におしえてやるわ

shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝
(pの先の排他ではこれは実現できない)

もちろんこれも正しく使わないと保証できない
よくあるミスは知ったかぶって参照カウントを操作しないようにshared_ptrを参照渡しとかにするやつな
その間に絶対deleteされない保証がないならやってはいけない

2024/09/26(木) 03:21:09.01

あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか
自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね
(オブジェクト内部の排他は別に必要だとしても)

2024/09/26(木) 10:52:52.31

そんなあなたにRust

2024/09/26(木) 11:26:35.22

>>472
c++コードと混在できるようになってからの話だな。
既存c++を捨てなきゃならんのなら要らん。

2024/09/26(木) 11:37:49.48

もちろんRustをやるにはC++を捨てる覚悟が必要
C++コード(特にテンプレやclass)とは相性最悪

2024/09/26(木) 11:38:22.04

>c++コードと混在できるようになって
Rustについて言うなら
おそらくそんな未来は永久に来ない

2024/09/26(木) 11:39:08.38

誤解の無いように言っておくと
(一部機能に限れば今でも混在出来るけど)
基本的にはC++とは相いれない

2024/09/26(木) 18:22:32.63

ならc++にRustの機能が取り込まれるのを待つ。

Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。

2024/09/26(木) 18:52:53.17

>>477
もう Rust を使えばよくない……？

2024/09/26(木) 19:43:24.82

>>478
>>473だっつうの。

Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。

2024/09/26(木) 20:25:47.69

>>165
C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。
たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。

Rust がやってるような安全性の保障を自動では受けられない。
当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。
大抵の場合に Rust の都合に合わせてラッパーを書くことになる。

2024/09/27(金) 10:23:27.00

>>480
KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？
Rustとc++では無理だと思うけど。

2024/09/27(金) 10:44:00.51

cxxとかあるけど個人的には中途半端だから使わない
普通に共有ライブラリにして呼び出す方が素直で汎用的で良い

2024/09/27(金) 12:33:43.81

スマートポインターを使うように強制できる機能とかなら必要ないなあ

2024/09/27(金) 16:51:52.33

>>473 のような未来は永遠に来ない

2024/09/27(金) 16:54:13.57

>>482
結局Cが正解なんよ
C++のスレで言うのもなんだけど

2024/09/27(金) 16:54:31.95

>>481
同意

2024/09/27(金) 16:54:58.40

>>480
嘘つくな
出鱈目言うな

2024/09/27(金) 17:14:28.28

>>483
コーダー向けので考えるなら、スマポ強制は最優先だろ。

生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。

2024/09/27(金) 18:24:18.27

極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし
今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ

2024/09/27(金) 18:46:28.46

gcがあったらメモリリークしないなんて幻想未だに信じてるとはね

2024/09/27(金) 18:59:34.32

リークの話なの？

2024/09/27(金) 19:07:06.62

>>489
ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。

コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。

2024/09/27(金) 23:12:04.55

>>492
それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど
ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな
それですら問題が起きるようならユーザーがクソ

2024/09/28(土) 10:42:06.28

C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね
ライブラリがあんまりそこ頑張っても仕方ない

2024/09/28(土) 12:39:39.83

Rustなら壊れないみたいな言い草だな

2024/09/28(土) 13:06:22.71

C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た
メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって
ほんとかな？

ただのラッパーじゃないの？
C++側でメモリアクセス違反があれば落ちそうだけど

2024/09/28(土) 14:26:57.72

その手の話はMICROSOFTの新機能ぐらいい思っておけば
腹も立たない

2024/09/30(月) 22:26:30.09

>>496
Rust の標準ライブラリだって内部は unsafe だらけだぞ。
unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。
ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。

ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。
押し込めた中に問題があればそりゃ当然駄目だよ。

2024/10/01(火) 02:05:59.60

V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ

2024/10/01(火) 15:19:57.32

>>498
>押し込めた中に問題があればそりゃ当然駄目だよ。
当然分かっているだろうが、unsafeの中だけでなく、
それが外側に及ぼす影響にも問題が生じないように作らなければなら
ないが、それにはunsafeとRustの両方に対する深い理解が
必要となるだろうな。

2024/10/01(火) 18:36:21.46

>>500
unsafeの中を通過する時には問題ないが、
戻り値などや、連携する他のメソッドなどが
関係した結果、どこかで分かりにくいメモリーエラー
になるようなことも避ける必要が有るが、
それにはかなりRustの内部構造(?)に対する深い知識
と理解が必要となりそうだ。

2024/10/17(木) 11:01:19.65

>>422
これ、static_assertだけ修正してもしょうがない気がするんだけどなぁ
他にも実体化しないはずの分岐でチェックされてエラーにされることあるし
まぁ条件式に無理矢理テンプレート入れて回避は出来るけど

2024/10/19(土) 17:30:35.94

>>491
Rustのオブジェクトの所有権管理の強制はコンパイラに従う限りリークしない
（病的な反例があるかどうかは知らん
からリークの話ではないが、GC付き言語で解決という香具師が現れたから

2024/10/19(土) 17:31:10.99

>>490な発言になったんじゃないの
知らんけど

2024/10/21(月) 07:19:50.64

>>503
RustはRcの循環参照解決できたの？
公式ソースある？

2024/10/21(月) 14:54:46.51

C++派だが、Rustをもってしても、相互参照みたいなものは、人類には早いらしい
(設計段階で)無理しないこったな。。

2024/10/21(月) 15:57:11.21

そもそも静的解析で解決できる問題か？

2024/10/21(月) 16:03:29.88

循環参照をしたいときに出来ないのも困るしな。
なるべくやらないに越したことはないが、やるなら後始末は人が考えないと仕方ないわ。

2024/10/21(月) 22:48:14.20

食事する哲学者の問題……
Rustだと循環参照するコードを書きにくくなっているから
循環参照によるリークとか病的な反例のうちなんじゃないの
知らんけど

ノードNode同士が論理的には循環参照し得るんだけど
その所有権をスーパーバイザ的な配列superArray: Node[]が持っていて、

2024/10/21(月) 22:53:33.76

Node間の参照はsuperArrayのindexで済ませるというのもRustではすんなり通してくれな
いんだっけどうだっけ……
Node& node1 = superArray[0];
Node& node2 = superArray[1];
node1.next = 1;
superArray[node1.next].value = 123; // node2.valueに書く

node1.nextがsuperArray[]の添え字範囲内であることを機械的に保証するためにRustはどんな魔法を使ってくれる
のか

2024/10/22(火) 11:28:00.82

>>510
Rust では実行時にチェックされて範囲から外れていたら panic (C/C++ で言うところの abort みたいなもの) する。
https://doc.rust-lang.org/std/ops/trait.Index.html#tymethod.index
C/C++ のように配列がポインタになるということはなく、スライス (C++ で言うところの span みたいなもの) が基本型として組み込まれているので範囲チェック出来る。

コンパイル時に範囲内であることがわかる状況なら最適化で消えることもあるみたいだけど
実行時に外部から入ってくる値に依存することもあるので実行時にチェックしないとどうしようもない。

2024/10/28(月) 13:44:32.71

enum、
文字列への変換、

大変すぎて、ビックリした

2024/10/28(月) 14:06:10.17

俺はenumの機能を拡張するクラスを自分で定義してるな
それで文字列変換も文字列からの変換も出来る

2024/10/28(月) 15:41:01.09

autogenerated.txt.c みたいなの使うのも手だぞ急がば回れ
そしてCよりはうまく書ける

2024/10/29(火) 08:22:28.04

>>514

うーん、どんなもの？それ

2024/10/29(火) 13:58:12.41

好きなように書いて、好きなように変換して、途中でincludeする
簡単に書くもよし、ガッチガチにチェックするもよし

2024/10/30(水) 23:11:10.17

HAGE(CAUWA1)
HAGE(CAUWA2)
HAGE(CAUWA3)
：
みたいなテキスト作っといて
手コキストを#includeする手前でHAGEの意味を変えてやるとうまいこと一元化できる

警備員[Lv.44] (ﾜｯﾁｮｲ 89c3-YFB5) · 2024/10/31(木) 00:43:29.18

ｶｳﾜ?

2024/10/31(木) 01:08:33.55

magic_enum教えてやれや
じじいは感度低いから知らんか

2024/10/31(木) 05:43:35.79

みてきたそれが人気の実装か
やりたいこと次第だが、オーバスペック感はある
ちょうどほしかったんなら止めないけどね

2024/10/31(木) 10:56:16.92

横からなるほどー！
__PRETTY_FUNCTION__ / __FUNCSIG__

2024/10/31(木) 15:32:14.58

あのー、アメリカグーグルで、検索すれば、良いのがでてきた

日本は、でてこない
これは、やっぱり、レベルなんだろうね

2024/11/01(金) 19:53:27.66

>>518
あさひ奈央

2024/11/02(土) 09:17:27.71

>>522
アメリカグーグルって言い方からして頭悪そう

2024/11/05(火) 08:04:39.53

magic_enumは個数制限がきついんだよな・・256くらいが限度じゃなかったっけ

**青木康善** (ｱｳｱｳｳｰ Sacd-P7MY) · 2024/11/06(水) 17:05:23.05

c plus plusとjava、電子音楽作成にどっちが向いてるかな？早いのは無論c plus plusだろうけど。

2024/11/06(水) 17:09:08.31

作成というが、記述したいのか、波形合成したいのか、はたまた生成(AI等)したいのか。。

2024/11/06(水) 17:14:36.09

なんでjava？

2024/11/06(水) 20:06:37.45

>>526
C++ね
記号の入れ方知らないのかな

**青木康善** (ｱｳｱｳｳｰ Sacd-P7MY) · 2024/11/06(水) 20:56:51.96

C soundというのはかつてありましたが。javaでやろうかな。C++は自分にはハードル高すぎます。

2024/11/06(水) 21:37:08.81

相談スレなんだから相談しなさいよ。
独り言を書きたいなら X で。

2024/11/06(水) 22:48:47.88

５ちゃん初めてなんでしょ。浮いてるのはほっとこう、じきに慣れてくれる

コンパイラがCらしいね。でもjavaからも操作できる実績があるって
こういうときは、「やってみて脳汁が出そうなほう」でいいとおもう
結局モチベなんで

2024/11/07(木) 03:05:44.48

Csound は公式に Python や Java 用のラッパーは用意してるみたいだから得意なのでやればよさそう。
ところで固有名詞は正確に表記してくれないと探しにくいやで。

2024/11/08(金) 17:26:41.87

g++とclang++が混ざった環境なのですが、g++でコンパイルしたバイナリはstd::stringとか
名前に__cx11というプレフィックスが付き、一方clang++の方は__1というものが付くようです

とりあえず、clang++の方で__cx11が付くようなバイナリを生成するにはどうしたら
いいでしょうか?

2024/11/08(金) 17:28:48.87

すみません、__cx11じゃなくて__cxx11でした

2024/11/08(金) 17:41:34.61

名前だけ合わせても具体的な実装方法が違えばどうせクラッシュするから意図的にマングルルールを違えている。
https://gcc.gnu.org/onlinedocs/gcc/Interoperation.html#Interoperation

2024/11/08(金) 17:52:36.03

>>536
なるほど、要は「C++コンパイラ、混ぜるな危険」ということでしょうか?

2024/11/08(金) 18:12:15.75

例外とか互換性があるんかいな?

2024/11/08(金) 18:14:37.25

C++コンパイラでコンパイルするにしても
ソースコードをCの範囲に留めて
関数プロトタイプを
extern "C"
すれば大丈夫だよ