【初心者歓迎】C/C++室 Ver.106【環境依存OK】

**デフォルトの名無しさん** · 2020/07/13(月) 13:51:48.09

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

**デフォルトの名無しさん** · 2021/03/13(土) 11:40:09.75

とりあえずwebのロベールとかでも良いとは思うけど・・
独習とかの本は何か持っといた方がいいと思う

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/13(土) 14:13:55.98

ウェブのロベール本ってこれのこと？
http://www7b.biglobe.ne.jp/~robe/cpphtml/
いまどき #include <iostream.h> とか書いてあるのはちょっと微妙だと思うぞ。
どの箇所だったか忘れたけど const の扱いで現行の仕様に合わない部分について
Taratail だったか Qiita だったかで見た記憶もあるし。

個別に見ればささいなことだけど、
入門者はそのささいなこともわかってないから入門者なわけで、
細かい引っ掛かりが多いとしんどいんじゃないか？

◆QZaw55cn4c · 2021/03/13(土) 14:52:13.00

>>575
本を買った方がいいでしょう、それも複数買う前提で、この世界では「一冊で完結」は無理です

最初の一冊なら私なら旧独習をお勧めします（私がそうでしたから）、が、新独習の評判は聞いてみたいとは思っています

**デフォルトの名無しさん** · 2021/03/13(土) 15:28:12.06

>>577
お前がゴリ押ししてる江添本よりはマシだと思うよ

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/13(土) 15:50:23.66

>>579
俺は江添本を (全体を通しては) 読んだことがないのでごり押しするほど強い関心無いんだけど。

ただ C++ は C++11 が大きなターニングポイントになってるので、それより古い前提の説明は論外という立場。
ましてや C++03 にすら合致しないのは論外も論外。
論外のものを除いて入門向けにマシそうな、
しかも無料で読めるものというと江添本以外に実質的に選択肢がないからよく挙げるだけだよ。

**デフォルトの名無しさん** · 2021/03/13(土) 16:12:25.33

QZも言ってるが独習の新版はC++17らしいぞ

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/13(土) 16:33:14.60

>>575
話題に上がったから紹介しておくけど、江添本ってのはこれのことね。
https://ezoeryou.github.io/cpp-intro/
入門書であまり取り上げられないけど入門者が躓きがちなコンパイラのコマンドの話や makefile とかいった周辺事情も
取り上げているかわりに、ヘッダファイルを使い分けしなかったり、継承を扱わなかったりで、
網羅的に C++ を理解するための本ではない。入門者が入門するための本。
それ以上のことは他の本を読めという投げっぱなしだが、
とりあえず無料で基礎をおさえられる (しかも日本語！) という意味では他に紹介できるほどのものはない。

C++ ではありがたいことに無料で利用できるリファレンスは意欲的に整備している方々がいて、
https://ja.cppreference.com/w/
https://cpprefjp.github.io/
あたりを見れば細かいことも書いてるんだけど……。
まあ当たり前だが入門書をひとつも読んでないレベルだとみてもわけわからんと思う。

本気で取り組むなら本の数冊くらいは買ったほうがいいと私も思う。

**デフォルトの名無しさん** · 2021/03/13(土) 16:48:52.40

そら今時コマンドラインツール使っててソース1つだけで書いてるようなC++オタクには合ってるかもしれんけどな・・

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/13(土) 17:11:08.84

他に存在するなら紹介するんだけど、
無料でという制約の中で (個別のブログ記事とかじゃなく) それなりに筋道をつけた入門書で古すぎないものとなると無いだろ。
英語でいいならあったりするかな？

**デフォルトの名無しさん** · 2021/03/13(土) 17:54:16.06

>>581
自分は半月ほど前に最新版の独習を買って、半分ぐらい(p370あたり)読み進めているんだが、「本書について」によると、C++14とC++17をメインのターゲットにしてるって書いてますね

**デフォルトの名無しさん** · 2021/03/14(日) 08:22:46.92

アドバイスありがとうございます。
とりあえず、教えていただいたロベールさんのページを見たのですが、網羅的に書かれているようなのでまずはこれを読もうと思います。

> いまどき #include <iostream.h> とか書いてあるのはちょっと微妙だと思うぞ。
すみません。これ、何が悪いのでしょうか。。。

あと、教えていただいて気がついたのですが、C++も結構色々なバージョンがあるのですね。
私が今回触らなければならないコードはかなり前のコードなので、もしかすると古いバージョンのC++かもしれません。
その辺も意識して勉強しなくては駄目ですね。

**デフォルトの名無しさん** · 2021/03/14(日) 10:23:48.46

