Ok... I find myself in a major quandry. I posted this in the General Programming board, but they didn''t respond. You guys are smarter anyway! I began this project by setting up classes as follows:
Notice that the objects are on the heap and I am creating an array of pointers to those objects. Now, for some of my collections... I created STL lists instead... for example:
The result is similar in that I end up with a list of pointers to objects that are created on the heap. My problem with method one stems from the fact that a lot of times these classes need to grab information (either data or results of functions) from many other classes. What''s worse, there are often times when I have to cascade through a number of classes to do this. For example, A is a B which is of type C. A now needs to get data from C via it''s relationship with B. I realize that I can create a function in A which retrieves a function in B which retrieves a function in C... but my problem is as follows. If we are storing the relationships between A-B and B-C as index IDs for the BCollection and CCollection objects, we need to have a reference to those collections. If A needs to ask BCollection about a particular B, I need to have passed in a reference to BCollection. Subsequently, the call to B (from BCollection) will need to have a reference to CCollection so that B can get the data (eventually) from C. It would seem that the original call to A would have to have references to BCollection AND CCollection. When I shifted to using pointers instead, I didn''t have to have A go through BCollection but rather called a function of B directly using mMyData = B->MyFunction(); B->MyFunction() could then call C directly by pointer using return C->CsFunction(); I thought my problem was solved. Of course, then I realized that I have no way of loading data from the file that says A is of this specific type of B. I had originally stored the index of BCollection that A was refering to... obviously I can''t store the pointer the same way. I made a quick effort to change my data load function to ask BCollection to return the pointer to a B object when I gave it the index to the array. However, I had originally been calling the data load function of ACollection in its constructor and I ran into some issues so I quickly backed out my changes prior to rethinking the issue. That brings me to you guys... I have many objects here to deal with with some very complicated relationships between them. At times, they may need to access data/functions from many different other objects of other classes. I am loathe to have all my function calls passing around &references to very many different classes unless that is the best way to go. How is this sort of issue generally handled? Is it common to pass references to 4-6 different class objects around at all times? Is there any value to creating a master object to pass around where the various collection objects are members of it? Are pointers the way to go instead so I can just get directly to the specific object I want to store as member data? If so, what is a good technique for saving references such as that in data files other than how I mentioned (saving an index to an array of pointers and converting the index to the actual pointer as you load it)? Your help would be appreciated! Dave Mark - President and Lead Designer Intrinsic Algorithm - "Reducing the world to mathematical equations!" RIPPL Sports - NFL Statistical Analysis and Prediction System

I'm having difficulty understanding your problem so forgive me if I'm wrong here...

You seem to be saying that you have several 'master' classes that are accessed frequently by many other classes to retrieve data of some sort.

One thing that may be useful to you is the 'singleton' design pattern. This will enable any of your classes to access the data at any time and with the minimum of fuss.

There are many articles to be found online about singletons so I'll leave the implementation details to your favorite search engine.



[edited by - fup on January 26, 2003 2:36:05 PM]

Singletons are something that I haven''t gotten into yet. (I''m a VB guy who has taught himself a shitload of C++ in the past 6 weeks.) What you are saying is that they almost come across as a global?

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

yes, but safe (ish). They are a way of guaranteeing that only one instance of a particular class is instantiated. The class is made available through a static pointer that points to the instance. (So you can access it using syntax like CMyClass::Instance()->DoStuff() from anywhere within your program)



ai-junkie.com

So in the example I gave above, the best bet would be to make my "collection" classes into singletons. We know there will only be one collection of these sorts of things. If I then write the functions in the collection class to retrieve the data from the child class that the collection is holding, I can get that data from anywhere by going through the singleton collection.

I was looking at the "gem" 1.3 from "Gems 1" regarding an automatic Singleton utility. That looks like a convenient way of setting them up. Anyone seen that gem and made use of it?

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

Like fup, I too am trying to figure out a) what it is you are trying to do; and b) what your exact problem is.

If fup''s suggestion hasn''t solved your problem, could you give a more concrete example please with surrogate variables and relationships?

Thanks,

Timkin

Let me give an example then. Here are some relationships:

A flight is assigned an aircraft.
An aircraft is of a certain config (seating, etc.)
An aircraft is of a certain type (which gives us size, body style)

To calculate the estimated passenger loading time for the flight, we need to know the number of seats (from "config") and the body style (e.g. narrow, wide, commuter from "type").

My classes are as follows.

Flight //has a pointer to aircraft
FlightCollection //std::list of flights

Aircraft //needs a config and a type - index or pointer?
AircraftCollection //std::list of aircraft

Config //also point to type - has functions for returning boarding times
ConfigCollection //either array or list?

Type
TypeCollection //either array or list?

With this structure, I would have to have the Flight class calling functions from Config and Type. The way I had done it was through the container ("collection") classes. Of course, that would necessitate that I pass those classes in by reference. That''s fine if you are passing one or two around, but it was getting to the point where I was having to pass 3-6 of them around by reference. Not tidy at all. That''s when I was looking for a better way.

With an experiment today, I have found out that I can do it by declaring those container classes as Singletons (thanks fup) so I can call their functions at will.

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

I''m confused. Why can''t you just access the collection classes as you would access any other global variable? And what was the problem with your idea of having collections of pointers and storing a pointer whenever needed rather than a collection index?

quote: Original post by Diodor
I''m confused. Why can''t you just access the collection classes as you would access any other global variable?

Uh... because they aren''t global? And it may not be a good idea (or good style) to make them global?

quote: And what was the problem with your idea of having collections of pointers and storing a pointer whenever needed rather than a collection index?

Because, as I mentioned, I then run into problems with saving data. If A has a * to B, I can''t save A to a file (or load it) with that pointer - it would be an ambiguous memory address.



Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

quote:
Original post by InnocousFox

Uh... because they aren't global? And it may not be a good idea (or good style) to make them global?

Can't argue with that


Just an idea: you can store references to the collection classes as static members in all your classes that need to access the collection. So now you can simply access them from whenever you need the collections by using just a member variable. This doesn't rule out using a singleton by any means.

[edited by - Diodor on January 27, 2003 10:23:14 PM]