- 1 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ efda-9b8G) mailto:sage [2023/10/31(火) 07:37:38.52 ID:+ZyYyqMO0.net]
- !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
- 400 名前：デフォルトの名無しさん mailto:sage [2024/08/08(木) 04:05:43.03 ID:G3QDAupS0.net]
- 今のANSI対応版は易しくなってると思うけどな。
不安ならアンサーブックとセットで買えば良いベ
- 401 名前：デフォルトの名無しさん mailto:sage [2024/08/08(木) 16:07:46.41 ID:fgfi2g+JM.net]
- VMのオーバーヘッドがあるのに20倍って?
あるいは20倍時間が掛かる?
- 402 名前：青木康善 [2024/08/09(金) 13:02:28.92 ID:FZEpuz0a0.net]
- いや、プログミング言語は、駿台電子は、国語の倒置法なんです。夜間の一年で、javaからで、二年でCなんです。いや、アンサーブックは、池袋ジュンク堂本店さんには、置いてなかったような。。。。。ありがたいというか、ビックリ。。。。マジか。。。機械語を仕事でプログラミングしていた先生が、喫煙所で、青木、お前、一つのことを本当に深く考えたことがあるか？と質問してくれた恩師なんです。
- 403 名前：デフォルトの名無しさん [2024/08/10(土) 12:16:45.89 ID:xFKQiXk00.net]
- スカイネットの誕生日
- 404 名前：デフォルトの名無しさん [2024/08/10(土) 23:52:09.93 ID:oQf4NdPPd.net]
- 御巣鷹山ノボレ
- 405 名前：デフォルトの名無しさん [2024/08/24(土) 08:35:54.88 ID:yYuYqoCz0.net]
- すみません。教えて下さい。
template<class T, class U>void (T& x, const U& y)
{
x=y;
...
}
double ←complex<double> の代入がコンパイルエラーとなるconceptの書き方あるんでしょうか？
complex<double> ← doubleの代入ではエラーが出てほしくないです。
- 406 名前：デフォルトの名無しさん [2024/08/24(土) 09:05:25.59 ID:yYuYqoCz0.net]
- あ、上では関数名fが抜けてましたね．concept使わずとも
template<class T> void f(complex<T>& x, const T& y)とすればいいでしょうけど、
y=xのときはどうかとか、あるいは complex<double>←float の代入はokにしたいとか、
いろいろ考えているとテンプレート関数なのに関数のオーバーロードが増えてしまって面倒だなと思ったものですから。
- 407 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 7f78-/FHh) [2024/08/24(土) 09:23:02.26 ID:yYuYqoCz0.net]
- y=xのときは忘れてください。(ｆ(complex<T>& y, const T& ｘ)とすればいいだけ)。どういう状況のためにconceptが必要なのか要点がまとまっていませんね。失礼しました。
- 408 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 09:53:34.49 ID:PPcTgFGr0.net]
- 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<T>,U>::value,"絶対にゆるさない！絶対ﾆﾀﾞ!!");
x=y;
...
}
- 409 名前：デフォルトの名無しさん [2024/08/24(土) 11:11:32.60 ID:yYuYqoCz0.net]
- && は右辺値参照ではなくてandの意味なんですね。std::is_same<double,T>はdouble型とT型が一致するかどうかを調べるヘルパー変数テンプレート、::value は trueかfalseのいずれかの値をとる定数ですか。static_assertは自分でエラーメッセージを作れるのがいいですね。完全にわかっていないですが、勉強します。ヒントありがとうございました。
- 410 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 11:44:22.45 ID:6PXbzil00.net]
- 最近、初心者にいきなり右辺値参照とかテンプレート教える風潮は良くないと思うんだよなぁ・・・論理andとごっちゃになってるやんけ
ともあれis_same自体は構造体で、中にあるvalueは定数値やで
変数テンプレートはis_same_vの方。利便性(::value書くのがめんどい)のために用意されてるだけ
static_assertの第一引数(bool)に条件式を与えてるんだが、間違ってる
static_assert(!(std::is_same<double,T>::value&&std::is_same<complex<T>,U>::value),"絶対にゆるさない！絶対ﾆﾀﾞ!!");
- 411 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 12:20:38.61 ID:PPcTgFGr0.net]
- ！抜けてたわ
ｽﾏｿ
- 412 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 12:40:45.95 ID:PPcTgFGr0.net]
- // こういう書き方もある
if const_expr ( std::is_same<double,T>::value && std::is_same<complex<T>,U>::value ) {
//許されない処理
static_assert(false,"許さんぞ!!");
}else {
//正常処理
}
- 413 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 12:43:11.34 ID:PPcTgFGr0.net]
- また間違えたw
× const_expr
● constexpr
- 414 名前：デフォルトの名無しさん [2024/08/24(土) 14:40:14.03 ID:yYuYqoCz0.net]
- いろいろとありがとうございます。参考になりました。
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;
}
template <class T, class U> void g(T& x, U& y)
{
static_assert( (std::is_same<T,double>::value && std::is_same<U, std::complex<T>>::v
alue),"ワシャ許さんぞ!!" );
y=x;
}
int main()
{
using namespace std;
double x=3.14159265358979;
complex<double> z;
f(x,z);
g(z,x); // 順番変えたり、ｘをfloatにするとエラー
cout<<z<<endl;
しかし、コンパイル時にifがつかえるんですねえ。凄いな、constexpr
- 415 名前：デフォルトの名無しさん [2024/08/24(土) 15:09:12.28 ID:yYuYqoCz0.net]
- std::is_same<T,double>::valueの代わりにstd::same_as<T,double>でも良いみたいですね．
- 416 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 16:42:04.52 ID:6x2BzwZB0.net]
- #ifdef NDEBUG
/*pass*/
#else
class dbg_complex {
std::complex<double> m_complex;
public:
// std::complex<double> のメソッドのうち使うやつ同じシグネチャのメソッドを書き並べ、m_complexに移譲
...
private:
dbg_complex(doble); // 禁止
};
#define complex dbg_compled
#endif
※ 個人の感想です。
- 417 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 16:48:40.66 ID:6x2BzwZB0.net]
- いちいち移譲せねばならないのはstd::complex<T>の継承が禁止されているためorz
実際デストラクタが十中八九virtualではないし、
>>416の最後の
#define complex dbg_complex
みたいな穴だらけの置換手段が嫌ならもうstd::complex<double> を普段からcomplexdbl という別名にすると決めてまう
すると
#ifdef NDEBUG
using complexdbl = std::complex<double>;
#else
using complexdbl = dbg_complex;
#endif
で済む
- 418 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 18:35:31.16 ID:BJpt+Mj00.net]
- >>412
これかなり新しめのコンパイラじゃないと動かないので注意
- 419 名前：デフォルトの名無しさん mailto:sage [2024/08/24(土) 19:16:42.78 ID:6PXbzil00.net]
- 行うべき解放処理が無い上ポリモーフィズムも不要なら、別にデストラクタがvirtualである必要は無いぞ
このケースで継承すべきかどうかはまた別として
- 420 名前：デフォルトの名無しさん [2024/08/24(土) 23:53:59.32 ID:4DIR6G6I0.net]
- >>412
constexpr if が使える (= C++17以上) なら std::is_same<T, U>::value よりも std::is_same_v<T, U> を使う方がシンプルだと思う
- 421 名前：デフォルトの名無しさん mailto:sage [2024/08/25(日) 00:16:13.89 ID:LfSHCV3h0.net]
- ま、お好きなの使えいいんじゃないんすか～
こちとら例文示しているだけで極めているﾜｹじゃないからぬ
- 422 名前：はちみつ餃子 [2024/08/25(日) 01:15:32.96 ID:zZ+WMAII0.net]
- >>414
テンプレート型引数に require 節などで制約を付けた場合に制約に合致しなければオーバーロード解決候補から除外されるが、 static_assert や if constexpr での判定は解決が終わってテンプレートが実体化されるときに判定される。
つまり、より優先順位の低い候補に当てはめたいかもしれない場合は static_assert や if constexpr での判定をすべきではない。
状況によって使い分けがある。
それと >>418 が注意しているのは、テンプレートはテンプレート引数に依存しない部分は実体化されなくても検証されるルールだから。
(Two phase name lookup について調べてみて。)
つまり static_assert(false, ほにゃらら) と書いてあったらそのテンプレートが使われるかどうかに関係なく問答無用でエラーとして報告されていた。
新しい仕様では static_assert は実体化のときまで検証しないように挙動が改められたのだが、これは欠陥報告の形で問題提起されて過去の仕様に遡って修正されるので C++11 からこの仕様だったことになった。
新しいコンパイラでは C++11 を指定したときでも新しい挙動になる。
- 423 名前：デフォルトの名無しさん [2024/08/25(日) 01:34:45.73 ID:GxcwnqZY0.net]
- まあ、そんな小難しいこと言われても。C++が嫌われる理由だわ
- 424 名前：デフォルトの名無しさん mailto:sage [2024/08/25(日) 02:05:31.18 ID:LfSHCV3h0.net]
- 実体化ってどっちみちコンパイルするときにエラー発生するんだから結果かわらねぇだろﾊﾞｶがよう
- 425 名前：デフォルトの名無しさん mailto:sage [2024/08/25(日) 06:41:14.01 ID:n8ainESh0.net]
- static_assert(false, "")は何かしらダミーの値入れて回避してたけど修正されてたんだ、知らんかった
- 426 名前：デフォルトの名無しさん mailto:sage [2024/08/26(月) 00:27:52.82 ID:JWWBXqLI0.net]
- false効かないﾊﾞｶｺﾝﾊﾟｲﾗはどうしようもないからどうにもならんか
//requires を使った方法
template<class T, class U>
requires(!(std::is_same_v<double,T>&&std::is_same_v<complex<T>,U>))
void f(T& x, const U& y)
{
x=y;
...
}
- 427 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 2963-G6Q9) mailto:sage [2024/08/27(火) 07:16:06.25 ID:NdPbjHCm0.net]
- 特定の引数型についてテンプレート展開を阻止したいんなら
特殊化してその中にstatic_assert(false, "*** ERR ***")書いても昔は駄目だったんか恐ろしい……
- 428 名前：デフォルトの名無しさん mailto:sage [2024/08/27(火) 07:35:09.57 ID:NdPbjHCm0.net]
- しかしまあ特殊化してテンプレート引数の型Tについて
態と存在しないメソッドを呼ぶように書いたらその特殊化ケースについて展開を阻止できうる（適当
クラス内でint型定数が欲しかったら古き良き enum { ONE, TWO, THREE } で十分やし
同じことをやる手段を増やせば良いってもんじゃないぞPerlじゃあるまいし……
- 429 名前：デフォルトの名無しさん [2024/08/27(火) 14:55:30.59 ID:oHcafaf7a.net]
- perlの面白仕様
- 430 名前：デフォルトの名無しさん mailto:sage [2024/08/27(火) 17:14:33.06 ID:K2iTXH930.net]
- まぁ普通にSFINAEなり=delete指定なりコンセプトなりでオーバーロード候補から外す方が利用者視点でいえば自然だな
- 431 名前：デフォルトの名無しさん [2024/08/27(火) 17:33:30.75 ID:K7dNHCWQ0.net]
- #include <iostream>
#include <complex>
template <class T> decltype(auto) f(T x)
{
decltype(abs(std::declval<T>())) w;
w=abs(x);
return w;
}
int main()
{
using namespace std;
cout<<f(-1) << endl;
cout<<f(2.f)<< endl;
complex<double> z=complex<double>(1.0,1.0);
cout<<f(z)<<endl;
cin.get();
return 0;
}
いちかばちかでやったら、通りました。abs！ Who are you？ sizeof演算子と同じくコンパイル時に評価されるんですか？ というか、地味だけど declval が凄い。
- 432 名前：はちみつ餃子 mailto:sage [2024/08/27(火) 18:27:19.33 ID:WfqXHPCU0.net]
- >>431
sizeof や decltype のオペランドは評価されないということになってる。
だからその文脈で関数を使う場合でもその関数が定義されている必要はない。 (宣言だけあればよい。)
評価されないけど実体化は起こるのでそのへんの理屈は複雑でよくわからん。
- 433 名前： mailto:sage [2024/08/30(金) 02:40:03.60 ID:qLymVnYK0.net]
- decval使ったコード始めてみたかも
- 434 名前：デフォルトの名無しさん mailto:sage [2024/08/30(金) 05:15:18.21 ID:ZIPlhev80.net]
- 相互参照わっかんねぇ
- 435 名前：デフォルトの名無しさん [2024/09/02(月) 12:36:59.33 ID:bqeYsc0k0.net]
- 相互参照は必要ない
最近はウェブプログラマのほうが賢くなった
すそ野が広がると質が良くなるらしい
- 436 名前：デフォルトの名無しさん mailto:sage [2024/09/02(月) 13:00:06.45 ID:Rco2Fp/20.net]
- 必要ない理由ぐらい言ったら？
- 437 名前：はちみつ餃子 mailto:sage [2024/09/02(月) 14:42:22.37 ID:o+5p2SR60.net]
- プログラムの文法要素が相互参照になっている状況という意味？
たとえば前方宣言が必要な場合とか。
それとも (実行時の) データ構造が相互参照ということ？
たとえば循環構造の後始末のやり方がわからんとか。
- 438 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 0701-+rOo) mailto:sage [2024/09/02(月) 19:52:42.06 ID:cn5uZ01w0.net]
- >>435
その「相互参照」って何?
- 439 名前：デフォルトの名無しさん [2024/09/05(木) 00:06:16.92 ID:/oUqYYg3a.net]
- 相互参照も自己参照も一緒
自己参照なんて参照してるのは自己ではない
ホントの意味での自己参照は循環参照
- 440 名前：デフォルトの名無しさん [2024/09/05(木) 18:17:57.29 ID:xTcyjaky0.net]
- shared_ptrを使いたくなったら設計を見直すべき
- 441 名前：デフォルトの名無しさん mailto:sage [2024/09/06(金) 07:27:10.33 ID:Qb4sTpDj0.net]
- >>440
それは無理があるんじゃないのかね。
データ共有とかインターフェイス共有とか本質的に所有者が複数存在するオブジェクトはsharedptr使うべきかと。
設計ではモジュール間の疎結合・インターフェイスの汎用化を重視すべきで、そのためにはデータの共有方法が重要になる。
- 442 名前：デフォルトの名無しさん mailto:sage [2024/09/06(金) 11:54:45.03 ID:onD85wsiM.net]
- >>440
マルチスレッドセーフ考えたら使わざるを得ない場合は多々ある
言ってる意味がわからないならお前は経験不足
- 443 名前：デフォルトの名無しさん [2024/09/06(金) 22:35:55.77 ID:0hxwMUxG0.net]
- recurcive_mutexが欲しくなったら設計を見直したい、なら分かる気もする
- 444 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 11:45:08.02 ID:Zy1zUumM0.net]
- C++11あたりから「生ポは使うな」みたいな極論で分かった気になってる思い上がった初心者が増えたからなぁ
- 445 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 11:58:09.00 ID:UFsx2JaR0.net]
- >>444
生ポ使うよりかスマートポインタの参照を使った方がマシだったりするからなぁ。スマートポインタがスタックフレームにあるなら安全だし。
スタック変数専用仮引数とかあればもっと安全になるのになぁ。
仮引数の種類はもっとあっていいと思う。
- 446 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 16:26:14.57 ID:lSV8lU690.net]
- >>445
考え方にもよるだろうけど、確保も解放も所有もしない関数でスマポ受け取る必要あるか？
特定の用途で管理されている特定のポインタしか許容しない、という意図ならスマポの参照でもいいだろうけど、汎用性は無いよね
生ポ受け取る場合暗黙のキャストも効かないし
- 447 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 20:17:38.39 ID:Ci+xhqlU0.net]
- >>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();
...
};
- 448 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 20:21:44.33 ID:Ci+xhqlU0.net]
- んまー前方宣言が必須というのは言い杉やったかもしれんorz
TreeNodeみたいなクラスはノード毎にヒープを確保するなんてことはやめて専用のアロケーターを設けて
専用の領域をまとめて確保して、
木全体がいらなくなったら木をトラバースすることなく一気に解放するのが本当やが
その場合m_pLeftやm_pRightにあたるのはポインタではなくて専用の領域（配列）のindexとかにすれば
前方宣言は不要、
- 449 名前：デフォルトの名無しさん mailto:sage [2024/09/07(土) 21:38:34.24 ID:lSV8lU690.net]
- >>442
使わざるを得ないは言い過ぎじゃね
同期取るのにshared_ptrのアトミック保証に依存するしか方法が無いの？
競技プログラマか何かか？
- 450 名前：デフォルトの名無しさん mailto:sage [2024/09/08(日) 00:33:39.65 ID:vgBqrjWA0.net]
- shared_ptrの内部的な参照カウンタとかはともかく
保持しているオブジェクト自体はアトミックでもなんでもないでしょ
ってなんか勘違いしてる?
- 451 名前：デフォルトの名無しさん mailto:sage [2024/09/08(日) 01:27:17.93 ID:6Lpw1aoe0.net]
- 持ってるポインタの指す先のオブジェクトがアトミックになるとか言ってると思ってんの？アホかw
- 452 名前：デフォルトの名無しさん mailto:sage [2024/09/08(日) 01:32:50.82 ID:TMvzCbR60.net]
- そこでRustですよ！
- 453 名前：デフォルトの名無しさん [2024/09/08(日) 12:52:42.06 ID:Lw7YNDXG0.net]
- でたｗ
布教ﾏｿw
- 454 名前：デフォルトの名無しさん mailto:sage [2024/09/10(火) 11:29:59.05 ID:v6KS9t6sM.net]
- >>447
お前の理解はshared_ptrの一面だけだな
ようするにunique_ptrの延長でしか見てない
shared_ptrがどうしても欲しくなるのは
オブジェクトのリリースタイミングが非決定的であるとき
これは一般的にマルチスレッド環境
お前のTreeNodeの例はそれこそ生ポで実装しても対して苦労しないが
例えば動的可変multi producerなqueueの場合確実に安全なqueueの解放タイミングを知るにはリファレンスカウントのような制御が必要となる
当然この場合コピーすれば安全なんて寝ぼけたことにはならない
- 455 名前：デフォルトの名無しさん [2024/09/10(火) 13:20:49.36 ID:KGjTz1X0a.net]
- x 対して
- 456 名前：デフォルトの名無しさん mailto:sage [2024/09/10(火) 15:36:50.97 ID:+l9ylb2n0.net]
- それで自己参照ってのは結局何のことを指して言っていたんだい
- 457 名前：デフォルトの名無しさん mailto:sage [2024/09/10(火) 15:39:03.70 ID:+l9ylb2n0.net]
- あ、相互参照が先か
>>435>>436の言うところの
- 458 名前：デフォルトの名無しさん [2024/09/11(水) 12:14:54.12 ID:n6/LwjNL0.net]
- (*this)
↑
自己参照
- 459 名前：デフォルトの名無しさん [2024/09/11(水) 12:19:01.05 ID:n6/LwjNL0.net]
- 木のノードはstd::vector<>で確保する
と言われて、だよねってなる人はnewもほとんど必要ない
- 460 名前：デフォルトの名無しさん [2024/09/11(水) 12:22:29.60 ID:n6/LwjNL0.net]
- 木の巡回は、巡回方向別にアダプタとしてイテレータを用意することが出来る
良くある行きがかり順のイテレータはスタックを使って作る
- 461 名前：デフォルトの名無しさん mailto:sage [2024/09/11(水) 15:12:04.16 ID:1n/VD1trM.net]
- でvectorの拡張で破綻すんだろ？
- 462 名前：デフォルトの名無しさん [2024/09/13(金) 16:29:50.66 ID:bblj+c3pa.net]
- move禁止
- 463 名前：デフォルトの名無しさん mailto:sage [2024/09/13(金) 19:59:43.80 ID:2C9M8qgO0.net]
- move禁止したらvector使えないし
- 464 名前：デフォルトの名無しさん mailto:sage [2024/09/17(火) 12:59:42.12 ID:TMGdiCOOa.net]
- それならオブジェクトを保持するためのオブジェクトと
moveためだけのインデックスを分けるかな
- 465 名前：デフォルトの名無しさん mailto:sage [2024/09/17(火) 16:24:30.60 ID:DN+X/Cyr0.net]
- 何がしたい
あほでしょ
- 466 名前：447 mailto:sage [2024/09/21(土) 20:05:42.93 ID:FUSKAHoo0.net]
- 何やら集中砲火を浴びている>>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する（←これは排他が要る
- 467 名前：447 mailto:sage [2024/09/21(土) 20:13:25.63 ID:FUSKAHoo0.net]
- ていうか2週間ぐらい前から作っていたやつが今さっき完動すた、
- 468 名前：デフォルトの名無しさん mailto:sage [2024/09/21(土) 20:35:47.52 ID:FUSKAHoo0.net]
- std::vector<TreeNode> nodes;
ならnodesを拡張したとき破綻するかもしれんが（nodeをnodesのindexで管理するならその限りではない
std::vector<std::shared_ptr<TreeNode> > apNodes;
ならapNodesを拡張しても破綻しないYO!（要素の実アドレスは保たれる
- 469 名前：デフォルトの名無しさん mailto:sage [2024/09/22(日) 08:21:05.99 ID:e5FZYjui0.net]
- それ何のためのshared_ptrなの？unique_ptrでいいというか横からコピーされないようにそうすべきでは
- 470 名前：デフォルトの名無しさん mailto:sage [2024/09/25(水) 13:57:54.93 ID:N5yN4IuU0.net]
- >>466
>>442 を書いたのおれだけど、なんでおれが集中砲火浴びてることになってんだよ
生ポとか意味不明なこといってる>>447は一見してわかるクソレスだろ
おまえはそれ以上のクソレスにクソコード
でもお前の勝ちだ
クソコードに2週間かけた情熱に免じて親切におしえてやるわ
shared_ptrはpに誰かがアクセスしている可能性がある間は決してdeleteされないことを保証できるのが肝
(pの先の排他ではこれは実現できない)
もちろんこれも正しく使わないと保証できない
よくあるミスは知ったかぶって参照カウントを操作しないようにshared_ptrを参照渡しとかにするやつな
その間に絶対deleteされない保証がないならやってはいけない
- 471 名前：デフォルトの名無しさん mailto:sage [2024/09/26(木) 03:21:09.01 ID:5BtHXQaO0.net]
- あーなるほど、一貫してshared_ptrの実体を渡してればそういう保証も出来るのか
自分の場合自前で排他処理や生存保証作ってたけど確かに大きなメリットだね
(オブジェクト内部の排他は別に必要だとしても)
- 472 名前：デフォルトの名無しさん [2024/09/26(木) 10:52:52.31 ID:R5lWYvWFa.net]
- そんなあなたにRust
- 473 名前：デフォルトの名無しさん mailto:sage [2024/09/26(木) 11:26:35.22 ID:r0pzUHiv0.net]
- >>472
c++コードと混在できるようになってからの話だな。
既存c++を捨てなきゃならんのなら要らん。
- 474 名前：デフォルトの名無しさん [2024/09/26(木) 11:37:49.48 ID:R5lWYvWFa.net]
- もちろんRustをやるにはC++を捨てる覚悟が必要
C++コード(特にテンプレやclass)とは相性最悪
- 475 名前：デフォルトの名無しさん [2024/09/26(木) 11:38:22.04 ID:R5lWYvWFa.net]
- >c++コードと混在できるようになって
Rustについて言うなら
おそらくそんな未来は永久に来ない
- 476 名前：デフォルトの名無しさん [2024/09/26(木) 11:39:08.38 ID:R5lWYvWFa.net]
- 誤解の無いように言っておくと
(一部機能に限れば今でも混在出来るけど)
基本的にはC++とは相いれない
- 477 名前：デフォルトの名無しさん mailto:sage [2024/09/26(木) 18:22:32.63 ID:sl+cfKHN0.net]
- ならc++にRustの機能が取り込まれるのを待つ。
Rustが大人気になったら、さすがに標準委員の連中も初心者・コーダー向けの"Safe c++"をやる気になるだろ。
- 478 名前：はちみつ餃子 mailto:sage [2024/09/26(木) 18:52:53.17 ID:B+Au+yIB0.net]
- >>477
もう Rust を使えばよくない……？
- 479 名前：デフォルトの名無しさん mailto:sage [2024/09/26(木) 19:43:24.82 ID:sl+cfKHN0.net]
- >>478
>>473だっつうの。
Kotlinみたいなのが欲しいのであって、Clojureみたいなのは要らん。
- 480 名前：はちみつ餃子 mailto:sage [2024/09/26(木) 20:25:47.69 ID:B+Au+yIB0.net]
- >>165
C++ のコードを Rust から呼び出したりするくらいのことは簡単に出来るよ。
たぶん (Java に対する) Kotlin みたいなこととして思い浮かべているようなことは出来る。
Rust がやってるような安全性の保障を自動では受けられない。
当然だが安全ではない (安全性が検証されていない) C++ のコードが Rust から呼び出すことで安全になったりはしない。
大抵の場合に Rust の都合に合わせてラッパーを書くことになる。
- 481 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 10:23:27.00 ID:n6BA5joS0.net]
- >>480
KotlinとJavaみたいにソースコードを混在できるレベルの相互運用性てあったっけ？
Rustとc++では無理だと思うけど。
- 482 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 10:44:00.51 ID:02Aq/BhWM.net]
- cxxとかあるけど個人的には中途半端だから使わない
普通に共有ライブラリにして呼び出す方が素直で汎用的で良い
- 483 名前：デフォルトの名無しさん [2024/09/27(金) 12:33:43.81 ID:6/1p1gGO0.net]
- スマートポインターを使うように強制できる機能とかなら必要ないなあ
- 484 名前：デフォルトの名無しさん [2024/09/27(金) 16:51:52.33 ID:pgg/4VuRa.net]
- >>473 のような未来は永遠に来ない
- 485 名前：デフォルトの名無しさん [2024/09/27(金) 16:54:13.57 ID:pgg/4VuRa.net]
- >>482
結局Cが正解なんよ
C++のスレで言うのもなんだけど
- 486 名前：デフォルトの名無しさん [2024/09/27(金) 16:54:31.95 ID:pgg/4VuRa.net]
- >>481
同意
- 487 名前：デフォルトの名無しさん [2024/09/27(金) 16:54:58.40 ID:pgg/4VuRa.net]
- >>480
嘘つくな
出鱈目言うな
- 488 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 17:14:28.28 ID:n6BA5joS0.net]
- >>483
コーダー向けので考えるなら、スマポ強制は最優先だろ。
生ポインタを(コーダーが)保存できなくするだけでも随分安全になる。あと生ポインタdelete禁止とか。
- 489 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 728c-rNKn) mailto:sage [2024/09/27(金) 18:24:18.27 ID:dg7IL8lg0.net]
- 極限のパフォーマンスは別に要らないから安全にしたいという要件なら GC が既に解決しているし
今更生ポインタを禁止したところで C# や Java と同じ方向性のナニカにしかならんじゃろ
- 490 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 18:46:28.46 ID:EoeiRCVP0.net]
- gcがあったらメモリリークしないなんて幻想未だに信じてるとはね
- 491 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 18:59:34.32 ID:RwmUzOsi0.net]
- リークの話なの？
- 492 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 19:07:06.62 ID:n6BA5joS0.net]
- >>489
ライブラリとかフレームワークを使う側のコーダーと作る側のライブラリアンは性能要件が全然別。
コーダーに対してライブラリアンが「コーダーのコードに極限のパフォーマンスは別に要らないから安全に「させたい」」というのはあるだろ。
- 493 名前：デフォルトの名無しさん mailto:sage [2024/09/27(金) 23:12:04.55 ID:cfj6fT7K0.net]
- >>492
それならライブラリ側でメモリ周りを隠蔽するような作り方も出来ると思うけど
ユーザー(コーダー)にはインスタンス使わせるけど内部では参照カウントなりスマポなり使ってるみたいな
それですら問題が起きるようならユーザーがクソ
- 494 名前：デフォルトの名無しさん mailto:sage [2024/09/28(土) 10:42:06.28 ID:swed/tX60.net]
- C++はどんな安全策敷いてもユーザー側がその気になればいくらでもぶち壊せるからね
ライブラリがあんまりそこ頑張っても仕方ない
- 495 名前：デフォルトの名無しさん (ｱｳｱｳｴｰ Saaa-rNKn) [2024/09/28(土) 12:39:39.83 ID:gf2/NL3ha.net]
- Rustなら壊れないみたいな言い草だな
- 496 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 77ba-vp5J) [2024/09/28(土) 13:06:22.71 ID:ZP4SxDa50.net]
- C++で書かれたChrome V8エンジンをRustから扱えるRusty V8というライブラリがリリースされたというニュースを見た
メモリ安全性を確保して呼び出しオーバーヘッドもゼロなんだって
ほんとかな？
ただのラッパーじゃないの？
C++側でメモリアクセス違反があれば落ちそうだけど
- 497 名前：デフォルトの名無しさん mailto:sage [2024/09/28(土) 14:26:57.72 ID:yW35cSECM.net]
- その手の話はMICROSOFTの新機能ぐらいい思っておけば
腹も立たない
- 498 名前：はちみつ餃子 mailto:sage [2024/09/30(月) 22:26:30.09 ID:JxqgGnHQ0.net]
- >>496
Rust の標準ライブラリだって内部は unsafe だらけだぞ。
unsafe は Rust のメモリ安全性検査の例外とする指定で、検査はされないが安全であることはプログラマが保証しないといけない。
ただ、 unsafe な部分を慎重に押し込めて (押し込めるのが正しく出来ていれば) あとは Rust のメモリ安全性検査に頼ることが出来る。
ずっと気を付けなきゃならない C++ よりは面倒ごとを基盤に押し込めたら後は機械が検査してくれるほうがマシという程度の話。
押し込めた中に問題があればそりゃ当然駄目だよ。
- 499 名前：デフォルトの名無しさん mailto:sage [2024/10/01(火) 02:05:59.60 ID:J7GPtKrz0.net]
- V8エンジンてCVE脆弱性で毎月アップデートの口実にされる迷惑なやつだからさっさとRustで書き直せよ
- 500 名前：デフォルトの名無しさん [2024/10/01(火) 15:19:57.32 ID:KXGxeTHwM.net]
- >>498
>押し込めた中に問題があればそりゃ当然駄目だよ。
当然分かっているだろうが、unsafeの中だけでなく、
それが外側に及ぼす影響にも問題が生じないように作らなければなら
ないが、それにはunsafeとRustの両方に対する深い理解が
必要となるだろうな。
|
 |