今はもう標準ライブラリに.hがついてるのは無いからそもそも実行できない可能性ある

**デフォルトの名無しさん** · 2021/03/14(日) 10:49:48.45

実行？

◆QZaw55cn4c · 2021/03/14(日) 14:53:49.63

>>585
旧独習には「std::stringを自分で実装せよ」という初級者には眩暈がするほどの崇高な課題が採用されていましたが、新独習には「～を独力で実装せよ」系のお題は採用されていますか？
すくなくとも「～を独力で実装する」系お題が可能になるだけの基礎知識をつけてくれる本ですか？

**デフォルトの名無しさん** · 2021/03/14(日) 17:03:20.15

>>589
全13章605ページのうち7章380ページまで進んでいますが、そのようなお題にはお目にかかっておりませんな。
練習問題やその章の理解度チェックで色々な問題が出されていますが、何れも本をよく読めば解ける問題ばかりです。
さらっと先まで目を通してみましたが、そのような課題は見当たらないようです。
旧版のどの箇所あたりで出題されたものですか？　もしかして、全く別の本のことなのでしょうかねえ。

↓の「おまけ」にあるような解答を求める問題でしょうか？
std::stringの実装に学ぶC++入門 - Qiita
https://qiita.com/YSRKEN/items/dd3b11e4670bb2b829a5

自分はまだ独習中で、C++は未だ*や&、&&、で頭の中がグルグル回ってしまうレベルなもので、理解できそうですが
いきなり自力で作れそうにありませんわｗ

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/14(日) 18:12:48.12

>>586
> これ、何が悪いのでしょうか。。。

1998 年に国際規格 (ISO) になって以来、規格に iostream.h というものが有ったことはない。
.h は不要。
諸々の事情から iostream.h も用意している開発環境が多かったせいか
古い書籍では iostream.h としている場合は少なからずあるのだけれど、
主要な処理系の標準への準拠が急速に進んだこともあって、
資料も規格に寄せた書き方が今では普通。
iostream.h は古い本の象徴みたいな感じになってる。

そんでもって規格にない以上は iostream.h が存在しない開発環境も普通にあるってのが問題。
https://wandbox.org/permlink/kwpJf5BumkarYWYD
規格になくてもデファクトスタンダードとしてどこにでもあるってのならまあいいかと思わないでもないけど、
無いこともあるんだ。
そういう環境だともちろんエラーになる。

初心者が入門書の最初に載ってるコードを入力してみてエラーになるってのは良くはないだろ。
そんでもって問題がそれだけとは限らなさそうという……と思わせるサインなんだよ、 iostream.h は……。

◆QZaw55cn4c · 2021/03/14(日) 20:04:14.75

>>590
手元の旧独習4版（ハーバード・シルト著）6章末「総合理解度チェック」
・次の演算ができるような strtype クラスを作成しなさい
・+ 演算子による文字列連結
・= 演算子による文字列代入
・<>==による文字列比較
固定長文字列を使ってもかまいません。難問ですが、よく考えていろいろと試してみてください。
必ずできるはずです。

◆QZaw55cn4c · 2021/03/14(日) 20:13:24.03

