|
nope.
(don't take my word for it)
in DEBUG more, variable _can_ be initialized to zero (or some other default patterns) as an aid for internal debugging , but in RELEASE, they are not (for performance issues).
When compiling, I would assume the compiler is just checking if the variable was assigned something.
This signature was proudly tested on animals.
|
|
|
|
|
so how compiler knows it?
|
|
|
|
|
it could checks syntactically if the variable is on the left-hand side of an '=', of if syntactically if follows the syntax of an initializer...
for example :
int i;
i = 0;
or
int i(123);
or
class Tata
{
Tata() : m_i(123){};
int m_i;
};
Or there might be other more advanced compiler tricks to keep track of variable assignments...
This signature was proudly tested on animals.
|
|
|
|
|
in the name of god
thanks Maximilien.
i don't know it up to now.
i have also another question :you said that when we use = compiler knows that a variable is initialized so if it save any data for this?any data to know which variables are initialized if yes where?
thanks.
valhamdolelah.
|
|
|
|
|
khomeyni wrote: i don't know it up to now.
Don't know what?
khomeyni wrote: i have also another question :you said that when we use = compiler knows that a variable is initialized so if it save any data for this?any data to know which variables are initialized if yes where?
The information you are after is not available via code. It's something that the compiler handles internally.
"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 don't care about = ,() , ...
thanks.but indeed i want to know more ,but as it seem it is deep because of compilers.
thanks.
valhamdolelah.
|
|
|
|
|
Easy.
You created the variable, so you know if it's initialized or not. Unless you can't remember 
|
|
|
|
|
khomeyni wrote: how we can know that a variable has been initialized or no?
Looking at the code?
Ah, and the compiler warns about uninitialized variables.
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 but:
suppose i created a variable x:int x; and then during program i dont use it and at last i want to know if it is initialized or no?for example if a condition occured then it would be initialized else ... and i dont know anything about this condition. i can use some idea as initializing it by infinite value but i want to know how to compiler do it? or is another way for?
valhamdolelah.
|
|
|
|
|
You should initialize a variable as soon as possible in your program.
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]
|
|
|
|
|
If no '=' has been encountered for a given variable during the token-parsing phase, it is assumed to be uninitialized. This is covered in compiler classes, and books such as the dragon book.
Keep in mind, though, all variables will have a value regardless of what that value is or where it came from.
"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
|
|
|
|
|
hello
how it saves that a variable is initialized or no.does it saves any data(where?)?or compiler uses a special method?
valhamdolelah.
|
|
|
|
|
This is not a basic programming subject, and certainly does not belong in the C/C++ forum. Unless you've written a compiler/parser, or have studied the subject, any answer that you are provided will not make any sense.
"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
|
|
|
|
|
Inner details of compilers are secret! 
On the serious side:
inner details of compilers are secret! 
If you are still there, consider that compiler's developers may freely choose the implementation details, provided they fullfill the language specification requirements. Hence different compilers may use different strategies to deal with the same problem.
If you are really interested in compiler inner mechanisms, I would suggest to start with some introductory material as, for instance, the excellent classic Wirth's "Compiler Construction", freely available (for instance here [^]).
As further reading, you may consider Hanson & Fraser's book "A Retargetable C Compiler: Design and Implementation" (see [^]): since lcc is a real compiler and its sourc code is available, you may have a look at it (well, gcc source code too is available...If you are going to examine it, good luck!).
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]
|
|
|
|
|
How about this. Use a boolean along with the integer. for example:
int x;
bool xIsInitialized = false;
And then, when you do start assigning some value to x, update the boolean to true.
I think this is a big waste of time though. You should always have it initialized, possibly to -1 or 0 to show that it hasn't been assigned to yet.
|
|
|
|
|
voted you down...
1- bad programming practice.
2- twice the danger of doing something stupid .. (change one and forget to change the other)
This signature was proudly tested on animals.
|
|
|
|
|
Um. Yeah. I know. That's why I didn't suggest it. It was an idea. If you read my second line, I said I didn't suggest it.
Next time, make sure you read my whole statement.
|
|
|
|
|
josda1000 wrote: How about this. Use a boolean along with the integer. for example:
int x;
bool xIsInitialized = false;
And then, when you do start assigning some value to x, update the boolean to true.
As it stands it is just an abomination.
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]
|
|
|
|
|
You should change your way of thinking: always initialize your variables. You should never have to test if a variable has been initialized or not.
|
|
|
|
|
in the name of god
thanks everybody.
i find my answer and thanks for everything. i promise you to don't question any other question that is irrelevant.
thanks.
valhamdolelah.
|
|
|
|
|
What is the difference between the following:
1. #Ifdef #else #endif and If else
Example:
#Ifdef 1
cout<<"Hello World"<<endl;
#else
cout<<"Have A Nice Day"<<endl;
#endif
and the code written as
if(1)
cout<<"Hello World"<<endl;
else
cout<<"Have A Nice Day"<<endl;
2.If we remove a macro from the code what impact we will have on the in respect to size of the code and the execution time and the size of exe.
Say we have a macro "RCAD"
The code looks like as
#if defined RCAD
// do some thing
#else
//do some thing
#endif
Now in our code the macro RCAD is always true so we remove the macro now
It will left only with
//do some thing
So what is the impact on our code and the size of it we doing the same thing.
|
|
|
|
|
1. The difference is that the #define version only ends up in your executable if the #ifdef statement is satisfied. (The if is executed at compile time)
The if(1) version ends up in your executable, and the if(1) is executed every time program control passes it.
2. You'll have no impact on the exe size/speed. All it will do is remove the code from your source files (and has the potential to leave you with some 'fun' maintenance work later on)
|
|
|
|
|
Can please tell me that what really internally happens when we use a macro.
I want to ask you that what is the difference in using macro and not using it
...................
|
|
|
|
|
A preprocessor directive (some folks refer to it as macro but I feel that is incorrect) is removed by the preprocessor thus the compiler does not even see it. You can see this for yourself by using the /P or /E compiler switch.
"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
|
|
|
|
|
The pre-processor (NOT the compiler) will parse the "#" and remove code that does not match the values...
for example :
#ifdef DEBUG
DoSomething();
#else
DoSomethingElse();
#endif
if that code is pre-processed and the value DEBUG (see pre-processor definitions in the project settings) is defined, the preprocessor will generate the following code :
DoSomething();
if pre-processed in RELEASE, (DEBUG is not defined) :
DoSomethingElse();
and only that code will be compiled.
if you have
if (1)
{
DoSomething();
}
else
{
DoSomethingElse();
}
There is no macro, so the pre-processor will do nothing the that whole code will compiled by the compiler; as someone else wrote, in a simple compiler, generated assembly will be generated for both the if and the else; so there will be code bloat in the final executable, but in modern compilers, if code will never be called, it will be removed, and in that case, only the DoSomething(); will be effectively compiled into the executable.
This signature was proudly tested on animals.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
