|
What is the Difference between Variable Definition and Declaration.?
|
|
|
|
|
AFIK, you can only declare a variable, but you can both declare and define a function.
For functions, the declaration is what you put in the header file:
BOOL Function( DWORD A, CString& B );
and the definition is where you put the body of the function - the code that makes up the function:
BOOL Function( DWORD A, CString& B )
{
A += 1;
B = "Hello World";
return TRUE;
}
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
You can declare a global variable with the extern keyword. Misleadingly many people say "variable declaration" however most of the "variable declarations" are actually variable definitions. Definition == declaration + storage.
definition - test.cpp:
int g_MyVariable;
declaration - test.h:
extern int g_MyVariable;
you can use the global variable anywhere by including test.h
Note: Using an extern variable as communication between compilation units is a bad design. Not using it is laudable! 
|
|
|
|
|
Ah, thank you for correcting me.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The variable declaration specifies the type and the link-name of the data. You usually put declarations to header files. When a .cpp file compiles and includes a header that declares a variable then that .c/.cpp file can use the variable despite the fact that the location of the variable isn't known because it can generate code that uses the specified type as needed and the link-name of the variable is known so later you can link the generated object file of your .c/.cpp to the object file of another .cpp that actually contains the data. A variable definition specifies the type and the link-name of the data like the declaration, but it also specifies the actual location of the data. The variable is located where you put the definition. For a variable you can use only one definition in one of your .c/.cpp files, your variable will be located in the generated object file of this .c/.cpp file, but you can have many declarations in other .c/.cpp files by including in a header with the declaration to many .c/.cpp files. This way the generated object file of the other .c/.cpp files will just have a reference by name to the defined variable if you actually used the declaration where you included it.
|
|
|
|
|
int x;
int x = 5;
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
|
Hi, dear all,
I have a MFC application created in C++ 6.0, it works fine in Window XP. When run this application in Window 7, if the dialog has progressbar on it, this dialog cannot be launched, but if you remove this progressbar or for dialog without progressbar, everything is fine.
But no all Window 7 computers have this error, only very few computer have this problem.
Is there anybody having this issue? or any idea?
Thanks!
|
|
|
|
|
I've used progress bars on Win7 with no issue. What do you mean it didn't launch? Was there an error? If so, what was the error?
|
|
|
|
|
Thanks for your reply.
As I said, most of the Window 7 computers have no problem to run this application, but some did have this issue.
If the dialog has progressbar on it, when you call Dialog.Domal(), even the OnInitDialog() function is not called.
I put a messagebox at the first line in OnInitDialog() function, when I open the dialog, no any message, just nothing, no any response.
|
|
|
|
|
If the same .exe file runs on some W7 machines and not others, then the problem is clearly something environmental on the machines that fail. Check for missing DLLs on the failing machines. Or build your application with MFC and C RTL as static libraries and try it that way.
|
|
|
|
|
Thanks for you suggestion.
Yes, you are right, it's because some files are not correctly registered.
|
|
|
|
|
The OnInitDialog() occurs after the creation of a window, so there's the possibility that the creation is failing and you're not checking that. Check the return of DoModal() and GetLastError() for errors.
|
|
|
|
|
We are all familiar with the sizeof operator, but is there an operator to get the offset of a structure member within the structure?
Example:
struct SampleStruct
{
DWORD Member1;
DWORD Member2;
}
DWORD Result = offset(SampleStruct.Member2)
I need something that would work with bit fields as well.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
How about:
DWORD Result = &SampleStruct.Member2 - &SampleStruct.Member1;
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Yeah, that would work with most types, but not bit fields. It gives an error if you try to take the address of a bit field.
I was hoping that there might be an operator.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Pretty sure there's no simple operator for what you want, you're going to have to make your own.
|
|
|
|
|
Try offsetof[^].
Since bits are not addressable I don't think you will find anything for them.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard MacCutchan wrote: Try offsetof[^].
Hooray!! Thanks for that.
I'll have to compute bit fields myself.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: I'll have to compute bit fields myself.
Emphasizing what was already said - you cannot address a bit field.
The syntax that does that in the language uses an address AND bit manipulation.
|
|
|
|
|
Yup, that was understood. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
re bit fields:
The standards (C and C++) explicitly state that the address-of & operator cannot be applied to bit fields, and consequently there are no pointers to bit fields.
Given that the layout of bit fields within some integral type is implementation-dependent, that all makes a lot of sense.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Not really anything to do with the language, more the fact that the hardware cannot do it.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I'm not really sure this deserves the joke icon.
What a surprise! Language standards reflecting hardware reality!
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
No, I think the joke icon is well deserved.
One of these days I'm going to think of a really clever signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