>>590
＞C++は未だ*や&、&&、で頭の中がグルグル回ってしまう
これらの「記号」は習得に順序があります。
まず * をしっかり理解します。C/C++ はなんといってもポインタが基本です。
次に参照 & を理解します。参照& を使う場面が出てきたら、これを * を使った書き方に書き直す、という機械的な訓練がいい練習になるでしょう
参照で返す、という場面でも、①参照返しが出来る場合と、②参照返しはできずせいぜい RVO に期待するしかない場合、の①②二つの違いを明確に即答できるようになるべきでしょう（最近まで私はそれができなかった……）参照& の表現は新しい表現( ranged-for とか）でよく目にしますし、①②は結構重要だと思います

&& は多分最後でしょうね、私も && は良く分かっておらず、というか、分からないから使わないという態度に留まっていますが、まあそれでもなんとかなる気がします

**デフォルトの名無しさん** · 2021/03/14(日) 20:26:39.87

>>592
やはり「独習」の違う本でしたわｗ
自分はC++関係の5ちゃんスレすら最近になって見てるんで、知らなかったけど
その本が「独習」のスタンダードなんですねｗ
独習C++ 第4版
https://poland-it-blog.com/c_plus_books/

自分のは、↓の９位に入ってる本です。（しかも同じ出版社）
https://freelifetech.com/cplusplus-books/
ご紹介の独習はやり応えありそうなので、今の本を2回ほどやってから、次のステップでそちらを検討してみますわ

**デフォルトの名無しさん** · 2021/03/14(日) 20:28:56.28

QZ案外初心者やなw
でも言ってることは全面的に賛成
ポインタや参照、クラス等の基本を抑えてからでないとスマポや、C++11からの要素(右辺値参照含む)の使い方もわからんと思う

**デフォルトの名無しさん** · 2021/03/14(日) 20:35:47.41

>>593
大変勉強になります
今後もよろしく

**デフォルトの名無しさん** · 2021/03/14(日) 20:46:24.30

>>595
＞でも言ってることは全面的に賛成
ありがとうございます！

＞QZ案外初心者やなw
もう永遠の初心者のままだと思っていますが、それならそれで「初心者の気持ちが分かる視点からの意見の表明」という形でコントリビュートするのもありかな…、と。

◆QZaw55cn4c · 2021/03/14(日) 22:01:53.26

>>594
>>592 は歯ごたえがありそうでしょう？私もこの課題を最初に見たときは眩暈がしました…
それから 10 年くらいかな？？それくらいたってから https://mevius.5ch.net/test/read.cgi/tech/1434079972/37 を書き、なんとか卒業できたような気がします
なおこれは、これでも例外方面に配慮が行き届いていない、とさらに書き直した気がしますが、その書き直しは失くしてしまいました……

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/14(日) 23:21:43.64

個別の機能を理解してからそれの組み立て方を学習するのがまどろっこしく感じる人もいると思う。
抽象度の高いほう (スマートポインタなど) から解体していく形での
学習のアプローチもそれはそれでありかもしれん。

個人的には個別の機能を先に学んだほうがいいとは思うんだけどね。
実例から学ぶと使い方のパターンとして頭に入ってしまって正確な理屈を
きちんと習得できない気がするから。

そうは言っても途中で学習を諦めてしまうようだと正確さもくそもないから、
人によってわかりやすさは違うし学習にはいろんなアプローチがあるということは
覚えておいてほしい。

◆QZaw55cn4c · 2021/03/14(日) 23:51:21.81

確かに、私が理解している狭い範囲においても、イテレータが先かポインタが先か、とか
C++11 / std::thread から入門したけど posix-thread なんか知らん！とか
そんな人から補強説が来るのが楽しみです

**デフォルトの名無しさん** · 2021/03/15(月) 07:36:02.64

>>591
ご回答ありがとうございます。
理解しました。
その辺も調査しながらやります。

**デフォルトの名無しさん** · 2021/03/15(月) 13:58:23.84

QZが意外と素直で好印象度アップ
逆に高飛車な餃子の高感度ダウン

**デフォルトの名無しさん** · 2021/03/15(月) 21:47:16.57

Qちゃんは昔からいるけど態度は変わらんね
ときどき自前のコード上げてるあたりは好ましい
プロへのリスペクトは持ってるし謙虚ではある

餃子ちゃんはマジメというか
いちいち規格に沿って発言してくれるんで好ましい
ただコード上げてるのはみたことないんで実力は不明
アマチュアなのにときどき調子乗っちゃってるのも微笑ましい

**デフォルトの名無しさん** · 2021/03/15(月) 23:09:56.95

はちみつのコードたまーに見るけどすごい変な癖があるよ
意味があるなしに関わらず固執するタイプなんだろうな

**デフォルトの名無しさん** · 2021/03/16(火) 13:45:10.41

参照を返す関数の質問です。
オブジェクトの複数のパラメータを設定するときに、obj.param1(...).param2(...).param3(...); みたいに呼ぶ
パターンがあるじゃないですか（ちなみにこれって名前はあります?）

これをやりたいときは
Obj& param1(int val) { mParam1 = val; return *this; }
みたいに参照を返すように宣言しないとダメですよね?

Obj param1(int val) { mParam1 = val; return *this; }
だと、obj.param1(...) は動くけどリターン用にオブジェクトの（余計な）コピーが発生する、
obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。
こんな理解で正しいでしょうか?

実は参照を使う判断にイマイチ迷っているんですが、もしかして毎回（オブジェクトの宣言、引数、戻り値等）、
「このときはここでオブジェクトのコピーが発生するから...」とかイメージすべきなんですかね?
例えば関数の戻り値、関数を出るときに戻り値が臨時で複製されて呼び出し元に渡されるイメージを持って、
「ああこれだと余計なオブジェクトが生成されるよな、じゃあ参照だ。」的な判断?

**デフォルトの名無しさん** · 2021/03/16(火) 16:13:51.30

builderパターンやね

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/16(火) 16:40:47.45

クラス構成を見ればビルダーパターンにあてはまりそうだけど、
メンバ関数を連鎖していく表記法のことはメソッドチェインと言ったり、
目的から言うと名前付き引数イディオムということもある。
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Parameter
(要するに考え方のレイヤによる。)

**デフォルトの名無しさん** · 2021/03/16(火) 17:00:51.56

obj + a + b + c
　operator + () は　obj そのものを書き換えず、新たな実体を戻す

obj += a
　operator += () は　obj そのものを書き換えるついでに、自分自身の参照を戻す

これのどっちに合致したほうが都合がいいかで
複製を戻すか、自分自身の参照を戻すかを分けてる感じ

**デフォルトの名無しさん** · 2021/03/16(火) 20:32:04.07

>>605
> （ちなみにこれって名前はあります?）

大きく言うとFluent interface
https://en.wikipedia.org/wiki/Fluent_interface

◆QZaw55cn4c · 2021/03/16(火) 21:25:10.58

>>609
その wikipedia の C++ サンプルは int main() が二箇所に現れていますが、これってどう読むのですか？

**デフォルトの名無しさん** · 2021/03/16(火) 22:36:52.42

すみません。
仮に、本を買って勉強する場合は独習C++というのがいいのですか？
独習C++はCの知識がなくても大丈夫ですか？？

**はちみつ餃子** ◆8X2XSCHEME · 2021/03/16(火) 23:10:25.95

>>610
単に使い方のサンプルを便宜的に main で書いてあるだけでふたつあるのは特に意味ない。

**デフォルトの名無しさん** · 2021/03/18(木) 18:04:58.78

>>611

**デフォルトの名無しさん** · 2021/03/18(木) 18:05:52.45

>>611
江添本一択

**デフォルトの名無しさん** · 2021/03/18(木) 18:59:10.35

>>611
C関係無しで覚えるのもいいんじゃね？

**デフォルトの名無しさん** · 2021/03/18(木) 19:00:25.69

>>611
独習C++はCの知識が前提だったはず

◆QZaw55cn4c · 2021/03/18(木) 23:28:58.79

>>605
＞これをやりたいときは
＞みたいに参照を返すように宣言しないとダメですよね?
＞obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
＞結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。

確かに、メソッドチェインを繰り返すたびにコピーコンストラクタが呼び出されるのは、イマイチ、という感覚を私も同様に持ちます
だからメソッドチェインを書くときには私も参照を返すように書きます、結局のところ「参照を返す」というのは「ポインタを返す」ことですから、コンストラクタの走りようがない

しかし「参照を返す『必要がある』」と言い切れるかどうか？
「結局破棄される」というのは最後のメンバ関数が返す実体を回収していないからであり、「参照を返すから」破棄されるわけではないと感じました。
実際、この実体を回収すれば、それはそれで 2 番目以降の呼び出しが意味を持つように書けると思います

https://ideone.com/skVFOr
https://ideone.com/LAKqIj

参照でよくわからなくなったときに私がよくやる「参照返しを全く使わずポインタで押し通す」とすると次のようになるかと思います
https://ideone.com/R82zEE

**デフォルトの名無しさん** · 2021/03/19(金) 03:28:58.86

だからムーブコンストラクタとムーブ代入演算子があるんだろうが・・

**デフォルトの名無しさん** · 2021/03/19(金) 03:37:37.65

>>617-618
てかそもそもコンストラクタ走っていいのかよこの場合に

**デフォルトの名無しさん** · 2021/04/09(金) 12:21:23.57

クラスFooのメンバ関数fの型ってどう書くの？
戻り値void、引数intです。

**デフォルトの名無しさん** · 2021/04/09(金) 12:52:45.71

>>620
f の型は void (int) だけど f へのポインタの型は void (Foo::*)(int)

**デフォルトの名無しさん** · 2021/04/09(金) 18:45:41.35

>>621
それはメンバ関数へのポインタでしょ
聞いてるのは関数の型でもなく、メンバ関数の型です

**デフォルトの名無しさん** · 2021/04/09(金) 20:18:08.96

言われてみれば関数の型ってなんだ？

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/09(金) 21:13:09.06

C だと関数指示子 (Function Designator) で説明されたりするんだが、
C++ の仕様を Designator で検索しても出てこないな。
シグネチャもまたちょっと違う概念だし、
このあたりのきちんとした解説がまとまったものがあればぜひ読みたい。

**デフォルトの名無しさん** · 2021/04/09(金) 21:39:18.43

「メンバ関数の型」が必要になるケースって何じゃろ？

**デフォルトの名無しさん** · 2021/04/10(土) 01:44:53.83

>>622
だから「f の型は void (int)」って書いたのに、なんでそれが答えじゃないと思うの？

typedef void ftype(int);
struct Foo { ftype f; };
void Foo::f(int) {}
int main() { Foo x; x.f(0); }

**デフォルトの名無しさん** · 2021/04/10(土) 08:44:20.64

関数ポインタを考える以前は関数の型と言えばイコール評価した値の型だったな。

**デフォルトの名無しさん** · 2021/04/13(火) 16:10:43.48

今は関数の型とかもうどうでもよくて
一周回り帰えりキャプチャとかダイナミックスコープとかの有用性や整合性が中心よね

**デフォルトの名無しさん** · 2021/04/15(木) 15:55:01.75

pod的な意味でなく論理的整合性的な型付けの恩恵受けたいなら、別に包む必要無くても常に即席structで返しててやんでい

**デフォルトの名無しさん** · 2021/04/24(土) 08:11:28.54

C++/CLIで、スタティックライブラリからマネージドクラスを公開するのは無理なんでしょうか？
ヘッダファイルに全部実装書けば出来る、ってところまでは調べたんですが、ソースコードをプロジェクト外に置いてるのと変わらないので…。
ダイナミックライブラリでできるならそれでも構わないです。

**デフォルトの名無しさん** · 2021/04/24(土) 08:19:46.15

>>630
.NETでstatic libraryなんて作れたっけ？
最終的に.exeと.dllができるのが邪魔だからstatic libraryにしたいというだけなら、
いったんDLLとして作ってILmergeするのが一般的だと思う

**デフォルトの名無しさん** · 2021/04/24(土) 08:36:31.23

>>631
Lib自体は作れるし、アンマネージクラスなら公開もできるんですが、マネージクラスだと参照側でメンバーが参照できず、LNK2020が発生してしまうんですよね。
ビルドオプションでなんとかできるものなのかな、と。

**デフォルトの名無しさん** · 2021/04/24(土) 09:53:24.75

LNK2020ってそれnativeのC++からリンクしようとしてる？

**デフォルトの名無しさん** · 2021/04/24(土) 14:56:57.93

>>633
libなのでクライアントはC++です

**デフォルトの名無しさん** · 2021/04/24(土) 15:16:56.42

そりゃ無理。その仲立ちをするためにC++/CLIがあるのに。
一応nativeのC++からでも自分でCLRを立ち上げたりしてマネージドクラスにアクセスする方法は
あるらしいが、リンクしてそのまま呼ぶという形にはならない。

**デフォルトの名無しさん** · 2021/04/24(土) 15:41:46.62

自作のプログラム、起動時の読み込み処理の前に以下を入れると
for(int i = 0; i < 100; ++i){
OutputDebugString("dummy!!!!\n");
}
起動時に行っている外部データの読み込みが凄く速くて
これを無くすと凄く遅くなるんですが怖い…
3分くらい違いが出るので明らかにおかしい
どっかでメモリでもぶっ壊れてますかね？
どういう理由が考えられるでしょうか？

**636** · 2021/04/24(土) 15:43:36.70

さっきのダミーを入れなくても
普通にコードを追加したりしてても遅くなったり速くなったりする
別に読み込み処理の部分とは関係ないところでも。
なんでだろう？

**デフォルトの名無しさん** · 2021/04/24(土) 15:54:20.61

>>637
それは、本当に native の C++？
もしかして、C#のC++/CLI とか？

**デフォルトの名無しさん** · 2021/04/24(土) 16:03:17.28

コンパイラはほんと何してるのか分からんから、問題の部分だけ切り出したのを.sへ吐かせて読みなさい
10行程度のcコードなら、edxとか変な名前のは取り敢えず変数だなって思って追えば、アセンブリ知らずとも大体分かるよ

**デフォルトの名無しさん** · 2021/04/24(土) 20:39:49.92

>>635
いや、
C++ライブラリ内にマネージクラスを作って
マネージのC++プロジェクトから
呼び出したいだけ
DLLだったら、C#のDLLからマネージクラスを呼び出すのと
理屈上同じだからできそうな気がするのだけれど

以前実装した時はInterfaceだけ公開して
呼び出されるとそのインスタンスを返す、みたいなことをしたんだけれど

**デフォルトの名無しさん** · 2021/04/24(土) 21:31:19.65

>>640
.NETはstatic libraryをサポートしていない
出来上がった.libにはそのマネージドクラスのメタデータとか入ってないんじゃない？

**デフォルトの名無しさん** · 2021/04/25(日) 00:05:51.07

>>641
結局そういうことだよね
なんか普通にlibのクラスを呼び出せますみたいなのをサンプル付きで出してた記事があってさ…。

まあstaticメソッドしかないクラスばかりだから、アンマネージクラスで公開するか、namespaceでまとめます。
ありがとうございました。

**636** · 2021/04/25(日) 00:07:18.69

>>638
C++とWin32APIのプログラムです
>>639
これは自分へのレスですか？

特に遅くなる以外は止まったりする事もないので
困ることはないですがなんか気持ち悪い…

**デフォルトの名無しさん** · 2021/04/25(日) 03:40:15.50

>>643
外部データの読み込みは、fopen, _open, CreateFile、CFile のどの系統を使
ってる？

**デフォルトの名無しさん** · 2021/04/25(日) 03:43:25.25

>>643
関係ないかもしれないが、HDDが寿命で故障寸前の時にHDDの読み込みが
時々極端に遅くなったりする現象を経験したことがある。
その場合は、そのプログラム以外でも同様の現象が起きるが。

**デフォルトの名無しさん** · 2021/04/25(日) 03:49:56.55

>>645
もし、他のアプリやファイルマネージャーも遅くなることがあるなら、
CrystalDiskInfoなどで診断してみて欲しい。
そのアプリだけ遅くなるが、アプリの動作は正常、というなら、
メモリーやスレッドやOSリソースの使いすぎなども考えられなくは無いが。
何か極端に変わったことしてたりしない？

**デフォルトの名無しさん** · 2021/04/25(日) 09:07:00.47

OutPutDegugなんちゃらの関数がファイル出力してるなら、単純にそのドライブのアクセス準備が整ってないとか。

以前、SSDに同じファイル名で一時ファイルの作成と削除を繰り返したら、SSDの仕組み上めっちゃ遅くなったことがある。

**デフォルトの名無しさん** · 2021/04/25(日) 09:59:46.07

>>642
どこの記事？
ちょっと気になった

**636** · 2021/04/25(日) 10:38:16.68

>>645-647
遅くなる原因の個所が分かった！
画像を読み込む時にメモリを操作して
16bitで読み込む部分があるんだけど
これを32bitで読み込むようにすると
どんなコードでもまったく遅くならない。
メモリの操作の部分がおかしかったみたい。
自分で書いたコードじゃないのでよくわからない。
32bitのやつと16bitのやつを載せるのでおかしい所あったら教えて。

**636** · 2021/04/25(日) 10:39:18.00

これは遅くならないコード
int X = 0;
for(int y = ImageHeight - 1; y >= 0; --y){
X = 0;
for(int x = 0; x < ImageWidth; ++x){
pPx[X] = ((DWORD*)pSrcBuf)[x + (y * ImageWidth)];
++X;
}
pPx += Pitch;
}

**636** · 2021/04/25(日) 10:42:37.48

これが遅くなる場合があるコード
WORD px, tmp;
BYTE b;
int X = 0;
for(int y = ImageHeight - 1; y >= 0; --y){
X = 0;
for(int x = 0; x < ImageWidth; ++x){
px = 0x00000000;
pPx[X] = px;

b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0xff000000) >> 24); //A
tmp = 15 * (b / 255.f);
px |= tmp << 12;

b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x00ff0000) >> 16); //R
tmp = 15 * (b / 255.f);
px |= tmp << 8;

