C++相談室 part155
■ このスレッドは過去ログ倉庫に格納されています
>>143 以下のサイトによれば、「標準的な仕様は決まっている」ようです: drafet C++11 standareのsection 12.8のparagraph 15に implicitly-defined copy/move constructor は、 「a memberwise copy/move of its bases and members」 であると書いてあるそうですから: https://stackoverflow.com/questions/18290523/is-a-default-move-constructor-equivalent-to-a-member-wise-move-constructor The implicitly-defined copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members. [ Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2. —end note ] The order of initialization is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2). Let x be either the parameter of the constructor or, for the move constructor, an xvalue referring to the parameter. Each base or non-static data member is copied/moved in the manner appropriate to its type: if the member is an array, each element is direct-initialized with the corresponding subobject of x; if a member m has rvalue reference type T&&, it is direct-initialized with static_cast(x.m); otherwise, the base or member is direct-initialized with the corresponding base or member of x. Virtual base class subobjects shall be initialized only once by the implicitly-defined copy/move constructor (see 12.6.2). >>142 >ムーブセマンティクス一般においてはムーブ後の抜け殻は「無効なオブジェクト」なのでアクセスに対して保証がないことがあるが、 >標準ライブラリのスマートポインタについては所有権を移動させた後にそれが空であり >メンバ関数 get で nullptr が返ることも、 nullptr と == で比較して真であることも保証される。 なるほど。 行(1)の場合、 1. 右辺でstd::move()をt1に行った段階では(実行段階で)マシン語は全く実行されない。 2. 中央の = は、move-constructor と解釈され、Tのmove-constructorが呼び出される。 3. Tの暗黙定義のmove-constructorは、メンバ同士のmove-construcotrなので、 メンバに shared_ptr<A> a があると、shared_ptr<A>のmoveコンストラクタが呼び出される。 そして、shared_ptr<A>のmoveコンストラクタは、実行後に「src側(from側)」をnullptr相当の 状態にしてしまう。 ということのようですね。 >>146 逆に言えば、Tのメンバに、A *pA; のような生ポインタがあると、 Tの暗黙のmoveコンストラクタ/move代入演算子では、恐らく、 「src側(from側)」にはnullptrが代入されない(??)ので、非常に困った 問題を招くかも知れないと? >>147 Tのデストラクタに if ( pA != nullptr ) { delete pA; } などと書いていた場合、問題を生じそうですね。 c++についてうんちく垂れるやつに限って仕事ができない そんなうんちくどうでもいいから、さっさと作れよって思われてる先輩いるわ >>150 プログラマは怠惰であれ、を地で行ってるんだろう >>144 > わざわざ誰が書いたかわからないようなものより自作できるなら自作するだろ おまえは一生二度とライブラリもOSも使うな ベアメタルだけで食っていけ それができたら、おまえに付いてくる者たちが顕れるだろう できなければ人知れず消えるだけだ どうなりたいかは、お前の人生だ 俺がどうしろとは言えない >>150 またお前か。さっさとプログラミング覚えろよ std::binary_search()は戻り値とかなんとboolや こんなのよかちゃんと位置を返してくれるstd::lower_bound()の方がよっぽど使いでがある ちなstd::lower_bound()が2分探索か線形探索かは使うイテレータの条件次第 std::lower_bound()が線形探索だと断言してくださる香ばしいblogも世の中にはあるが https://rsk0315.hatenablog.com/entry/2019/09/10/173708 これがまつがいであることは比較関数の中でprintf()でもしたらたちどころにワカル ゴメソリンク先は必ずしも断言はしていなくって、std::set<T>にstd::lower_bound()を適用する例か、 これのイテレータはrandom-access iteratorでないから確かに線形探索になる >>144 こういうのが井の中の蛙ってのだな 蛙くん >>149 生ポインタのメンバ変数がある場合で、デストラクタで>>148 のように 書いている場合は、暗黙のmove関数は自動定義されないようです。 なぜなら、暗黙のmove関数は、デストラクタがユーザー定義されている 場合には自動定義されないためです。 他にも、コピーコンストラクタ、コピー代入演算子、move代入演算子 がユーザー定義されている場合も、暗黙のmove関数は自動定義されない そうです。 >>158 誤:暗黙のmove関数 正:暗黙のmove-コンストラクタ コンパイラはともかくリンカに計算負担をかけるのはバカな設計だなと思うわ。 暗黙のmoveがnullptr代入してくれないとか生ポあるクラスに暗黙のctor定義してくれるのか、とか 学ぶ順番間違えて勘違いしてるやつ上の方にいるけど そもそも生ポの扱いに言語が介入するんならdtorでdeleteしてくれるのか、とか考えつかないのかね・・ 質問者はポインタ型とshared_ptrについて聞いてたのに、shared_ptrのことしか答えなかった餃子が悪い。 謝れ!俺に 皆さま御機嫌よう、ちょっと質問させてください class hogeの内部でenum class fugaを定義し、 そのfugaをclass hogehoge でメンバ変数として使用したいのですが、 hogehoge のヘッダーにはなるべくhoge をインクルードさせたくありません。 もちろんfuga変数はヘッダーに置いて使用したいのですが…… 前方宣言でfugaを宣言してもhoge::fugaと互換?が無いため代入が出来ません。 キャストで戻したりして使っているのですがこれならintでもいいかなと…… クラス内クラスの前方宣言は難しいのでしょうか? 何か方法がありましたら教えていただきたく…… class hoge{ enum class fuga{ one,two,three,SUM }; }; //ヘッダーはソースにインクルードしたい class hogehoge{ hoge::fuga mfuga; }; こんかかんじで使いたいのですがエラーになってしまいsまずorz enum classはグローバルに置いた方がいいんでしょうか? 任意のクラス内部で規定したいenumが見た目も便利だと思ったのでなるべく入れ子にしたかったのですが >>167 hoge をインクルードしないところで hoge::fuga を使いたいということは fuga は hoge にそれほど強く結びついていないということで、外に出すのが妥当なのでは? 外に置いたうえで hoge 内で using fuga = outer_fuga とでもすれば、見た目は損なわれないだろうし。 >>168 名前に「ホゲで使うフガ」と名付けるのがいいですかね? 前方宣言で定義したクラスは不完全型みたいでクラス内クラスにアクセスする場合は別途定義が必要みたいです…… 難しい感じですかね std::sortがセーフソートかどうかって決まってないんですね? 安定ソートのことならstd::stable_sortを使え std::stable_sort<T>はどうしてもstd::sort<T>より遅い からstd::stable_sort<T>で安定ソートするテクニックが存在するし需要がある もちろんタダでというわけにはいかずn個のTのソーティングに対しn個の整数型の配列が別途必要だがとにかくできる まつがえたorz 誤: std::stable_sort<T> 正: std::sort<T> 計算量の仕様からすると何だかんだ言って std::stable_sort<T>の中身はマージソートで、 std::sort<T>の中身はイントロソートとクイックセレクトとクイックソートの複合技 ぐらいしかありえない みなさんありがとうございます 安定ソートのことでした > std::stable_sort<T>の中身はマージソートで、 これはまあそんなもうだろうけど > std::sort<T>の中身はイントロソートとクイックセレクトとクイックソートの複合技 なんでここまで限定するんだ? https://cpprefjp.github.io/reference/algorithm/sort.html >C++11以降: O(N log N) (N == last - first) 計算量での比較 >クイックソートは平均計算量がO(N Log N)だが、最悪計算量がO(n^2)である。そのため、C++03の計算量要件には合致するが、C++11の要件には合致しない ubuntuでの開発環境って何があるんでしょうか? openglなのでc++を使うことになると思うんですが、c++はideとしてvscodeでいいですよね guiは何が一般的なんでしょうか? > この関数には、特定のアルゴリズムで実装すべきという規定はない 古典的なソート議論はユニプロセッサ前提 今どきの並列化の流れに必ずしも当てはまるとは思えない boost::sort::pdqsort(), boost::sort::block_indirect_sort() あたりならヘッダーだけで並列ソートできる >>181 GUIなんか使わないのが一般的だよ 開発環境にわざわざC++とLinuxを選ぶような人は自分用アプリにGUIなんて組み込まないだろうし、 他人に使わせるならどうせWindowsでテストしなきゃいけないからLinuxなんて時間の無駄だ OpenGLだったらOpenGLの描画結果を表示するウィンドウとターミナルでいい 自分用アプリねえ 俺の定規ウインドウなんてGUIだけど ぐぐったら沢山出てきた 頭が悪くて理解出来ないけど需要あるんだね unique_ptr<hoge> 自体が型名なんでしょうか? class unique_ptr<hoge>で前方宣言してもいいのかな? 素人なんで自分の説明が難あると思うんだけど自分なりに精一杯説明すると、 ヘッダー部の引数にclass unique-ptr<hoge>& uhogeを載せて、 ソース部にhoge.hをインクルードして定義する感じでつかいたんだけども…… 試してみたけど動くんだけどなんか怖い 想像ではunique-ptr<class hoge>が前方宣言だと思ってたもので…… どこをどう調べればいいのかだけでも教えていただければ…… >>191 テンプレートのインスタンス化は暗黙にやってくれるので基本的にはする必要がない。 どうしても宣言したいのなら extern class unique_ptr<hoge>; と書くことは可能。 ただし、このように宣言した場合には暗黙のインスタンス化は抑制されるので、 別の場所で明示的インスタンス化をしておく必要がある。 テンプレートの展開はその仕組み上、各翻訳単位ごとにやった上でリンク時に統合されるというクソみたいなことになってるので、 コンパイル時間を抑制したいなどの理由でこういった変なことになってる。 ユニークポインタ自体の大きさが、ポインタだから4バイトくらいに統一されているのかな? 型テンプレートがどんな型でも、定義部分で明示してあればポインタ長のメモリをアロケートされているから、宣言自体はある程度の許容範囲があるということなのかな? 理解が違ってたらすいません >>191 1行目yes 2行目はその場合クラステンプレートの明示的実体化になる 前方宣言の場合は template <class T, class D> class unique_ptr; (もちろん名前空間std内 テンプレートは引数与えられてない限りあくまでテンプレートであってコードは生成されないよ >>194 え、明示的インスタンス化しておけばコンパイル時間抑制できるの? 前方宣言というのはあくまで「こういう名前のこういう奴が(どっかに)いますよ」って言ってるだけ 実体がどんなサイズでどんな値やメンバやなんやかんやを持ってるかとかには関知しない >>196 > 明示的インスタンス化しておけばコンパイル時間抑制できるの? ちがうちがう。 extern のほう (宣言) が暗黙のインスタンス化を抑制するからコンパイル時間が短縮されることが期待できる。 でも、インスタンス化を抑制するんだからどこか別の翻訳単位に実体が存在する必要はあって、 それに明示的インスタンス化を使えるようになってるって話。 リッチにテンプレート使いまくって一本ソフト書いてみ まぁわかりやすいのはspiritとかのET使ったやつ、それを複数のソースファイルで使いまくればわかる さらに言えば自分でそういうライブラリ書いて少しの変更でほぼフルビルドかかるのを体験すればわかるやろ >>200 今時コンパイル時間を気にしないほうが頭悪いわ。 いまいちメタプの必要性が理解できん コンパイル時に決定してる値しか計算できないんでしょ 3の階乗は計算できるけど、ユーザーから入力された値の階乗は計算出来ないって・・・ だったらはなから6ってハードコーディングしとけ >>203 抽象化の手段でもある。 脳内で計算できる程度のものであっても、 ちゃんと名前が付いた関数になってるほうが 読むほうにとってはありがたいもんだよ。 >>203 こういう書き方出来たら便利なのにな、とかを無理矢理実現できるというロマンはある (マクロと似たようなもんだが プロパティみたいなことも一応出来るし ただまぁ・・・労力に見合うか、というと散々だわマジで。 持て囃すようなものでは決してない(他人のふんどしでドヤりたい連中が持て囃してるだけ >>203 まあ実際ビルドシステムを自分で構築するかコンパイラにやらせるかの違いしかない。 フーリエ変換の係数みたいなものを事前に設定するとかは少し便利かもね。 それなりに手計算すると大変だけれどそこまで本格的に計算時間がかからないような 事前計算できて使いまわせるようなものが念頭にあるんだろうが、まあそんなないわな。 状況に応じてコードジェネレータを用意するよりはマシってくらいか。 condition_variableってなんでこんなに面倒なんだ winなら、イベントの方が高速だし楽で懐疑起床も起きないし >>212 特定変数に依存しないbool条件式で起床できるのはWindowsのイベントよりも楽で応用が利く 今さらイベントには戻れない便利さがある >>212 ほんまこれ。せめてspurious無かったらなあ。 めんどいから手っ取り早くspinして待ってまうわ。 >>213 その式を書かなくてもいいイベントを使ってからは condition_variableには戻れなくなった おすすめ本ってありますか? C言語のプログラムを、文法などカンニングしながら書けるレベルです。 cppreference.comの何が不満かによる プログラミングにカンニングという概念はない 常にオンラインヘルプなので正確な仕様を確認しながら作業するのがプログラミングの常なので、 カンニング(仕様確認、他人の書いたコードをチラ見してコーディング規約ぶ追従)は仕事の一部 訂正 プログラミングにカンニングという概念はない 常にオンラインヘルプなどで正確な仕様を確認しながら作業するのがプログラミングの常なので、 カンニング(仕様確認、他人の書いたコードをチラ見してコーディング規約に追従)は仕事の一部 明確なコーディング規約がない場合にはなおのこと、カンニングが重要になる condition_variableに似た関数SleepConditionVariableCS()がWin32APIにも用意されてるけど、直感的で使いやすいのはcondition_variableでしょ https://docs.microsoft.com/en-us/windows/win32/sync/using-condition-variables 質問なのですが教えてくだちい Q1. 64 bit符号付整数の積の結果をオーバーフロー無しで(128 bit等で)で得る方法 ※ 64 bit整数を2^32進数2桁とみなして筆算する処理より速い方法キボン SSE4.1可 Q2. (Q1にうまいやり方が無い場合)64 bit符号付整数の積がオーバーフローしたことを検知する方法 Q3. 多倍長整数(例えば8要素のunsigned longの配列として表された符号無し整数0〜2^256-1) を10で割る方法orz Q2は現状a*bの前に std::abs(a) <= std::numeric_limit<int64_t>::max / std::abs(b) という判定をやっているのですが もっと速いやつ(除算不要のやつ)キボン、 winならMultiply128、gccやclangなら__int128ってのが使えるみたいだけど >>223 特定の環境ならアセンブラでやっちゃえば? ちなみに環境は? 昔その辺の演算は良くやった Q3は10の逆数を求めておいてかけ算命令でやるのが良いけど 多売長は何進数? 10で割るだけの為にバッファスキャンはもったいない 何かの演算とセットに出来ない? もしやりたいことが2進多倍長の10進数化なら もっと良い方法がある 環境 (CPU, OS) 多倍長の構成 (整数?指数部あり?2進?10進?変則?) 最終的に何がやりたいか この辺がわかれば色々と教えられる >>223 >>225 も多倍長演算ですか、じゃ、私も私の多倍長演算を https://mevius.5ch.net/test/read.cgi/tech/1434079972/37 >Q3. 多倍長整数を10で割る方法 であれば上のリンク先の line:383 から、std::ostream &operator<<(std::ostream &stream, mpz_base_class c) にて、ちょこっと工夫したつもりです、剰余は下位から確定する点では普通、ですので順序を逆にするのはアレかもしれませんが とりあえず筆算のやつをゴリゴリ書いてや った https://ideone.com/pcltLW ヒント 除算は遅い 除算は逆数の乗算 定数の除算のコンパイル結果 ちゅか10で割るのは10の剰余を知りたいからなのだというのは 言ってなかったわサーセン、orz 多倍長整数の10進数表現を得るために、多倍長整数を10で割って剰余を求める必要があった この目的には誤差の見積や処置が面倒な方法はNGでありかつ 10進数化とかどうせ表示の時しか使わないのでこの割り算自体はそうメチャクチャチューニングする必要は ありませぬ(と後出し もしガチで全く除算を使わずに10進数に変換せよと言われたら 5*10^n、2*10^n、1*10^nを作ってnがデカい順に元の数と比較して引いていく、 ぐらいしかなさげ 知らんけど >>223 トンチンカンなこと聞いてたらすみませんが、Q1って多倍長整数を文字列で持ってカラツバ法とか高速フーリエ変換で計算するやり方だと「遅い」んですか? >>236 であれば >>230 で まあ多倍長演算を実装するのならアセンブラが最適で、なんといってもキャリーフラグやゼロフラグを触れるのはアセンブラしかないですからね というか、C/C++ だけで多倍長を実装するなんて馬鹿なことを思いつくのは私くらいですかね‥‥ >>238 >カラツバ法とか高速フーリエ変換で計算するやり方だと「遅い」んですか? これらは、オーダーは O(n^2) より下のクラスなので速いのはそのとおりですが、しかし使えるのは掛け算のときだけですね まあ逆数を掛けるという意味では割り算も OK かもしれません、そして逆数計算は「単桁 vs 多桁」だから、オーダーは無視できますし それはそうと、昔バグっていた例のペンティアムの除算アルゴリズムを解説してくれるサイトはないですかね‥‥ >>236 いいわすれましたが、商が高速に求められれば、剰余は 被除数−商×除数、で求めるものですし、多分高速除算・高速剰余計算は多分そうしているでしょうね >>240 質問者は掛け算と10で割る (小数点以下は無視する割り算ですよね?) しか聞いてないので、掛け算さえできれば良くないですか? ああ、10で割るのはあまりを求めたいからって書いてあった でも10で割った余りって1の位の数字ですよね? そんな話じゃない? まあいいや チューニングする必要はないって話なんで、わり算の話は置いといて、結局やりたいのは整数同士の掛け算ですよね? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる