C++相談室 part144

**デフォルトの名無しさん** · 2019/07/22(月) 13:18:35.52

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part143
https://mevius.5ch.net/test/read.cgi/tech/1560574313/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/08/04(日) 09:37:37.80

>>327
正確にはそれをリカバーする人だがな。
バカはリカバーされて成り立ってることすら理解せず同じことを繰り返す。

**デフォルトの名無しさん** · 2019/08/04(日) 18:06:02.62

min(), max() マクロのような件は別として、標準的なライブラリであるところの
std::系の名前は、using namespace std; してもそんなに問題ないということは
無いんですか？？？

他のライブラリの名前空間 XXX も同時に using namespace XXX;　した場合に
もし衝突が起きる場合は、using namespace XXX; だけはしないようにすれば、
特に問題ないような気がします。実際やってみたことが無いので経験者の意見を
聞いてみたいです。

**デフォルトの名無しさん** · 2019/08/04(日) 18:48:22.76

個人の趣味プログラミングならご自由に
仕事ならコーディング規約にあわせる
コーディング規約作る立場なら、チームにバカが混ざってる前提で非属人的になるようにルールを設ける
で経験を積めば積むほど自分がバカであることが身にしみてわかる
そういうことだよ

**デフォルトの名無しさん** · 2019/08/04(日) 18:54:59.65

>>331
別に衝突しなくても問題は起こる。
using namespace stdで書いたコードをヘッダーのインライン関数に持って行く必要が出た場合とか、

using namespace std；
#inlucde "...."

となってしまっていてたまたま動いていたコードを、別の箇所でincludeしたときにエラーがでまくるとか。

**デフォルトの名無しさん** · 2019/08/04(日) 19:00:40.18

>>333
ほとんど言いがかりレベルw

**デフォルトの名無しさん** · 2019/08/04(日) 19:02:23.99

std::くらい書けで終わる話をいつまで続けるつもりだ

**デフォルトの名無しさん** · 2019/08/04(日) 19:04:24.66

>>335
10万行とかのソースでそれをやりますか？

**デフォルトの名無しさん** · 2019/08/04(日) 19:06:21.58

>>336
ところどころについてたり、ついてなかったりするくらいなら、最初からstd::つける方がはるかにマシ。

**デフォルトの名無しさん** · 2019/08/04(日) 19:06:25.70

やるよ

**デフォルトの名無しさん** · 2019/08/04(日) 19:09:16.58

普通頻繁に使うライブラリをusingするだけで、名前空間ごとはやらんだろ
chrono使う時はたまにやるけど

**デフォルトの名無しさん** · 2019/08/04(日) 20:26:05.66

ていうかstd::程度を書くのが面倒な人はC++向いてない

**デフォルトの名無しさん** · 2019/08/04(日) 20:49:37.11

size_tにだけ頑なにstd付けない人いるんですがなにか理由あるんですか

**デフォルトの名無しさん** · 2019/08/04(日) 20:52:21.46

>>336
１ファイルが10万行じゃないだろ（１ファイルならそこから直せw）

**デフォルトの名無しさん** · 2019/08/04(日) 20:54:10.96

>>341
size_t は大昔からあるのと明らかに型名っぽい名前なのでわざわざバッティングさせる奴もいないからじゃね？

**デフォルトの名無しさん** · 2019/08/04(日) 21:52:28.11

>>341
size_tはC言語時代から存在してるから、もともとnamespace関係なく使える

**デフォルトの名無しさん** · 2019/08/05(月) 00:32:36.26

むしろstdにsize_tあったんだくらいの認識

**デフォルトの名無しさん** · 2019/08/05(月) 02:02:36.01

おれも知らんかったなまぁ言われてみればたしかにそうだなsize_tってネィムスペィス上でも定義されてたのか今度から一貫性のためにstd::つけとこうかな
まぁ、editorのちょい設定いじるだけなんだがな(´・ω・｀)

**デフォルトの名無しさん** · 2019/08/05(月) 12:35:07.05

>>340
そうでもない。

**デフォルトの名無しさん** · 2019/08/05(月) 14:11:04.57

>>342
1ファイルの行数は関係有りません。
要は大きなプログラムを書いているとき、string で済むところを
全ての箇所で std::string と書くのかということです。
void func(std::string &somename, int a, int b) {
std::string aaa;
aaa = somename + "abc";
}
struct Txxx {
　std::string　name1;
　std::string　name2;
　・・・・
};
↑のようにタイピングするのは余り賢いやり方だとは思えません。

