|
CString is from MFC.
so follow this.
CString str;
str="HELLO";
str.MakeLower();
now this should work.
|
|
|
|
|
if your problem is solved, please indicate the same in your main subject by prefixing [SOLVED] to your subject.
|
|
|
|
|
Can you help me.
Help to be going to create Virtual IP using "iphlp" libarary raise just there is example code using c++
wait for your advice.
thank you.
ps : thanks is add "iphlp" library fils(iphlp.h , iphlp.dll ...)
|
|
|
|
|
There is no need to repeat your question. When and if somebody is able to help you, they will reply to your origional post!
|
|
|
|
|
I think I saw your question 6 hours ago why but you asked again?
|
|
|
|
|
Hi All
I have a confusion related to global and local variables...
why global variables are initialized to zero whereas local variables are not...
What is the reason behind this.
Please suggest me the answer.
Thanks & Regards
|
|
|
|
|
Global variables can be used within any function from anywhere within your code, local variables can only be used within scope that they were created ( usualy a single function ). It's good practice and reduces many bugs if you initialize all your variables when you create them, regardless of what the books tell you.
|
|
|
|
|
thanks WalderMort
it is fine that we should initialize each var while creating it,
but wondering that why global variables are initialized to zero by compiler whereas local variables are not..
Please help to understand the logic
Thanks & Regards
|
|
|
|
|
In a debug build, variables are initialized, but you will find that within a release build, they are not. This is one of the main reasons why people complain that their release build doesn't work. Take the following example:
bool bIsEqual;<br />
<br />
if ( ... )<br />
bIsEqual = true;<br />
<br />
if ( bIsEqual )
....
|
|
|
|
|
Hi
could not understand your example
I wrote an example As follows:
int pg;
int _tmain(int argc, _TCHAR* argv[])
{
int pl;
int s;
printf("Global %d \n", pg);
printf("Local %d \n" , pl);
scanf("%d", &s);
return 0;
}
and while printing pl prompts an error message
"Run-Time Check Failure #3 - The variable 'pl' is being used without being defined."
any comments on this....
|
|
|
|
|
rajeevktripathi wrote: "Run-Time Check Failure #3 - The variable 'pl' is being used without being defined."
At compile time, you have got a "warning C4700: local variable 'pl' used without having been initialized".
As you have enabled "Runtime checks" (probably a Debug-build), the runtime complains that you use this variable without prior assignment to it.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
rajeevktripathi wrote: why global variables are initialized to zero whereas local variables are not...
During the CRT initialization routine ( wWinMainCRTStartup function ), there is special code for intializing the c objects and c++ objects. You can find a function called _initterm() called from the wWinMainCRTStartup. That function does all this.
|
|
|
|
|
rajeevktripathi wrote: why global variables are initialized to zero whereas local variables are not...
You'll likely see a difference in initialization between release and debug compiles of your program. In debug mode, since the frame pointer is always pushed onto the stack at routine entry, variables are almost always assigned locations on the stack (e.g., 0). In the release mode, optimizations of the compiler (and other factors) may detect that the frame pointer is not needed, so the frame pointer is not pushed onto the stack, thus no initial value.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Would this warrent taking any safeguards for reader writer lock?
Thread 1 pushes items to the back of a vector.
Thread 2 pops the first item ( if not empty ), does some action, and loops constantly.
The vector contains only pointers. I'm not worried about the execution time of thread 2, but it's critical that Thread 1 isn't required to wait? Using Mutex's or critical sections all involve using the WaitXXX functions. If a safeguard is required, would setting a simple bool be adequate enough to prevent Thread 2 from reading the data while Thread 1 is writing?
|
|
|
|
|
definitely this will work,
in one of my project, i had to implement it.
sure that, it will work even for you,
any more suggestions required,
please.
|
|
|
|
|
There are two issues here. One is the internal gubbins of the vector class you're using. If it's the stl vector then you may be stuck as the code is essentially unreadable gibberish. The other is the synchronisation issue itself.
I use a very similar trick with a queue implemented as a linked list where one thread can remove from the queue and another append to it wihtout any blocking calls. The proviso is that there must be at least 3 items in the queue to gaurantee that the threads don't clash while they're rearraning the node pointers. My queue class itself checks this and it has never failed me. It works in practice because in low load situations where you only have on or two queue items at a time perfromance is not so critical and I can afford to switch on the locking code. I wrote this by implementing it all wiht full locking and testing it then made each locking and unlocking call conditional on swithc which is set and unset when the list size goes over the 3 item boundary. The switch itself is just a long which is incremented and decremented with the Interlocked functions.
The issue if you use someone elses underlying data structure like std::vector is that you don't know what the conditions are for it restructuring or reallocating the memory involved so this kind of scheme is risky. The activity of one thread could cause the data being access by the other to be moved even though there is no obvious overlap between what they're doing. No harm in trying it though and let me know if it works.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Your idea of a linked list que sounds interesting, though in my situation it would not work.
I'm implementing a console stub which will divert a second consoles output to my gui app in real time. The main loop constantly scans the screen buffer, reads the text and clears it. Due to sluggish behaviour I'm using a thread to do the actual writing to the pipe ( since the text gathered from the buffer needs manipulating ).
Thinking about the vector class, esentialy it's just an array which is re-arranged on each insert() erase(). So it would cause reader/writer problems. I've had to use a critical section 
|
|
|
|
|
WalderMort wrote: Thinking about the vector class, esentialy it's just an array which is re-arranged on each insert() erase(). So it would cause reader/writer problems. I've had to use a critical section
use a vector designed for high concurrency threaded operations. http://www.threadingbuildingblocks.org/[^]
http://www.intel.com/cd/software/products/asmo-na/eng/294797.htm[^]
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
WalderMort wrote: I'm implementing a console stub which will divert a second consoles output to my gui app in real time. The main loop constantly scans the screen buffer, reads the text and clears it. Due to sluggish behaviour I'm using a thread to do the actual writing to the pipe ( since the text gathered from the buffer needs manipulating ).
It suddenly occured to me after answering you... though the answer is still a possibility, it may not be necessary. We're both thinking too "direct" to get an efficient answer.
Problem: you need to add in one thread, read in another, you don't want constant memory allocation of a queue, you want vector speed and efficiency.
Answer: preallocate the vector, and use it as a ring-buffer queue. A ring buffer queue is different than a standard queue in that it is just a section of preallocated memory (in the past an array, recently a vector) in which you keep two indexes: head, tail. You start with head and tail pointing to the start of the vector, head==tail is an empty buffer. Thread 1 adds an item to the vector, write first, then increment the tail, if the tail exceeds the buffer size, set it to 0. if incrementing tail ever makes tail== head you have a full buffer, expand it. to pop something off the queue, read first, then increment the head similarly as you did the tail.
You can protect only the subportions of the algorithm, reading and writing the head/tail indexes and fully lock during expansion. This is a prime example of an implicitely shared container. as long as adding to the tail never reaches the head (fills the buffer) you can run almost free-running, as near as wait-free as you can imagine.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
It's an interesting concept, though I have managed to do away with the thread altogether.
|
|
|
|
|
WalderMort wrote: It's an interesting concept, though I have managed to do away with the thread altogether.
well, then to quote one of my favorite movies....
"I am happy and sad for you."
I am glad you solved it, but sad you didn't get the thread going. threaded operations when written correctly can gain you a lot of time back. Though perhaps in this case it was really extra overhead. Still, I have many reader/writer threads running independantly, my whole streaming debugging system works under the multi-threaded ring buffer concept. (it's why it suddently occured to me, that has been stable for a year, so I haven't really thought about it since). It's a streaming writer with the debugs coming from multiple threads (multi-threaded write), and a single thread streaming the output of the embedded debugger to another computer. I have debugged in this fashion from 40 miles away using a packet radio, nifty.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
I can't see any obvious reason why the linked list would not work. Perhaps I misunderstand your situation? Anyway good luck with the screen sraping project.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
You mentioned earlier that you need to have at least 3 items in the que for it to work without problems, unless I missunderstood. In my situation there could be 0+ items.
|
|
|
|
|
Ahh I see, No it works with 0+ list items it just does locking in the normal way you'd expect until there are 3 items and then the locking is switched off until the queue shrinks again. The theory is that if you never have enough asynchronicity between your threads to get 3 items then you probably aren't pushing the system hard enough to need the extra performace of no locking.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Matthew Faithfull wrote: The theory is that if you never have enough asynchronicity between your threads to get 3 items then you probably aren't pushing the system hard enough to need the extra performace of no locking.
does that save you anything over a ring buffer? other than possibly memory use? seems more complicated than it should be. Esentially with a CAS operation on the ring buffer indexes, the locking/unlocking of your queue is identical but without the exceptional check for size, it just automatically occurs because of how the CAS works.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
