|
Thank you sir I have posted the question below the article 
|
|
|
|
|
Hi,I had a question about class and object memory, any hints are welcome.
1) Is the class occupies some memory? as I understand it, class is just a data type as int, long ,double.
2) Is the member function in the Object's memory ? I mean, in the sizeof(object).
3) The derived class object inherited from base class, the base class has member functions, then is the member function memory layout be inherited to the derived class object?
Thanks
|
|
|
|
|
- No a class is like a template or blueprint, and just contains the definitions used by the compiler to generate the code that construct objects.
- No, member functions exist in a separate part of the application's address space, they are not part of the object.
- No, all member functions will be present in memory and invoked as required by the running application.
For more details consult your reference guide or the documentation on MSDN.
|
|
|
|
|
Thanks.
Then in the inheritance operation, for example:
class A {
public:
void funct() { cout << "a" << endl; }
}
};
Class B:protected A {
private:
void funct() { cout << "b" << endl; }
};
int main()
{
B c;
b.funct();
;
return 0;
}
B's funct() can hide A's funct(), if I comment funct()in Class B, b.funct() will call funct() in class A.
Seems like b inherited the function in class A.
Since member function only has one copy in memory, then how can B inherit the member function from A?
|
|
|
|
|
Like I said before, both functions will be in memory, so either or both of them can be called. Overriding and hiding affects how the compiler will invoke the functions, it does not affect how the code exists in memory.
|
|
|
|
|
Thank you for your reply.
I am a little confused about the inheritance, member function inheritance.
So the member function of one class, only has one copy in the memory map, then if class B's base class is class A,
the inheritance mechanism makes the B's object has member variables of class A.
and B's object inherited the member functions of class A,while B's object don't have those functions, B's object just know how to invoke those functions, right?
And the member function inheritance follow same inheritance rule as member variables, for example, private inheritance will make all member functions inherited from base class A, turn to private in class B.
class A {
public: void f1(){}
protected: int f2() {}
private: char f3() {}
};
class B:private A {
// B inherit f1(), f2(), f3(), and access for all 3 functions will be private.
};
Thanks
}
|
|
|
|
|
You have the general idea. All methods of all classes will be available in memory. The actual method being called at any time is controlled according to the inheritance rules; see Inheritance (C++)[^].
|
|
|
|
|
thanks, so both functions will has only one copy in memory. but compiler decide overriding and hiding effects, right?
|
|
|
|
|
Correct the selection is done via a Virtual Method Table (VMT) and now you have got the concept this will make sense
Virtual method table - Wikipedia[^]
In vino veritas
|
|
|
|
|
|
See if this is of any help - Polymorphism in C[^]
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
Hi
I am getting the above error, and I know its a programmer trainee error but I can't for the life of me figure it out
I did a find all from Visual Studio (looking in my solution directory) and what found was
the function was defined once
I did declare it ending with ';'
And when I call it or the declaration or the actual routine all have the same parameter list
Here is the result of the find all
line 43 is the declaration line 1606 is the actual function line 1743 is where it actually used
, Subfolders, Find Results 1, "quot;"
cpu.c(43):void hex_to_ascii(BYTE *ipx, char *str, int num);
cpu.c(1606): void hex_to_ascii(BYTE *ipx, char *str, int num)
cpu.c(1743): hex_to_ascii(ipx,str,num);
hmacros.h(182): hmacros.h(187): cpu.c(43) : see previous definition of 'hex_to_ascii'
Matching files: 3 Total files searched: 764
|
|
|
|
|
"Matching files:3" but I only see two distinct file names... do you have cpu.c included in the project twice somehow?
|
|
|
|
|
That's not it I checked only once the other was the output (compiler output) file
|
|
|
|
|
Well, there are very few things that could cause this... an actual redefinition or a namespace conflict. To test if it's a namespace conflict, wrap the function in a namespace and recompile, if it gives you the same error, you have a redefinition in that same file somehow. I can't tell you exactly how without looking at your code and your project/makefile.
edit: You can also check namespace conflict by changing your function name temporarily (just to see if that's it).
|
|
|
|
|
I just recompile that file seems like the compiler doesn't like function definition
but there is nothing wrong with it. I don't have hex_to_acii anywhere in the file
void hex_to_ascii(BYTE *ipx, char *str, int num) <-- line 1607
{ <- line 1606
BYTE inst;
int i;
char *holdstr;
and got this compile error message
(1607): error C2084: function 'void hex_to_ascii(BYTE *,char *,int)' already has a body
1> d:\cpu.c(1606) : see previous definition of 'hex_to_ascii'
|
|
|
|
|
ForNow wrote: I don't have hex_to_acii anywhere in the file
...and then you proceed to show me how you have hex_to_ascii defined... 
|
|
|
|
|
I meant just that one area
I am not sure how make a namespace in C
Besides from compiler message it seems like it doesn't like the way I declared the function in the file
Maybe I'll rename it or move it to a different area in the file
|
|
|
|
|
Thought you were doing C++... in that case, change the name of the function and see if the error persists.
|
|
|
|
|
Haha if we have ruled out multiple includes let me guess at this ... ready
You have a forward declaration prototype at line 43
>>> cpu.c(43):void hex_to_ascii(BYTE *ipx, char *str, int num);
You have the body presented at line 1606
>>> cpu.c(1606): void hex_to_ascii(BYTE *ipx, char *str, int num)
BYTE is a non standard and often misused piece of junk definition often abused by people. I am going to guess the definition of BYTE between line 43 and 1606 changes. So it's trying to tell you that you forward declared a prototype in that name already and your new body mismatches its definition and is trying to define under the same name.
Usually the problem is BYTE gets defined as a char one place and as unsigned char somewhere else and so the compiler has two non matching definitions of BYTE. You just see the word BYTE but you can't see it's definition. In Visual studio if you right click on the word BYTE in both cases and on the menu click on "goto definition" it will show you what it is using for the two definitions.
This is the reason the standards type unit was created to stop this sort of problem. If that is the problem the solution is simple #include <stdint.h> and use the proper standard type uint8_t which is an unsigned 8 bit integer which is after all what the non standard BYTE definition is I imagine.
In vino veritas
modified 18-Dec-16 23:48pm.
|
|
|
|
|
You have a definition of hex_to_ascii in hmacros.h (defined as extern) and also in cpu.c. Remove the one from cpu.c and see if that fixes it.
|
|
|
|
|
Assuming OP has cut'n'pasted accurately, the lines from hmacros.h are commented out.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
It won't be commented out nor does it need to be. I take it he is just using the commenting out to show whats there.
Assuming it uncommented it's an extern (which is nothing more than a forward prototype) with a macro calling the extern. That won't create any problem at all as there is clearly no function body provided in hmacros.h by doing that and it will simply defer to the extern body provided with one big proviso that the prototype matches the external body declaration.
I am still backing that BYTE gets defined differently (probably inside hmacros.h) and so the prototype doesn't match the body. We know BYTE must be defined prior to CPU.C using it and CPU.C then includes hamacros.h. I am betting hmacros.h defines BYTE as well (probably one is as a char and one as unsigned char).
Given that the compiler is seeing no macro redefinition etc it's clear one will be #define BYTE ... and the other typedef so BYTE has two valid but different definitions which don't on their own clash.
Here try it
typedef unsigned char BYTE;
void hex_to_ascii(BYTE *ipx, char *str, int num);
#define BYTE char
void hex_to_ascii(BYTE *ipx, char *str, int num) {
};
That is illegal in C especially if one is declared extern, the header and the body don't match because they are using different versions of BYTE. In C++ it would overload and then tell you one of your overloads hasn't got a body definition. Remove the macro and it will compile correctly because the forward declaration and body match then.
It's dead easy to do and one of the normal problems of merging multiple libraries who like to make there own definitions.
In vino veritas
modified 20-Dec-16 1:56am.
|
|
|
|
|
If BYTE is defined differently between the forward declaration and the definition, you certainly wouldn't get a "redefinition" error.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