b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x0000ff00) >> 8); //G
tmp = 15 * (b / 255.f);
px |= tmp << 4;

b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x000000ff)); //B
tmp = 15 * (b / 255.f);
px |= tmp;

pPx[X] = px;

++X;
}
pPx += Pitch;
}

**636** · 2021/04/25(日) 10:46:22.20

pPxは、32bitの時はDWORD*で、16bitの時はWORD*になってた。
全て載せると長くなるので変更すると速度が変わる部分だけ載せたよ。
16bitの方でも>>636のダミーを入れれば遅くならないんだよね。
やっぱメモリが壊れてるのかな？

**デフォルトの名無しさん** · 2021/04/25(日) 11:02:40.44

>>651
pSrcBuf, pPx, Pitch の型、及び、それらを初期化しているコードが重要。
そこに問題があるとバッファオーバーランしている可能性が捨てきれない。

**デフォルトの名無しさん** · 2021/04/25(日) 11:04:39.40

>>653
「初期化しているコード」を載せる際、ImageWidth, ImageHeightとの
値の関係が分かるようにしてほしい。
要は、ちゃんとバッファの範囲内に読み書きが収まっているかどうかが知りたい。

**デフォルトの名無しさん** · 2021/04/25(日) 11:19:47.09

>>652
例えば、pPxの指しているメモリーブロックのバイトサイズが、
Pitch * ImageHeight * (pPx の 1 要素当りのバイト数)
以上に、pSrcBufの指しているメモリーブロックのバイトサイズが、
ImageWidth * ImageHeight * 4
以上になっていることが重要。

