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/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"
すれば大丈夫だよ

2024/11/08(金) 18:18:53.42

>>539
なるほど、例えばこんな感じなら大丈夫なんですかね?
g++でコンパイルされたバイナリのグループAとclang++でコンパイルされたバイナリの
グループBがあったとき、AからB（またはその逆）を呼ぶときは必ずCリンケージの関数
経由にする、とか....

2024/11/08(金) 18:25:46.25

>>540
OK。
C インターフェイスの範囲ではどちらも同じ ABI (Application Binary Interface) に従ってるはず。

2024/11/08(金) 18:35:59.90

>>541
なるほど
皆さんどうもありがとうございます

2024/11/09(土) 19:08:22.86

昔std::vector<T>とかstd::stringを前のコンパイラでビルドしたDLLに渡したら以下略
やっぱコンパイラを混ぜるときはextern "C" な関数にプリミティブな型のみを渡すインターフェース設計にするﾊﾟﾃｨｰﾝが安牌
文字列とか渡したかったらあくまでchar[]にすべき……

2024/11/10(日) 16:10:22.46

>>536
この場合は別々に標準ライブラリがリンクされる、つまり2つ動くのかな？

2024/11/10(日) 17:48:03.99

単にリンクするだけではどっちかのライブラリのスタートアップしか呼ばれないから
呼ばれてない方のライブラリの初期化がされなくてまともに動作しない問題が残ると思う

2024/11/10(日) 18:18:05.60

仮にどうにか辻褄合わせが出来てちゃんと動いたとしても将来の開発環境・実行環境でどうなるか予想しづらいというのもある。

2024/11/10(日) 18:55:50.75

こういう感じの実装を見かけたんだけど、ptrって解放済みの領域を指してないよね？

int *ptr = NULL;
std::map<char, int> m;
m.insert(std::make_pair('a', 30));
{
　　std::map<char, int>::iterator itr = m.find('a');
　　if (itr != m.end()) ptr = &(itr->second);
　　// ここでitrは解放される
}

if (ptr) printf("*ptr = %d\n", *ptr);　// 大丈夫？

2024/11/10(日) 19:59:53.20

>>547
itr が指してる先は m の一部なのでまだ生きてる。
問題ない。

2024/11/10(日) 20:31:11.60

>>548
あざっす！なるほど、よかった～

2024/11/11(月) 00:36:44.76

>>545
ﾔｳﾞｧｲやん>>539しても全然OKじゃないやん……

2024/11/11(月) 00:38:49.39

ただしウィンドーズのDLLの呼び出し場合は>>539に従っていれば問題無いはず……
ランタイムの初期化エントリはDLL毎に_DllMainCRTStartup が用意されてDLL初期化時に呼ばれる

2024/11/11(月) 16:46:00.51

https://www.openwork.jp/company.php?m_id=a0910000000FrzY

**青木康善** (ｱｳｱｳｳｰ Saa9-gsEs) · 2024/11/12(火) 22:22:32.82

独習C++を図書館で借りました。よく、こんな、難しく、エグい言語が出来ますねみなさん。

2024/11/12(火) 22:26:44.98

他に選択肢がなかったんや😭

あと最近はobjective-cとかいう悪魔合体に比べたらなんでもマシな言語に思えてきてる

2024/11/13(水) 01:53:29.63

Objective-C++もよろしく

2024/11/13(水) 02:14:12.02

>>553
汚いが、必要なものはある。
綺麗に整理されてても必要なものがないよりは良い。

2024/11/13(水) 03:47:19.43

そーだそーだ
C++は難しいからObject Pascalやろうぜ！

2024/11/14(木) 07:49:57.71

C++女学院の人々ってまだ読める所ある？
大好きだったんだけど。

2024/11/14(木) 12:23:07.88

>>554
C++と悪魔合体してObjective-C++とかなってるけど自分は実用的に感じた
全部それで書こうとは思わんけど、C++との共存のレベルが高くて鼻血出そうになったわ
OSやその他Apple系APIとのやり取りはObjC++、それ以外のソースはC++のみ、とかも簡単だし

2024/11/14(木) 14:52:24.21

>>553
若い人がCからC++の増築増築で可笑しくなって行った歴史をなぞるのは無意味ではない

