Two questions for help!

[away]

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!

[Daniel T.]

"away" <Gu*******@spambs.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.
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.

[Mike Wahler]

"away" <Gu*******@spambs.com> wrote in message
news:rv*********************@bgtnsc05-news.ops.worldnet.att.net...

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.

2. Unnamed namespace and global scope, are they equivalent to each other?

No.

-Mike

[Phlip]

Daniel T. wrote:

2. Unnamed namespace and global scope, are they equivalent to each

other?

Are these from a test?
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/bi...UserInterfaces

[Dave Townsend]

"Daniel T." <po********@earthlink.net> wrote in message
news:po******************************@news2.east.e arthlink.net...

"away" <Gu*******@spambs.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.

[Ioannis Vranos]

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...up/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

[David Hilsee]

"Dave Townsend" <da********@comcast.net> wrote in message
news:g4********************@comcast.com...

"Daniel T." <po********@earthlink.net> wrote in message
news:po******************************@news2.east.e arthlink.net...

"away" <Gu*******@spambs.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

[Dave Townsend]

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:cj***********@ulysses.noc.ntua.gr...

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...up/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

[Ioannis Vranos]

Dave Townsend wrote:

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

[Dave Townsend]

"David Hilsee" <da*************@yahoo.com> wrote in message
news:Ga********************@comcast.com...

"Dave Townsend" <da********@comcast.net> wrote in message
news:g4********************@comcast.com...

"Daniel T." <po********@earthlink.net> wrote in message
news:po******************************@news2.east.e arthlink.net... --
It's generally a philosophical design issue. However, you must admit that

aprotected 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.

[Ioannis Vranos]

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

[Dave Townsend]

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:cj**********@ulysses.noc.ntua.gr...

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

[Ioannis Vranos]

Dave Townsend wrote:

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

[David Hilsee]

"Dave Townsend" <da********@comcast.net> wrote in message
news:RZ********************@comcast.com...

"David Hilsee" <da*************@yahoo.com> wrote in message
news:Ga********************@comcast.com...

"Dave Townsend" <da********@comcast.net> wrote in message
news:g4********************@comcast.com...

"Daniel T." <po********@earthlink.net> wrote in message
news:po******************************@news2.east.e arthlink.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

baseclass 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 verybeneficial. 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

[Ron Natalie]

"Daniel T." <po********@earthlink.net> wrote in message news:postmaster-

Making a variable protected ensures that only the class and sub-classes
can modify the variable.
Or can even read it.
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.

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.