C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Two questions for help!          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message away Guest Posted: Sat Sep 25, 2004 3:21 am    Post subject: Two questions for help! 1. It is showed in a book that a class has all member variables declared as protected. What's the reason for doing this? 2. Unnamed namespace and global scope, are they equivalent to each other? Thanks for your help! Back to top Daniel T. Guest Posted: Sat Sep 25, 2004 3:31 am    Post subject: Re: Two questions for help! "away" <Gusalpine (AT) spambs (DOT) com> wrote: Quote: 1. It is showed in a book that a class has all member variables declared as protected. What's the reason for doing this? Making a variable protected ensures that only the class and sub-classes can modify the variable. The assumption is that sub-class writers will be careful enough. Personally, I feel that all variables should be declared private. Quote: 2. Unnamed namespace and global scope, are they equivalent to each other? No. A variable declared in an unnamed namespace can only be accessed from the cpp file that contains it. A variable in global scope can be accessed from anywhere in the program. Back to top Mike Wahler Guest Posted: Sat Sep 25, 2004 3:32 am    Post subject: Re: Two questions for help! "away" <Gusalpine (AT) spambs (DOT) com> wrote Quote: 1. It is showed in a book that a class has all member variables declared as protected. What's the reason for doing this? So that derived classes may have access to those members. This is a design decision that depends upon the nature of the problem being solved. Quote: 2. Unnamed namespace and global scope, are they equivalent to each other? No. -Mike Back to top Phlip Guest Posted: Sat Sep 25, 2004 3:56 am    Post subject: Re: Two questions for help! Daniel T. wrote: Quote: 2. Unnamed namespace and global scope, are they equivalent to each other? Are these from a test? Quote: No. A variable declared in an unnamed namespace can only be accessed from the cpp file that contains it. A variable in global scope can be accessed from anywhere in the program. A better name for the unnamed namespace would be "the namespace whose name cannot be written". Otherwise the unnamed namespace would not be unique to each translation unit; the global one would be unnamed. -- Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces Back to top Dave Townsend Guest Posted: Sat Sep 25, 2004 4:31 am    Post subject: Re: Two questions for help! "Daniel T." <postmaster (AT) earthlink (DOT) net> wrote Quote: "away" <Gusalpine (AT) spambs (DOT) com> wrote: 1. It is showed in a book that a class has all member variables declared as protected. What's the reason for doing this? Making a variable protected ensures that only the class and sub-classes can modify the variable. The assumption is that sub-class writers will be careful enough. Personally, I feel that all variables should be declared private. Can you enumerate why all variables should be private ? I've written classes a a number of times where I've made all variables private and had to write numerous member functions to allow access to the variables by the derived classes, it didn't seem that there was much advantage and a lot of extra code was needed to wrap the data member . It seems to me that there are good reasons for making variables protected :- 1. if the derived classes would access them 2. modifying these variables does not require side effects. Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 5:32 am    Post subject: Re: Two questions for help! Dave Townsend wrote: Quote: Can you enumerate why all variables should be private ? I've written classes a a number of times where I've made all variables private and had to write numerous member functions to allow access to the variables by the derived classes, it didn't seem that there was much advantage and a lot of extra code was needed to wrap the data member . It seems to me that there are good reasons for making variables protected :- 1. if the derived classes would access them 2. modifying these variables does not require side effects. One value of the data-hiding is that it isolates the implementation from the functionality. So for example if you have // Silly example class someClass { string fullName; // ... public: //... string getName() const; void setName(const string &newName); // ... }; class fullClass: public someClass { string address; // ... public: // ... string getAddress() const; void setAddress(const string &); // ... }; Now imagine that one day for some reason, you decide to change fullName to char *. All you have to do is modify someClass::getName() and someClass::setName(). Had you reimplemented these member functions and in general allowed access to fullName in all derived classes, you should modify all of them. However there are cases when it is good to have this access. There is no "silver bullet". Have a look here about "silver bullets": http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html And here about "separate concerns": http://www23.brinkster.com/noicys/docs/blk.htm As TC++PL 3 says at the end of chapter 12: "Keep the representations of distinct concepts distinct; §12.4.1.1.". -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top David Hilsee Guest Posted: Sat Sep 25, 2004 6:01 am    Post subject: Re: Two questions for help! "Dave Townsend" <datownsend (AT) comcast (DOT) net> wrote Quote: "Daniel T." <postmaster (AT) earthlink (DOT) net> wrote in message news:postmaster-6B8393.23311024092004 (AT) news2 (DOT) east.earthlink.net... "away" <Gusalpine (AT) spambs (DOT) com> wrote: 1. It is showed in a book that a class has all member variables declared as protected. What's the reason for doing this? Making a variable protected ensures that only the class and sub-classes can modify the variable. The assumption is that sub-class writers will be careful enough. Personally, I feel that all variables should be declared private. Can you enumerate why all variables should be private ? I've written classes a a number of times where I've made all variables private and had to write numerous member functions to allow access to the variables by the derived classes, it didn't seem that there was much advantage and a lot of extra code was needed to wrap the data member . It seems to me that there are good reasons for making variables protected :- 1. if the derived classes would access them 2. modifying these variables does not require side effects. It's generally a philosophical design issue. However, you must admit that a protected getter/setter member function pair provides a little more flexibility than a protected member variable. If you ever wanted the base class to perform some sort of action (e.g. validation of the member's value) when the member was changed, then the getter/setter approach would be very beneficial. The cost is that there are a couple of extra member functions, which may or may not be a problem for you, depending on your environment. -- David Hilsee Back to top Dave Townsend Guest Posted: Sat Sep 25, 2004 6:02 am    Post subject: Re: Two questions for help! "Ioannis Vranos" <ivr (AT) guesswh (DOT) at.grad.com> wrote Quote: Dave Townsend wrote: Can you enumerate why all variables should be private ? I've written classes a a number of times where I've made all variables private and had to write numerous member functions to allow access to the variables by the derived classes, it didn't seem that there was much advantage and a lot of extra code was needed to wrap the data member . It seems to me that there are good reasons for making variables protected :- 1. if the derived classes would access them 2. modifying these variables does not require side effects. One value of the data-hiding is that it isolates the implementation from the functionality. So for example if you have // Silly example class someClass { string fullName; // ... public: //... string getName() const; void setName(const string &newName); // ... }; class fullClass: public someClass { string address; // ... public: // ... string getAddress() const; void setAddress(const string &); // ... }; Now imagine that one day for some reason, you decide to change fullName to char *. All you have to do is modify someClass::getName() and someClass::setName(). Had you reimplemented these member functions and in general allowed access to fullName in all derived classes, you should modify all of them. However there are cases when it is good to have this access. There is no "silver bullet". Have a look here about "silver bullets": http://www.itworld.com/AppDev/710/lw-02-stroustrup/page_1.html And here about "separate concerns": http://www23.brinkster.com/noicys/docs/blk.htm As TC++PL 3 says at the end of chapter 12: "Keep the representations of distinct concepts distinct; §12.4.1.1.". -- Ioannis Vranos http://www23.brinkster.com/noicys Yes, I agree, this would be a consideration to keep the members private. But I often come across the same pattern in GUI programming, the base class has a bunch of members, ( for instance the parent pointer to the parent widget of this component, or the "container" of this component). I find I seem to be mindlessly writing accessor functions which don't seem to add much value. Just a thought. dave Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 6:41 am    Post subject: Re: Two questions for help! Dave Townsend wrote: Quote: Yes, I agree, this would be a consideration to keep the members private. But I often come across the same pattern in GUI programming, the base class has a bunch of members, ( for instance the parent pointer to the parent widget of this component, or the "container" of this component). I find I seem to be mindlessly writing accessor functions which don't seem to add much value. Just a thought. So do you mean that those data members should be made public? What if the base class changes some day? -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top Dave Townsend Guest Posted: Sat Sep 25, 2004 6:42 am    Post subject: Re: Two questions for help! "David Hilsee" <davidhilseenews (AT) yahoo (DOT) com> wrote Quote: "Dave Townsend" <datownsend (AT) comcast (DOT) net> wrote in message news:g4idnTtVuvwracncRVn-vA (AT) comcast (DOT) com... "Daniel T." <postmaster (AT) earthlink (DOT) net> wrote in message news:postmaster-6B8393.23311024092004 (AT) news2 (DOT) east.earthlink.net... -- It's generally a philosophical design issue. However, you must admit that a protected getter/setter member function pair provides a little more flexibility than a protected member variable. If you ever wanted the base class to perform some sort of action (e.g. validation of the member's value) when the member was changed, then the getter/setter approach would be very beneficial. The cost is that there are a couple of extra member functions, which may or may not be a problem for you, depending on your environment. -- David Hilsee I think the keypoint is that if invalidation is required when accessing member variables, then setters/getters would be the way to go, otherwise its reasonable to consider accessing the members directly in the derived class. A better example came to my mind, in the project I'm working on, we have a lot of interface pointers passed around. Typically, an GUI object will have a member variable which holds an interface pointer, it doesn't seem to reduce complexity by providing an access function in this case for the derived classes, all you can do is call methods on the interface, you cannot change the pointer value. Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 6:54 am    Post subject: Re: Two questions for help! Ioannis Vranos wrote: Quote: So do you mean that those data members should be made protected? Quote: What if the base class changes some day? I am writing GUI applications in .NET,and all .NET classes come with public, protected and private methods and properties(=member functions again). So if the internal representation (data members) some day change, there is a good possibility the member functions will not. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top Dave Townsend Guest Posted: Sat Sep 25, 2004 10:17 am    Post subject: Re: Two questions for help! "Ioannis Vranos" <ivr (AT) guesswh (DOT) at.grad.com> wrote Quote: Ioannis Vranos wrote: So do you mean that those data members should be made protected? What if the base class changes some day? I am writing GUI applications in .NET,and all .NET classes come with public, protected and private methods and properties(=member functions again). So if the internal representation (data members) some day change, there is a good possibility the member functions will not. -- Ioannis Vranos http://www23.brinkster.com/noicys No, that is not what I'm saying. If the data members are likely to change or changing their values could generate side effects, then having member functions is the way to go. In other situations it depends on the circumstances. I never said the data members should be public. The pattern that keeps popping up in my line of work is a class contains a member variable which is an interface pointer (com like). In this situation, you can only call methods of the interface, not change the interface pointer value. So I think in this type of situation its ok to access this as a protected variable. ( or lets be weaker, to consider this for being a protected variable). dave Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 5:12 pm    Post subject: Re: Two questions for help! Dave Townsend wrote: Quote: No, that is not what I'm saying. If the data members are likely to change or changing their values could generate side effects, then having member functions is the way to go. In other situations it depends on the circumstances. I never said the data members should be public. The pattern that keeps popping up in my line of work is a class contains a member variable which is an interface pointer (com like). In this situation, you can only call methods of the interface, not change the interface pointer value. So I think in this type of situation its ok to access this as a protected variable. ( or lets be weaker, to consider this for being a protected variable). I suppose you mean that it looks messy to type member function calls for this particular task? Well, hasn't your platform the notion of property? -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top David Hilsee Guest Posted: Sun Sep 26, 2004 9:47 pm    Post subject: Re: Two questions for help! "Dave Townsend" <datownsend (AT) comcast (DOT) net> wrote Quote: "David Hilsee" <davidhilseenews (AT) yahoo (DOT) com> wrote in message news:GaGdnV0uyv8IlMjcRVn-ig (AT) comcast (DOT) com... "Dave Townsend" <datownsend (AT) comcast (DOT) net> wrote in message news:g4idnTtVuvwracncRVn-vA (AT) comcast (DOT) com... "Daniel T." <postmaster (AT) earthlink (DOT) net> wrote in message news:postmaster-6B8393.23311024092004 (AT) news2 (DOT) east.earthlink.net... -- It's generally a philosophical design issue. However, you must admit that a protected getter/setter member function pair provides a little more flexibility than a protected member variable. If you ever wanted the base class to perform some sort of action (e.g. validation of the member's value) when the member was changed, then the getter/setter approach would be very beneficial. The cost is that there are a couple of extra member functions, which may or may not be a problem for you, depending on your environment. -- David Hilsee I think the keypoint is that if invalidation is required when accessing member variables, then setters/getters would be the way to go, otherwise its reasonable to consider accessing the members directly in the derived class. A better example came to my mind, in the project I'm working on, we have a lot of interface pointers passed around. Typically, an GUI object will have a member variable which holds an interface pointer, it doesn't seem to reduce complexity by providing an access function in this case for the derived classes, all you can do is call methods on the interface, you cannot change the pointer value. I'm not sure that I understand what you mean. Do you mean class Foo { // ... protected: Interface * p_; }; or class InterfaceHolder { // ... private: Interface * p_; }; class Foo { protected: InterfaceHolder other_; }; At any rate, I think that a class should try to hide information from derived classes and other code. In order to hide information from derived classes, I use protected sparingly and don't place anything other than member functions in the "extended interface" presented to the derived classes. If you don't treat derived classes as "special" when it comes to information hiding, then the same reasoning that keeps you from making something public will also keep you from making it protected. Of course, occasionally, it's impossible to avoid "protected". -- David Hilsee Back to top Ron Natalie Guest Posted: Mon Sep 27, 2004 5:43 pm    Post subject: Re: Two questions for help! "Daniel T." <postmaster (AT) earthlink (DOT) net> wrote Quote: Making a variable protected ensures that only the class and sub-classes can modify the variable. Or can even read it. Quote: Personally, I feel that all variables should be declared private. This is correct. People who make things protected by default are only slightly less sloppy than those who leave them public. There's good reason why the default access control on classes is private. Quote: 2. Unnamed namespace and global scope, are they equivalent to each other? No. A variable declared in an unnamed namespace can only be accessed from the cpp file that contains it. Actually, in the TRANSLATION UNIT in which it is defined. By and large C++ cares nothing about files, but it's the stream of the base file and all it's includes together that matters. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.