1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
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.
|
