C++相談室 part148

1 名前：デフォルトの名無しさん mailto:sage [2020/01/31(金) 20:54:06.26 ID:Nt0XFA2s.net] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part147 https://mevius.5ch.net/test/read.cgi/tech/1576659413/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.105【環境依存OK】 mevius.5ch.net/test/read.cgi/tech/1556142878/ ■長いソースを貼るときはここへ。■ 　codepad.org/ 　https://ideone.com/ [C++ FAQ] https://isocpp.org/wiki/faq/ www.bohyoh.com/CandCPP/FAQ/ (日本語) 813 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 00:26:27.60 ID:YbJF2Pjt.net] テスト機能が標準で用意されてるのはいい 814 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/13(Thu) 00:45:52 ID:XX4mj9DD.net] 個人的には Rust は好感触。 型システムは ML 系言語で実績があるものを基礎にしてることもあって、C++ のグダグダな歴史を背負ったものよりはまとも。 ML 系はやっぱり高級路線の言語だし、インデントでブロックを表す系統なのがしんどいけど、 Rust は上手く低レイヤ用 (としても使えるよう) に着地させてるし、 C 風の外観を踏襲してもいる。 C++ が Rust から取り入れられるものはそんなに多くないと思う。 C++ は良くも悪くも互換性についてかなり強い要求があるので、 Rust 的な、カッチリと保護された仕組みを後付けするのはどう考えても無理。 C++ が Rust を参考にすることは間違いなくあるとは思うが、 全体の思想がまるで違うので限定的な範囲でしか取り入れられない。 もし取り入れらたらそれは C++ の新機能として新しく学ぶので十分でしょ。 Rust を学ぶのは間違いなく有用ではあるけども、 Rust の知見が C++ に取り入れられる可能性がありそうだからという理由ならそんなに意味ない。 815 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 01:02:46 ID:b1nbpqgi.net] C++の配列は長さの情報を持ってないってことになってるけど 長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？ なんでその情報をプログラマが利用できないようになってるの？ 816 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 01:06:29 ID:qzSQSiwu.net] rustがかっちり保護してくれるとか低レイヤー向けとか馬鹿ほど信じてるよね。 ありゃ帯に短し襷に長しの典型言語だわ。 817 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 01:44:34.08 ID:X++L6urQ.net] >>792 実際、Rustは、Cを簡単にするのではなく、Cを難しくしてしまっていて、Cのポインタが理解できない or 難しく感じる人には、Rustの特徴の核心たる所有権、借用などの部分はちんぷんかんぷんだと思う。 818 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 01:48:50.73 ID:X++L6urQ.net] >>793 Cの問題点を取り除いたと言うより、ほとんど全てのプログラミング言語が暗黙のうちに用いている代入の概念をなるべく使わないようにして変数束縛などの全く異なる独自概念を用いようとしている。 しかし、これは、手続き型言語と関数言語の違いに匹敵するくらいのプログラミングの概念の変更になってしまうため、手続き型言語の中で改良された次世代言語と言うものではなくなってしまっているとも言える。 819 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 05:24:36 ID:AWnkBPoe.net] 変数束縛って右辺値参照でしょ 820 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 06:24:47.58 ID:fMXzK7Sc.net] RustはC++なら簡単にできることをものすごく回りくどく書かないとコンパイル通らない感じだからとてもつらい 821 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 09:13:38.23 ID:6FSFTWhE.net] >>790 RustがC++に取って代わることがあるか、というニュアンスの質問でした 今C++でやってる仕事がRustに置き換わる可能性が高いなら今から勉強しとこうか、と 822 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 12:35:22.33 ID:z5cRWLgY.net] >>797 断言してもいいが、RustはC++に取って代わることは無い。 なぜなら、普通の手続き型言語での枠組みにすら入ってない書き方を強要されるから。 手短に言えば、単にC/C++と書き方が大幅に違っているだけではなく、書き方が他のどんな減の範疇にも属していない。 823 名前：はちみつ餃子 mailto:sage [2020/02/13(木) 13:30:24.18 ID:XX4mj9DD.net] >>796 C/C++ でのオブジェクトの寿命の管理の難しさってのは 理屈が理解しづらいというよりはわかってても間違うという難しさなんだよね。 そして間違っていてもコンパイラは黙って通すことも多い。 C/C++ を長く使っていればそれを感じることって結構あるでしょ。 そういう部分のプログラムが正しいことはプログラマが保証しなくてはならんわけだ。 でも Rust では言語処理系の側でやってくれる。 C/C++ で面倒な部分を Rust では自動でやってくれる。 まわりくどいのは確かだけど、それで楽できるのも確かなので、 どっちを取るかって話だな。 オブジェクトをどこで後始末するか。 管理の主導権はどのモジュールに持たせるか。 そういうのって C/C++ でも考えてるよね。 C/C++ ではプログラムに書いてないだけで本来はあるはずのものなんだよ。 (C++ だとスマートポインタの導入で少し楽にはなったけど。) 自分が何を考えていたのか、そして何を考えられていなかったのが 明らかになるのはそれはそれで楽しいと思う。 まあ、それは俺が趣味でやってるからかもしれんな。 824 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 13:34:58.25 ID:3lSBa444.net] おまえの設計がヘタクソなだけだろ 825 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/13(Thu) 13:45:30 ID:XX4mj9DD.net] >>800 そうだよ。 そんでもって大抵の人間は設計がヘタクソだし、 ヘタなところが検出されるなら検出されないより良い。 826 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 14:01:13 ID:z5cRWLgY.net] >>799 変数束縛やら所有権や借用の概念が複雑すぎて、そっちの方が C/C++の メモリ管理よりミスし易い。 827 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/13(Thu) 14:13:53 ID:XX4mj9DD.net] >>802 間違いなくミスし易いけどミスした箇所が検出できないということはあまりない。 828 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 14:20:14 ID:3lSBa444.net] 設計がヘタクソなヤツが書いたソースのメンテやらされるのは最悪だけど自分で組み上げるならC++以外有り得ない 各々の力量が顕著に表れやすい最高の言語には違いない バカも容易に炙り出せるしな 829 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 14:20:33 ID:z5cRWLgY.net] >>803 仮にあなたはちゃんと理解できても、一般のプログラマは変数束縛やら所有権や借用の概念を理解することが難しすぎるので、C/C++を置き換える言語にはならない。 それらの概念は学習コストが高すぎるどころか、一生理解できないプログラマが多いだろう。 830 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/13(Thu) 15:53:13 ID:XX4mj9DD.net] >>805 誤解のないように補足しておくけど、俺は Rust が C++ を置き換えるという主張はしてないからね。 C++ の重大な欠点を (実行コストをあまり払わない形で) 改善しているのは確かってだけ。 そんでもってそれが必要な場面は間違いなくあるってことも。 831 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 19:21:34 ID:b1nbpqgi.net] >>791 わかる人いませんか？ 832 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 19:29:34 ID:z5cRWLgY.net] >>807 new TYPE[] のようにしてヒープから配列として確保されたメモリは確かに 要素数の情報を持っている。 しかし、new TYPEのように配列ではない場合は、高速化のために情報を 持ってない処理系もある。そのために 前者では delete[] を、後者では deleteを使うことになっており、間違った組み合わせを使った場合には 不具合を生じる。 また、ポインタは、ヒープから確保された配列ばかりをポイントしているとは 限らず、例えばスタック上のローカルオート変数や、グローバル変数をポイント していることもあり、その場合には、要素数の情報は全く持っていない。 さらに、Cの場合、関数の引数に TYPE buf[] のように配列を書いても、 TYPE *buf に自動修正される仕様となっている。 そのため、配列を受け取るのは、必ずポインタということになる。 しかし、ポインタで受け取るということは、そこには、&a のように、 ローカルオート変数も実引数として指定して呼び出すことも出来る。 その場合には要素数が無いので、あなたの望みをかなえる高速な 一般的方法が存在しない。 望みをかなえるためには、言語の拡張が必要となる。 833 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 19:33:05 ID:bRhYdbIA.net] Rustっていろいろ清々しいよね 関数型言語に必須じゃねえのと思うリスト関係がぽっかり抜けてるのは不満だけど 834 名前：デフォルトの名無しさん [2020/02/13(Thu) 19:57:05 ID:WjLTLikp.net] >>807 https://ideone.com/DfYRYS 835 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 20:01:17 ID:b1nbpqgi.net] >>808 ヒープに確保した配列の要素数はやはりメモリ上にあるんですね 手段がないのは文法として一貫性をもたせられないからということでしょうか なるほど、回答ありがとうございます 836 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 20:08:49 ID:J94ypinO.net] delete [] pと同じように sizeof [] pを用意すりゃいいのにね pがnew []されてなかったら誤動作するって挙動ならdeleteと同じだろうに 837 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 20:15:32 ID:iivZofrB.net] 言いたいことは分かるが構文がきもい 838 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 20:17:34 ID:Y6SS1xK+.net] 欲しいなら作れば？ それができるのがc++じゃん 839 名前： mailto:sage [2020/02/13(木) 20:36:41.73 ID:ImKshd8q.net] >>791 ＞C++の配列は長さの情報を持ってないってことになってるけど ＞長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？ new したときは、その領域サイズが実行時にユーザーのみえないところに保存される、というだけなのでは？ C/C++ の配列は長さ情報を（自分でそう書かないかぎり）持たないとおもいますよ 840 名前：デフォルトの名無しさん [2020/02/13(木) 20:38:39.62 ID:WjLTLikp.net] ちゃうねん。 841 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 20:50:05.52 ID:qzSQSiwu.net] 設計がダメな場合コンパイラにいくら指摘されようと根本的には治らんのだが、 （たいていそういう馬鹿はコンパイラ通すためにmut,RefCell,unsafeを使いまくる） そういうのを少しもわかってないバカがrust推しなんだよなぁ。 構造体を１から作り直さなきゃならんかったり根本的に間違ってる。 842 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 21:00:18 ID:sl9OX6cI.net] >>808 new TYPE[]するとき内部的にサイズ情報を持つ保証ってあったっけ？ 例えば自前でoperator new []を実装するとき、予め2^nバイトのブロックを所定の数用意しておいて、要求サイズに応じて必要十分な大きさのブロックを返すなら、割り当て時に要求されたバイト数または要素数の情報を保持しないという実装も可能かと思う。 843 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 21:18:32.64 ID:9NIgZq2/.net] >>811 いえいえ 844 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 21:37:18.24 ID:Y6SS1xK+.net] >>818 デストラクタ呼ぶ必要ある 845 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 21:39:24.09 ID:J94ypinO.net] デストラクタ呼ぶ必要ない型だと、size情報持ってないと言うことなんだろうね 846 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 21:40:36.17 ID:sl9OX6cI.net] >>820 デストラクタの実装も、返ってきたアドレスの値でどのサイズの領域か(割り当て要求されたサイズではなく、自分で区切ったブロックのサイズ)が分かるようにしておけば大丈夫でないかな？ 847 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 21:41:24.98 ID:sl9OX6cI.net] >>822 すまん、勘違いでした。全部忘れてください 848 名前：デフォルトの名無しさん [2020/02/13(木) 22:02:22.87 ID:WjLTLikp.net] はい忘れました。 849 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 22:06:16.93 ID:Bk3UL691.net] アドレスだけじゃなくて長さも受け渡しするインターフェースにしましょうとしか。 850 名前：デフォルトの名無しさん [2020/02/13(木) 22:36:33.13 ID:WjLTLikp.net] シリアル化の王道ってありますか？ 851 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 22:45:19.55 ID:iq5JxXln.net] オブジェクトならCORBA、データ構造だけでいいならASN.1とか。 852 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 22:54:55 ID:tx2lxPGZ.net] >>822 TYPEがデストラクタを持つclassの場合に、ptr = new TYPE[n] で確保されたメモリ を delete[] ptr とすると、 正確に n 回デストラクタを呼び出す必要がある。 new が n * sizeof(TYPE) より大きめのブロックを確保した場合でも、 delete[] ptr 時に正確な n の値を割り出す方法が必要となる。 なので、n の値は ptr の値さえあれば知ることが出来ることが必要条件となる。 つまり、少なくともデストラクタを持つ TYPE の場合に TYPE の配列をヒープから 確保した場合には、配列の要素数を必ず配列の先頭のポインタの値から「知る」事が出来る。 853 名前：デフォルトの名無しさん [2020/02/13(Thu) 23:01:33 ID:WjLTLikp.net] >>827 もうちょっと簡単なのないですかね。 型情報要らないんで。 854 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 23:09:58 ID:iq5JxXln.net] 型情報が無けりゃデシリアライズしても使いようがあるまい。 855 名前：デフォルトの名無しさん [2020/02/13(Thu) 23:12:32 ID:WjLTLikp.net] それがあるんですよ兄さん。 856 名前：デフォルトの名無しさん mailto:sage [2020/02/13(Thu) 23:12:57 ID:ktN45haN.net] 双方向mapって何使うのがいいですか？boostのbimap？ それともこのくらいは自作してる人のほうが多いですか？ 857 名前：デフォルトの名無しさん [2020/02/14(金) 00:05:24 ID:CPLKNT1n.net] 双方向Mapって何に使えるんですか？ 858 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 01:54:24 ID:0WgbwkuV.net] 型情報ないならそもそもデシリアライズできないし 型情報なしで成り立つ、つまり型情報を事前に知っている前提なら バイナリでそのまま送ればいいだろ 859 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 02:05:36 ID:raWqkpxU.net] 型がわかっててもコンテナはそのままではバイナリで送れない 860 名前：デフォルトの名無しさん [2020/02/14(金) 02:11:15 ID:CPLKNT1n.net] >>834 そのやり方教えて。 あめさんあげるから。 861 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 07:52:45.40 ID:RsXMnrpQ.net] ちゃんとやるならPODに詰め替えてからchar配列へreinterpret_cast 862 名前：はちみつ餃子 mailto:sage [2020/02/14(金) 09:19:01.22 ID:nLeEzkye.net] >>826 シリアル化ってのにどういう要件を置くかだな。 同じ環境でデシリアライズ出来ればよいのであれば >>837 で十分だろうし、 データ形式が決まってて (あるいはデータ形式の側を中心に策定したくて) それのシリアライズとデシリアライズを (それぞれ別の環境で (ときには言語も違うかも)) やりたいということなら protobuf などのツールを使うのはよい案だと思う。 863 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 13:35:07 ID:vZZ7SPTm.net] boostにあるじゃないですか googleのなんか使うんじゃありません 864 名前：デフォルトの名無しさん [2020/02/14(金) 13:41:23 ID:a5iC3cHy.net] >>791 >>807 実装� 865 名前：ﾋ存だと思うけど hoge[-1] あたりに格納されてた [] [ここ壊れてます] 866 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 13:49:57 ID:rQdJoGM9.net] >>840 VC++の場合、ptr = new TYPE[n] で確保された場合は、確かに ptr[0] == n になっていた気がする。 「確かに」というのは言葉のあやで、厳密には覚えてないが、 VC++の new で使われる組み込み関数のライブラリのソースコードを見ると分かる。 867 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 13:50:28 ID:rQdJoGM9.net] >>841 すまん、 ptr[-1] == n の間違い。 868 名前：デフォルトの名無しさん [2020/02/14(金) 14:03:39 ID:a5iC3cHy.net] >>807 >>841 OSやコンパイラで違うんでしょ https://ideone.com/DuTmC5 869 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 15:26:11.39 ID:rQdJoGM9.net] >>842 あ、すまん、正しくは、大体、 　((DWORD *)ptr)[-1] == n だ。 ptr[-1] だと、sizeof(TYPE)分、アドレスが戻ってしまうし、 結果の型も DWORD とかではなく、TYPE 型になってしまう。 870 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 15:28:19.59 ID:rQdJoGM9.net] >>843 言っておくが、new char[n] とかでは、駄目な可能性は有るよ。 話は、「TYPEがデストラクタを持つとき」のnew TYPE[n]に限定。 871 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 17:17:51.62 ID:jFoBh/u0.net] 一時オブジェクトの寿命について、ご教示ください。 例えば、以下のようなコードがあった時、 void foo(const char* c); // 外部ライブラリの関数につき変更不可とする void main() { const std::string s = "aaa"; foo((s + "bbb").c_str()); } 一時オブジェクトstring(s + "bbb")の破棄が行われるのは、 関数foo()を呼ぶ前でしょうか、呼んだ後でしょうか。 調べた範囲では、「完全式の終わり」という話が出てきたのですが、 どこまでが完全式なのか判断できませんでした。 872 名前：はちみつ餃子 mailto:sage [2020/02/14(金) 17:22:07.67 ID:nLeEzkye.net] >>846 この場合はその行の終わり。 セミコロンのところだと思っていい。 873 名前：はちみつ餃子 mailto:sage [2020/02/14(金) 17:34:07.49 ID:nLeEzkye.net] すごくどうでもいい話なんだけど、 JIS では完結式という用語を使ってるのに完全式って言葉の方がよく使われているよね……。 874 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/14(金) 17:59:01 ID:nLeEzkye.net] >>846-847 式の一部であるような式が部分式で、 そうでないような式が完結式って言う。 875 名前：デフォルトの名無しさん [2020/02/14(金) 19:29:16.13 ID:CPLKNT1n.net] >>837-838 ありがとん。 876 名前：846 mailto:sage [2020/02/14(金) 19:44:55.13 ID:jFoBh/u0.net] >>847-849 ご回答ありがとうございます。 大変勉強になりました。 877 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 20:52:54 ID:x/oqiD9H.net] おいCぺろぺろ 878 名前：デフォルトの名無しさん mailto:sage [2020/02/14(金) 20:58:59 ID:V/oEZCXU.net] >>851 いえいえ 879 名前：デフォルトの名無しさん [2020/02/15(土) 10:34:21 ID:BMoFghq4.net] newって意外と速いんだな。 アクセスは不利かもしれないけど。 880 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 12:11:39.70 ID:DzNKB5Jj.net] >>854 速いよ。 高速なゲームでも普通に使える。 881 名前：デフォルトの名無しさん [2020/02/15(土) 12:12:59.04 ID:BMoFghq4.net] でもスタックは常にキャッシュに乗ってるから、そこらへんでどう変わるのかな。 882 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 13:19:54 ID:J1bovO5o.net] キャッシュに乗るくらいの量だったらそもそもクリティカルな重さにはならんだろ。 newで問題になるのは10万とかそのくらいのオーダーをがっつりfor文で呼ぶとかそれくらいのことする場合。 883 名前：デフォルトの名無しさん [2020/02/15(土) 13:21:27 ID:BMoFghq4.net] スタックは常にキャッシュに乗ってる。 884 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 13:23:13 ID:lTU5fwx1.net] >>857 風邪が騙りかけます 885 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 14:11:39.55 ID:DzNKB5Jj.net] >>857 VC++の場合、コンストラクタが無い場合、new が必要とする時間は 170クロック。 3.0GHz の CPUの場合、1.7 * 10^7 回(1,700万回)くらい new してやっと一秒 位。 だから、問題になるのは、1万回ループではなく、100〜1000万回くらいのループ。 886 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 14:15:19.79 ID:DzNKB5Jj.net] もちろん、スタック変数で済むならスタック変数の方がい 887 名前：い。 ただ、スタックは容量に限りがあるので全部スタックという訳にもいかない。 ヒープにも限りはあるにはあるが、それは OSやマシンの限界。 [] [ここ壊れてます] 888 名前：デフォルトの名無しさん [2020/02/15(土) 14:25:57.86 ID:BMoFghq4.net] そこでgotoなんですよ。 889 名前：デフォルトの名無しさん [2020/02/15(土) 14:43:25.87 ID:BMoFghq4.net] コレクションがソートの有無でだいぶ変わる。 trie_base_benchmark__sorted_words_1 trie assign. 409ms size : 466551 words : 466551 trie insert. 762ms size : 466551 words : 466551 std::set insert. 69ms std::unordered_set insert. 149ms (assigned) trie find. 24ms (inserted) trie find. 25ms std::set find. 194ms std::unordered_set find. 63ms 890 名前：デフォルトの名無しさん [2020/02/15(土) 14:44:57.19 ID:BMoFghq4.net] trie_base_benchmark__random_words_1 trie assign. 2034ms size : 466551 words : 466551 trie insert. 2026ms size : 466551 words : 466551 std::set insert. 490ms std::unordered_set insert. 146ms (assigned) trie find. 158ms (inserted) trie find. 169ms std::set find. 477ms std::unordered_set find. 62ms 891 名前：デフォルトの名無しさん [2020/02/15(土) 14:46:37.02 ID:BMoFghq4.net] 挿入速度が変わるのは仕方ないとしても、検索速度が変わるのは、キャッシュじゃないかと思うんだけど。 892 名前：デフォルトの名無しさん [2020/02/15(土) 14:49:41.43 ID:BMoFghq4.net] std::sort: 306ms, (466551count). 先にソートしてから挿入したほうが速度的にお得っぽい。 893 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 16:03:09.29 ID:0hgUDlXi.net] >>854 速いといっても 単純な演算と比べれば劇遅 894 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 16:18:40.81 ID:qSK05WKV.net] >>867 とにかく、足し算/引き算が1クロック程度、new が170クロック程度だからね。 使い方を間違えなければ劇遅とはいえまい。 895 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 16:32:01.46 ID:4O8uAQVX.net] auto hentai = SM(std::move(羞恥心)); 896 名前：デフォルトの名無しさん [2020/02/15(土) 17:12:18.08 ID:BMoFghq4.net] newより+のほうが速いってことか。 897 名前：デフォルトの名無しさん [2020/02/15(土) 17:25:57.34 ID:BMoFghq4.net] +と-ならどっちが速いんだろう。 898 名前：はちみつ餃子 mailto:sage [2020/02/15(土) 17:49:06.00 ID:cwLPNCdO.net] >>871 回路はほぼ共有してるんじゃないの？ 2の補数を使うのもそれが理由なんだろうし。 少なくとも Pentium 時代まではクロックは同じだったはず。 近頃の事情は知らんけど GCC あたりで強い最適化をかけてみても引き算か足し算を特に避ける様子もないので、 まあだいたい同じなんでしょ。 899 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 18:01:50.38 ID:zARYy4pH.net] >>870 C++の場合、+ひとつだけでも裏でどんなコードが動くか油断ならない。 900 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 18:13:26.25 ID:2RWOAy2H.net] >>871 + と - で速度が違うCPUは見たことがない - は順番が関係あるので 処理によっては遅い事がある b = 1 + b b = 1 - b 901 名前：はちみつ餃子 mailto:sage [2020/02/15(土) 18:14:19.52 ID:cwLPNCdO.net] 整数だけの話じゃなくてってことか。 ある程度の常識的判断が出来る場合もあるけど、 基本的には実装次第だわな。 902 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 18:19:46.61 ID:2RWOAy2H.net] 組み込み型じゃなけりゃそりゃね + でミサイル発射とか 903 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 19:02:33.35 ID:qSK05WKV.net] >>870 new より + の方が 170 倍速いと言うことだ。 904 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 19:04:43.75 ID:cVttwiPD.net] >>874 一度bをnegateしてから足す処理系があるかもな 905 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 19:30:46 ID:qSK05WKV.net] >>874 確かに引き算には順序があるので、足し算より最適化に不利になることがある。 906 名前：デフォルトの名無しさん mailto:sage [2020/02/15(土) 19:48:11.00 ID:x3vECiAE.net] if(bReaZyuu){ 907 名前：デフォルトの名無しさん mailto:sage [2020/02/16(日) 00:34:55 ID:pXV6w9YM.net] if (false != bReaZyuu) { 908 名前：デフォルトの名無しさん mailto:sage [2020/02/16(日) 00:35:58 ID:pXV6w9YM.net] newが常に数百クロックで済むと思ったら 間違いかもしれん… 909 名前：デフォルトの名無しさん mailto:sage [2020/02/16(日) 01:50:35.50 ID:1DEBeg9G.net] 経験的にはnewが遅いと思ったことは無い。 なお、コンストラクタの処理時間以外はnewはmallocと同じ速度。 ゲームメーカーでも必要な場合に malloc を使うことは問題� 910 名前：ﾈいとされている。 [] [ここ壊れてます] 911 名前：デフォルトの名無しさん mailto:sage [2020/02/16(日) 02:03:13.40 ID:MPWqg8uW.net] new からしてmallocを呼んでる実装が多い気がする。 912 名前：デフォルトの名無しさん mailto:sage [2020/02/16(日) 02:34:52 ID:yR2k1LO6.net] そりゃnew用とmalloc用でヒープ別けたら無駄だし 913 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2020/02/16(日) 02:36:27 ID:VK9AAsv4.net] ヒープからの割り付けをする機会を減らすことで実行速度を上げる工夫はよく聞く話ではあるよな。 ただ、そこまでギリギリのチューニングが必要ってことがあまりないだけで。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef