Microsoft !!! Q's
-
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? :) :)
-
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? :) :)
( is it a rant or a question ? ) suiram40 wrote: 1. How they can call a type(class name) CObject. Why not ? I can call my base class CPotato if you want ... suiram40 wrote: 2. Extreme encapsulation!!! for the first part, Yeah, this is the way to do OO programming ( IMHO ), to privatize data members, and have setters and getters. why ? because it's safer. clearer. if for some reason, you decide to change the name of the variable; you will need to change it everywhere, with getter/setters, you only change the class.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
( is it a rant or a question ? ) suiram40 wrote: 1. How they can call a type(class name) CObject. Why not ? I can call my base class CPotato if you want ... suiram40 wrote: 2. Extreme encapsulation!!! for the first part, Yeah, this is the way to do OO programming ( IMHO ), to privatize data members, and have setters and getters. why ? because it's safer. clearer. if for some reason, you decide to change the name of the variable; you will need to change it everywhere, with getter/setters, you only change the class.
Maximilien Lincourt Your Head A Splode - Strong Bad
Maximilien wrote: I can call my base class CPotato if you want ... Yes, but would it be able to handle ketchup (for frenched fries), or butter (for mashed)? I like both styles so these accommodations are a requirement!!
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
-
Maximilien wrote: I can call my base class CPotato if you want ... Yes, but would it be able to handle ketchup (for frenched fries), or butter (for mashed)? I like both styles so these accommodations are a requirement!!
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
-
-
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? :) :)
For point two: Imagine a simple circle class. You have setters and getters for Area, Radius, and Diameter. Simple grade school math gives the relation between them. Now which are you going to store in your class? If you use setters and getters it doesn't matter because you can change it at anytime without anyone else being affected. (and a good compiler will inline them so there isn't overhead) Think it doesn't matter? Say you pick area. Well I'm going to use your class, but after a profiler I've discovered that getting the diameter is taking a large part of the CPU time, and the system is too slow. A simple change to the class to store diameter will speed things dramaticly. Of course if you anticipated area being most needed, then area would be right. (even though square roots are slower than powers in general) Of course the example I gave is contrived. You should get the idea though. In the real world it often turns out that you don't know in advance what you will need to change latter so you use getters and setters everywhere just in case. 95% or more of the time you will never change it, but overall you have saved yourself a lot of work with the getters and setters.
-
suiram40 wrote: but CObject ??? Why not
CObject? It is the least common denominator.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
-
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? :) :)
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? The idea is that all objects in MFC are based on it ... much as object in Java and C# 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? As others have said its good style to have setters and getters, especially for setters ... Maybe you want a member to be restricted to 1..100 .. How would you do that otherwise ? Maybe you have a member that constantly needs to be refreshed ... say the exchange rate for Euros to US Dollars. Just returning the current value stored would do no good, and constantly updating the value may be inefficent ... so just make sure you have the current value when you need it. This is dealt with in other languages via properties ... getters and setters kinda hidden in the syntax.
-
1. How they can call a type(class name) CObject. As long an object is an instance of a class, How they can call a class 'CObject' ??? 2. Extreme encapsulation!!! -I've seen this in MFC/ATL implementations: If they have C++ classes usually they make data members private and provides public functions for access Them as read/write (Set***(), Get***), so instead writing obj.member=5; you write obj.SetMemebr(5); and type t = obj.member; you write type t = obj.GetMember(). -On the other hand when you use some COM components type libraries By default (!raw_interfaces_only) they wrap the ccom_ptr In the *.tli generated files around the interfaces 'transforming' The interface method calls (__declspace(propput=)...) po->SetVar(type) into po->_var=type; which is the other way around. So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls We wrap direct member access call. Isn’t this weird? :) :)