|
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.
|
|
|
|
|
Hi,
#Ifdef 1
cout<<"Hello World"<<endl;
#else
cout<<"Have A Nice Day"<<endl;
#endif
The compiler preprocessor will explicitly skip the code within the #else and no code will be generated because the previous condition was true.
if(1)
cout<<"Hello World"<<endl;
else
cout<<"Have A Nice Day"<<endl;
A non-optimizing compiler may generate code for both conditions including the impossible condition. An optimizing compiler will detect the second condition is unreachable and skip code generation.
Essentially you will probably get exactly the same result in both cases in a modern optimizing compiler in a Release build.
#if defined RCAD
#else
#endif
deadlyabbas wrote: So what is the impact on our code and the size of it we doing the same thing.
The outcome will probably be exactly the same. By defining RCAD condition as true... the compiler ignores the other condition completely.
Best Wishes,
-David Delaune
|
|
|
|
|
deadlyabbas wrote: Example:
#Ifdef 1
cout<<"Hello World"<<endl;
#else
cout<<"have a="" nice="" day"<<endl;
#endif<="" blockquote="">
That's conditional compilation (compiler doesn't even 'see' the "Nice Day" statement, the preprocessor removes it).
deadlyabbas wrote: if(1)
cout<<"Hello World"<<endl;
else
cout<<"have a="" nice="" day"<<endl;<="" blockquote="">
That's runtime evaluation of statements.
Hint: compile with /E flag to see the preprocessor in action.
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]
|
|
|
|
|
Hello Sir,
How to read Byte array From image ?
in C# i can read perfect but in VC++ i dont know how to do it ?
Thanks !
|
|
|
|
|
raju_Code wrote: How to read Byte array From image ?
Do you mean from a GDI+ Image[^]?
Best Wishes,
-David Delaune
|
|
|
|
|
hi.
i want to write an image processing program and i don't need to preview the image so i decided to use win32 console application to avoid any unwanted delays. i want to use GDI+ classes but there is a runtime error.
my program :
#include "stdafx.h"
#include <windows.h>;
#include <gdiplus.h>;
using namespace Gdiplus;
int main()
{
Bitmap *bmp;
bmp = new Bitmap(L"my image path");
unsigned int w = bmp->GetWidth();
return 0;
}
the error :
Unhandled exception at 0x00411761 in GdiPlusTest.exe: 0xC0000005: Access violation reading location 0x00000004.
any help? thanks.
|
|
|
|
|
__erfan__ wrote: i want to write an image processing program and i don't need to preview the image so i decided to use win32 console application to avoid any unwanted delays.
Hey, you're in the un-managed world here. 
Probably the bitmap object it is incorrectly built because you've not initialized, as required, the GDI+ library (MSDN [^]):
You must call GdiplusStartup before you create any GDI+ objects, and you must delete all of your GDI+ objects (or have them go out of scope) before you call GdiplusShutdown.
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]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
