Every time I try to increase my cell values I input in my GLM function, it turns out to be bad alloc. I would like to know if there's a way I can resolve it?
not sure what kind of answer you are expecting
the code would not just happily throw exceptions, so in order to solve it you need to analyse why do you keep reaching this situation over and over again.
It's also tricky whenever I run the code myself.
It's kind of a tradeoff.
Whenever I increase the resolution of my 3D object, for instance,
if I use, 50x50x50, then it works fine, but, if I will use 60x60x60, it suddenly stops and
gives me the bad::alloc.
On the flip side, this resolution value also changes depending on the OBJ file I am using...
std::vector<float> phi;
std::vector<float> lambda;
std::vector<float> indCoordinates;
std::vector<float> g_Cen;
std::vector<float> g_CenIndex;
// User specific parameters
const std::string fName = "fox.obj"; // OBJ file
const glm::ivec3 g_numDiv = glm::ivec3(50, 50, 50); // Number of division
constint g_numMC = 200; // Number of division for marching cubes
constfloat g_distRatio = 0.01f; // Ratio of the width of the domain
I also tried to print the max.size of my std vectors, and this is what I got:
You're not allocating anything there (other than the string fName). That's just where you declare your vectors. I assume there's some place where you're doing something like
some_vector.resize(60*60*60);
or something like that. Show the code around that.
Well, I can't see anything there. The snippets are out of context, so I can't tell the value of anything.
Do this: run your program through a debugger and let it crash. When it crashes, the debugger will highlight the point where the exception was thrown. The debugger should have a way to let you see the call stack. The call stack will look something like
where the numbers after the colon are line numbers. The debugger should let you jump to those places (e.g. if you're using a GUI, by double-clicking those lines in the call stack). In the example above, the most interesting stack frame is your_code.cpp, line 58, because in all likelihood that's the immediate source of the error.
Find that line in your source and post the code around that line.
To clarify: I don't want you to post line 58 of your code. I want you to run your code through a debugger and find which line in your code is the immediate source of the error.
Thank you very much for your detailed information, though I must admit it's pretty new and hard for me to detect the error. I would like to verify if I'm doing the right thing before I move forward to the next step...
When I try to let my program crash, here's what I got from the "call stack" (I took a screenshot of the first scenario like the ones you mentioned in "your_code.cpp: 58" to make sure I don't miss any details):
1. [Inline Frame] Tani and Gerald's Method.exe!std::_Allocate(unsigned int) Line 78
Question: Does it mean the size of vector array is too big?
Note: I also updated the resize codes I pasted above with other vectors where I used resize. Maybe it could shed some light, I am not sure... Also, I found this code from this link: https://github.com/icestudent/vc-19-changes/blob/master/xmemory0
and I was wondering if it would be helpful to use this and replace the current code in the xmemory0?
I also would like to ask if does it really matter if I use resize or not? If I remove it and just rely on the push_back, will it be a big problem?