[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
407: (ﾜｯﾁｮｲ 7f78-/FHh) 2024/08/24(土)09:23 ID:yYuYqoCz0(3/6) AAS
y=xのときは忘れてください。(ｆ(complex<T>& y, const T& ｘ)とすればいいだけ)。どういう状況のためにconceptが必要なのか要点がまとまっていませんね。失礼しました。
408: (ﾜｯﾁｮｲ 7ff0-aWDb) 2024/08/24(土)09:53 ID:PPcTgFGr0(1/4) AAS
conceptで無理やりくくるよりか、static_assertのほうが楽そう
template<class T, class U>void f(T& x, const U& y)
{
static_assert(std::is_same<double,T>::value&&std::is_same<complex<TU>::value,"絶対にゆるさない！絶対ﾆﾀﾞ!!");
x=y;
...
}
409: (ﾜｯﾁｮｲ 7f78-/FHh) 2024/08/24(土)11:11 ID:yYuYqoCz0(4/6) AAS
&& は右辺値参照ではなくてandの意味なんですね。std::is_same<double,T>はdouble型とT型が一致するかどうかを調べるヘルパー変数テンプレート、::value は trueかfalseのいずれかの値をとる定数ですか。static_assertは自分でエラーメッセージを作れるのがいいですね。完全にわかっていないですが、勉強します。ヒントありがとうございました。
410: (ﾜｯﾁｮｲ 1f23-dwWB) 2024/08/24(土)11:44 ID:6PXbzil00(1/2) AAS
最近、初心者にいきなり右辺値参照とかテンプレート教える風潮は良くないと思うんだよなぁ・・・論理andとごっちゃになってるやんけ
ともあれis_same自体は構造体で、中にあるvalueは定数値やで
変数テンプレートはis_same_vの方。利便性(::value書くのがめんどい)のために用意されてるだけ
static_assertの第一引数(bool)に条件式を与えてるんだが、間違ってる
static_assert(!(std::is_same<double,T>::value&&std::is_same<complex<TU>::value),"絶対にゆるさない！絶対ﾆﾀﾞ!!");
411: (ﾜｯﾁｮｲ 7ff0-aWDb) 2024/08/24(土)12:20 ID:PPcTgFGr0(2/4) AAS
！抜けてたわ
ｽﾏｿ
412(2): (ﾜｯﾁｮｲ 7ff0-aWDb) 2024/08/24(土)12:40 ID:PPcTgFGr0(3/4) AAS
// こういう書き方もある
if const_expr ( std::is_same<double,T>::value && std::is_same<complex<TU>::value ) {
//許されない処理
static_assert(false,"許さんぞ!!");
}else {
//正常処理
}
413: (ﾜｯﾁｮｲ 7ff0-aWDb) 2024/08/24(土)12:43 ID:PPcTgFGr0(4/4) AAS
また間違えたw
× const_expr
● constexpr
414(1): (ﾜｯﾁｮｲ 7f78-/FHh) 2024/08/24(土)14:40 ID:yYuYqoCz0(5/6) AAS
いろいろとありがとうございます。参考になりました。
template<class T, class U> void f(T& x, U& y)
{
if constexpr ( !(std::is_same<T,double>::value &&
std::is_same<U, std::complex<T>>::value) ) static_assert(false,"ワシャ許さんぞ!!");
y=x;
}
省15
415: (ﾜｯﾁｮｲ 7f78-/FHh) 2024/08/24(土)15:09 ID:yYuYqoCz0(6/6) AAS
std::is_same<T,double>::valueの代わりにstd::same_as<T,double>でも良いみたいですね．
416(1): (ﾜｯﾁｮｲ 9f63-rdaS) 2024/08/24(土)16:42 ID:6x2BzwZB0(1/2) AAS
#ifdef NDEBUG
/*pass*/
#else
class dbg_complex {
std::complex<double> m_complex;
public:
// std::complex<double> のメソッドのうち使うやつ同じシグネチャのメソッドを書き並べ、m_complexに移譲
省7
417: (ﾜｯﾁｮｲ 9f63-rdaS) 2024/08/24(土)16:48 ID:6x2BzwZB0(2/2) AAS
いちいち移譲せねばならないのはstd::complex<T>の継承が禁止されているためorz
実際デストラクタが十中八九virtualではないし、
>>416の最後の
#define complex dbg_complex
みたいな穴だらけの置換手段が嫌ならもうstd::complex<double> を普段からcomplexdbl という別名にすると決めてまう
すると
#ifdef NDEBUG
省6
418(1): (ﾜｯﾁｮｲ ff67-kHtd) 2024/08/24(土)18:35 ID:BJpt+Mj00(1) AAS
>>412
これかなり新しめのコンパイラじゃないと動かないので注意
419: (ﾜｯﾁｮｲ 1f23-dwWB) 2024/08/24(土)19:16 ID:6PXbzil00(2/2) AAS
行うべき解放処理が無い上ポリモーフィズムも不要なら、別にデストラクタがvirtualである必要は無いぞ
このケースで継承すべきかどうかはまた別として
420: (ﾜｯﾁｮｲ 1fbe-3Zrt) 2024/08/24(土)23:53 ID:4DIR6G6I0(1) AAS
>>412
constexpr if が使える (= C++17以上) なら std::is_same<T, U>::value よりも std::is_same_v<T, U> を使う方がシンプルだと思う
421: (ﾜｯﾁｮｲ 02f0-HfY5) 2024/08/25(日)00:16 ID:LfSHCV3h0(1/2) AAS
ま、お好きなの使えいいんじゃないんすか～
こちとら例文示しているだけで極めているﾜｹじゃないからぬ
422(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 4d32-7Uxd) 2024/08/25(日)01:15 ID:zZ+WMAII0(1) AAS
>>414
テンプレート型引数に require 節などで制約を付けた場合に制約に合致しなければオーバーロード解決候補から除外されるが、 static_assert や if constexpr での判定は解決が終わってテンプレートが実体化されるときに判定される。
つまり、より優先順位の低い候補に当てはめたいかもしれない場合は static_assert や if constexpr での判定をすべきではない。
状況によって使い分けがある。
それと >>418 が注意しているのは、テンプレートはテンプレート引数に依存しない部分は実体化されなくても検証されるルールだから。
(Two phase name lookup について調べてみて。)
つまり static_assert(false, ほにゃらら) と書いてあったらそのテンプレートが使われるかどうかに関係なく問答無用でエラーとして報告されていた。
省2
423: (ﾜｯﾁｮｲ 0278-RCJX) 2024/08/25(日)01:34 ID:GxcwnqZY0(1) AAS
まあ、そんな小難しいこと言われても。C++が嫌われる理由だわ
424: (ﾜｯﾁｮｲ 02f0-HfY5) 2024/08/25(日)02:05 ID:LfSHCV3h0(2/2) AAS
実体化ってどっちみちコンパイルするときにエラー発生するんだから結果かわらねぇだろﾊﾞｶがよう
425: (ﾜｯﾁｮｲ c5a7-8JDH) 2024/08/25(日)06:41 ID:n8ainESh0(1) AAS
static_assert(false, "")は何かしらダミーの値入れて回避してたけど修正されてたんだ、知らんかった
426: (ﾜｯﾁｮｲ 02f0-HfY5) 2024/08/26(月)00:27 ID:JWWBXqLI0(1) AAS
false効かないﾊﾞｶｺﾝﾊﾟｲﾗはどうしようもないからどうにもならんか
//requires を使った方法
template<class T, class U>
requires(!(std::is_same_v<double,T>&&std::is_same_v<complex<TU>))
void f(T& x, const U& y)
{
x=y;
省2
427: (ﾜｯﾁｮｲ 2963-G6Q9) 2024/08/27(火)07:16 ID:NdPbjHCm0(1/2) AAS
特定の引数型についてテンプレート展開を阻止したいんなら
特殊化してその中にstatic_assert(false, "*** ERR ***")書いても昔は駄目だったんか恐ろしい……
428: (ﾜｯﾁｮｲ 2963-G6Q9) 2024/08/27(火)07:35 ID:NdPbjHCm0(2/2) AAS
しかしまあ特殊化してテンプレート引数の型Tについて
態と存在しないメソッドを呼ぶように書いたらその特殊化ケースについて展開を阻止できうる（適当
クラス内でint型定数が欲しかったら古き良き enum { ONE, TWO, THREE } で十分やし
同じことをやる手段を増やせば良いってもんじゃないぞPerlじゃあるまいし……
429: (ｱｳｱｳｴｰ Sa0a-PBPb) 2024/08/27(火)14:55 ID:oHcafaf7a(1) AAS
perlの面白仕様
430: (ﾜｯﾁｮｲ c5f3-8JDH) 2024/08/27(火)17:14 ID:K2iTXH930(1) AAS
まぁ普通にSFINAEなり=delete指定なりコンセプトなりでオーバーロード候補から外す方が利用者視点でいえば自然だな
431(1): (ﾜｯﾁｮｲ 0278-RCJX) 2024/08/27(火)17:33 ID:K7dNHCWQ0(1) AAS
#include <iostream>
#include <complex>
template <class T> decltype(auto) f(T x)
{
decltype(abs(std::declval<T>())) w;
w=abs(x);
return w;
省12
432: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 4d32-7Uxd) 2024/08/27(火)18:27 ID:WfqXHPCU0(1) AAS
>>431
sizeof や decltype のオペランドは評価されないということになってる。
だからその文脈で関数を使う場合でもその関数が定義されている必要はない。 (宣言だけあればよい。)
評価されないけど実体化は起こるのでそのへんの理屈は複雑でよくわからん。
433: ころころ (ﾜｯﾁｮｲ 0202-3rb6) 2024/08/30(金)02:40 ID:qLymVnYK0(1) AAS
decval使ったコード始めてみたかも
434: (ﾜｯﾁｮｲ 0220-Fpn2) 2024/08/30(金)05:15 ID:ZIPlhev80(1) AAS
相互参照わっかんねぇ
435(2): (ﾜｯﾁｮｲ 5f2f-+rLF) 2024/09/02(月)12:36 ID:bqeYsc0k0(1) AAS
相互参照は必要ない
最近はウェブプログラマのほうが賢くなった
すそ野が広がると質が良くなるらしい
436(1): (ﾜｯﾁｮｲ bf0a-5+wm) 2024/09/02(月)13:00 ID:Rco2Fp/20(1) AAS
必要ない理由ぐらい言ったら？
437: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e732-CMA8) 2024/09/02(月)14:42 ID:o+5p2SR60(1) AAS
プログラムの文法要素が相互参照になっている状況という意味？
たとえば前方宣言が必要な場合とか。
それとも (実行時の) データ構造が相互参照ということ？
たとえば循環構造の後始末のやり方がわからんとか。
438: (ﾜｯﾁｮｲ 0701-+rOo) 2024/09/02(月)19:52 ID:cn5uZ01w0(1) AAS
>>435
その「相互参照」って何?
439(1): (ｱｳｱｳｴｰ Sa1f-XN8b) 2024/09/05(木)00:06 ID:/oUqYYg3a(1) AAS
相互参照も自己参照も一緒
自己参照なんて参照してるのは自己ではない
ホントの意味での自己参照は循環参照
440(2): (ﾜｯﾁｮｲ 5f00-+rLF) 2024/09/05(木)18:17 ID:xTcyjaky0(1) AAS
shared_ptrを使いたくなったら設計を見直すべき
441: (ﾜｯﾁｮｲ 277f-jESi) 2024/09/06(金)07:27 ID:Qb4sTpDj0(1) AAS
>>440
それは無理があるんじゃないのかね。
データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。
設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。
442(4): (ﾌﾞｰｲﾓ MM7f-5+wm) 2024/09/06(金)11:54 ID:onD85wsiM(1) AAS
>>440
マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある
言ってる意味がわからないならお前は経験不足
443: (ﾜｯﾁｮｲ e7df-UdSI) 2024/09/06(金)22:35 ID:0hxwMUxG0(1) AAS
recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする
444(1): (ﾜｯﾁｮｲ 0753-60ma) 2024/09/07(土)11:45 ID:Zy1zUumM0(1) AAS
C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ
445(1): (ﾜｯﾁｮｲ bfac-jESi) 2024/09/07(土)11:58 ID:UFsx2JaR0(1) AAS
>>444
生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。
スタック変数専用仮引数とかあればもっと安全になるのになぁ。
仮引数の種類はもっとあっていいと思う。
446: (ﾜｯﾁｮｲ 27ea-60ma) 2024/09/07(土)16:26 ID:lSV8lU690(1/2) AAS
>>445
考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？
特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね
生ポ受け取る場合暗黙のキャストも効かないし
447(2): (ﾜｯﾁｮｲ 8763-0xUn) 2024/09/07(土)20:17 ID:Ci+xhqlU0(1/2) AAS
>>442
むしろshared_ptr<T>でスレッド間共有オブジェクトを保持するのは
生ポに対するshared_ptr<T>のメリットが無い……
可能な限りスレッド間共有なんてことはやめてconstオブジェクトのコピーにするのが正義……
>>439
自己参照ではないが前方宣言が必須の例、
class TreeNode;
省8
448: (ﾜｯﾁｮｲ 8763-0xUn) 2024/09/07(土)20:21 ID:Ci+xhqlU0(2/2) AAS
んまー前方宣言が必須というのは言い杉やったかもしれんorz
TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて
専用の領域をまとめて確保して、
木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが
その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば
前方宣言は不要、
449: (ﾜｯﾁｮｲ 27ea-60ma) 2024/09/07(土)21:38 ID:lSV8lU690(2/2) AAS
>>442
使わざるを得ないは言い過ぎじゃね
同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？
競技プログラマか何かか？
450: (ﾜｯﾁｮｲ 069a-KwgP) 2024/09/08(日)00:33 ID:vgBqrjWA0(1) AAS
shared_ptrの内部的な参照カウンタとかはともかく
保持しているオブジェクト自体はアトミックでもなんでもないでしょ
ってなんか勘違いしてる?
451: (ﾜｯﾁｮｲ 91ea-IbtD) 2024/09/08(日)01:27 ID:6Lpw1aoe0(1) AAS
持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw
452: (ﾜｯﾁｮｲ b501-I4rH) 2024/09/08(日)01:32 ID:TMvzCbR60(1) AAS
そこでRustですよ！
453: (ﾜｯﾁｮｲ eaf0-8qrK) 2024/09/08(日)12:52 ID:Lw7YNDXG0(1) AAS
でたｗ
布教ﾏｿw
454: (ﾌﾞｰｲﾓ MM0a-bJfQ) 2024/09/10(火)11:29 ID:v6KS9t6sM(1) AAS
>>447
お前の理解はshared_ptrの一面だけだな
ようするにunique_ptrの延長でしか見てない
shared_ptrがどうしても欲しくなるのは
オブジェクトのリリースタイミングが非決定的であるとき
これは一般的にマルチスレッド環境
お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが
省2
455: (ｱｳｱｳｴｰ Sa52-t/33) 2024/09/10(火)13:20 ID:KGjTz1X0a(1) AAS
x 対して
456: (ﾜｯﾁｮｲ 8a48-/VPw) 2024/09/10(火)15:36 ID:+l9ylb2n0(1/2) AAS
それで自己参照ってのは結局何のことを指して言っていたんだい
457: (ﾜｯﾁｮｲ 8a48-/VPw) 2024/09/10(火)15:39 ID:+l9ylb2n0(2/2) AAS
あ、相互参照が先か
>>435>>436の言うところの
458: (ﾜｯﾁｮｲ 1ede-2PHd) 2024/09/11(水)12:14 ID:n6/LwjNL0(1/3) AAS
(*this)
↑
自己参照
459: (ﾜｯﾁｮｲ 1ede-2PHd) 2024/09/11(水)12:19 ID:n6/LwjNL0(2/3) AAS
木のノードはstd::vector<>で確保する
と言われて、だよねってなる人はnewもほとんど必要ない
460: (ﾜｯﾁｮｲ 1ede-2PHd) 2024/09/11(水)12:22 ID:n6/LwjNL0(3/3) AAS
木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る
良くある行きがかり順のイテレータはスタックを使って作る
461: (ﾌﾞｰｲﾓ MM45-bJfQ) 2024/09/11(水)15:12 ID:1n/VD1trM(1) AAS
でvectorの拡張で破綻すんだろ？
462: (ｱｳｱｳｴｰ Sa52-t/33) 2024/09/13(金)16:29 ID:bblj+c3pa(1) AAS
move禁止
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
嘘つくな
出鱈目言うな
上下前次1-新書関写板覧索設栞歴
あと 515 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s