OSF DCE Application Development Guide--Core Components

Attribute Configuration Language
Do not use nocode on any of the operations if the compiler is generating only server
stub code because it has no effect. Server stubs must always contain generated code for
all operations.
In the following example, the IDL compiler generates client stub code for the operations
open, read, and close, but not for the operation write. An alternative method for
specifying the same behavior is to use [nocode] write( ) in the ACF.
Example Using the code and nocode Attributes
ACF
[nocode,auto_handle] interface open_read_close
{
[code] open();
[code] read();
[code] close();
}
IDL File
[uuid(2166d580-0c69-11ca-811d-08002b111685)]
interface open_read_close
{
void open (...);
void read (...);
void write (...);
void close (...);
}
18.3.9 The represent_as Attribute
This attribute associates a local data type that your application code uses with a data
type defined in the IDL file. Use of the represent_as attribute means that, during
marshalling and unmarshalling, conversions occur between the data type used by the
application code and the data type specified in the IDL.
The represent_as attribute has the following syntax. (See the example at the end of this
section.)
typedef [represent_as (local_type_name)] net_type_name;
The local_type_name is the local data type that the application code uses. You can
define it in the IDL file or in an application header file. If you do not define it in the IDL
file, use the include statement in the ACF to make its definition available to the stubs.
The net_type_name is the data type that is defined in the IDL file.
The represent_as attribute can appear at most once in a typedef declaration in an ACF.
124245 Tandem Computers Incorporated 18− 13