**デフォルトの名無しさん** · 2019/08/05(月) 14:19:44.18

そんなに面倒ならusing S = std::stringでもすればいいじゃん

**デフォルトの名無しさん** · 2019/08/05(月) 14:24:57.77

過度に賢く振る舞おうとして滑ってるパターン
それくらい普通に書けばいいじゃん

**デフォルトの名無しさん** · 2019/08/05(月) 14:27:04.00

こういう奴って馬鹿丁寧に一文字ずつ全部打ってんのかね
補完って機能の概念がない世界に住んでんのかしら

**デフォルトの名無しさん** · 2019/08/05(月) 14:51:04.49

>>348ってジョルノっぽいよな

**デフォルトの名無しさん** · 2019/08/05(月) 20:01:38.61

>>348
> 1ファイルの行数は関係有りません。
> 要は大きなプログラムを書いているとき、string で済むところを
> 全ての箇所で std::string と書くのかということです。
俺は書く。

> ↑のようにタイピングするのは余り賢いやり方だとは思えません。
お前の感想はどうでもいい

**デフォルトの名無しさん** · 2019/08/05(月) 22:09:13.72

>>348
高々数文字のタイピングに拘って名前空間のメリットが理解できないという主張を繰り返すお前さんの行動は、余り賢いやり方とは思えません。

**デフォルトの名無しさん** · 2019/08/05(月) 22:10:29.33

>>348
だから何のために名前空間があるのかググれよ
別に好きにやればいいけどお前がいつもstd名前空間取り込んで便利だと思ってるのは
標準ライブラリしか使ってないからだ

**デフォルトの名無しさん** · 2019/08/05(月) 22:17:59.20

無駄だと思うならtypedefやusingすりゃいいじゃないか
そもそもstringって名前長すぎだろ

**デフォルトの名無しさん** · 2019/08/05(月) 22:26:34.39

usingである程度の広さのスコープでやるんが正解だろ。
まあこのある程度の広さってのが人によってだいぶ違うだろうが。

**デフォルトの名無しさん** · 2019/08/05(月) 22:37:46.60

少なくともstdは普通using namespaceしないよね
でかすぎる
最近良くやるのは
namespace fs=std::filesystem;
だな

まあこれもヘッダで使うなら独自namespaceに入れてからだが

**デフォルトの名無しさん** · 2019/08/05(月) 23:33:53.82

using namespace std;をグローバルなスコープでやってしまうと
ソースコードを他に持って行ったとき困る
fooをstd::fooに変換するのはfooの種類が100台になると並みのエディタの置換機能では手間的にアウト
一方std::をとるのなら簡単にできる
std::をつけるのは将来への投資といえる

**デフォルトの名無しさん** · 2019/08/07(水) 02:10:18.89

初心者除ける、上級勘違い中級者こそ、出て行ってくれないかな。
本当の上級者は、プログラミング初めての人でも、優しくあたってくれますよ。

**デフォルトの名無しさん** · 2019/08/07(水) 02:48:46.85

>>360=>>348？

**360** · 2019/08/07(水) 03:17:50.31

>>360 = not(>>348)
ですが。
証明方法は無いですから、わかりませんけどね。

**360** · 2019/08/07(水) 03:53:56.72

>>342
各1万行30ファイルは、セーフですか？

**デフォルトの名無しさん** · 2019/08/07(水) 08:04:40.03

入れ子となったクラスの内側のクラスから外側のクラスのprivateメンバにアクセスできるという
内側のクラスの特権はJavaやC#と同じくC++にもあるから、これを使って大規模なStateパターンでも書いた日には
ソースコードの行数も大規模にならざるおえない
このとき上記3言語の中で唯一大規模にならずに済むのはクラスの分割定義が可能なC#だけ

**デフォルトの名無しさん** · 2019/08/07(水) 09:17:55.92

まず日本語を勉強しましょう

**デフォルトの名無しさん** · 2019/08/07(水) 09:31:41.35

昨今のプログラミング用語における入れ子は界隈に限らず日常的に使われているが
プログラミング業界では特に再帰的構造を指す場合にも多く使われる

そこに非常に現代的な特殊用語たる「出し子」が加わると
一般人は入れ子と出し子が対になっていると思い込む

**デフォルトの名無しさん** · 2019/08/07(水) 09:45:33.66

入れ子の内側のクラスは別ファイルに定義できる

