|
#include iostream; //can't paste the << >> things here
#include string;
int main()
{
//works, from what i can see, because you cant compile "int someArray[] = {}" or "int arr[0];" because you cant allocate a 0-length array according to vs.net errors. So your guarenteed atleast 1 item in the array for "sizeof(_array[0])" to always find an item. this is the alternative to doing sizeof(int) or passing the type of the array to the macro.
#define ARRAY_LENGTH(_array) (sizeof(_array)/sizeof(_array[0]))
int someArray[] = {1, 2, 3, 4};
for(int i = 0; i < ARRAY_LENGTH(someArray); i++)
{
std::cout<<*(someArray + i)<
|
|
|
|
|
ARRAY_LENGTH macro is always ok for real array but not for pointer.
By the way, ARRAYSIZE() macro is predefined in windows.h of some newer sdk and it looks the same form as above. 
|
|
|
|
|
wow norish i had no idea about that macro :P when i read that sizeof returned the number of bytes used by an array, i figured if i just divided by the size of the datatype used that i could get the length.
|
|
|
|
|
If you want a type-safe mechanism for getting the number of elements in an array, you might consider this:
#include <iostream>
template<class A, size_t N>
inline size_t ArraySize(const A ( & )[N]) { return N; }
template <typename T>
struct array_info
{
};
template <typename T, size_t N>
struct array_info<T[N]>
{
typedef T type;
enum { size = N };
};
int main()
{
typedef int (MyArray)[120];
int a[120];
float b[120];
std::cout << ArraySize(a) << std::endl;
std::cout << ArraySize(b) << std::endl;
std::cout << array_info<MyArray>::size << std::endl;
}
Here you have mechanisms for getting the number of elements in an array variable (function ArraySize) or an array type (struct array_info). And (unlike the macro version) these two won't compile if given a pointer variable/type - the power of pattern matching sees to that
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
hmm vectors? i suppose. Is it possible that arrays are more efficient?
Now this part of the code is really sexy:
<br />
template<class A, size_t N><br />
inline size_t ArraySize(const A ( & )[N]) <br />
{ <br />
return N; <br />
}<br />
<br />
int main()<br />
{<br />
int a[120];<br />
<br />
std::cout << ArraySize(a) << std::endl;<br />
}<br />
i'm not sure how it works but my guess is that somehow it's magically reading the size from the declaration of the array.
|
|
|
|
|
FocusedWolf wrote: possible that arrays are more efficient
Nope - in VS2008, vectors are guaranteed to use contiguous storage (i.e. same as arrays).
FocusedWolf wrote: i'm not sure how it works but my guess is that somehow it's magically reading the size from the declaration of the array.
That's the one. You pass an array and the compiler instantiates the function with the template parameters appropriate for that array.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
Not always necessarily better - not until C++ 0x when vectors get array style initialisers (IIU&RC).
Say I have an encryption key that (foolishly) I'm hardcoding in the software - which is simpler:
[edit]Or a better example - say I'm implementing a CRC32, which can be highly optimised by using a static array of byte values[/edit]
const BYTE key[] = { 12, 34, 4, 5, 36, 23, 765, 34 };
std::vector<BYTE> vKey;
vKey.push_back(12);
: :
vKey.push_back(34);
Yes, I know Boost has a library[^] that almost gives vectors initialiser syntax...but sometimes you just can't be bothered
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
FocusedWolf wrote: #include iostream; //can't paste the << >> things here
#include string;
Why not?
#include <iostream>
#include <string> Did you use the < button above the smileys?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
Hmm:
#include <iostream>
#include <string>
O i see... if this works then the lt,gt things are auto replacing my < >. Ya didn't realize that yesterday lol
|
|
|
|
|
see the _countof macro in the Run-Time Library Reference
|
|
|
|
|
Hi
How can I disable MDI to send a "File New" message at start up? So there will be no child window to be opened.
Best regards,
|
|
|
|
|
See here.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
i am devloping an gui i want to use the costum controls(like styleish buttons) available in net but don't know how to use the code in my project ..have tried a lot but failed pls help me out..
|
|
|
|
|
Are you possibly referring to a manifest?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
Bisua wrote: costum controls(like styleish buttons)
On Halloween CodeProject sends out stylish costume controls for free! 
Anyway, you should have a look at this section:
http://www.codeproject.com/KB/buttons/[^]
|
|
|
|
|
In VS 2005, When I do CView::OnFilePrintPreview, it loads up the printPreview into the frame, not into a View frame. If I close the print Preview(using the X close button), it just closes the frame window, which I don't wanna do. I would like to keep the frame window open when I close the print Preview. It didn't work this way in V6.0, Does any one know how can I fix this?
sft
|
|
|
|
|
I'm new in Visual C++
I've made an empty DIALOG where I load a floor layout (BMP resource) and then I draw on it a dot indicating my position (dot = dot.bmp as a resource as well)
I added a ZOOM button (boolean). If user presses it image would be zoomed-in tweaking STRECHTBLT
void CDisplayDlg::OnPaint()
{
HBITMAP hBmpL1=::LoadBitmap(AfxGetResourceHandle(),
MAKEINTRESOURCE(IDB_DISPLAY_BITMAP));
CRect rc;
this->GetClientRect(&rc);
HDC hdc1 = ::GetDC(this->m_hWnd);
HDC hdcmem = ::CreateCompatibleDC(hdc1);
::SelectObject(hdcmem,hBmpL1);
if (zoom)
{
::StretchBlt(hdc1, 0,0, 364, 64, hdcmem,0,0, 620, 109,SRCCOPY);
}
else
{
::StretchBlt(hdc1, 0,0, 205, 37, hdcmem,0,0, 620, 109,SRCCOPY);
}
}
screencap: http://telefonica.net/web/episodio1/cap001.gif[^]
I dont know how to add horizontal scroll bar to my image when I zoom. If I add scrollbar to my whole dialog it doesn't do anything.
Thanks.
|
|
|
|
|
Please Help me:
I found I cannot see the result of CMemu::SetMenuItemBitmaps, after the response message WM_DRAWITEM.
I have checked the return value SetMenuItemBitmaps by GetLastError(). It is TRUE.
How should I do if I wanna see the result!
Plz help me! Thx.
modified on Tuesday, June 2, 2009 11:45 PM
|
|
|
|
|
i have a bit of C++ code that does some pretty heavy-duty image processing work. sadly, the code wasn't running as fast as i'd hoped, so, after doing all the optimizations i could think of, i decided to try multi-threading it.
i broke the job into strips, with each thread taking a horizontal strip of the image. the algorithm is the same, and 99% of the code is the same; the only difference is some bounds-checking code that the multi-threaded version skips. there is no communication between threads.
the multi-threaded version was more than twice as slow as the single-threaded version - i kept the single-threaded version of the code intact, for benchmarking.
i wrote it using VC6 (because I prefer the IDE to the VS.Net IDEs). so, i opened the project in VS05, built and ran it - hoping the VS05 compiler had some better optimization. but no, the single-threaded version ran exactly as fast as it did when built with VC6.
on the other hand, in VS05, the multi-threaded version ran twice as fast as the single-threaded version. again: the multi-threaded code went from twice as slow to twice as fast, simply by changing the compiler, but the single-threaded version didn't change at all.
these projects are all built with the multi-threaded CLR, same optimizations (controlled by pragmas in the code). the single and multi-threaded function live in the same module (same class, in fact).
so, something changed between VC6 and VS05 which affects how fast threads run.
does anybody know what that change was ?
|
|
|
|
|
Hi Chris,
I don't think the IDE is fundamentally involved in the difference of the results. IMO you either are unfortunate or made some major mistake.
Here are some possible mistakes:
- a total disregard of "locality of reference": in the ideal case all data ever gets loaded only once in the data cache(s); having two or more threads working somewhat independently may make that harder to achieve.
- too much need for synchronization;
- an overall alignment problem, e.g. when both threads need new cache loads at the same time, they both sit idle waiting for main memory to respond. At best memory accesses should be staggered somehow by design.
- cache trashing for shared data (when the same data resides in the data cache of two distinct CPU chips and gets written by one processor, it needs updating in the other cache, a very expensive operation); the extreme case is when synchronization is based on spin locks, and two or more spin lock variables reside in the same cache line. (There is an interesting Intel Application Note on keeping no more than one sync variable in a cache line, applicable to dual processor chips, not Core2Duo).
Image processing generally is quite vulnerable to all kinds of such phenomena, mainly because there is a rather high transport/calculation ratio, where data streaming can work well (making the job entirely compute bound) and can work very badly (making it bus bandwidth bound); and the difference may be minor and accidental, as well as major by a faulty approach.
I would suggest you research this case starting with a simple experiment: ignore the middle border pixels, i.e. let one thread handle the left 45% of the image, the other the rightside 45% of the image, and ignore the middle 10%. Have it run on both IDE; if you did everything right you should notice it runs about twice as fast as a single-threaded solution, and it is IDE independent. Then all you have to do is look into the way you handle the middle 10% of the image.
BTW: don't forget to observe CPU load in Task Manager for both the 1 and 2-threaded attempts.
If OTOH the two-thread solution isn't really twice as fast as the single-threaded one, forget about the middle 10% (and all sync stuff) until you got the threading right for the independent image areas.
If you were to want more specific advice, please provide detailed information on the task: system hardware, typical image size, kind of image operation (e.g. filter size, is it inherently sequential?), etc.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: gnore the middle border pixels, i.e. let one thread handle the left 45% of the image, the other the rightside 45% of the image, and ignore the middle 10%.
i think i updated my post since you started your reply.
the process here isn't the 50/50 split with the heavy inter-thread communication, which i initially described - that was a different part of the job, the one i stayed up all night fighting with. rather, the process is four totally independent threads going after different horizontal strips of an image, doing a Sobel filter (a two kernel convolution) (tried vertical strips, too - slightly slower). the only difference in code for the multi-threaded operation is that threads working on strips which don't touch the top or bottom of the image don't have to worry about bounds checking.
Luc Pattyn wrote: I don't think the IDE is fundamentally involved in the difference of the results.
it is IDE (or at least CRT) dependent.
single-threaded, VC6: 0.31 s
multi-threaded, VC6: 1.0 s
single-threaded, VS05: 0.31 s
multi-threaded, VS05: 0.14 s
VS08 results are the same as the VS05 results.
exact same code, same machine, same input and parameters, tested multiple times. the single-threaded result confirms that the difference must be in how threading is handled by the different VC versions.
|
|
|
|
|
Hi Chris,
yes I was replying to your post in VS forum, however by the time I had finished, your message was gone; I found this one here, but didn't notice it was somewhat different.
Of the four numbers you mention indeed the multi-threaded VC6 is odd, I still don't believe it is due to the IDE, compiler progress is steady but slow, I have never seen a huge gain from one version tot he next.
The single-thread results being equal suggests very similar code was generated, and the two-threaded VS05 being twice as fast tells us your multi-threading seems to work just fine.
I can't imagine they ever wasted up to 1 second in launching some threads. Maybe the runtime libraries were structured quite differently, causing other/more/larger DLL files to be loaded after you started your timing. How did you measure these times? how did you build and run?
Here are some experiment suggestions:
- enclose code in a for(i=0; i<10; i++) loop and measure 10 executions inside a single process, watching for variance due to code loading, memory allocation effects, and the like. (I always do this, I have seen too many weird things going on in a first execution)
- release build
- run outside VS
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: How did you measure these times? how did you build and run?
{
CTimer[^] t("Sobel");
Sobel(....);
}
start the test app, wait a couple of seconds for things to settle down, etc..
release build, yes. tried all the various compiler optimizations, etc..
i didn't put this one in a loop because it took long enough that i wasn't up against the resolution limit of GetTickCount. i understand the need to time multiple iterations in order to get a decent average, but i did run it dozens of times, with consistent results.
weird stuff.
anyway, i guess i'll just build the final DLL in VS05
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
