C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
Javaは心が洗われるような美しい言語だったのに、豆とか言い出したあたりから汚れてしまった。 もはや何も感じない。 https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inhtml 今ここやってんの。 色々検索してたら、std::sortにconstexprが付くというのを見つけて。 なんだこれ! なんだこれ! なんだこれ! となった。 でもまだついてないから使えない。 翻訳時に解決できることを、実行環境に持ち越さないために コンパイラ方式であることが20年かかってもわからんやつが constexprという止めまで刺されてまだ暴れてるな 20年前のitaniumみたいな失敗を繰り返そうとしてるバカ。 >>136 うん、だから実例よろしく 所詮、TMPでやってたことを実行時コンパイル時普通の関数の形で書けるなら便利ってだけの話だよね constexprの利点がそれ以上であるというなら実例出せ 発想を逆にしてみたらどうだろ。 100万件のデータをソートしたらコンパイル時間が増えるみたいな方向性じゃなくて。 100万件のデータにマッチさせる側の数十件の情報をコンパイル時にソートするとしたら? ぐもももも!ってなる。 ちなみに100万件の文字列をソートするのは数百ミリ秒。 そんなに怖がるほどでもない。 >>140 コンパイラ方式という壮大な実例を出しているんだが 20年かかってもわからんやつには無理のようだな >>141 普通そういうのはファイルから読むだろうしなぁ・・ (そういう意味では>>110 に同意するけど 21世紀最大の発明と言われる右辺値参照についてもコメントお願いします。 ノーベル賞はいつ決まるんでしょうか。 まあPL/1は35年前からプリプロセッサでサブルーチンも定義できてたから今更コンパイル時にソートできてもたいした驚きはないわ 西洋人の決定論が反映されている 「未来は決まって無い」という考え方はダイナミックであり動的と呼ばれる 「未来は全て決まっている」というのが彼らの古典的な思考方法 未来において起こることの全ては、あらかじめ既に決まっている というか、神が決めた そういう宗教的思想あるいは神学が反映されている >>147 ドラゴンブックを一通り実装したかどうかで変わるだけでは。 >>150 不要にはならない。 より効果的に使えるようになる。 >>147 自分が書いたコードの中までコペンハーゲン解釈なんだろ 量子コンピュータでもないTTL〜CMOSの回路で >>153 ET (Expression Template) >>152 デジタル回路は決定論的かもしれんがI/Oを通して外界と繋がっている件 デマングルのことで質問があります。Ubuntu上でwebkitgtkというライブラリを見てるんですが、ライブラリ内に 以下のような2つのシンボル _ZN3WTF6StringC1EPKDsj _ZN3WTF6StringC2EPKDsj があるんですが、これらはデマングル後 WTF::String::String(char16_t const*, unsigned int) WTF::String::String(char16_t const*, unsigned int) となって区別がつかない(少なくとも自分には)んですが、これはどういうことでしょう。C1とC2という部分の違いは... ちなみに元のコード上では同じ型のコンストラクタがダブってたりはしていません(と思います)。し、ダブってたら コンパイル時にエラーになりますよね? リンカー的にはデマングル前のシンボルで扱うんでしょうから両者とも必要なんでしょうねやはり unique_ptrについて質問です。 std::unique_ptr<T> uptr(new T); に対して、uptr.get() と *reinterpret_cast<T**>(&uptr) は常に一致するでしょうか。 用途としては生ポインタの配列を受けとる関数にstd::vector<std::unique_ptr<T>>を渡したいです。 例: void display_ptr(size_t n, int** pp){ for(size_t i=0; i<n; ++i){ std::cout << pp[i] << '\n'; } } int main(){ std::vector<std::unique_ptr<int>> vec; for(size_t i=0; i<3; ++i){ vec.emplace_back(new int); } display_ptr(vec.size(), reinterpret_cast<int**>(&vec[0])); return 0; } UChar * と char16_t * の方だから 84-86 行目の方だったスマソ >>160 おっとすみません、単なるその説明の訳かもしれませんが、
内部的には (1)基底クラスを直接使う時のコンストラクタ (2)基底クラスから継承したクラスを 使う時に基底クラスを初期化するコンストラクタ と二つある、 けどデマングルした名前では両者の区別はつかなくなる(だけ)、みたいな感じでいいんですかね? >>159 >>161 うーんと意味がよくわからないです。あと、特定のコードには寄らない話っぽいですね。 2次元のレイキャスティングを作成しようとしてます。 ttps://github.com/OneLoneCoder/olcPixelGameEngine/blob/master/Videos/OneLoneCoder_PGE_ShadowCasting2D.cpp にあるコードを現在javaで書いており、 ttps://youtu.be/fc3nnG2CG8U?t=1519 のように縦に長く1本線が出来てほしいのですが、 縦やにブロックを並べた時に、なぜか1ブロックごとに線が出来てしまいます。 どうすれば動画みたいに、縦に長い1本線が出来ますでしょうか? コードは ttps://ideone.com/spxzNE に載せてみました。 無駄に長い一本糞を作りたいのなら修行を積んでください 質問ですが抽象メソッドを有するクラスのデストラクタは なんで勝手に仮想デストラクタにならないんでしょうか… なんか有用なイディオムでもあるんでしょうか…………… C#しばらくやった後だったのでC#のつもりでインターフェースを定義して virtual ~IFoo() { } を書き忘れた結果盛大にリークすたgrz >>168 ゼロオーバーヘッドの原則は C++ 的にはかなり強い要請なので……。 オブジェクトに常にポインタを保持しなければならないことと、 呼び出すときに仮想関数テーブルをたどるコストがあるってのは看過できなかったんだろう。 ん〜そもそも抽象と仮想はもともとの発想が違うから似て非なるもの さらにC#においてclassとinterfaceは似て非なるもの C++に厳密な意味でinterfaceを実現する機能はない そのへんはよしなによしなに ていうか~IFOOの書き忘れがリークの元凶て発想があかん 解放し忘れしたらあかん物はsafe〜とかのクラスに押し込むべき でも仮想関数を持つクラスのデストラクタをわざわざ非仮想にするメリットってなんかあるの?実際の所 shared_ptrで管理するなら仮想デストラクタである必要がない 無駄に遅くなる >>171 インターフェースという位置づけなら仮想・非仮想どちらにしろデストラクタが直に呼ばれるべきじゃないんじゃないかと思うわ ただのインターフェースだからむしろ非仮想&protectedで隠すのがいいんじゃないかと(しらんけど) ↓こんなイメージで直にデストラクタ触れるのはclass A以降 struct IFOO { protected:~IFOO(); }; class A:IFOO { public: virtual ~A(); }; class B:A{}; class C:A{}; それって要するに解放する時に、IFOOじゃなくてAだとかBだとかの インスタンスの正体を全て把握しとけってことでしょ? だったらそもそもIFOOって必要なの?って思う >>171 俺の狭い知見ではまず無いと思うよ ただvirtual付けてないのに勝手に仮想になると言うのもいかがなものかと思う 途中で書き込んでしまった なので、やるとしても警告を出すぐらいだな って思ってたらVisual Studio 2017だと既に警告出るわ(「警告をすべて有効にする」にしないとダメだけど) warning C4265: 'C': クラスは仮想関数を含んでいますが、デストラクタはこのクラスの仮想インスタンスではなく、正しく消滅されない可能性があります >>174 まあ不要かもしらんけどねぇ でもC#でも仮想デストラクタを入れてるインターフェースてなくね? リソース開放を請け負うIDisposableにしても派生クラスのデストラクタから呼び出す形 呼び出さなきゃ勝手に呼ばれるわけでもない むしろ仮想デストラクタは便利だから使う程度の利点しかなくてインターフェースとしては不要なんじゃないかと言う気がする 夢の話じゃなくてリソース解放戦略が全然違うんだから比べても仕方ないだろ というかそもそもC#は全部のメソッドがC++で言うところのvirtualなんだから比べようもない 学術の巨大掲示板群 - アルファ・ラボ ttp://x0000.net 数学 物理学 化学 生物学 天文学 地理地学 IT 電子 工学 言語学 国語 方言 など PS スカイプ友達の掲示板 ttp://skype.x0000.net class IFoo { virtual int sum(int a, int b) const = 0; }; これの書き方でリーク原因だったという話、 public: を忘れたgrz、 で、 class IFoo { public: virtual ~IFoo() { } virtual int sum(int a, int b) const = 0; }; としたら治まった、 >>172 std::shared_ptr<(IFooの派生クラス)> pObj(new (IFooの派生クラス)()) ならそもそもsumの方こそ仮想関数でなくても良い std::shared_ptr<IFoo> pObj(new (IFooの派生クラス()) ならデストラクタが仮想でないとマズー 仮想関数有りかつ非仮想デストラクタ、を許すC++のこの仕様の理由をゼロオーバーヘッドの原則で説明くのであれば 仮想関数有りかつ非仮想デストラクタ、を許すことで得られる性能上のメリットが指摘されねばならない てかそれ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> とか観るとげんなりする なんで動的にアクセスできないんだ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる