|
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)
|
|
|
|
|
El Corazon wrote: does that save you anything over a ring buffer?
I don't know. I'd have to look at the details of such a ring buffer. I've never coded one and it's many years since I studied them.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
|
Here is a basic question on Structures. Do Structures support inheritance and if so how different is it from Class inheritance?
---
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) Hakuna-Matata
It means no worries for the rest of your days...
It's our problem free, Philosophy
![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
"I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."
|
|
|
|
|
Yes, structures do support inheritance in C++. If I remeber correctly the only difference now remaining between structures and classes is that structure members are public by default as opposed to protected. I generally use a struct by convention when the object I'm creating is data only, ie. it has no functions beyond possibly constructors. Occasionally I might use a struct with functions if I'm creating a type that's intended to behave like a built in type or a special translation type but that is a whole different tricky kettle of fish 
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Generally a struct is for data only, and yes they can be inherited. You will sometimes see structs derived from the built in windows types. It's not often you will see member functions within a struct, though sometimes the need does arrise, especialy when overiding the comparison operators. Other than that, a structs members are public by default, whereas a class's members are protected.
|
|
|
|
|
Yes its possible on the C++ and C++.Net different is about access level also I think you need to see again about classes and structs so you will be see differences classes and structs.;)
|
|
|
|
|
Is there a way to add a new search engine(top right corner) in IE programmatically?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
