[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
463: (ﾜｯﾁｮｲ 5ef4-bJfQ) 2024/09/13(金)19:59 ID:2C9M8qgO0(1) AAS
move禁止したらvector使えないし
464: (ｱｳｱｳｴｰ Sadf-N1Zj) 2024/09/17(火)12:59 ID:TMGdiCOOa(1) AAS
それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな
465: (ﾜｯﾁｮｲ bf84-GITO) 2024/09/17(火)16:24 ID:DN+X/Cyr0(1) AAS
何がしたい
あほでしょ
466(1): 447 (ﾜｯﾁｮｲ d763-HdVQ) 2024/09/21(土)20:05 ID:FUSKAHoo0(1/3) AAS
何やら集中砲火を浴びている>>442 やが
マルチスレッド状況でshared_ptr<T>を超有効活用できる手が一つあったわ；；；
スレッド間の共有オブジェクトをポインタpで保持する際の問題点は、
そのポインタを知っている複数スレッドの間でpが指すオブジェクト*pへのアクセスを悉く排他制御せなばならない点やが
逆にpを知っているスレッドが任意の時刻につき1つだけなら、オブジェクトのアクセスに対して排他の必要が無い
それでいてスレッドへのデータの受け渡しに関してコピーの手間は減らせる
例:
省8
467: 447 (ﾜｯﾁｮｲ d763-HdVQ) 2024/09/21(土)20:13 ID:FUSKAHoo0(2/3) AAS
ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、
468: (ﾜｯﾁｮｲ d763-HdVQ) 2024/09/21(土)20:35 ID:FUSKAHoo0(3/3) AAS
std::vector<TreeNode> nodes;
ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない
std::vector<std::shared_ptr<TreeNode> > apNodes;
ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる
469: (ﾜｯﾁｮｲ e37c-C1Jv) 2024/09/22(日)08:21 ID:e5FZYjui0(1) AAS
それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは
470: (ﾜｯﾁｮｲ 1e52-VArp) 2024/09/25(水)13:57 ID:N5yN4IuU0(1) AAS
>>466
>>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ
生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ
おまえはそれ以上のクソレスにクソコード
でもお前の勝ちだ
クソコードに2週間かけた情熱に免じて親切におしえてやるわ
shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝
省4
471: (ﾜｯﾁｮｲ cb41-LUcV) 2024/09/26(木)03:21 ID:5BtHXQaO0(1) AAS
あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか
自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね
(オブジェクト内部の排他は別に必要だとしても)
472(1): (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/26(木)10:52 ID:R5lWYvWFa(1/4) AAS
そんなあなたにRust
473(2): (ﾜｯﾁｮｲ 3224-jZWQ) 2024/09/26(木)11:26 ID:r0pzUHiv0(1) AAS
>>472
c++コードと混在できるようになってからの話だな。
既存c++を捨てなきゃならんのなら要らん。
474: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/26(木)11:37 ID:R5lWYvWFa(2/4) AAS
もちろんRustをやるにはC++を捨てる覚悟が必要
C++コード(特にテンプレやclass)とは相性最悪
475: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/26(木)11:38 ID:R5lWYvWFa(3/4) AAS
>c++コードと混在できるようになって
Rustについて言うなら
おそらくそんな未来は永久に来ない
476: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/26(木)11:39 ID:R5lWYvWFa(4/4) AAS
誤解の無いように言っておくと
(一部機能に限れば今でも混在出来るけど)
基本的にはC++とは相いれない
477(1): (ﾜｯﾁｮｲ 77da-jZWQ) 2024/09/26(木)18:22 ID:sl+cfKHN0(1/2) AAS
ならc++にRustの機能が取り込まれるのを待つ。
Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。
478(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e332-Pvcq) 2024/09/26(木)18:52 ID:B+Au+yIB0(1/2) AAS
>>477
もう Rust を使えばよくない……？
479: (ﾜｯﾁｮｲ 77da-jZWQ) 2024/09/26(木)19:43 ID:sl+cfKHN0(2/2) AAS
>>478
>>473だっつうの。
Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。
480(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e332-Pvcq) 2024/09/26(木)20:25 ID:B+Au+yIB0(2/2) AAS
>>165
C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。
たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。
Rust がやってるような安全性の保障を自動では受けられない。
当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。
大抵の場合に Rust の都合に合わせてラッパーを書くことになる。
481(1): (ﾜｯﾁｮｲ e39c-jZWQ) 2024/09/27(金)10:23 ID:n6BA5joS0(1/3) AAS
>>480
KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？
Rustとc++では無理だと思うけど。
482(1): (ﾌﾞｰｲﾓ MMe3-VArp) 2024/09/27(金)10:44 ID:02Aq/BhWM(1) AAS
cxxとかあるけど個人的には中途半端だから使わない
普通に共有ライブラリにして呼び出す方が素直で汎用的で良い
483(1): (ﾜｯﾁｮｲ 5e79-w5sm) 2024/09/27(金)12:33 ID:6/1p1gGO0(1) AAS
スマートポインターを使うように強制できる機能とかなら必要ないなあ
484: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/27(金)16:51 ID:pgg/4VuRa(1/4) AAS
>>473 のような未来は永遠に来ない
485: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/27(金)16:54 ID:pgg/4VuRa(2/4) AAS
>>482
結局Cが正解なんよ
C++のスレで言うのもなんだけど
486: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/27(金)16:54 ID:pgg/4VuRa(3/4) AAS
>>481
同意
487: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/27(金)16:54 ID:pgg/4VuRa(4/4) AAS
>>480
嘘つくな
出鱈目言うな
488: (ﾜｯﾁｮｲ e39c-jZWQ) 2024/09/27(金)17:14 ID:n6BA5joS0(2/3) AAS
>>483
コーダー向けので考えるなら、スマポ強制は最優先だろ。
生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。
489(1): (ﾜｯﾁｮｲ 728c-rNKn) 2024/09/27(金)18:24 ID:dg7IL8lg0(1) AAS
極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし
今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ
490(1): (ﾜｯﾁｮｲ 1e02-VArp) 2024/09/27(金)18:46 ID:EoeiRCVP0(1) AAS
gcがあったらメモリリークしないなんて幻想未だに信じてるとはね
491(1): (ﾜｯﾁｮｲ a778-KU+G) 2024/09/27(金)18:59 ID:RwmUzOsi0(1) AAS
リークの話なの？
492(1): (ﾜｯﾁｮｲ e39c-jZWQ) 2024/09/27(金)19:07 ID:n6BA5joS0(3/3) AAS
>>489
ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。
コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。
493: (ﾜｯﾁｮｲ cb9e-LUcV) 2024/09/27(金)23:12 ID:cfj6fT7K0(1) AAS
>>492
それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど
ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな
それですら問題が起きるようならユーザーがクソ
494: (ﾜｯﾁｮｲ e37c-C1Jv) 2024/09/28(土)10:42 ID:swed/tX60(1) AAS
C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね
ライブラリがあんまりそこ頑張っても仕方ない
495: (ｱｳｱｳｴｰ Saaa-rNKn) 2024/09/28(土)12:39 ID:gf2/NL3ha(1) AAS
Rustなら壊れないみたいな言い草だな
496(1): (ﾜｯﾁｮｲ 77ba-vp5J) 2024/09/28(土)13:06 ID:ZP4SxDa50(1) AAS
C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た
メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって
ほんとかな？
ただのラッパーじゃないの？
C++側でメモリアクセス違反があれば落ちそうだけど
497: (ﾌﾞｰｲﾓ MMde-7TYI) 2024/09/28(土)14:26 ID:yW35cSECM(1) AAS
その手の話はMICROSOFTの新機能ぐらいい思っておけば
腹も立たない
498(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ b332-XD+R) 2024/09/30(月)22:26 ID:JxqgGnHQ0(1) AAS
>>496
Rust の標準ライブラリだって内部は unsafe だらけだぞ。
unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。
ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。
ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。
押し込めた中に問題があればそりゃ当然駄目だよ。
499: (ﾜｯﾁｮｲ 6f79-uMZa) 2024/10/01(火)02:05 ID:J7GPtKrz0(1) AAS
V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ
500(1): (ｵｲｺﾗﾐﾈｵ MMa7-Pc8v) 2024/10/01(火)15:19 ID:KXGxeTHwM(1) AAS
>>498
>押し込めた中に問題があればそりゃ当然駄目だよ。
当然分かっているだろうが、unsafeの中だけでなく、
それが外側に及ぼす影響にも問題が生じないように作らなければなら
ないが、それにはunsafeとRustの両方に対する深い理解が
必要となるだろうな。
501: (ｵｲｺﾗﾐﾈｵ MMa7-Pc8v) 2024/10/01(火)18:36 ID:al1nAqGBM(1) AAS
>>500
unsafeの中を通過する時には問題ないが、
戻り値などや、連携する他のメソッドなどが
関係した結果、どこかで分かりにくいメモリーエラー
になるようなことも避ける必要が有るが、
それにはかなりRustの内部構造(?)に対する深い知識
と理解が必要となりそうだ。
502: (ﾜｯﾁｮｲ 1fb1-/QnX) 2024/10/17(木)11:01 ID:P7X9/HPx0(1) AAS
>>422
これ、static_assertだけ修正してもしょうがない気がするんだけどなぁ
他にも実体化しないはずの分岐でチェックされてエラーにされることあるし
まぁ条件式に無理矢理テンプレート入れて回避は出来るけど
503(1): (ﾜｯﾁｮｲ 2b63-4umj) 2024/10/19(土)17:30 ID:vb3IsOJN0(1/2) AAS
>>491
Rustのオブジェクトの所有権管理の強制はコンパイラに従う限りリークしない
（病的な反例があるかどうかは知らん
からリークの話ではないが、GC付き言語で解決という香具師が現れたから
504: (ﾜｯﾁｮｲ 2b63-4umj) 2024/10/19(土)17:31 ID:vb3IsOJN0(2/2) AAS
>>490な発言になったんじゃないの
知らんけど
505: (ﾜｯﾁｮｲ 8593-t4Y2) 2024/10/21(月)07:19 ID:ThoL8xQh0(1) AAS
>>503
RustはRcの循環参照解決できたの？
公式ソースある？
506: (ﾜｯﾁｮｲ 1907-zDHq) 2024/10/21(月)14:54 ID:WHCxApN50(1) AAS
C++派だが、Rustをもってしても、相互参照みたいなものは、人類には早いらしい
(設計段階で)無理しないこったな。。
507: (ﾜｯﾁｮｲ c60f-zhf3) 2024/10/21(月)15:57 ID:Hhc6wfX80(1) AAS
そもそも静的解析で解決できる問題か？
508: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 0d32-zDHq) 2024/10/21(月)16:03 ID:6JU3cZPt0(1) AAS
循環参照をしたいときに出来ないのも困るしな。
なるべくやらないに越したことはないが、やるなら後始末は人が考えないと仕方ないわ。
509: (ﾜｯﾁｮｲ e963-f5bJ) 2024/10/21(月)22:48 ID:XvJERuqr0(1/2) AAS
食事する哲学者の問題……
Rustだと循環参照するコードを書きにくくなっているから
循環参照によるリークとか病的な反例のうちなんじゃないの
知らんけど
ノードNode同士が論理的には循環参照し得るんだけど
その所有権をスーパーバイザ的な配列superArray: Node[]が持っていて、
510(1): (ﾜｯﾁｮｲ e963-f5bJ) 2024/10/21(月)22:53 ID:XvJERuqr0(2/2) AAS
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はどんな魔法を使ってくれる
省1
511: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 0d32-zDHq) 2024/10/22(火)11:28 ID:UXnTPhGj0(1) AAS
>>510
Rust では実行時にチェックされて範囲から外れていたら panic (C/C++ で言うところの abort みたいなもの) する。
外部ﾘﾝｸ[html]:doc.rust-lang.org
C/C++ のように配列がポインタになるということはなく、スライス (C++ で言うところの span みたいなもの) が基本型として組み込まれているので範囲チェック出来る。
コンパイル時に範囲内であることがわかる状況なら最適化で消えることもあるみたいだけど
実行時に外部から入ってくる値に依存することもあるので実行時にチェックしないとどうしようもない。
512: (ﾜｯﾁｮｲ 8901-1CwD) 2024/10/28(月)13:44 ID:A9ortPvu0(1) AAS
enum、
文字列への変換、
大変すぎて、ビックリした
513: (ﾜｯﾁｮｲ 1901-2Yr6) 2024/10/28(月)14:06 ID:/lht/Ba/0(1) AAS
俺はenumの機能を拡張するクラスを自分で定義してるな
それで文字列変換も文字列からの変換も出来る
514(1): (ﾜｯﾁｮｲ 4907-+Yhf) 2024/10/28(月)15:41 ID:xcgYWtNU0(1) AAS
autogenerated.txt.c みたいなの使うのも手だぞ 急がば回れ
そしてCよりはうまく書ける
515: (ﾜｯﾁｮｲ 8901-1CwD) 2024/10/29(火)08:22 ID:XRXAB2XQ0(1) AAS
>>514
うーん、どんなもの？それ
516: (ﾜｯﾁｮｲ 4907-+Yhf) 2024/10/29(火)13:58 ID:WYOK+g300(1) AAS
好きなように書いて、好きなように変換して、途中でincludeする
簡単に書くもよし、ガッチガチにチェックするもよし
517: (ﾜｯﾁｮｲ fb79-fQm0) 2024/10/30(水)23:11 ID:x0G86HEF0(1) AAS
HAGE(CAUWA1)
HAGE(CAUWA2)
HAGE(CAUWA3)
：
みたいなテキスト作っといて
手コキストを#includeする手前でHAGEの意味を変えてやるとうまいこと一元化できる
518(1): 警備員[Lv.44] (ﾜｯﾁｮｲ 89c3-YFB5) 2024/10/31(木)00:43 ID:ET2RcGMR0(1) AAS
ｶｳﾜ?
519: (ﾜｯﾁｮｲ 7b4d-XqAs) 2024/10/31(木)01:08 ID:gisW4Gdb0(1) AAS
magic_enum教えてやれや
じじいは感度低いから知らんか
520: (ﾜｯﾁｮｲ 4907-+Yhf) 2024/10/31(木)05:43 ID:J4xtBqBy0(1) AAS
みてきた それが人気の実装か
やりたいこと次第だが、オーバスペック感はある
ちょうどほしかったんなら止めないけどね
521: (ﾜｯﾁｮｲ 1901-2Yr6) 2024/10/31(木)10:56 ID:++2hP8JV0(1) AAS
横からなるほどー！
__PRETTY_FUNCTION__ / __FUNCSIG__
522(1): (ﾜｯﾁｮｲ 8901-1CwD) 2024/10/31(木)15:32 ID:IcW65SaY0(1) AAS
あのー、アメリカグーグルで、検索すれば、良いのがでてきた
日本は、でてこない
これは、やっぱり、レベルなんだろうね
523: (ｱｳｱｳｴｰ Sae3-07nO) 2024/11/01(金)19:53 ID:TgBKHsuNa(1) AAS
>>518
あさひ奈央
524: (ﾜｯﾁｮｲ 1395-VVnD) 2024/11/02(土)09:17 ID:KpOoS8wa0(1) AAS
>>522
アメリカグーグルって言い方からして頭悪そう
525: (ﾜｯﾁｮｲ 5910-fVPo) 2024/11/05(火)08:04 ID://VVBUiD0(1) AAS
magic_enumは個数制限がきついんだよな・・256くらいが限度じゃなかったっけ
526(1): 青木康善 (ｱｳｱｳｳｰ Sacd-P7MY) 2024/11/06(水)17:05 ID:vfgxFq1Ya(1) AAS
c plus plusとjava、電子音楽作成にどっちが向いてるかな？早いのは無論c plus plusだろうけど。
527: (ﾜｯﾁｮｲ 6107-Q1tn) 2024/11/06(水)17:09 ID:jrSvpMvx0(1) AAS
作成というが、記述したいのか、波形合成したいのか、はたまた生成(AI等)したいのか。。
528: (ﾜｯﾁｮｲ f618-UxC2) 2024/11/06(水)17:14 ID:P7rcAaD30(1) AAS
なんでjava？
529: (ﾜｯﾁｮｲ a901-jwtj) 2024/11/06(水)20:06 ID:TrFjb6KE0(1) AAS
>>526
C++ね
記号の入れ方知らないのかな
530: 青木康善 (ｱｳｱｳｳｰ Sacd-P7MY) 2024/11/06(水)20:56 ID:XG1hV+N8a(1) AAS
C soundというのはかつてありましたが。javaでやろうかな。C++は自分にはハードル高すぎます。
531: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f532-Q1tn) 2024/11/06(水)21:37 ID:O6Mhx+Gj0(1) AAS
相談スレなんだから相談しなさいよ。
独り言を書きたいなら X で。
532: (ｵｯﾍﾟｹ Sr79-Q1tn) 2024/11/06(水)22:48 ID:tlKINjNQr(1) AAS
５ちゃん初めてなんでしょ。浮いてるのはほっとこう、じきに慣れてくれる
コンパイラがCらしいね。でもjavaからも操作できる実績があるって
こういうときは、「やってみて脳汁が出そうなほう」でいいとおもう
結局モチベなんで
533: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f532-JeGG) 2024/11/07(木)03:05 ID:LEgJ6Wm00(1) AAS
Csound は公式に Python や Java 用のラッパーは用意してるみたいだから得意なのでやればよさそう。
ところで固有名詞は正確に表記してくれないと探しにくいやで。
534: (ﾜｯﾁｮｲ 7e9a-NsVU) 2024/11/08(金)17:26 ID:k0cYSKPq0(1/5) AAS
g++とclang++が混ざった環境なのですが、g++でコンパイルしたバイナリはstd::stringとか
名前に__cx11というプレフィックスが付き、一方clang++の方は__1というものが付くようです
とりあえず、clang++の方で__cx11が付くようなバイナリを生成するにはどうしたら
いいでしょうか?
535: (ﾜｯﾁｮｲ 7e9a-NsVU) 2024/11/08(金)17:28 ID:k0cYSKPq0(2/5) AAS
すみません、__cx11じゃなくて__cxx11でした
536(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f532-JeGG) 2024/11/08(金)17:41 ID:Me1tPYCI0(1) AAS
名前だけ合わせても具体的な実装方法が違えばどうせクラッシュするから意図的にマングルルールを違えている。
外部ﾘﾝｸ[html]:gcc.gnu.org
537: (ﾜｯﾁｮｲ 7e9a-NsVU) 2024/11/08(金)17:52 ID:k0cYSKPq0(3/5) AAS
>>536
なるほど、要は「C++コンパイラ、混ぜるな危険」ということでしょうか?
538: (ﾜｯﾁｮｲ a901-7tmY) 2024/11/08(金)18:12 ID:6Qfff3nN0(1/2) AAS
例外とか互換性があるんかいな?
539(3): (ﾜｯﾁｮｲ a901-7tmY) 2024/11/08(金)18:14 ID:6Qfff3nN0(2/2) AAS
C++コンパイラでコンパイルするにしても
ソースコードをCの範囲に留めて
関数プロトタイプを
extern "C"
すれば大丈夫だよ
540(1): (ﾜｯﾁｮｲ 7e9a-NsVU) 2024/11/08(金)18:18 ID:k0cYSKPq0(4/5) AAS
>>539
なるほど、例えばこんな感じなら大丈夫なんですかね?
g++でコンパイルされたバイナリのグループAとclang++でコンパイルされたバイナリの
グループBがあったとき、AからB（またはその逆）を呼ぶときは必ずCリンケージの関数
経由にする、とか....
541(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 71e8-JeGG) 2024/11/08(金)18:25 ID:Evz7xgHe0(1) AAS
>>540
OK。
C インターフェイスの範囲ではどちらも同じ ABI (Application Binary Interface) に従ってるはず。
542: (ﾜｯﾁｮｲ 7e9a-NsVU) 2024/11/08(金)18:35 ID:k0cYSKPq0(5/5) AAS
>>541
なるほど
皆さんどうもありがとうございます
543: (ﾜｯﾁｮｲ b163-+nMC) 2024/11/09(土)19:08 ID:djyKk80a0(1) AAS
昔std::vector<T>とかstd::stringを前のコンパイラでビルドしたDLLに渡したら以下略
やっぱコンパイラを混ぜるときはextern "C" な関数にプリミティブな型のみを渡すインターフェース設計にするﾊﾟﾃｨｰﾝが安牌
文字列とか渡したかったらあくまでchar[]にすべき……
上下前次1-新書関写板覧索設栞歴
あと 459 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.026s