**デフォルトの名無しさん** · 2021/04/25(日) 11:46:51.84

そういえば、pSrcBufを((DWORD *)pSrcBuf)のようにキャストしてから使っている
ことも気になる。
pSrcBuf = new DWORD [ImageWidth * ImageHeight]
ではなく、
pSrcBuf = new BYTE [ImageWidth * ImageHeight * 4]
などとしているのだろうか。

**636** · 2021/04/25(日) 12:16:02.68

>>653-656
void *pSrcBuf;
LONG Pitch;
pPxは、16bitの時がWORD*で32bitの時がDWORD*
という感じになってた。

初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
でも思うのは初期化は、16bitと32bit大体同じで違うのはpPxの型くらいで
それで>>650の32bitのコードだと全然遅くならないから
>>651の16bitのコードの部分自体が何か変だったのかなと思ったんだけど
ここ自体は大丈夫なのかな？

**デフォルトの名無しさん** · 2021/04/25(日) 13:26:15.86

そもそも遅くなるって何分が何分になるん？
100分が103分ならそんなもんじゃね？
としか思えないし

**デフォルトの名無しさん** · 2021/04/25(日) 13:48:46.76

>>658
それが30秒が2分とか3分とかになっちゃって。

**デフォルトの名無しさん** · 2021/04/25(日) 14:01:13.96

