|
Great answer.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
SetRedraw(FALSE) is no better than ShowWindow(SW_HIDE), and there is no double effects when call both - time reduced is same as by calling ShowWindow(SW_HIDE).
I think there should be other ways for faster adding items.
|
|
|
|
|
includeh10 wrote: I think there should be other ways for faster adding items.
Yes, there is a much, much faster way. The secret? Don't add them at all. Instead, use a virtual listctrl to supply the items "on demand".
Anytime you try to add > 1000 items you will see slowdown. Adding 100,000 items will be incredibly annoying to your users.
|
|
|
|
|
It depends of course on the goal of your program, but 100,000 items seems an excessive amount; the most notable speed improvement would come from not adding so many items. If this were possible, it would also speed things up later when you're scrolling the view, selecting items, deleting selections etc.
Maybe it would be useful to add some filter functionality, this would both help the loading time and help the user find what he wants more easily.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
|
Hi All,
If a process creats a threads and then detaches that thread. Now If I kill my process then in this case will my thread run upto its completion ?
|
|
|
|
|
pandit84 wrote: If a process creats a threads and then detaches that thread.
I have no idea what this means.
pandit84 wrote: Now If I kill my process then in this case will my thread run upto its completion ?
If it is a native application, then every other thread created within the application will be killed abruptly when the main thread comes to a halt. If you want a graceful exit, you need to take care of that yourself.
For example:
UINT AdditionalThread(LPVOID p)
{
return 0;
}
int main()
{
_beginthread(AdditionalThread, 0, 0);
return 0;
}
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Rajesh R Subramanian wrote: If it is a native application, then every other thread created within the application will be killed abruptly when the main thread comes to a halt.
Technically this actually isn't the case, although from C/C++ it generally is (unless you take unusual measures). See here[^] for a more complete explaination.
Steve
|
|
|
|
|
Stephen Hewitt wrote: See here[^] for a more complete explaination.
I love it. One of the posts on that link says "Win32 is a component of the .NET system". Dang! I've been programming .NET all this time! So there, Nish.
|
|
|
|
|
There is an open secret in Redmond that .NET has build-in time travel, if you don't believe me, what do you think the "T" on .NET stands for?
|
|
|
|
|
Threads can not be detatched from the containing process. A process provides the context the threads runs in (such as the address space) and it doesn't really even make sense to consider a thread without one.
Steve
|
|
|
|
|
As others have correctly pointed out, user mode threads always runs in the context of its process and cannot be detached.
However you can create a kernel mode thread using PsCreateSystemThread[^] which does not run in any process context.
But you can only call this routine from driver code.
|
|
|
|
|
how to get the upper bound and lower bound of an array
BYTE *pByte = new BYTE[64];
Some Day I Will Prove MySelf :: GOLD
modified on Friday, February 4, 2011 8:37 AM
|
|
|
|
|
goldenrose9 wrote: BYTE *pByte = new BYTE[64];
You are allocating the array, then it is your responsibility to keep the bounds as 0 and 64. 
|
|
|
|
|
I think you mean 0 and 63.
I must get a clever new signature for 2011.
|
|
|
|
|
yes.. of course it is!! thanks for pointing about that small but BIG mistake.. 
|
|
|
|
|
My pleasure; it's your turn to catch me out next time.
I must get a clever new signature for 2011.
|
|
|
|
|
yes, 0 to 63,
but i was in search of a function that returns the bound of an array,
as in vb UBound() and LBound() function is used. Is there any similer function that helps to acheive bounds in c++
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
Nope.
Otherwise you have to go for STL container classes in C++, collection classes in MFC, or your own array class to achieve this.
|
|
|
|
|
thanx.
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
pByte as you declared is just a pointer. You are putting the semantics of an array into it by assigning the memory for it. But the compiler has no way of knowing what, exactly this pointer is pointing to at any time.
In other words, no, the compiler cannot know what the semantics of the memory is that any pointer is pointing to, nor can any function.
That said, the above is not entirely true: when you compile your program in debug mode and check what new (and delete ) actually do, you will find that, internally, the system's memory manager indeed does store information about the memory being allocated, including the information whether this memory is for an array of objects or just one object. Therefore, if you try to release an array using delete rather than delete [] , you will get a runtime error!
If you want to, you can replace the system's operator new and delete with your own implementations. These could then store additional information, such as the number of elements being allocated, and then you could implement a function UBound() that takes advantage of that hidden information.
|
|
|
|
|
hmm, never thought of that. Rather clever!
|
|
|
|
|
Stefan63 wrote: If you want to, you can replace the system's operator new and delete with your own implementations. These could then store additional information, such as the number of elements being allocated...
Which is essentially what happens in debug mode.
"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
|
|
|
|
|
Since it is C++, why not make your own little class that stores the length of the array.
class Buffer {
public:
Buffer(unsigned nSize) : m_pBuffer(NULL), m_nLength(nSize) {
if (nSize > 0) {
m_pBuffer = new BYTE[nSize];
if (m_pBuffer == NULL) {
m_nLength = 0;
}
}
}
~Buffer() {
if (m_pBuffer != NULL) {
delete []m_pBuffer;
}
}
unsigned GetLength() {
return m_nLength;
}
BYTE &operator[](unsigned nIndex) {
if (nIndex >= m_nLength) {
}
return m_pBuffer[nIndex];
}
BYTE *operator*() {
return m_pBuffer;
}
private:
BYTE *m_pBuffer;
unsigned nLength;
};
Then you can use it like
Buffer bufData(64);
strcpy(*bufData, "hello world");
printf("The valid range is 0-%u\n", bufData.GetLength() - 1);
printf("The 2nd character is \'%c\'\n", bufData[1]);
You still need to call delete pData; if the buffer was created with Buffer pData = new Buffer(64);
|
|
|
|
|
Problem is, when you write things like this yourself, you always forget something . Like declaring GetLength() const for instance, and having a const accessor.
std::vector<BYTE> is the way to go.
|
|
|
|