C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
てかそれshared_ptrの作り方が悪いだけじゃん
普通make_sharedで作る。
weakを使う場合でオブジェクト自身が巨大なためメモリは即座に解放したいときでも一度newした型のshared_ptr作れと 大体純粋仮想しか持たないクラスって要はinterfaceでしょ
そのポインタで派生オブジェクトのインスタンスのリソース管理するってのとは全く別の概念じゃないか >>186
あー何となくわかったわ
shared_ptrの使い方分かってないのね
一度派生型のshared_ptrで作ったら、それをbaseのshared_ptrに代入して保持していても、デストラクタは元の型で呼ばれるよ
ってかそういう風に使うもの
newと入れるshared_ptrの型を変えるのはダメな使い方 って思ったけどよく考えたらいきなりbaseのshared_ptrに入れても大丈夫だったはず (はてさて…よくわかっていないのはどちらなのやろうか… >>193
いや、上でも下でも不味くない
きちんと派生クラスのデストラクタが呼ばれるよ >一度派生型のshared_ptrで作ったら、それをbaseのshared_ptrに代入して保持していても、デストラクタは元の型で呼ばれるよ
えっそうなん?って試してみたらマジだった。
https://ideone.com/ZRde8G
https://cpprefjp.github.io/reference/memory/shared_ptr.html
> 通常、void*に型変換して代入されたポインタは、delete演算子を呼んだとしても元の型のデストラクタは呼び出されない。しかしshared_ptrの場合は、代入されたポインタの型が持つデストラクタが正しく実行されることが保証される。
知らんかった。 万能じゃないけどな
作る時に本来の型を教えないといけない
shared_ptr<Base> s(new Derived()) // OK
Base* b = new Derived();
shared_ptr<Base> s(b); // NG > 作る時に本来の型を教えないといけない
なるほど。
ttps://ideone.com/BUt4xc
教えてくれてありがとうな。勉強になる。 横レスですみませんがそもそもポインタなんてCの配列かscanfくらいでしか使ったことないんですがスマポとかってどんな事(時)に使うんですか? スマートポインタどころか、new deleteさえ使わなくなったな。 結局、計算資源はそのスコープで管理するってのが主流になりつつある。 C++は昔からそうだったと思うが
まぁCだと関数が確保して呼び出し元でどうこうするのも多かったけど std::make_shared<hoge>(); 知らんの? >>207
mainでsort呼び出すところで、boolの後にret=みたいなのが無いせいで変に解釈されている >>200
CreateWindowExのlParam経由でオブジェクトのポインタを渡して受けて側でunique_ptrに格納して管理したりしてるよ >>204
スコープを飛び越えて永続的にデータを保持するために使うのが Heap なんだが。 >>211
だからあんまり使わんようにって感じなってるだろ。
使うとしてもスマポであるスコープ外れたら回収するように作るとか、
そういう方向をどの言語も推奨してる。 >>212
> そういう方向をどの言語も推奨してる。
具体的にどの言語のことを言ってるんだ? python,go,rustあたり見てもスコープ抜けた時に後処理する機構をサポートしとる。 お前はスコープで管理するのが主流っていったわけだけど
gcのないc++ではスコープで管理できるものはスコープで管理するのは
大昔から当たり前ではないでしょうか
何がいいたいのやらわからん C++はおじょーずでも日本語アレな奴多いよね
職場でちゃんとコミュニケーションとれてるか?www そんなん昔からじゃん
それこそcどころかアセンブラの頃から コンピュータとコミュニケーション取る方が大事だから >>216
スコープ抜けた時の後処理ってなんだ?
まさかと思うがGCの話じゃないよな? プログラミングスタイルが変わってきてるんだよね。
アジャイルとOOPは相性が悪いのかもしれない。 sort(
vecVisibilityPolygonPoints.begin(),
vecVisibilityPolygonPoints.end(),
[&](const tuple<float, float, float> &t1, const tuple<float, float, float> &t2)
{
return get<0>(t1) < get<0>(t2);
});
はt1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか?
[&]の意味はよく分からなくて教えて頂けると幸いです。 そうですね。
&に何の意味があるのか僕にもわかりません。 >>223
>t1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか?
その通りです。get<0>(t)でタプルの最初の要素を取り出して大小比較してます。
ちなみにget<0>を使わずに直接 t1 < t2 と比較すればタプルの左の要素から順に辞書順でsortされます。リンク先の(3)参照。
https://ja.cppreference.com/w/cpp/utility/tuple/operator_cmp
[&]はラムダ式の中で使われる外部の変数を参照で持ってくるものです。リンク先のラムダキャプチャを参照。
ただ上の例ではそもそも外部の変数を使っていないので[&]ではなく単に[]で問題ないです。
https://ja.cppreference.com/w/cpp/language/lambda >>217
当たり前はそうなんだが言語機能や標準ライブラリでそういうのを守りやすくしようぜって
流れは感じるけどね。 >>226
お前さんがそこで流れと言っているものは別に最近できた流れでもなく、昔からあったし随時拡充されてきているものだぞ。 僕も流れを感じますね。
このフォースを感じ取れないものもいるんですね。
少し驚きました。 get<0> とか get<1> とか観るとげんなりする
なんで動的にアクセスできないんだ そりゃ0番目と1番目の型が違うかもしれないからだよ >>230
タプルはそれぞれの要素の型が違う可能性があるから仕方がないし、
array とかなら get を使わない選択肢があるんだから問題なくね? 格納する値の型を知っているのに相称型でしかアクセスできないのは不便ではないかというご提案として、受け付けました。
進捗状況は、ご提案番号1として随時ご確認できます。
格納する値が実行時にしか確定しない以上、コンパイラが値の型にアクセスすることも出来ないんだよな。
std::variantのoperator==は荒業でアクセスしてるよね。 あらかじめインデックス渡した関数テンプレートを実体化して
boost::anyみたいなものを返すという力技でどうにか出来なくもないだろうけど
上の方で何でもコンパイル時にやるのが良い事みたいに思ってるアホがいたけど
この辺の問題全く分かってないんだろうなぁ
(tupleを否定してるわけじゃないので変な噛み付き方しないように 学術巨大掲示板群: アルファ・ラボ
ttp://x0000.net
物理学 化学 数学 生物学 天文学 地理地学
IT 電子 工学 国語 方言 言語学 など int要素が1個だけならget<int>でアクセスできなかったっけ 出来る限りコンパイル時に解決したほうが良いと思います。 constexpr ifで実行時の条件分岐数を減らす。
これがいま話題の都会的プログラミング。 >>230
楽してコストを減らす工夫だよ
見た目がイヤなら横着しないで
ちゃんと意味がわかる名前を付けなさい template < typename > union vector3 {
struct {
T x;
T y;
T z;
};
T[3];
T&operator[](int n);
const T& operator [](int n) const;
}; >>238
規模の小さな小さなプログラムでしか効果が無いようなことが都会的かあ >>242
何も知らない田舎者が漠然と憧れてイメージする都会ってことだろう 都会が優れていると思っている人を見ると、馬鹿なのかな、と思ってしまう。 タプルの分解は構造化束縛でだいぶ楽になったけど使わない変数を読み棄てる機能も欲しい
int main(){
const std::tuple<std::string_view, int> person("nanashi", 35);
const auto [name, age] = person;
std::cout << "name:" << name << ", age:" << age << std::endl;
return 0;
} タプルなんて小規模のちょこっとしたプロトタイプコードのときは
楽だなんておもうけど、きちっとした巨大なコードに仕立て上げていく経過で
結局ふつうにちゃんと構造体なりを定義してそれ返すようにしないと後々
混乱しかないのが見えて結局こんなのイラネーな、ってなる 都会つってもアーバンライフが理想だったりするんだよね
最先端とは言わなくても整った街並み統一された景観
中心部は新旧入り混じったごみ溜めみたいなもん
流行に飛びついてつまみ食いするだけのが最悪 タプルは雑多な多値を返したいときが本来の目的
メタプログラミングでも活躍するけど 使い方のわからない初心者が要らないというが、必要ないなら標準に入るわけがない。 >>225
ありがとうございます。
リンクと丁寧な説明、大変助かりました。 タプルはどっちかというと無名クラスそのものな印象
なので>>249に1票を入れたい
さらに言うとC++ではラムダ式の引数にもポインタを渡せるし、
[&]で呼び出し元変数の書き換えもできるしで
ラムダ式との絡みでもタプルという機構はそこはかとなく重畳な印象
、 ゼロコストのための手段の品揃えが良いのはいかにもC++だが
JavascriptやPythonに似せる方向性の努力はC++的では無い
キモス なんじゃそりゃC++はプログラミング言語界のPerlでも目指しとるんか、 というのは半分は冗談で、
スレッド安全のために関数からはオブジェクトのコピーを返したいのだが
オブジェクトのクラスをいちいち定義したくない、と言う場合には多少便利 時代はjavascriptとPythonだからねー
キミたちより意識高いし「デキる」人多いよ ランタイム速度落とさずに高級なことできるならなんでもやるがc++だろ >>261
最近多いんだよねー
JavaScriptやPythonとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子
最初の入り口が動的型付け言語なんだよね最近の子って
そんなもんじゃ使いものにならねっての いつの時代にもいるもんだよ
CでPascalっぽいコード書くような手合いは でも、constexprの使い道もわからないようじゃC++の意味ないのでは。
豚に真珠。 CひいてはC++の需要が無駄に高まってきてるのは、一つは競技プログラミングのため、もう一つはpythonのためだ >>267
>constexprの使い道もわからない
誰と戦ってるんだ 学術の巨大掲示板群 - アルファ・ラボ
ttp://x0000.net
数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など RTTIをプログラムの一部で使用した場合
使用していない部分でもRTTIを有効にしたデメリット(実行速度など)の影響を受けますか? RTTIって何だっけ要るときになったら確保とかいうやつだっけ dynamic_castとtypeidを使う時に必要な機能 >>274
実行速度は実際に使うところにしか影響ないと思う。
バイナリサイズの面でのデメリットはRTTIを有効にしてコンパイルしてたら使わなくても発生すると思う。 C++の設計思想としては
Cで同じコードを書けば同じ速度、リソースで実行出来るのを目指している
で基本的には思想通りに仕上がってる 関数形式のキャストってあるじゃん
int(a)みたいの
これのlong long版ってあるの?
スペースを含んでいるのだが(笑) >>282
実は、コンパイラからすれば、それは、旧来のC形式の
(型名)値
の形式のキャストとみなされている。 >>283
(TYPE)x // 原初的なCから存在していた旧来のキャスト形式
TYPE(x) // C++ で追加された関数形式のキャスト >>281
typedef long long long_long_type;
using alias_ll = long long;
てな感じに別名をつけたらどうだろ。 ■ このスレッドは過去ログ倉庫に格納されています