Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

RolandofGilead

use of private?

This topic is 6042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
The private keyword helps when you want to make sure that nothing except that class can alter its contents, not even classes that derive it.

Share this post


Link to post
Share on other sites
the private describes the scope of a class variable. a public variable will be accessible from anywhere, while a private varaible is only accessible from class member and freind funtions.

its useful for data hidding.
for instance, if you has a class with a variable that can be read, but not written to, you could do this:

class A{
public:
inline int Width();
private:
int m_Width;
};
int A::Width()
{
return m_Width;
}

Edited by - evilcrap on December 31, 2001 11:21:30 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It helps by separating interface from implementation. Declaring the implementation details private shields users of a class from changes that the author/maintainer of the class might decide to make.

For example, in the previously mentioned example of class A, if m_Width is public, a user might write code that directly accesses it. Then, the implementer of the class may decide to eliminate m_Width and instead calculate the width on the fly from some coordinates also stored with the class. Users of the class who used m_Width will now get quite upset when they update to the latest version of class A and get errors when they try to compile. If the Width() method is used instead, the implementer can make internal changes without breaking users'' code.

Share this post


Link to post
Share on other sites
OOP???

Really?

It sounds marvelous, where oh where can I find this
magical OOP?

In the class's interface there's usually a MyClass::SetX();
for everything and if there's a Set, then there's a way
to change the var.

If the var is only used in methods, then you might as well
have a local var. It's like a global var on a smaller scale.
And everyone keeps saying global vars are bad.
Oh and you could use namespaces instead.
Since everyone insists on separate .cpp files for each class,
you could do without OOP and use the separate .cpp files and
it would be impossible to access those variables without
the extern keyword.

Most importantly, when looking at the code, honestly what
difference is there between

draw(&this);
draw(&that);

and

this.draw();
that.draw();

Some of what I'm saying could be wrong, I wish I could find
that post where this guy shows how to convert from C to C++
including the OOP aspects.

Create.
Liv Tyler makes a really great elf.


[edit: #@$#@$ I almost did it again (those edit and quote button need to be further apart)]

Edited by - Magmai Kai Holmlor on January 1, 2002 4:35:58 AM

Share this post


Link to post
Share on other sites
quote:

In the class''s interface there''s usually a MyClass::SetX();
for everything and if there''s a Set, then there''s a way
to change the var.


I concur, I very rarely do this. It also allows you to create side-effects, which are poor design, imnsho, but some people like them.

quote:

If the var is only used in methods, then you might as well
have a local var.


Wrong, if it''s used in a method make it local, if it''s used in methods it can''t be local; this is a good candidate for a private (or perhaps protected) variable.

quote:

It''s like a global var on a smaller scale.


Every (non-global) variable is a ''global var on a smaller scale''.

quote:

And everyone keeps saying global vars are bad.


Not always, but usually.

quote:

Oh and you could use namespaces instead.


Code bandaid to a design problem. If you going to write alot of common/related code, a namespace for it is a good idea. namespace MyGameEngine....

quote:

Since everyone insists on separate .cpp files for each class,
you could do without OOP and use the separate .cpp files and
it would be impossible to access those variables without
the extern keyword.


I put related classes in the same header and cpp, one class per h/cpp would get outta hand in a hurry. It''s not unusual to find only one class in a file, but I wouldn''t insist on it.
It wouldn''t be the same, because there''d only one instance of those variables - if it''s in a class there''s a different variable for each instance. If you don''t think data-hiding is a good idea, then OOP isn''t for you. If you don''t think encapsulation is a good idea... only harsh words come to mind. Everything that makes-up OOP isn''t specific and special about it - encapsulation is found everywhere; even ID does this.

quote:

Most importantly, when looking at the code, honestly what
difference is there between

draw(&this);
draw(&that);

and

this.draw();
that.draw();


Well, looking at it: in the first case you have a function being pass a variable by address; in the second case you have a method being invoked on an object.
Now, if you meant the disassembly, absolutely none (look at it sometime).

OOP isn''t magic, it''s just additional language support for good design and coding practices - many aspects of which are done even when you''re not using OOP.

So, the private section of a class let you control what code has access to those methods and variables. Know what private does -> how private is useful.


Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
In the class''s interface there''s usually a MyClass::SetX();
for everything and if there''s a Set, then there''s a way
to change the var.

If there is, then it''s either a coincidence of interface and implementation, or (more likely) bad design. The public interface of a class should mostly reflect the logical use of that class, not the physical implementation. If someone provides Get/Set for every private member, it is better than allowing direct access, but it''s far from ideal (for the same reason that direct access is far from ideal). If you have a SetX method, you have the option of going back in the future and easily adding features to it if needed, for example logging for debugging purposes or some kind of lock for thread safety. Direct access does not allow this to be done easily.
quote:
If the var is only used in methods, then you might as well
have a local var. It''s like a global var on a smaller scale.
And everyone keeps saying global vars are bad.

That''s totally false. The lifetimes of global, local, and class variables differ greatly. Global variables exist from program startup to program shutdown. Local variables exist from the point they are encountered in a block of code to the end of that block. Class variables exist from class creation to destruction.

I get the impression from this that you aren''t really familiar at all with C/C++ (or programming in general). Before attempting to learn concepts like ''private'', it''s probably a good idea to understand basic concepts like variable scope.
quote:
Oh and you could use namespaces instead.

Nope, for the same reason listed above. Also, there''s really no relation here with ''private'' since namespaces do nothing to hide variables or functions declared within them from other code.
quote:
Since everyone insists on separate .cpp files for each class,
you could do without OOP and use the separate .cpp files and
it would be impossible to access those variables without
the extern keyword.

This is also false for the same reasons as above, but it is similiar in that both are a form of encapsulation/information hiding. One of the uses of OOP features in C++ is to take advantage of this kind of hiding on a much broader and more formal scale. If you can accept that hiding stuff in different CPP files is useful, then it shouldn''t be difficult to understand why the generalized concept (included the ''private'' keyword) is useful. You simply need to understand why a class is different than a CPP file (and why global variables are different from class variables).
quote:
Most importantly, when looking at the code, honestly what
difference is there between

draw(&this);
draw(&that);

and

this.draw();
that.draw();

It''s not a good idea to use ''this'' as an example name because it''s a reserved, and important, keyword in C++, but that''s beside the point.

The major conceptual difference between draw(&that) and that.draw() is who is doing the drawing. draw(&that) implies that the draw function is something external to ''that'' that knows how to draw variables of whatever type ''that'' is. that.draw() implies that the drawing is being done by ''that'' itself.

Both forms can be useful, thus the existance in STL of both a std::find function and classes that contain their own ''find'' functions. std::find knows how to generically find something from the variables passed, given the availability of a few simple operations. The classes that have their own ''find'' functions have them because the internal details of the implementation allows them to implement a better ''find'' algorithm.

Share this post


Link to post
Share on other sites
quote:

Nope, for the same reason listed above. Also, there''s really no relation here with ''private'' since namespaces do nothing to hide variables or functions declared within them from other code.


Actually the anonymous namespace does hide both variables and functions.


Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!