>>659
それだとせいぜい6倍くらいだね。
>>650 と >>651 だと 6倍くらいの差が出るのは当然だよ。

**デフォルトの名無しさん** · 2021/04/25(日) 14:37:31.77

>>660
いやそうじゃなくて、>>636のダミーコードを入れると
何故か速い速度になって、それを取り除くと遅くなってしまう感じ。
普通にコード書いてても関係ない部分を追加したりすると遅くなったり
速くなったりするからおかしいなと思ってて。

**デフォルトの名無しさん** · 2021/04/25(日) 14:41:04.92

>>661
なるほど。では、
>初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
であったとしても、原因を特定するには、少なくともまずそこを丹念に
調べる必要がある。

**デフォルトの名無しさん** · 2021/04/25(日) 14:41:34.25

>>661
とりあえず遅いコードと速いコードを晒してよ
バッファーオーバーランで制御変数壊してるとかあるかも知れんし

**デフォルトの名無しさん** · 2021/04/25(日) 14:45:29.68

>>661
そういえば、速い時でも30秒もかかっていることはとても気になる。
>>650 のコードだとどれくらいの時間になるの？
経験と勘で言えば、そのような平易なコードで30秒も掛かって、
時と場合により3分もかかるという現象が起きる場合、キャッシュ
が乱れている可能性がある。
もしかして、どこかで極端にメモリーをランダムアクセスしてない？
巨大なメモリーの中を、極端に不連続な場所をあっちこっちアクセスすると
キャッシュが聞きにくくなって、急激に遅くなることがある。