**デフォルトの名無しさん** · 2019/08/07(水) 09:55:09.68

好きなだけわけてincludeすればいいじやん

**デフォルトの名無しさん** · 2019/08/07(水) 23:36:21.14

スコープにあった変数名の長さにするべきとかそういうのお前らは習ってねーの？

**デフォルトの名無しさん** · 2019/08/07(水) 23:50:58.34

そういう感覚的なルールいらない
チェックできないルールはなくていい

**デフォルトの名無しさん** · 2019/08/08(木) 00:01:50.09

>>370
感覚的な部分を必要とすべきでないなら全てアセンブラで書けばか。

**デフォルトの名無しさん** · 2019/08/08(木) 03:03:18.83

>>370
チェック出来るルールに完璧に沿って書けてるボクちゃん偉い！エッヘン！
ってこと？
ユーザーからしたらクソの役にも立たねーよそれ

**デフォルトの名無しさん** · 2019/08/08(木) 03:51:27.57

errnoに謝罪しる

**デフォルトの名無しさん** · 2019/08/08(木) 05:46:38.89

>>367
1行で2クラス以上定義しないという原則を守る限り、30億状態あったら外側のクラスはどうがんばっても30億行未満では書けない
この場合でも30億行未満で書けるのは分割定義できる言語だけ
また、内側のクラスを使わない普通のStateパターンなら30億ファイルに分割してかけばだいたいおk
（1状態から遷移し得る状態の数による。30億状態のどれにでも遷移しえる状態、
　みたいな極端なやつはさすがに遷移先状態クラスの#includeで30億行になるが

>>368
おk

**デフォルトの名無しさん** · 2019/08/08(木) 06:53:52.07

頭悪そう

**デフォルトの名無しさん** · 2019/08/08(木) 10:31:27.94

それは設計の問題でしょ
30億通りのstateパターンで設計する方が悪い
言語の問題じゃあないな
あり得ないヘンな例を持ち出してdisる詐欺師の方法だ

**デフォルトの名無しさん** · 2019/08/08(木) 21:15:10.76

>>359
ファイル単位でそのまま使えや
コピペして改変部分があるとか当たり前のこと言うなよwwww

**デフォルトの名無しさん** · 2019/08/08(木) 22:58:59.35

コンパイル時に発覚する程度のエラーなら許容範囲でしょ。

**デフォルトの名無しさん** · 2019/08/09(金) 00:11:55.59

c++で想定外の場合にエラーメッセージとその行数を出して終了させたいのですが、
どのようにしたらできますか？
下記のようにしてもexitした行数が出ません。。

::fprintf(stderr, "error.\n");
exit 1;

perlのdie()のようなものをイメージしています。

**デフォルトの名無しさん** · 2019/08/09(金) 00:39:22.71

::fprintf(stderr, "error. (line: \d)\n", __LINE__);
とか

**デフォルトの名無しさん** · 2019/08/09(金) 22:56:01.92

丁寧にエラーメッセージ出すよりデバッガでバックトレースかけた方が早かったりするのは内緒

**デフォルトの名無しさん** · 2019/08/09(金) 23:44:34.34

右辺値参照ってconst参照という認識でOKですか？

**デフォルトの名無しさん** · 2019/08/10(土) 01:07:05.35

>>382
moveで中身を奪い取るからconstじゃだめよ。

**デフォルトの名無しさん** · 2019/08/10(土) 06:27:08.55

>>381
そりゃデバッガ使える状況ならその方が速いことは誰でも知ってるだろw

**379** · 2019/08/10(土) 09:48:42.90

>>380
その方法で目的の動作ができました。
行の最後にexit入れたら一行でかけて良さげな感じです。
ありがとうございました。
::fprintf(stderr, "error. (line: \d)\n", __LINE__); exit(0)

>>381,384
バックトレースというものを知らなかったのでググりました。
色々なものがあるようですが、gdbの下記程度の使い方なら自分でもできそうなので
これをちょっとづつ使ってみようと思います。

ttps://rat.cis.k.hosei.ac.jp/article/devel/debugongccgdb1.html

**デフォルトの名無しさん** · 2019/08/10(土) 15:57:01.40

ｸﾞｸﾞってもなかなか出てこないが__LINE__はlong型だったと思った！

**デフォルトの名無しさん** · 2019/08/10(土) 16:00:35.87

>>386
intじゃないの？
まあクロスの場合開発環境側のintな気もするが

**デフォルトの名無しさん** · 2019/08/10(土) 16:25:20.56

