Archived

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

RolandofGilead

use of private?

Recommended Posts

EvilCrap    134
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   
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
RolandofGilead    100
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
Shannon Barber    1681
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   
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
Arild Fines    968
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
RolandofGilead    100
to ap, the conceptual difference as you say, is written
into the very functions themselves, would you like to also
point out that grass is green and the sky is blue?

also, I am not learning the concept of private:,
I know how to program and I know c++.
True, asking what good is private may make one wonder
about my knowledge of C++, but you really show your
small-mindedness and snobbery when you wonder about
my programming skills in general since NEWS FLASH!,
this just in, not everyone uses OO.

And thank you Arlid Fines, I also really like your sig.

------------
Freedom for the variables, let them go into public and
be free! Down with the oppression. Let them see their
relatives and friends.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by Arild Fines
Actually the anonymous namespace does hide both variables and functions.

I left that detail out for a variety of reasons, mainly because he said namespaces rather than anonymous namespaces and I didn''t see the need to confuse the issue.

Also, it''s not entirely true. Anonymous namespaces hide variables and functions within a translation unit from other translation units, something that is particularly significant at link time. Any code that can see an anonymous namespace and the variables and functions within it can access those variables and functions. Private members, however, are hidden from all code that sees them (other than their own class or friends of that class).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
RolandofGilead, I assumed that you aren''t very familiar with C++, or programming in general, because you don''t seem to grasp the significance of data declared in a struct or class vs. data declared globally or locally. If you''ve accomplished something such as writing an application with 100,000+ lines of code or working with a team of 10 other programmers or maintaining a code base for 3+ years without using structs or classes then I commend you and apologize.

Share this post


Link to post
Share on other sites
Shannon Barber    1681
quote:
AP
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


Get/Set tuples CANNOT SOLVE THREAD SYNCRONIZATION ISSUES.
Let''s have a race...


...
Even if you''re not using OOP Rolando, I''m willing to bet you''re still using encapsulation and data-hiding, which is what classes and private do for you. The C file functions are encapsulated, you pass a FILE* to those functions; and the implementation details of the FILE are hidden from you (kinda like the private parts of a class).
Any time you use a handle this will be the case - HWND, EVENT, CRITICALSECTION (true you can fiddle it if you want to, but your not suppose to, private enforces this in C++).

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
Oluseyi    2103
There seems to be a recent trend of seemingly under-informed individuals criticizing established and validated constructs for no apparent reason other than that they "don''t like it."

Obligatory insultive responses to obligatory incendiary comment >&/dev/null

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
DrPizza    160
quote:
Get/Set tuples CANNOT SOLVE THREAD SYNCRONIZATION ISSUES.

They can indeed. If your ''set'' is a complex operation that needs to be performed atomically and would be broken if a value were changed half way through (which is possible with multithreading), wrapping it in a critical section (which accessors permit but public variables do not) will prevent corruption from occurring. It will force serialization of attempts to alter the variable, which is desirable.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by Magmai Kai Holmlor
Get/Set tuples CANNOT SOLVE THREAD SYNCRONIZATION ISSUES.
Let''s have a race...

Yeah, obviously. Whoever said they can? Are there people who monitor these forums for the sole purpose of seeking out something to misquote so they can point out some pedantic detail that has nothing to do with the original point?

I never implied that Get/Set methods are a general solution to thread synchronization. However, as explained by DrPizza, there are cases where thread safety can be or needs to be handled within a Get or Set method.

Share this post


Link to post
Share on other sites