>>554-555
Objective-C や Objective-C++ の方がまし

やる気は無いけどObjectPASCALはDelphiだっけ

**デフォルトの名無しさん** (JP 0H1e-hB9O) · 2024/11/19(火) 11:41:41.34

演算子のオーバーロードない言語はダメだ

2024/11/19(火) 11:53:31.53

演算子オーバーロードがもたらす言語仕様の複雑性を理解してたら軽々しくそういうことは言えない

2024/11/19(火) 12:47:14.19

演算子なんてなしでも書けるわけで単なる見た目だよ
些末な話

2024/11/19(火) 13:12:37.41

見た目はとても重要だが
見ただけでは何が実行されるかわからない

2024/11/19(火) 15:35:04.94

JavaのBigDecimalなんか見てると演算子オーバーロードのあるC++羨ましいよ
c = a.multiply(b); とか長くなり過ぎて何をやってる式なのか分からなくなる

2024/11/19(火) 15:37:29.08

いや固定小数型を言語仕様に盛り込まずにライブラリとして実装したJavaが悪いのか・・・
固定小数の取り扱い以外で演算子オーバーロードが欲しいと思ったことはない

**デフォルトの名無しさん** (JP 0H1e-hB9O) · 2024/11/19(火) 15:45:09.52

複素数計算やったことないからそんなこと言える

2024/11/19(火) 17:03:01.93

JAVAはコボラーが転んで使う言語だし

**デフォルトの名無しさん** (JP 0H1e-hB9O) · 2024/11/19(火) 17:38:58.74

自動微分のボトムアップ微分はC++の演算子オーバーロード機能のおかげで簡単に実現できる

2024/11/19(火) 18:42:30.52

javaって演算子オーバーロードないのか・・・

2024/11/20(水) 17:06:14.09

>>567
†とか造った？

2024/11/20(水) 21:14:42.80

Javaが持て囃されてた頃は「演算子オーバーロード？＋で引き算もできるってこと？なんて危険な機能なんだ！」って叩かれてて
そんな危険なものはJavaにはありません！って売り文句にされてたんだよ
アホみたいだけど本当の話

2024/11/20(水) 21:21:46.59

アホといい切れる根拠は言える？

2024/11/20(水) 22:54:39.86

アホみたいなカスの嘘です

2024/11/20(水) 23:28:22.48

演算子オーバーロードは定義のリスクや手間の割には結局自己満に完結する事が多くて、
しかも結局C++という小さな世界でしか通用しないから、他に楽しい事が沢山ある今の人は時間の無駄と考えるんじゃないかな

2024/11/20(水) 23:48:15.85

無理に使うもんではないなたまにすごく便利

2024/11/21(木) 00:20:44.87

std::chronoの時間型なんかは良い例だよね

・clock - clock = duration (例. 13時 - 12時 = 1時間)
・clock + duration = clock (12時+1時間=13時)
・duration + duration = duration (1時間 + 1時間 = 2時間)
・clock + clock: 不可

こういう型表現もできるのは良い点

2024/11/21(木) 01:22:06.15

初見で単に整数で取り出すのに一苦労だけどな
型安全厨くささ感じる

2024/11/21(木) 08:22:14.09

演算の組み合わせが多いユースケースで可読性を上げるためのものだろう。
少ないなら関数のままでも十分。そういう意味で std::chrono は微妙。

**デフォルトの名無しさん** (JP 0H1e-hB9O) · 2024/11/21(木) 10:15:07.08

>>575

あんた他人の受け売りだろ。fortran90にだって演算子オーバーロードあるのに

**デフォルトの名無しさん** (JP 0H1e-hB9O) · 2024/11/21(木) 10:20:45.90

>>571
随伴行列(共役転置行列)か？　それは演算子オーバーロードじゃなくて普通の関数でいいだろ

2024/11/21(木) 19:11:25.04

いわゆる演算子オーバーロードのメリットは、中置記法が使えるということと、一部の人間が使い慣れている演算子の算数・数学的記法のメタファーが使えることくらいかね。

その代償として文章構造の曖昧さや(その対処のための)優先順位といった規則の複雑化が必要になるので、言語設計観点からはメリット小さいよなぁ。
可能ならば中置記法を捨てて全部後置記法に統一したいところ。