intでダメなファイルとかそもそもコンパイルできねーだろ。

**デフォルトの名無しさん** · 2019/08/10(土) 16:36:59.44

2GBの¥nの後にソースかいてみるとわかるかなw

**デフォルトの名無しさん** · 2019/08/10(土) 16:48:09.53

>>387
> まあクロスの場合開発環境側のintな気もするが
そんなアホなw

**デフォルトの名無しさん** · 2019/08/10(土) 16:57:47.58

いや、多分そこまで考えてないから、コンパイラ上ではintもしくはsize_tで
マクロ展開時は文字列化して接尾の型指定とかつけないだろ

勝手につけられると逆に困るし

**デフォルトの名無しさん** · 2019/08/10(土) 17:01:16.99

int型はターゲットアーキテクチャーで一番自然な型というのが本来の意味なのでソースコードの最大行数と関係する理由が無い
C++の最新規格ではどうなったかわからんが、longは規格上32 bit固定なのに対してintは16 bitのアーキテクチャーが有り得るはず

**デフォルトの名無しさん** · 2019/08/10(土) 17:02:52.50

32bit固定？

**デフォルトの名無しさん** · 2019/08/10(土) 17:06:31.95

longが32bit固定なシステムは64bitでは異端じゃね
まあwindowsはLLP64っぽいが

**デフォルトの名無しさん** · 2019/08/10(土) 19:05:34.69

バイナリファイルを一度に読み込もうとしています。
圧縮ありファイルと圧縮なしファイルを以下のように判定して読み込もうとしているのですが、
ファイルの全てを読み込む方法がわかりません。
①②はどのようにしたら良いですか？

http://codepad.org/FwYwQ62R

**デフォルトの名無しさん** · 2019/08/10(土) 19:14:37.23

std::
これ自体は大した量ではないとは思うけど
これが何百何千と書かないといけないなら省略できる方法は必要だと思う
省略して且つ安全で簡単な方法が無いのが問題なんだと思う

ここまで読んででusing宣言を書き連ねたファイルを用意して
関数定義の次の行で#includeするのが今の所一番良い様な気がした

const何かも余りに書きすぎるので
これも何らかの形で省略できる記法を搭載できないのだろうかとは思ってる
classのpublic:
みたいに
const:
とかするとその後は記載しなくてもconst宣言になる
みたいな方法を搭載したりはしないのか?
と何時も疑問に思う

**蟻人間** ◆T6xkBnTXz7B0 · 2019/08/10(土) 19:18:00.44

>>395
malloc

**デフォルトの名無しさん** · 2019/08/10(土) 19:26:04.25

>>396
constこそusing書き連ねたファイル用意してincludeすればいいのでは

using cchar = const char;
using cuchar = const unsigned char;
using cint = const int;
using cuint = const unsigned int;

**デフォルトの名無しさん** · 2019/08/10(土) 20:32:30.45

>>396
その疑問の答えは、あなたが具体的な提案を標準化委員会に持っていかない理由の答えと同じでしょう。

**デフォルトの名無しさん** · 2019/08/10(土) 20:36:22.66

constじゃないのにmut書かされる方が面倒

**デフォルトの名無しさん** · 2019/08/10(土) 20:51:51.67

c++20のimportで解決するだろうか。

**デフォルトの名無しさん** · 2019/08/11(日) 00:40:56.64

>>397
ありがとうございます。
とりあえず圧縮なしの方は以下で取得できたようです。
ここで一点疑問です。
mallocの値がぴったり正しいかの確認をしようと、下記5行目のdatasize+1を-2や-3にしたのですが、
printf()で最後まで値が正常に出てきます。
datasize-3としてもたまたま連続して拾っているだけなので問題ありだと思うのですが、
malloc(datasize)ではなく、malloc(datasize+1)でぴったりメモリ確保ができているのでしょうか？

unsigned char* data;
long datasize;
fseek(fp, 0, SEEK_END);
datasize = ftell(fp);
data = (unsigned char*)malloc(datasize+1); // +1を-2, -3にしてもprintf()では最後まで正常な値が出てくる。
if( data == NULL ){
exit(1);
}
fseek(fp, 0, SEEK_SET);
fread(data, 1, datasize, fp);
fclose(fp);
for(int i=0; i < datasize; i++){
printf("%02x\n", data[i]);
}

**蟻人間** ◆T6xkBnTXz7B0 · 2019/08/11(日) 00:49:51.23

