|
That may not accomplish what he wants. If he's making a temporary copy to use as a scratch pad in a calculation and wants to preserve the original, it certainly won't. Your example just provides a different way to access the same data, not a copy.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
For copying arrays, you can use functions like memcpy_s[^] and CopyMemory[^].
These functions require you to know the size of the array.
In C++, ideally you should be using the STL containers like vector, list etc. and then you can use the copy[^] function to make a copy of a container using iterators as shown in the example in the documentation.
|
|
|
|
|
In the following code when we print the list why do we do curr = curr->next ;
#include<stdlib.h>
#include<stdio.h>
struct list_el {
int val;
struct list_el * next;
};
typedef struct list_el item;
int main() {
item * curr, * head;
int i;
head = NULL;
for(i=1;i<=3;i++) {
curr = (item *)malloc(sizeof(item));
curr->val = i;
curr->next = head;
head = curr;
}
curr = head;
while(curr) {
printf("%d\n", curr->val);
curr = curr->next ;
}
}
|
|
|
|
|
Razanust wrote: why do we do curr = curr->next ;
to get to the next item in the list... ?
|
|
|
|
|
Code should be:
int main()
{
item *head,*prev,*curr;
int i;
for(i=0;i<3;i++)
{
curr=(item *)malloc(sizeof(item));
curr->val=i+1;
if(i==0) head=curr;
else prev->next=curr;
prev=curr;
}
curr->next=NULL;
......
}
But I did not test...
|
|
|
|
|
Hi,
In your code, 'curr' is at all times the item you are currently looking at, I assume tat that's why you called it 'curr'
curr=curr->next, advances your pointer. So, after that statement, curr points at the next item of your list.
In that way, your printf will print each value in your list, by starting at the head, and then by iterating thru the list items.
BTW Was this a School Assignment? Surely looks like one.
Bram van Kampen
|
|
|
|
|
Hi,
In windows programming all the messages will be placed in the message queue for processing.
Let us assume I have a dll which continuously raises events.
These events will be placed in the Message queue.
Now my doubt is, if the message queue fills , the application will crash.
1)How to handle the scenario... so that my application should not crash.
2) How to find the size of the Message queue.
Thanks inadvance.
|
|
|
|
|
From PostMessage function documentation on MSDN [^]:
There is a limit of 10,000 posted messages per message queue. This limit should be sufficiently large. If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources. To adjust this limit, modify the following registry key.
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows NT
CurrentVersion
Windows
USERPostMessageLimit
The minimum acceptable value is 4000.
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]
|
|
|
|
|
Trust Microsoft to put this detail in the one function that I did not look at just now. 
|
|
|
|
|
You should subscribe, like I did, the
'immediately informed by Microsoft about' neewsletter. 
BTW: Merry Christmas!!!
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 for the tip, I'll give it a try. And Merry Christmas to you also.
|
|
|
|
|
Changing the limit is one alternative. Another is to check the return value from PostMessage. If the queue is full and the message can not be posted, I believe PostMessage returns a boolean false to indicate failure. Just wanted to suggest another way of looking at the problem.
Happy Holidays to everyone.
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]
|
|
|
|
|
Chris Meech wrote: Changing the limit is one alternative. Another is to check the return value from PostMessage. If the queue is full and the message can not be posted, I believe PostMessage returns a boolean false to indicate failure. Just wanted to suggest another way of looking at the problem.
Good Lord, so you've worked with that sort of horrendous applications? (I'm into that club too and I ended up rewriting an app once)
BTW, Merry Christmas to you!
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
I have worker thread classes that query a database and post registered messages to controls. The loop that posts always seems to run faster than the UI thread can process. So I use a lock to throttle the worker thread when this happens. It was a difficult bug to deal with. 
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]
|
|
|
|
|
vc++_fragrance wrote: 1)How to handle the scenario... so that my application should not crash.
Your message loop should take care of this by processing every message on the queue. Only if the loop does not handle the messages is this likely to happen.
vc++_fragrance wrote: 2) How to find the size of the Message queue.
I'm not sure if this information is available, but you could check the MSDN documentation[^] for further information.
|
|
|
|
|
Either SendMessage can be used, or if you're afraid of the sender being taken into a deadlock, consider SendMessageTimeout[^]
But more importantly, why is it that your DLL needs to continuously raise events and clobber the message queue? May be if you could explain your scenario, someone here might be able to suggest a better alternative.
I say it because if you increase the message queue size on one computer, your program will still not work on another computer whose message queue size is the default! This is not a pretty sight.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
HI all,
i m receiving this error,when i print records with large number of pages like 50 or above.
when i debug the code i m note able to find out this error.
please help me for this.
thanks in advance.
To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.
|
|
|
|
|
Hi all,
I want to pass a CString variable to my worker thread.
How can i do it...
Thanks in advance
To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.
|
|
|
|
|
Change Allocation to Heap if scope of thread is unknown
pass the TCHAR*.
CString csTemp( "Sample data" );
LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
_tcscpy(lpszData , csTemp)
Величие не Бога может быть недооценена.
|
|
|
|
|
Adam Roderick J 09 wrote: Change Allocation to Heap if scope of thread is unknown
pass the TCHAR*.
CString csTemp( "Sample data" );
LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
_tcscpy(lpszData , csTemp)
While a pointer to the CString object on the heap itself can be passed to the thread, why bother creating a character array on the heap and deal with allocation size manually?
Adam Roderick J 09 wrote: LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
That won't work as expected with Unicode strings.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: Adam Roderick J 09 wrote:
LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
That won't work as expected with Unicode strings.
Why not?
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]
|
|
|
|
|
CPallini wrote: csTemp.GetLength()+1
Because of the +1 part, which makes a wrong assumption of the size of an Unicode character! It could have been multiplied by sizeof(TCHAR), that would make it work, but is not very clean (IMHO).
There's generally no reason to write C-Style code with manual memory allocation (deciding the size, etc.,) while using MFC, or even C++. Using a CString instead is much more elegant.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
I think, there is a small misunderstanding.
for MBCS
LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
Here we are allocating for TCHAR so it will allocate 2 bytes for every new operator.
so if
csTemp = _T("ab" )
size allocation with above allocation will be 4 +2 =6 bytes.
Величие не Бога может быть недооценена.
|
|
|
|
|
Rajesh R Subramanian wrote: Because of the +1 part, which makes a wrong assumption of the size of an Unicode character! It could have been multiplied by sizeof(TCHAR), that would make it work, but is not very clean (IMHO).
Nope:
LPTSTR lpszData = new TCHAR[csTemp.GetLength()+1];
Looks correct to me, whatever CString is of wide characters or not.
Rajesh R Subramanian wrote: It could have been multiplied by sizeof(TCHAR)
It is already taken into accout by the new operator.
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]
|
|
|
|
|
For first case the reason is performance, CString is a bit heavy
2.That won't work as expected with Unicode strings.
Why it wont work?
Can you please give me the reason. 
Величие не Бога может быть недооценена.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