**デフォルトの名無しさん** · 2021/04/25(日) 14:57:01.28

>>662
確かにそこは念入りに調べる必要がありますね。
>>663
それが本当に>>636をまったく関係ない部分に入れるだけで
速くなったりしてて。普通にコード書いてまったく関係ないところ追加したりすると
速くなったり遅くなったりするんだよね。一旦速くなったら弄らない限り遅くなる事はなくて
逆に一旦遅くなったら弄らない限り速くなったりする事はない感じ。
>>664
読み込んでメモリ操作する部分自体はかなり多い数をやってるので
20～30秒くらいかかる時もある感じ。
読み込みとメモリ操作の部分で細かくメモリ確保と解放をやってるので
それのせいもあるのかな？

**デフォルトの名無しさん** · 2021/04/25(日) 15:04:55.13

>>665
>読み込んでメモリ操作する部分自体はかなり多い数をやってるので
>20～30秒くらいかかる時もある感じ。
話を総合すると、
>>650 のコードが、「20～30秒くらいかかる」が、
>>651 のコードが、速い時には「30秒」
ということになるが、コードを見る限り、651のコードは650の
コードの10倍以上かかっても不思議ではないコードになっているので、
この速度差はむしろ、少な過ぎる。
むしろ、>>651のコードは「3分」かかっている方が、
長年の経験と勘では正常に思える。

**デフォルトの名無しさん** · 2021/04/25(日) 15:13:30.56

読込とか細かいメモリー確保とかコードに無いこと言われてもエスパーじゃないのでどうしょうもないな
悪いけど情報出せないなら他でやってくれ

