|
In your original post, you allocated an array of 1000 pointers on the stack.
float * tim_var[1000];
then, for every pointer, you allocated a memory buffer (6 float s) on the heap.
for (i=0;i<1000;i++)
{
tim_var[i] = new float[6];
}
Heap-allocated memory must be explicitely released, hence
for (i=0;i<1000;i++)
{
delete tim_var[i];
}
On the other hand, you must not release stack-allocated memory.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
My intention is to release all memories. The following code was suggested by a guru. I tried however, seems a problem. I got error message when I run the program: (delete statements got problem).
"DAMAGE after normal block (#125) at 0x00E40610"
////////////////////////////////////////////////////////////////////////////
float **tim_va;
tim_va = new float*[1000];
for (int ix = 0; ix < 1000; ix++)
{
tim_va[ix] = new float[6];
for (int jy = 0; jy < 6; y++)
tim_va[ix][jy] = 0.0;
}
for (ix = 0; ix < 1000; ix++)
delete [] tim_va[ix];
delete [] tim_va;
//////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
The code you're reporting doesn't compile. However if you modify it in order to make the compiler happy, it will run fine.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks. Would you please modify the code to make it work ?
Thanks
|
|
|
|
|
float **tim_va;
tim_va = new float*[1000];
for (int ix = 0; ix < 1000; ix++)
{
tim_va[ix] = new float[6];
for (int jy = 0; jy < 6; jy++)
tim_va[ix][jy] = 0.0;
}
for (int ix = 0; ix < 1000; ix++)
delete [] tim_va[ix];
delete [] tim_va;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi
Thanks. The code you put are the same as I reported before. I can not see any difference.
Please check. I know you have a very clear concept according to you post before.
|
|
|
|
|
mrby123 wrote: The code you put are the same as I reported before. I can not see any difference.
If you cannot see the difference, please check better.
This thread cannot last forever, I suppose: Good luck.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The code I put in this forum has a typo. In fact, it was correct typed in my test program.
So your code is the same as the I reported. It not run, but compiled.
I do not think we are clear about this topic. I think if we are not clear, it needs to find out the truth.
|
|
|
|
|
The code above compiled, but when run it, I got:
"Damage after normal block (#126) at 0X00406A0"
|
|
|
|
|
I need to parallel for loop which processes some image data.
The problem is that there is one function call in that for loop which takes as the argument some object (class, struct) whose data is used for processing.
It leads to multiple threads access problems to a single object as they process its own part of the image.
Is there a solution to solve the problem or it needs to have as many copies of the object as the number of threads to avoid multiple access?
Чесноков
|
|
|
|
|
are the threads modifying this shared object ?
if so, you will at least need to synchronize access to the object - to make sure one thread isn't reading while another thread is writing. but it's impossible for us to say if threads will all need their own copy or not, without knowing what the threads are doing to the object.
if they are just reading from the object, they can probably all share one instance.
|
|
|
|
|
For critical sections, #pragma omp single can be used as barriers.
In a parallel region, there are often sections of code where limiting access to a single thread is desired,
such as when writing to a file in the middle of a parallel region.
In many of these cases it does not matter which thread executes this code,
as long as it is just one thread. OpenMP has #pragma omp single to do this.
#pragma omp parallel
{
if(omp_get_thread_num() > 3)
{
#pragma omp single // May not be accessed by all threads
x++;
}
}
OpenMP features for multithreaded applications
http://msdn.microsoft.com/en-us/magazine/cc163717.aspx
|
|
|
|
|
I have a simple MFC application. I would like to save ths position (coordinates) of my application into the registry, so it can remember it's position the next time I launch.
When I launch, I am using SetWindowPos(x,y,cx,cy). I am also doing theApp.m_pMainWnd->GetWindowPlacement( ) when I close the app to get the coordinates and save them to registry. But when I launch back, it isn't in the same position.
Is GetWindowPlacement( ) not the right call in this case?
|
|
|
|
|
|
oops, I forgot to do (right - left) and (bottom - top) in my WindowSetPos().... this will do it.
|
|
|
|
|
How can i resize my controls when i resize my Dialogue
is there any method to achieve this automatically ....
thanks in advance
|
|
|
|
|
No, you have to do it manually. However, if you are using MFc (but it seems not the case because you specified win32), there are some articles on codeproject which provide helper classes to do so. I don't know if you'll be able to find something similar for win32.
|
|
|
|
|
thanks Cedric
No MFC wont help me. I try to find some solution for win32
|
|
|
|
|
|
In response to WM_INITDIALOG , call GetClientRect() to get the dialog's initial size.
In response to WM_GETMINMAXINFO , set the minimum size of the dialog. If nothing else, you can use the values returned from GetClientRect() , but you might also want to consider frame and caption sizes.
In response to WM_SIZE , resize each control that is affected by the dialog's new size.
It's MFC, but I show how to do this here and here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi,
I would recommend EasySize[^] by Marc Richarme[^]. I have used it in many projects over the years.
Its an absolute Meisterstück.
Best Wishes,
-David Delaune
|
|
|
|
|
Does it work with Win32 or is it MFC only ?
Watched code never compiles.
|
|
|
|
|
Well the version I am using supports both Win32 and MFC. I think I downloaded it from one of the article comments several years back. Looks like the article was geared towards MFC.
Best Wishes,
-David Delaune
|
|
|
|
|
You might want to remove the extraneous dot in those two URLs.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi DavidCrow,
Actually the trailing dot at the end of the URI is correct. It is called the root zone and is described in RFC-1034[^]. I come from a Unix backgound and have always written my URI with the DNS root zone. It is only recently within the last 2-3 years that I have noticed that certain browsers and webservers cannot handle the DNS root zone being present in the URI. I guess their 20 year old software engineers forgot to read RFC-1034.
Maybe I am just getting old. I guess the next thing that will dissapear will be the HTTP:// protocol indicator.
Best Wishes,
-David Delaune
|
|
|
|