_gr_todo.cpp

// _gr_todo.cpp

1) Check for assignment from this in operator=().
2) Allow initialization of forward iterator with graph link.
3) Add an allocator for allocation of temporary info ( i.e. destruction info, copy info, fwd iterator info etc. ).
4) Remove stray links after a closed directed copy.
5) Decide whether stray links can be constructed - may want to allow a base class link that has a boolean
		indicating whether the link is constructed or not. Then we could templatize the graph by whether stray
		links are allowed. This would complicate the templated perhaps - there is likely a way to avoid
		any cost whatsoever through compile time mechanisms.
		SOLUTION: Just add a boolean FIsConstructed() to the link base that currently returns false if either
			of its nodes are null. Then we can change the functionality in the future with ease ( if we also call
			the function at the appropriate times.
6) Optimization: Check the code to make sure that the more likely block is result of the first if() - i.e.
		not the else.
7) Make the most natural base class the first - this lets gdb see them - it won't check multiple inheritance
		in some scoping cases.
8) Low priority: When throwing is turned off methods should return values when allocation fails, etc.
		This would let us be more OLE compatible when the time comes.
9) Fast objects: We can have objects where the data structures that allow fast iteration are kept
		up to date at all times - this would allow many interesting things to occur. The cost of forward
		iterators is reduced somewhat - since the data for the forward iteration need not be stored inline.
		IDEA: Store the data for a forward iteration within a ( per-connected region of nodes ) data structure - 
		we can allow it to be filled as used.
10) Shadow graphs - graphs whose elements ( or even part of whose elements ? ) are linked to some main graph.
		We could have auto-updating shadow graphs that automatically mimic there parent graph as changes are
		made. The graphs would have to have knowledge of each other's existence. The cool thing about this is that
		the main graph remains constant size while the shadows add operations and functionality. Perhaps could
		have "lazy" functionality - i.e. have the shadow graph on another lower-priority thread. The safety mechanism
		already takes care of updating the shadow when the main graph's elements go away.
11) Make copying a bit more efficient by getting rid of directional hash tables. We could also specialize
		(somehow) when using an arena to hold the information in these lookups - since we could then de-allocate
		without performing any data-structure unlinking ( i.e. the hash table destructors ). Some mechanism where
		by an arena registers thoses things allocating from it ( i.e. through a member of _allbase.h struct ) - then
		a set of object could be "destroyed" at one time - if it is found that an arena would be cleared by this
		operation then skip de-initialization and merely restore all the data structures to their initial state -
		i.e. call the constructor again. We could use the SGI small allocator as a pool - we already have this -
		we could even make it more efficient by compile-time "registration" of used size pools - not that
		this is such an improvement. Then when we destroy temporaty look-up tables with small element sizes 
		we can have an interface like: SetInitialClearElement(), AddClearElement(), FinishClearElements() - which
		either executes all of the clears on each of the correponding objects or merely calls the constructor
		on each of these objects. This would significantly improve many things - including iteration, copy,
		reading and writing. Since in all of these cases we call clear on at least some of the lookup tables.
		We could also likely figure out a way to do this at compile time - except that we would certainly
		have to organize those objects that would be cleared together in some type of data structure and
		somehow compare this with another data structure that is generated by "adding" memory users together.
		This creates static types which can then be compared against the same static types that would be
		gernerated by the clear type object - generated similarly. If the types were the same then the constuctors
		would be called - otherwise the clears would be called.
12) Pull a base class out of the copy stuff and use member function pointers to do the construction
		of the new nodes. This will not only conserve code, but will also allow some interesting construction
		options - i.e. for the construction of "shadow" graphs.
13) Update copying to deal appropriately with unconnected links ( I don't think it does now ).
		Taking into account FIsConstructed().
14) Test throw-safety - this involves checking for every place that could throw and putting a throw object
		of some sort there whose throwing can be controlled. Then ensure that the state remains the same.
15) "skip zones" on a stream - could allow records to be skipped - or even parts of records. Easy to implement
		as a set. Could also keep an associated data structure for fast seek(), tell() support. Could even allow
		the skip zone to contain substitute data.
16) Better test border cases where two unfinished nodes from different directions are multiply connected.
		There is very likely a bug in copy. Should be fixed need to test it - very simple graph.
17) Move Init() into the allocation methods.
18) New paradigm - destruction can throw ( for cases like copy-on-write ) but deallocation cannot throw.
19) Get rid of recursive copy - cannot handle large numbers ( like 160000 ) of nodes and links - use context
		stack as in forward iterator.
20) Should swap instanced allocators - need to update the STL as well in this regard.