割り当てされてない領域に書き込むというのは、C/C++ではあり得る。
そこに他に意味のあるデータがあれば、そのデータは壊れる(データ破壊)。

**デフォルトの名無しさん** · 2019/08/11(日) 07:16:49.27

>>402
処理系によるけど大抵の処理系では指定されたサイズをきっちり確保とかはしなくて16バイト単位くらいで確保する
なのでそのdatasizeの値によっては-15とかしても大丈夫な場合すらあることがある
もちろん動作は保証されない

**デフォルトの名無しさん** · 2019/08/11(日) 08:16:38.18

> malloc(datasize)ではなく、malloc(datasize+1)でぴったりメモリ確保ができているのでしょうか？
malloc(datasize)で十分、malloc(datasize+1)だと1つ余分
freadでもprintfでもdatasize個までしかアクセスしていないので

**デフォルトの名無しさん** · 2019/08/11(日) 09:14:50.61

とりあえずvalgrindかけてみるのが良い。

**デフォルトの名無しさん** · 2019/08/11(日) 10:12:56.60

昔みたいにメモリ枯渇なんてそうないし誰かがデータ破壊やらかして休みに呼び出し食らいたくないので16バイトくらい余計に確保しとこ

**デフォルトの名無しさん** · 2019/08/11(日) 10:13:58.51

なんでビット単位で確保できないんですか？

**デフォルトの名無しさん** · 2019/08/11(日) 10:36:40.97

面倒だし遅いし...

**デフォルトの名無しさん** · 2019/08/11(日) 10:41:05.01

CPUがそう出来てないから

**395** · 2019/08/11(日) 11:36:18.32

>>404
malloc()は数を指定していて、for分でアクセスしているdataは配列だから最後はdatasize-1ということですね。
僕の理解と合いました。
malloc(datasize)とします。
ありがとうございます。

次にgzipの全読み込みも調べています。
とりあえず下記でout.dbと展開後のaaa.dbのcksum値が一致したのでちゃんと読み込めたと思います。
※1のところで配列に格納すれば良いと思うのですが、最初は配列の数が確定していないので
配列数を決定することができません。
読み込むファイルサイズはギガバイトクラスの大きなファイルなので、なるべく速度を維持したまま
一つの配列に格納したいのですが、どうすれば良いですか？

FILE *wfp;
gzFile rzp;
unsigned char buf[8192*1000] = {0};

rzp = gzopen("aaa.db.gz", "rb");
wfp = fopen("out.db", "wb");

while((cnt = gzread(rzp, buf, sizeof(buf))) > 0){
fwrite( buf, sizeof( unsigned char ), cnt, wfp );
※1 ここで全データを一つの配列に格納したい。
}

gzclose(rzp);
fclose(wfp);

**デフォルトの名無しさん** · 2019/08/11(日) 12:32:14.46

gzipって全部読まないと展開後の長さ分からないんじゃね
2パスにするとか

**デフォルトの名無しさん** · 2019/08/11(日) 17:00:08.00

qiitaでさC++のタグ検索したらcppreference.comが公式リファレンスと書かれてたけどここ公式なの？

**デフォルトの名無しさん** · 2019/08/11(日) 17:08:33.67

>>413
https://ja.cppreference.com/w/Cppreference:FAQ
このサイトの背後にいるのは誰ですか？
cppreference.com は世界中の C++ 愛好家のグループによって作成され、メンテナンスされています。

**395** · 2019/08/11(日) 18:01:46.19

>>412
コメントありがとうございます。
全部読む以外に調べる方法は無いんですね。
ということでrealloc()で拡張していくことを考えてみました。
下記で作られた解凍後のデータがgunzipで解凍したものと一致したので大丈夫そうです。
ありがとうございました。

#define MAX_BYTE 8192*1000

data = (unsigned char*)malloc(MAX_BYTE);
rzp = gzopen("aaa.db.gz", "rb");
long data_size = 0;
while((cnt = gzread(rzp, data+data_size, MAX_BYTE)) > 0){
data_size += cnt;
data_new = (unsigned char*)realloc(data, data_size+MAX_BYTE);
if( data_new == NULL ){
free(data);
::fprintf(stderr, "拡張失敗\n");
exit(EXIT_FAILURE);
}
// アドレスが変化した場合
if( data != data_new ){
// free(data); // 元オブジェクトは解放済みのため不要
data = data_new;
}
}
gzclose(rzp);

