|
Chesnokov Yuriy wrote: Only after I moved them to the point where main() function starts execution (as with C style declare them all first) debugger started to see them.
Once I move them back to their original place they are invisible again!
This does not make sense, can you show the code for both instances, and where you stop in the debugger when they can or cannot be seen?
It's time for a new signature.
|
|
|
|
|
That will be hard to investigate, you need to install http://registrationcenter.intel.com/irc_nas/1749/w_ipp-samples_p_6.1.5.060.zip[^] along with IPP and Intel compiler.
The console application is face detection one. It is too big to fit and you will not be able to debug it without all those tools installed.
When you get to the variables from my question post and step over them you will not be able to see them.
Чесноков
|
|
|
|
|
Well, I guess the problem lies elsewhere within this sample code, so unless you can find someone else who has tried it out you are at an impasse. Sorry I cannot offer any other ideas.
It's time for a new signature.
|
|
|
|
|
Have you turned the optimiser off? Compilers are quite good at creating code that's equivalent to your source with a lot of the redundant stuff you've put in for readability removed.
Cheers,
Ash
|
|
|
|
|
That is debug build from IPP project. There is No Whole Program Optimization and in Linker->Optimization all fields are cleared.
Чесноков
|
|
|
|
|
As Aescleal hinted at...
You will get this sort of thing in Release. There's not those variables to display, as the code is heavily optimised. You want to check this sort of thing in Debug first.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
It is debug build. I can not see permanently only those variables but all stepping over the lines is normal.
In release even stepping in debugger is wierd.
Чесноков
|
|
|
|
|
configuration of your solution is "Debug"?
|
|
|
|
|
|
These are the debug build command lines
/I"..\..\image-codecs\ijg\include" /I"samples" /I"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\include" /Zi /nologo /W0 /WX- /Od /Oy- /D "_DEBUG" /D "WIN32" /D "_WIN32" /D "_WIN32_WINNT=0x500" /D "_WINDOWS" /D "STRICT" /D "_MBCS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CONSOLE" /Gm- /EHsc /RTC1 /MTd /Zp16 /GS /fp:precise /Zc:wchar_t /Zc:forScope /openmp- /Fp"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.pch" /Fa"_bin/Win32/Debug/Face_Detection_obj\" /Fo"_bin/Win32/Debug/Face_Detection_obj\" /Fd"_bin/Win32/Debug/Face_Detection_obj\vc100.pdb" /Gd /analyze- /errorReport:queue
/OUT:"_bin/Win32/Debug\Face_Detection.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"..\..\image-codecs\ijg\_bin\Win32\Debug" /LIBPATH:"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\stublib" "ippcc.lib" "ippi.lib" "ipps.lib" "ippcore.lib" "ippcv.lib" "ippj.lib" "ijg6b.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "uuid.lib" "comctl32.lib" "Ws2_32.lib" "winmm.lib" "wininet.lib" "vfw32.lib" "winspool.lib" "ole32.lib" "oleaut32.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.exe.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pdb" /SUBSYSTEM:CONSOLE /OPT:NOREF /PGD:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE
Чесноков
|
|
|
|
|
Having a real-time app which main processing function is invoked as much as 20-30fps performing some image processing is it better to preallocate all temporary buffers used or it does not cost to invoke allocations?
E.g. having to build pyramid of images with specific rescaling for 640x480 image might not consume much of the memory using preallocation scenario.
On the contrary for 15Mpx image the pyramid preallocation is very costly in consuming OS memory.
Is there a frequent memory allocation cost in real-time apps performance?
I remember I tested it long time before and each ::new operation took about dozen of millisecs or so while malloc() was 0 ms.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: I remember I tested it long time before and each ::new operation took about dozen of millisecs or so while malloc() was 0 ms.
new does not simply allocate memory, it will also call the object constructor.
I'd suggest using some kind of memory pool, pre-allocating your data structure and swap data in/out.
Watched code never compiles.
|
|
|
|
|
Try profiling it and see - that's the only way you're ever going to know for sure. Presumably you're talking about a soft real time application like a game rather than a hard real time app - if you're talking hard real time then I'd suggest getting a real time OS before doing anything else.
Cheers,
Ash
|
|
|
|
|
I would try and reuse those buffers, i.e. allocate the required number of them and keep using them over and over again. That is the cheapest way of them all, as it does not cost any CPU cycles, and it does not cause excessive cache trashing. It does put the responsibility in your hands though, you must make sure to use the buffers consistently.
|
|
|
|
|
Don't forget: "Early optimization is the root of all evils"... Well, I prefer to weaken this famous sentence by replacing "all" with "many", but anyway: The advice given above might pay off, but for different reason independent of using new or malloc:
If you allocate and release on free store with high frequency, (possibly in a long running application) you almost certainly run into fragmentation issues making allocations increasingly slow or impossible... As mentioned above new invokes constructors and some mechanics regarding correct behaviour in case of exceptions. You should not give this up - In our team, I do not accept c++ code which contains other free store queries than new and delete
|
|
|
|
|
"In our team, I do not accept c++ code which contains other free store queries than new and delete" ...
For a Windows application? No wonder the memory gets fragmented.
What about HeapCreate/HeapAlloc/HeapFree for larger custom data objects?
VirtualAlloc/VirtualFree for large data objects? The fastest one there - evrything else just layers on top of VirtualAlloc.
|
|
|
|
|
The Gdiplus Bitmap:Save method returns void and generates two exceptions, ArgumentNullException and ExternalException, neither of which cover the case where a save fails because, say, there is not enough space on the disc or trying to write to a read-only disc. Can anyone tell me how to detect such a failure. My program seems to silently ignore such failures. Thanks for any help.
Niklas Lindquist's suggestion of calling GetLastError solves the problem. After a little experimentation I discovered that Bitmap::Save set the last error to 0 if it succeeds so if GetlastError((0 returns a non-zero value there has been an I/O error. Thanks for the two replies.
-- Modified Tuesday, August 24, 2010 2:33 PM
|
|
|
|
|
One idea could be to check if GetLastError() changes.
(and please don't cross post[^])
|
|
|
|
|
Thanks for your reply which has helped me to solve my problem. I found that Bitmap::Save sets the last error to 0 if (it thinks) it is successful and non-zero if it fails.
Sorry about the cross-post. This is my first attempt at using the bulletin board and I thought that my first post had failed.
Thanks again for your help.
Hugh McIntyre.
|
|
|
|
|
No problem 
|
|
|
|
|
Hi,
I have a very strange problem with edit controls in Windows 7 (Ultimate), where once the number of characters exceeds a certain number, the contents become invisible. The text is still there, and can be copied, edited etc, but it is just not shown. Deleting characters makes it re-appear.
I have reproduced this in a new MFC project, using Visual Studio 2010, just by making a dialog app which has a single-line edit control on its dialog.
I have found that the exact number of characters required to make the text disappear depends on the text. For instance, filling the control with the letter 'i', it takes 16379 chars to become invisible, but for the letter 'W' it takes 3275. For '_', it takes 5459. I wondered if it was the size in pixels that caused the problem, and found (using GetTextExtent on the edit control's DC) that for the letter 'i' the width was 65516 pixels, 'W' was 45850 pixels, and for '_' was 43672 pixels, so I can't see any relationship there.
(I am building the app in Visual Studio 2010 on Vista, though that doesn't make any difference, as an old version of our app built in VS2005 behaves the same in Win7).
Does anyone have any ideas of what is going on?
Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
"A problem well defined is a problem half-solved" – John Dewey
|
|
|
|
|
Hi all,
i analyze some times in 64 bit machine Print and Print Function not responding.
when i debug the code i found in OnPreparePrinting(CPrintInfo* pInfo) function DoPreparePrinting(pInfo) return false.
one more thing i noticed here,this problem occur only when i run my application with Administrator priviledegs means by using "Run An Administrator" option.
but this problem is resolve when i restart the machine.
if i run application without using option run as admin its working fine.but its necesary for my application to run as admin
please tell me how can i resolve the problem without restarting the machine.
thanks in advance.
|
|
|
|
|
Hello all,
I'm trying to print the filename to Dbgview which i receive from GetFileInformationByHandleEx, But it's getting crashed every time..
PFILE_NAME_INFO pFileNameInfo;
DWORD dwFileNameLength = 1024;
DWORD err;
TCHAR szTemp[MAX_PATH] = "";
pFileNameInfo = (PFILE_NAME_INFO)HeapAlloc(GetProcessHeap(), 0, dwFileNameLength);
if(pFileNameInfo != NULL)
{
if(GetFileInformationByHandleEx(FileHandle, FileNameInfo, &pFileNameInfo, dwFileNameLength) != 0)
{
MessageBox(NULL, L"Before Check", L"Success", MB_OK);
OutputDebugStringW(pFileNameInfo->FileName);
}
else
{
err = GetLastError();
swprintf(szTemp, L"Get info Error = %d", err);
MessageBox(NULL, szTemp, L"Error", MB_OK);
}
HeapFree(GetProcessHeap(), 0, pFileNameInfo);
}
else
{
err = GetLastError();
swprintf(szTemp, L"Heap Error = %d", err);
MessageBox(NULL, szTemp, L"Error", MB_OK);
}
Thanks All..
|
|
|
|
|
Have you tried single stepping?
Do you end up with a filename which should be NULL terminated, but is not?
If it's crashing all the time, it sounds simple to find with a debugger! If nothing else, you'll know WHICH line is crashing.
Have you tried with a small filename?
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
You are sending the address of your memory pointer rather than the pointer itself to the GetFileInformationByHandleEx() function. The code should read:
if (GetFileInformationByHandleEx(FileHandle, FileNameInfo, pFileNameInfo, dwFileNameLength) != 0)
Note: no & (addressof operator) on pFileNameInfo.
It's time for a new signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
