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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
// This may look like C, but it's really -*- C++ -*-
// ============================================================================
//
// = LIBRARY
// TAO
//
// = FILENAME
// nvlist.h
//
// = AUTHOR
// Copyright 1994-1995 by Sun Microsystems Inc.
//
// ============================================================================
#if !defined (TAO_NVLIST_H)
# define TAO_NVLIST_H
// @@ IS it necessary to use TAO_Export on a forward decl? I
// simply did a global replace of _EXPCLASS with TAO_Export. I'm
// not familiar enough with crazy MSVC nuances to know if this is
// necessary, what it means, etc. Perhaps Brian can shed some light
// on the subject? --cjc
class TAO_Export CORBA_NamedValue
{
// = TITLE
// NamedValue ... these occur only in "NVList" (named value list) data
// structures. The binary form of the data structure is frozen and
// visible to programs using it (e.g. from C). The C++ class supports
// some programming discipline, e.g. to avoid memory leaks.
//
// They just represent parameters to calls. The name is optional, and
// the value is packaged as an Any. The flags indicate parameter
// mode, and some ownership rules for "top level" memory.
public:
TAO_CONST CORBA::String _FAR name (void)
{ return (CORBA::String) _name; }
CORBA::Any_ptr _FAR value (void) { return &_any; }
CORBA::Flags flags (void) const { return _flags; }
~CORBA_NamedValue (void);
// = Methods required for COM IUnknown support.
ULONG __stdcall AddRef (void);
ULONG __stdcall Release (void);
HRESULT __stdcall QueryInterface (REFIID riid,
void **ppv);
private:
u_int refcount_;
ACE_SYNCH_MUTEX lock_;
CORBA::Any _any;
CORBA::Flags _flags;
const CORBA::Char *_FAR _name;
CORBA_NamedValue (void) : refcount_(0), _flags (0), _name (0) { }
friend class CORBA_NVList;
friend class CORBA_Request;
};
class TAO_Export CORBA_NVList
// = TITLE
// NVList ... this is used in the (client side) DII (Dynamic
// Invocation Interface) to hold parameters, except for the return
// parameter. It's used in the same role in the (server side) DSI
// (Dynamic Skeleton Interface).
//
// = DESCRIPTION
// Each user (client, server) provides the typecode and memory for
// each parameter using an NVList, then talks to the ORB using a
// Request or ServerRequest pseudo-object. The ORB copies data
// to/from the IPC messages (e.g. IIOP::Request, IIOP::Response)
// as appropriate.
{
public:
CORBA::ULong count (void) const
{ return len_; }
CORBA::NamedValue_ptr add_value (const CORBA::Char *_FAR ,
const CORBA::Any _FAR &,
CORBA::Flags,
CORBA::Environment _FAR &);
CORBA::NamedValue_ptr item (CORBA::Long n) const
{ return &values_ [(u_int) n]; }
~CORBA_NVList (void);
// = Methods required for COM IUnknown support
ULONG __stdcall AddRef (void);
ULONG __stdcall Release (void);
HRESULT __stdcall QueryInterface (REFIID riid,
void **ppv);
private:
// @@ Do we really need to keep these _FAR macros?
CORBA::NamedValue *_FAR values_;
u_int max_;
u_int len_;
ACE_SYNCH_MUTEX lock_;
u_int refcount_;
CORBA_NVList (void)
: values_ (0),
max_ (0),
len_ (0),
refcount_ (1)
{ }
friend class CORBA_ORB;
friend class CORBA_Request;
};
#endif /* TAO_NVLIST_H */
|
