|
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]
|
|
|
|
|
ops... A photo finish. and you won
|
|
|
|
|
I'm pretty sure he has borrowed some of Rajesh's monkeys. He only slept 4 hours last night. He is training them to play chess. 
Best Wishes,
-David Delaune
|
|
|
|
|
|
Randor wrote: I'm pretty sure he has borrowed some of Rajesh's monkeys
Randor wrote: He is training them to play chess.
I actually was persuading one of them (the most appealing female of the group) to have some ...
(well I suppose it's not sister kid safe)
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]
|
|
|
|
|
|
__erfan__ wrote: Unhandled exception at 0x00411761 in GdiPlusTest.exe: 0xC0000005: Access violation reading location
You have to initialize GDI+ before you make any GDI+ calls. check GdiplusStartup()[^] function
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
