cpp Linked List

[Mumbles]

41. Make data members private, except in behaviorless aggregates (C-style structs). 72

 

Do they really mean private, or would protected be OK? I find myself only giving functions private access if they are only called the constructor/destructor. Variables I never make private, as I've never found a reason why a derived class shouldn't have access to them.

[Clackdor]

It bothers me to read the title of this thread. A C++ linked list simply doesn't exist. It's a C concept that has been replaced by vectors in C++.

[Rick]

I think in the ideal world (again I have a hard time with this also) all data would be private no matter what and all interactions with the data would be from member functions. Even getter/setter isn't really "ideal" as simply getting the data and setting it all over the place sort of defeats the idea of a self contained encapsulated object.

 

 

Article that talks about it

http://www.javaworld...box.html?page=1

 

 

A key idea behind this is:

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

 

 

Seme quotes from article:

 

The most difficult problem in teaching object-oriented programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Novice designs are littered with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropriate reliance on the implementation of other objects.

 

The point is that an OO system is a conversation between objects. If you think about it for a moment, get/set methods just don't come up when you have a conversation. By the same token, get/set methods won't appear in your code if you design in this manner before you start coding.

 

At the end of page 5 and into page 6 is an interesting classroom example to show how to accomplish this.

 

 

A practicle idea would be to have a kill() function for an Actor class instead of exposing the isAlive flag via a setter (saw this from another article).

[Pixel Perfect]

I tend to ensure class variables are private and completely internal to the class/object. If external access is required then its provided via public or protected functions in order to maintain a high degree of encapsulation and to know the scope of any bugs/issues with the functionality lies within the class itself.

 

I also use vector templates as my container of choice unless the design dictates otherwise where I may for instance use map containers. vectors have never caused me any problem to date and are fast and efficient. I also tend to access them using direct indexing, which I know is generally frowned upon but again has never caused me any problems.

[Rick]

I find myself using maps all over the place. I almost always want to look data up easily with a key that I will have handy at the point in which I need to find something in the map. I store animation objects in a map with a string as the animation name so when I press 'W' I can say playAnimation("walk"). I find maps so handy! If I have a list of enemies I give them ID's and use that as the key so when in collision functions I can get the ID of the entity that's colliding to easily find them in the map (if I need this for whatever reason).

[Josh]

I store animation objects in a map with a string as the animation name so when I press 'W' I can say playAnimation("walk").

I think in that situation you would usually want to use an integer variable with a recognizable name like ANIMATION_WALK, but unless you are doing it hundreds of times each frame, it won't make any noticeable difference.

[TheoLogic]

It bothers me to read the title of this thread. A C++ linked list simply doesn't exist. It's a C concept that has been replaced by vectors in C++.

Vector is not a linked list, an element in a vector does not know the next element... Lists are double linked lists.

 

I find myself using maps all over the place. I almost always want to look data up easily with a key that I will have handy at the point in which I need to find something in the map. I store animation objects in a map with a string as the animation name so when I press 'W' I can say playAnimation("walk"). I find maps so handy! If I have a list of enemies I give them ID's and use that as the key so when in collision functions I can get the ID of the entity that's colliding to easily find them in the map (if I need this for whatever reason).

Indeed, maps is probably the most used container after vectors for the reasons you state. I have to agree partially with Josh's comment that you should probably use an "integer type". I suspect he means static const integers, but I would strongly suggest enumerations.

 

Do they really mean private, or would protected be OK? I find myself only giving functions private access if they are only called the constructor/destructor. Variables I never make private, as I've never found a reason why a derived class shouldn't have access to them.

Depends, it's rather a design principle. If you don't design your object to be inherited from, just make all members private, else make the members required in the subclass protected. You should never have globals (and if you have them please do add them to a namespace) and public datamembers.

Really, a book to read for everyone working with C++! It's "just" 101 rules, short book, but very handy.

[Rick]

I would say in my experience, enums for that purpose aren't dynamic enough. Ideally all animations would be stored in a database system (sqlite for example) so they can be added/removed without getting into the source. It's just more flexible to do that. Doing that one could make an argument to use an int ID, but to speed up debugging I often find using strings more convenient. It skips a lookup step of trying to figure out what the int value means. If the code hits a breakpoint and I mouse over the animation name variable value and it says "walk" I get more value from that than if it says 25. I'm not a big speed freak though as most basic indie games aren't pushing any boundaries. I value debugging speed and flexibility more than raw run-time speed myself because not to many people are pushing the envelope.

[Mumbles]

Don't worry about globals, I used to love them when I was like 15 (when I was still using Dark Basic) because they were so convenient, but now I hate them. They very quickly use up just about every name you can think of, and it becomes almost impossible to track down where it's being modified when you have a large project.

 

For me, any variables that aren't limited in scope to a single function, will either be protected access inside a class, or inside a namespace (often with many more secretly hidden inside a deeper unnamed namespace if they're supposed to be read only), depending entirely on whether I think I'm building an object, or a set of object helper functions, "CreateNewEntity()" as an example.

[TheoLogic]

I would say in my experience, enums for that purpose aren't dynamic enough. Ideally all animations would be stored in a database system (sqlite for example) so they can be added/removed without getting into the source. It's just more flexible to do that. Doing that one could make an argument to use an int ID, but to speed up debugging I often find using strings more convenient. It skips a lookup step of trying to figure out what the int value means. If the code hits a breakpoint and I mouse over the animation name variable value and it says "walk" I get more value from that than if it says 25. I'm not a big speed freak though as most basic indie games aren't pushing any boundaries. I value debugging speed and flexibility more than raw run-time speed myself because not to many people are pushing the envelope.

 

Agreed, your animation example is a good one. I might state as:

* Static: use enumerations

* Dynamic: use strings for debug, used hashes in release. You can fairly implement such system that in debug you have access to the actual string value (member of your hash object), but in release it's a hashed version only.