C++相談室 part139
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
----- テンプレ ここまで -----
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>358
std::vector の要素は CopyAssignable と CopyConstructible の要件を満たす必要がある。
実際、 std::vector は内部で要素をコピーしたり代入したりすることがあるんだから、
それが出来ない要素を入れられないのは当たり前の話で、
コンテナに入れるならポインタ (上記要件を満たすスマートポインタでもよい) を入れるようにするくらいしか方法はないと思う。 >>358
ムーブしてもいいならムーブコンストラクタと代入演算子を定義すれば行けないかな どうせ所有権意識して std::move を使うなら個々のクラスには
手を加えず unique_ptr かますのが楽じゃないかな >>362-363
ムーブ可能なだけでは必要な要件を満たしてない。
コピー可能であることが要求されている。 >>364
vectorの型Tの満たすべき要件は操作による
push_backとかresrveとかはコピーかムーブのどちらかが可能ならば問題ない リストのイテレータ使って周期的な処理をしたいんだが、そういう使い方合ってる?
N 要素のリストのイテレータ it = s.begin() を N 回インクリメントしたら、it はルート(?)を指すわけだが、そうじゃなくて s.begin() と同じところを指してほしい
こういう場合、どうしたら良いだろうか スアホポインタみたいな頭ワルイの使うぐらなら
C++なんかつかわなければいいのに
低学歴知恵遅れは新しいもんができると
使わないといけないという使命感があるらしい
低学歴知恵遅れは自分で要否が判断できない そうだね痴呆おじいちゃんには7年前に標準化された最新機能は難しすぎるから仕方ないね
半角に限らず今でもウヨウヨいるからあんまり笑い事じゃないんだけど あんのが難しい?
知恵遅れは頭ワルイシロモノを使ってる自覚がないからな
低学歴知恵遅れはアレで難しいもん使ってるつもりでいんのか
へー >>367
それ参考にして自力で実装してみます
ありがとうございます >>365
あ、ほんまや。 ワイの記憶は C++03 時代のやつやった。
ムーブないからしゃーなしでコピー必要やったんやな。 うろ覚えで>>364みたいなこと断言してたのかよ
自分の記憶を疑う癖つけた方がいいよマジで >>373
いや、このサイトを見て確認はしたんだよ。
https://ja.cppreference.com/w/cpp/container/vector
ただ、 「C++11 以前」という書き方になってたから、前後を見ずに C++11 は含むのだと思ったし、
(現在の最新ではないとはいえ) C++11 くらいには配慮すべきだろうなっていう前提で言ってたの。
でも、ちゃんと仕様を確認したら「C++11 以前」は C++11 を含まないことに気づいたって次第。 あー、確かにあれは紛らわしいかもね・・
でもすぐ近くに「C++11およびそれ以降」ってあるしな Cとhaskellはどちらがどれくらい速いですか? STLのリストは要素を挿入するごとにメモリーの割り当てが起こるのか一度に割り当てられている場所に
なのかどちらですか? 規格は要素ごとに割り当てるのを想定してるだろうけど
例えば10個分まとめて、みたいな実装もOKじゃないかな……
挿入削除やイテレータの++がO(1)みたいな各種要件さえ満たしてれば vectorならともかく、そんな実装するってメリットがあまり無い気が メモリのローカリティを維持できれば性能がよくなる可能性もあるんじゃね? >>380
メモリのアロケーションは意外にコスト高いからまとめてアロケートしておいて
node を用意するときにそこから placement new とかして使ってゆくと高速になる
リストのノードに限らず、プロファイル取って new が時間
食ってるときにオブジェクトについてはこれで簡易に改善できる
最近はデフォルトのアロケータが高性能で意味がないこともあるけど 続き
解放も一気にしないと面倒なので基本追加一方で不要になったら全部消すみたいな場合に使う
巨大 xml の dom を作って、不要になったら全解放みたいなとき。 大きいデータだと何十万回、何百万回もnewしなくちゃいけないようなクラスは
1メガくらいまとめてnew [] したほうが絶対いい。
実行時間比較すればわかるけど、かなり高速になる。 1メガくらいという根拠の薄いマジックナンバーに依存する糞コード >>385
当然、実装するときは、まとめて確保するメモリ量は指定できるように作るのが当たり前。
いちいちそんなこと言わなくてもみんなわかると思って、例えば1メガという意図で「1メガくらい」
と書いたが、バカには伝わなかったみたいだな で、1メガという定量的な根拠は? いくら罵倒しても自動的には出てこないぞ パフォーマンスを求めるシーンでダブルリンクリストって ダブルかどうかは知らんが深さが不定の木構造なら仕方ない
んでメモリ確保はn個まとめればアロケーションコストはほぼ1/nになるんで
10とか100で十分で別にそんなに増やす必要はない
が、大量にアロケートするときしか使わない手法なので1000とか大きな数にするのが人の情 まあnewするクラスのサイズによるだろ
サイズが100バイトのクラスなら1メガでもnewの回数が一万分の1になるので効果はありそう データ構造全体でどれくらいの大きさになるのか事前に見積もれればいいんだけどね。
ガチでチューニングしようと思ったら
各アプリケーションでのメモリの使い方の特性を考慮しなきゃならんし、
パラメータの微調整は実際にやって試してみるしかしょうがない。 >>392
>データ構造全体でどれくらいの大きさになるのか事前に見積もれればいいんだけどね。
そうだな
実行開始して何時間も待たされた挙句、メモリ不足でエラー終了とかマジ勘弁して欲しいわ
最初に使用メモリ量を予測してエラーにしてくれよ 今時はメモリエラーなんて出さずに延々確保しにいってスラッシングしまくるだけ >>387 >>385
キャッシュなんだから 2のn乗で適当な大きさ持ってれば大丈夫 >>395
テキトーの用語の使い方を間違っているな jemallocのデフォルトチャンクサイズは1MiBらしいな
経験的に悪くない数字なんだろう 一気解放テクというのはN億個のオブジェクトをフルスピードで作って10秒かかったとして、
破棄するときもバカ正直に10秒かけるつもりなのかとかそういう話だが
オブジェクトがリソースを所有しておりデストラクトを要するブツだったりすると
オブジェクトの占有メモリだけ一気に解放することはできないから成立しない
というわけでコンパイラの中で構文解析結果であるところの木構造を破棄するのにお目にかかるぐらい
なキモス ソースコードを読んだわけじゃないが、
ウェブサーバの H2O はドカンと大きいメモリを確保して頭から順番に使っていくという戦略を取ってるのでクソ速いというのを
どこかで見た覚えがあるな。
ウェブサーバならセッションが基本単位と考えれば、
セッション開始時に大きいメモリを確保してセッション終了でまるっと捨てるというのは確かに理にかなった方針だと思う。 >>400
いやnewもdeleteもインプレイスでやるからメモリの確保と解放はまとめてできるんだ
んでコンストラクタとデストラクタはどっちにせよ必要なので、メモリの確保と解放が問題なんだよ
で、指摘の通り
メンバ変数がまたメモリを確保/解放してるとご利益がぐっと薄れるので
まとめて確保を使い始めるとベクターだなんだもショートストリング最適化みたいな
小サイズなら静的に確保したメモリを使うようなテクニックを使い始める。
LLVM の SmallVector やそれを基にした boost の smallvector なんかがそれか boost のは small_vector の typo まとめてアロケートするコードのテストコードを書いてみた
簡単なリストのアロケーションと解放
100個ずつと1000個ずつではだいぶ違った
1000を10000にしても大差ない
https://ideone.com/oyIM5p 上の例はリストのノードにstring を持たせているが、
これをvectorにするだけで高速化の倍率はひどく悪化する。
https://ideone.com/k6XiHK
string は SSO(ショートストリング最適化)で小サイズならメモリのアロケートを行わないが、
vector はサイズ1でも必ずアロケートするため。 opencv(c++)で適当な画像をDCTしてDCT係数をテキストファイルにプログラムを教えていただけませんでしょうか。
画像をDCTするとこまでは分かったんですがそのあとが分からないです。 >適当な画像をDCTしてDCT係数をテキストファイルにプログラム
日本語で >>408
もう1回書きますがテキストファイルに書き出すです OSが分からんが、一番楽チンであれこれ考えなくて良いのは普通にprintfしてファイルにリダイレクト。 dctは出来るのにストリームへの出力は出来ないのか ofstreamでファイル開いて<<で出力
ascii文字だけなら文字コード気にしなくてもいい DCT係数が配列に格納されているんですがそのすべてを書き出すのができないです >>418
Mat 型の変数 m に入ってるなら
std::cout << m;
で標準出力に出るだろう
参考
http://opencv.jp/cookbook/opencv_mat.html C言語は高校・大学の頃やったので大体わかります
今更ですがC++勉強するのに良い教材は何でしょうか?
本が良いですがもっと良い方法がありましたらそれでも良いです >>421
まずは「プログラミング言語 C++」を読んでみては?
高いから図書館で借りるといい C++ってnumpyみたいに2次元配列から範囲を指定して抜き出しとか出来ないですかね?
10, 20, 30, 40, 50
60, 70, 80, 90, 100
110, 120, 130, 140, 150
160, 170, 180, 190, 200
このようなvectorがあった際に
70, 80, 90
120, 130, 140
170, 180, 190
を抜き出したいです >>424
自分で書きたくないならあり物のライブラリ使えばいいのでは
よく知らんけど opencv の Mat とか BLAS とか
https://minus9d.hatenablog.com/entry/2014/03/21/114514 boost の multi_array でできる
かなり調べた結果これに行き着いたから、他のを見つけるのは至難の業だと思う まぁ2次元配列に限るなら正直 vectorのvector でそういう動作するもの簡単に作れるよね 普通こういうものの部分行列はデータをコピーしないで動作するんだよ。用途によるけどだいたいは。 >>424
C++ から python も numpy も使える >>424
vectorではなくvalarrayの使いどころだ valarrayじゃなきゃ駄目な場面なんて知らんがな そもそも2次元の配列使う必要がない
1次元で十分
池沼はいちいちみため2次元にしたがる みため二次元ねえ
int vec[][5] { 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200 };
これで済むことを、
int& elm(int row, int col)
{
static int vec[] { 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200 };
return vec[row * 5][col];
}
いちいちこう書くやつも充分に池沼なんだが
そういうやつをちょっとプロファイリングしてみると
配列へのポインタに腹を立て、ポインタの配列にmallocして
強引に**で二次元を扱えることにするテクニックを某所で自慢したら
タコ殴りにされて、すっかり心を病んでしまい
以後、二次元配列というワードで凶暴化するようになった、とかね >>436
tcl/tk なら枯れてるから大腿同じ ていうか(アドレスp)[x]は*(p+x)の別表記に過ぎないというのは規格上の話にすぎなくて、
実際問題としては一次元配列アクセスと二次元配列アクセスには最適化のかかり方次第でかなり速度差が生じるお
一次元配列にすると、概念上の次の行の要素への移動が加算1発で済むというのが喜ばしい
これとループ最適化が組み合わさると、配列スキャンが主な仕事の処理は爆速になり得る
といいつつ次の例はideoneでこそ一次元配列アクセスの方が遅いが(爆
Visual C++ 2010だと一次元配列は10倍超速いお
https://ideone.com/K7uLo9
(VC++での結果)
******* Array 1D opt:
ntimes=100000^2, sum=2372578304
Consumed time=0 sec
******* Array 2D:
ntimes=100000^2, sum=2372578304
Consumed time=10 sec C/C++で「二次元配列」と言った場合
char *hoge[N]; の方を指すのであって
char **fuga; の方は決して「二次元配列」ではない
Javaなら後者を指してるので
これらが初心者には混乱の元 ごみん
いきなり間違えた
char *hoge[N]; じゃなくて
char (*hoge)[N]; こうです 439 の言うばふぉーマンスは
char **fuga; だから落ちるのであって
char (*hoge)[N]; では落ちない ていうか>>439のやつもよく調べたら1000倍近い速度差で一次元配列の方が早いお
今日日のCPUアーキテクチャーでよく見られるいつもの光景だお…
(VC++でntimes = 百万の2乗にした結果)
******* Array 1D opt:
ntimes=1000000^2, sum=2273652736
Consumed time=0 sec
******* Array 2D:
ntimes=1000000^2, sum=2273652736
Consumed time=928 sec >>443はジャグ配列と通常の二次元配列の区別も付いていないおむつも取れていない赤ん坊だお;; >>444
VC++は2次元配列が苦手ってだけじゃない?
手元のgccとclangは最適化なし(-O0)だと1次元の方が少し遅くて最適化あり(-Ofast)だと1次元と2次元で計算部分は全く同じアセンブリになった >>436
文法古くて生産性低いってだけで、コードは動くよ。 いい質問があったら鬼のように加速するけど、そうじゃないときはかなり穏やかなんだな おいEffectiveC++がいつの間にかオライリーになって高価くなってるじゃねぇか
誕生日におばあちゃんにもらった図書カードでも買えないぜ Javaが来年頭から死亡展開になるの今日知った
C++はやっぱ平和だな
ところでみんなはC++で何を作ってるの? ■ このスレッドは過去ログ倉庫に格納されています