*** empty log message ***

1 files changed, 47 insertions, 0 deletions

diff --git a/TAO/tests/DynAny_Test/README b/TAO/tests/DynAny_Test/README
new file mode 100644
index 00000000000..2a00456ee91
--- /dev/null
+++ b/TAO/tests/DynAny_Test/README
@@ -0,0 +1,47 @@
+
+DynAny_Test files, updated 9/17/98.
+
+
+What we have so far starts with the DynAny.idl file. Since TCKind is required
+as a return type in one or two of the functions by the spec, another file called
+tckind.idl is included in DynAny.idl, but is not included in the NT project build.
+This causes the TAO IDL compiler to generate include statements for files called
+tckindC.h and tckindS.h which don't exist, so these statements must be commented
+out of the generated source files. Note that tckind.idl contains a copy of the
+enum in Orb.h, so if the TCKind enum ever changes, there will be a choice of recompiling
+from scratch or doing an extensive search and edit for code depending on this enum.
+
+Each of the _i classes inherits from the POA_ classes generated by the IDL compiler, not
+from each other in a tree structure rooted at DynAny_i. 
+This leads to some repeated code (mostly in the insert and get functions, the other common
+functions being slightly different for each class), but allows specialization of classes
+(notably DynAny_i and DynUnion_i) without inheriting useless members. Since the
+basic DynAny_i instances will populate the lowest level of any complex DynAny, this class
+has been kept as lightweight as possible, containing only an Any data member.
+
+As of now, all the pure virtual functions in the POA_ classes have been modified to be
+non-virtual (so I could instantiate a _i class that hadn't overridden every virtual function. 
+When all the code is finished, most of the pure virtual functions can be
+restored, except perhaps the insert and get functions for DynEnum_i.
+
+The file da_tests.idl contains some data structures that have been used for debugging.
+The file driver.cpp has been used for this debugging, and contains quick code that
+is erased after debugging a class, but the file will eventually contain the
+"official" test code when that code is written.
+
+Two things to note about DynUnion. The spec is vague on the action of set_as_default
+and member_name and there seems to be disparity in the interpretation of the spec by
+other vendors. In this implementation, they are interpreted as follows:
+
+set_as_default -
+	Treated as read-only, the assignment version is included to everride the
+	virtual function, but has an empty body. The fetch version returns TRUE
+	if the DynUnion has a default value and that default value is the active
+	member.
+
+member_name
+	Fetch version just returns the name (if not null) of the active member. The
+	assignment version makes active the member with the supplied name (if it is
+	valid), but does not save the previous value, so to be meaningful, an
+	insert or assignment should be done after this operation, since the new
+	active member will be uninitialized.
\ No newline at end of file