写入超过 1GB 的 .txt 文件时的奇怪行为答案

【问题标题】：Odd behaviour when writing to a .txt file that is over 1GB写入超过 1GB 的 .txt 文件时的奇怪行为
【发布时间】：2020-05-18 13:25:35
【问题描述】：

我有一些查找素数的代码，它将数字输出到 .txt 文件中，这似乎工作正常，直到达到 1GB（我不确定确切的文件大小，但它在那）。达到 1GB 后，文件大小似乎迅速扩展，我相信这是因为整个数字块都在重复。这是我的代码：

#include "pch.h"
#include <cmath>
#include <fstream>
#include <thread>
#include <iostream>
#include <string>
#include <mutex>

int nextInt = 1;
std::ofstream file;

bool TestPrime(int number)
{
	double rootInt = sqrt(number);
	for (int i = 3; i <= rootInt; i += 2)
	{
		double divValue = (double)number / i;
		if (int(divValue) == divValue)
		{
			return false;
		}
	}
	return true;
}
int GetNextNumber()
{
	static std::mutex m;
	const std::lock_guard<std::mutex> lock(m);
	return (nextInt += 2);
}

void PrimeFinderThread()
{
	while (true)
	{
		int number = GetNextNumber();
		bool isPrime = TestPrime(number);
		if (isPrime)
		{
			std::string fileOutput = std::to_string(number) + "-";
			file << fileOutput;
		}
	}
}

int main() {
	file.open("primes.txt", std::ofstream::app);
	file << "2-";
	std::thread threads[4];
	for (int i = 0; i < 4; i++) {
		threads[i] = std::thread(PrimeFinderThread);
	}
	for (int i = 0; i < 4; i++) {
		threads[i].join();
	}
	return 0;
}

以下是 .txt 文件开头的摘录：

2-3-5-7-11-13-17-19-23-29-31-37-41-43-47-53-59-61-67-71-73-79-83-89-97-101-103-107-109-113-127-131-137-139-149-151-157-163-167-173-179-181-191-193-197-199-211-223-227-229-233-239-241-251-257-263-269-271-277-281-283-293-307-311-313-317-331-337-347-349-353-359-367-373-379-383-389-397-401-409-419-421-431-433-439-443-449-457-461-463-467-479-487-491-499-503-509-521-523-541-547-557-563-569-571-577-587-593-599-601-607-613-617-619-631-641-643-647-653-659-661-673-677-683-691-701

这是文件中间某处的摘录：

2038621267--2038621265--2038621269--2038621263--2038621259--2038621257--2038621255--2038621253--2038621261--2038621249--2038621247--2038621245--2038621367--2038621251--2038621243--2038621237--2038621239--2038621233--2038621231--2038621235--2038621241--2038621227--2038621223--2038621221--2038621219--2038621217--2038621225--2038621213--2038621215--2038621209--2038621207--2038621205--2038621211--2038621203--2038621199--2038621197--2038621229--2038621193--2038621201--2038621189--2038621187--2038621185--2038621183--2038621195

还有一些来自文件末尾的：

1812147945--1812147959--1812147941--1812147939--1812147947--1812147935--1812147933--1812147937--1812147929--1812147943--1812147925--1812147927--1812147921--1812147919--1812147917--1812147915--1812147913--1812147911--1812147923--1812147909--1812147907--1812147903--1812147901--1812147931--1812147897--1812147895--1812147893--1812147905--1812147889--1812147887--1812147885--1812147899--1812147881--1812147883--1812147891--1812147879--1812147873--1812147871--1812147875--1812147869--1812147865--1812147877--1812147867--1812147859--1812147857--1812147855--1812147853--1812147861

所以，这个文件有很多问题：

-There are two dashes sometimes.
-There are numbers at the end of the file that are smaller than the ones in the middle, which should 
 not happen. The numbers may be a bit out of order since it is running on multiple threads, but not 
 by that much.
-if we assume that ever number is 10 digits long, which would mean that they take up 11 bytes each, 
 the largest number it got to was about 2.2 billion. you can estimate the number of primes under that 
 number by using an estimate of the PI function which is π(x) ≈ (x/ln(x)), so the number of primes is 
 about 102 million, so they should take up about 1.1GB of storage. the .txt file is 3.1GB.

有时我会在一段时间后测量文件大小的地方进行测试：

10 Minutes : 760MB
20 Minutes : 3.1GB
30 Minutes : 14.6GB

我知道文件大小不是衡量速度的好方法，但值太高了，我认为这足以表明有问题。

【问题讨论】：

我看不到您在哪里检查数字溢出。有这种可能吗？
哦，这是有道理的，为什么它得到的最大数字约为 22 亿。
虽然这可能是问题所在，但有谁知道为什么会导致文件像那样快速扩展？
它得到的最大数字是 2147483579，因此几乎是有符号整数的最大大小。
我发布了一个总结答案，但实际上双破折号是因为溢出导致负数，而第二个破折号实际上是减号。它是重复序列，因为使用负数而不是稳步增加它实际上是向后跳跃，然后再向上增加。

标签： c++ file text storage large-data

【解决方案1】：

根据我对帖子的原始评论和 OP 的回复，问题似乎是数字溢出。一旦数字溢出，您将处于混乱模式。有些数字可能会溢出，而有些数字尚未溢出，还有一些可能是负数（因此是双破折号，因为第二个破折号实际上是一个减号）

【讨论】：