**デフォルトの名無しさん** · 2021/04/25(日) 15:19:48.04

>>666
今チェックしたら650の方が少し速かったですｗ
650が12秒くらいで、651が22秒くらいでした
これが速い場合で、651が遅い場合は2分くらいでした。
650は遅くなることがないです。

>>667
ほんとうにそうですね。
とりあえず晒した所が大丈夫なら
他の部分は自分で調べてみようと思います。

**デフォルトの名無しさん** · 2021/04/25(日) 15:45:51.96

>>668
>今チェックしたら650の方が少し速かったですｗ
>650が12秒くらいで、651が22秒くらいでした
>これが速い場合で、651が遅い場合は2分くらいでした。
>650は遅くなることがないです。

これだけでも重要なことが分かる。以後は、処理時間に関する(数学的な)定量的な話になる。
まず、650と651の速度差が1.8倍程度しかないことからすると、
pSrcBuf と pPx の読み書きに相当時間が掛かっていることを示唆している。
650と651のソースを比較した時、計算部分の処理がとても増加しているが、
読み書きはキャッシュまで考慮すると、650と651で差が出ない。
651では、pSrcBufからは何度も読み込まれているが、最初に一回読み込まれた後はキャッシュに乗っているため、
複数回読んだからといって時間増大の原因にはなりにくい。
651では割り算や掛け算の計算量が物凄く増えているのにそれが比率にして 0.8 にしかなっていない。
(割り算や掛け算は本質的に遅いことはこの議論に置いて重要である。)
大量の割り算、掛け算に掛かっている時間が 0.8しかないのに、高々1回ずつのメモリーへの読み書きが 1.0 の時間
かかっていることに着目すると、1ピクセルあたり、データバス-CPU間の転送の観点で言って、
pSrcBufからの「一回の」読み込みとpPxへの一回の書き込みに、かなり時間が掛かっていることを意味する。
データがキャッシュに乗っていれば、ここまでの時間が掛からないので、
長年の経験と勘によれば、このような事態が起きたとき、CPUの中のすべてのキャッシュを一掃してしまっていることが多い。
だから、例えば、バックグラウンドで他のアプリが動いていたりすると、キャッシュを
復活させるために物凄く時間が掛かることがある。
それで、他のアプリがメモリーを復活させようとしたかしていないかによって、
OS全体としての処理時間が如実に変わる現象が起きることがある。
これが、今回の奇妙な現象が起きている原因かも知れない。

**デフォルトの名無しさん** · 2021/04/25(日) 16:25:58.61

>>669
細かい分析ありがとう。
だとしたら>>636のダミーを入れると速くなるのも
そのキャッシュの原因に何か関係してるのかな？
でも今まで>>665でも書いたように一旦遅くなったら
遅くなったままで、速くなったら速くなったままなんだよね… コード弄らない限り。
もしかすると何か条件が重なればコードを弄らなくても遅くなったり
速くなったりすることもあるのかもしれないけど。今のところは確認出来てない感じ。

**デフォルトの名無しさん** · 2021/04/25(日) 16:32:43.41

>>670
それより、650のコードで12秒も掛かっていることにかなり違和感を覚える。
ImageWidth が、ImageHeight が 2000 位までなら、4*10^6 ピクセルくらいで、
32BIT RGBカラーだとしても16MB位。
いまのCPUだと、>>650のコードくらいで12秒も掛かるはずは無い。
大雑多な予測だと、3.0GHzのCPUで、10(ms)くらいまでのはず。
ImageWidth や ImageHeight の値はいくらくらいになってる？

**デフォルトの名無しさん** · 2021/04/25(日) 17:04:17.68

650は最適化で X も x も同じ値で遷移していくし内側のループは
memcpy 相当のブロック転送におきかわりそうだけど

**デフォルトの名無しさん** · 2021/04/25(日) 20:18:48.31

650使えば遅くならないならいったん解決？

**デフォルトの名無しさん** · 2021/04/26(月) 01:18:20.13

>>671
大きな画像(2048*2048)とかを結構読み込んでて。
読み込み処理自体は他の部分もあるのでそのくらいになってしまってる感じ。
>>672-673
一応は650にすれば何の異常もなくとても速く動作はするんだけど
出来れば原因が知りたいと思ってて。難しいならもうあきらめるけど。

**デフォルトの名無しさん** · 2021/04/26(月) 01:51:09.48

>>674
ファイルから読み込んでるらしいけど、fseek をループの中で多数回使うと
使わない場合と比べて劇的に遅くなるけど、seek 系の関数は使ってない？