// 解凍後データを書き込み
wfp = fopen("out.db", "wb");
fwrite( data, sizeof( unsigned char ), data_size, wfp );
fclose(wfp);

**デフォルトの名無しさん** · 2019/08/11(日) 18:25:47.16

>>415
そんなでかい領域をreallocすると何度もコピーするはめになるから>>412の言うように2パスにするか、各領域をリストで繋いて最後に一気にコピーするようにした方がいい

**395** · 2019/08/11(日) 19:34:48.78

>>416
2パスをググってもそれらしいものがなかったのですが、どういうものなのでしょうか？
あと、「各領域をリストで繋いて」というのはvectorに追加しながら最後に連結するということでしょうか？

**デフォルトの名無しさん** · 2019/08/11(日) 19:44:47.41

>>417
> 2パスをググってもそれらしいものがなかったのですが、どういうものなのでしょうか？
１回目（Pass 1）ではデータの格納はせずにサイズだけ取得する
合計サイズ分を確保して２回目（Pass 2）で実際に格納するってこと

> あと、「各領域をリストで繋いて」というのはvectorに追加しながら最後に連結するということでしょうか？
そう言うこと
でかいデータはコピーにも時間がかかるからできるだけコピーしないようにした方がいい

**395** · 2019/08/11(日) 20:30:35.16

>>417
2パス良さそうですね。
gzread(rzp, data+data_size, MAX_BYTE)
のところを下記のようにNULLにしてもちゃんとファイルの最後まで動いているようなのですが、これがデータ格納せずにサイズを取得するということでしょうか？
gzread(rzp, NULL, MAX_BYTE)

**デフォルトの名無しさん** · 2019/08/11(日) 20:43:01.53

すみません、NULLだとそもそも一回も取得できずに終わっていました。。
データ格納せずに一回ファイル精査するのってどうするんでしょうか？

**デフォルトの名無しさん** · 2019/08/11(日) 21:37:44.09

>>420
固定長のバッファを1つ用意して、そこに上書きしながら繰り返し読み込めばいい。内容は上書きされて読めなくなるけど、読み捨てるつもりなので気にしない。

**デフォルトの名無しさん** · 2019/08/11(日) 21:42:34.43

（最終的なところに）格納しないってことな
適当なバッファを１つ用意して毎回そこに格納しとけばいい

**デフォルトの名無しさん** · 2019/08/11(日) 21:43:08.15

あっ、被ってた

**デフォルトの名無しさん** · 2019/08/11(日) 22:55:38.50

>>421,422
そういうことですか、理解できましたありがとうございます。

**デフォルトの名無しさん** · 2019/08/12(月) 00:27:35.40

vectorだって償却定時間なのに
ホントに2回読む方が速いんか？

**デフォルトの名無しさん** · 2019/08/12(月) 00:55:04.06

valgrindってみんな開発に使ってるの？死ぬほど遅いんですが

**デフォルトの名無しさん** · 2019/08/12(月) 09:13:50.21

でかい領域のreallocで毎回コピーが発生するというのは都市伝説、
と言いたいところだが他のスレッドが動いているとそうとも言い切れないかそうか、
この場合の2パス方式はgzipが2回走るのがいかにも実行時間の無駄でいやすぐる
最初に大きめの領域をmallocして足りんかったら2パスに切り替えるという投機的なやり方のが良い

**デフォルトの名無しさん** · 2019/08/12(月) 09:18:32.18

だいたいいかにgzip様といってもファイルを毎回1/10まで圧縮できるわけはないのだから
読み込むファイルサイズの10倍を確保しておけばほぼ1パスで済む
展開後の実サイズがわかったら展開後の実サイズぴったりにreallocで縮小すれば良い

ちなメモリの断片化はｶﾞﾝ無視
実使用サイズの倍のメモリも用意できないようなプアな環境のならmallocやreallocする設計から見直さねばならない
見直すべき

**デフォルトの名無しさん** · 2019/08/12(月) 10:16:31.87

>>427
意味わからん
スレッドなんて関係ないだろ

**デフォルトの名無しさん** · 2019/08/12(月) 10:19:40.97

>>429
ヒープメモリはスレッドで共有される
もしヒープメモリを使う他のスレッドが一切無いなら
realloc()でサイズ拡大してもコピーは生じない（後ろに領域伸ばせるから
この説明でまだ疑念が渦巻くのならプログラミング言語Cをきちんと読み直した砲が良い
（あのmalloc()実装例がmalloc()実装の全てとは言わんが基本