VisiBroker for C++ Developer’s Guide : Programmer tools for C++

Programmer tools for C++
This chapter describes the programmer tools offered by VisiBroker for C++.
VisiBroker for C++ Switches for Header Files
The following switches are used to point consumers of the header files to the proper code libraries.
_VIS_STD
On Windows, earlier versions of VisiBroker for C++ provided libraries for both Classical and Standard C++.
In VisiBroker version 8.5, only the Standard C++ libraries are supported. Therefore, the _VIS_STD compiler flag is now mandatory.
_VIS_NOLIB
On Windows, a VisiBroker for C++ header file (vdef.h) automatically places the VisiBroker for C++ library search records in the object files. This is done using the #pragma comment for both MSVC and BCB compilers. Depending on certain other definition such as _DEBUG, VISDEBUG or _VIS_STD, appropriate library search records are selected. If this behavior is not required and VisiBroker for C++ library names are to be specified explicitly in the application link command, then _VIS_NOLIB should be defined. By default it is not defined.
Arguments/Options
There is a set of arguments common to all VisiBroker programmer's tools and, in addition, each tool has its own arguments. The specific arguments and options for each tool are listed in the section for the tool. The general options are listed below.
General options
The following options are common to all programmer tools:
Note
On UNIX platforms, the -J option is only available with VisiBroker Edition for Java on Solaris.
General information
The syntax of the VisiBroker programming tools described in this chapter differs depending on whether you call them from a UNIX or a Windows environment. The UNIX version of each tool is listed first followed by the Windows version.
UNIX
To display the options of a command under UNIX, enter:
Windows
To display the options of a command under Windows, enter:
idl2cpp
This command implements VisiBroker's IDL to C++ compiler, which generates client stubs and server skeleton code from an IDL file.
Syntax
idl2cpp [arguments] infile(s)
idl2cpp takes an IDL file as input and generates the corresponding C++ classes for the client and server side, client stubs, and server skeleton code.
The infile parameter represents the IDL file for which you wish C++ code to be generated and the arguments provide various controls over the resulting code.
Example
idl2cpp -hdr_suffix hx -server_ext _serv -no_tie -no_excep-spec bank.idl
Windows: When linking implementations based on the stubs and skeletons idl2cpp generates, use the -DSTRICT preprocessor option. Otherwise, the linker may display an error message stating that a constructor is missing from orb.lib.
Defines a preprocessor macro foo, optionally with a value bar. To specify more than one preprocessor macro, use the -D option multiple times. For example: -Dfoo=bar -Dhello=world
Specifies an additional directory for #include searching. To specify more than one additional #include directory for searching, use the -I option multiple times. For example: -I/home/include -I /app/include
Specifies the file extension to be used for client files that are generated. The default extension is (_c). To generate client files without an extension, specify none as the value for <file_extension>.
Generates the _pretty_print method. By default, this is set to on.
Generates class stream operators with standard iostream classes in their signature. The default is on.
Generates the _tie template classes. By default, _tie classes are generated.
Generates a warning if a #pragma is not recognized.
Causes the #include <filename> directive to be inserted in generated code instead of the usual#include <corba.h> directive. By default, #include <corba.h> is inserted into generated code.
Windows: -export <tag>
Defines a tag name to be inserted into every client-side declaration (class, function, etc.) that is generated. Specifying-export _MY_TAG when invoking idl2cpp results in a class definition like this:   class _MY_TAG Bank{...} instead of   class Bank {...} By default, no tag names for client-side declarations are generated.
Windows: -export_skel <tag>
Defines a tag name to be inserted into just the server-side declarations that are generated. Specifying -export _MY_TAG when invoking idl2cpp results in a class definition like this:  class _MY_TAG POA_Bank{...} instead of   class POA_Bank {...} By default, no tag names for server-side declarations are generated.
Specifies the file extension to be used for server files that are generated. The default extension is (_s). To generate server files without an extension, specify none as the value for <file_extension>.
Requires -type_code_info flag. Generates pointer insertion/extraction into/from CORBA::Any. By default, it is off.
Requires -tie flag. Generate a tie class within same scope as skeleton class. By default, it is off.
The orb.idl has conditional definitions which are specific to either VisiBroker for C++ or VisiBroker for Java. Therefore, if you want to include the orb.idl in your IDL, you must turn on the VisiBroker for C++-specific definitions using the CPP macro. For example, use the following: idl2cpp -D CPP test.idl. Alternately, you may put the following line at the top of your IDL file:
idl2ir
This command allows you to populate an interface repository with objects defined in an Interface Definition Language source file.
Syntax
idl2ir [-ir <IR_name>] [-replace] <filename>.idl [<filename2>.idl ...]
Example
idl2ir -ir my_repository -replace bank/Bank.idl
Description
The idl2ir command takes the name of an IDL file as input, binds itself to an interface repository server, and populates the repository with the IDL constructs contained in <filename>.idl. If the -replace option is specified, if the repository already contains an item with the same name as an item in the IDL file, the old item is replaced.
Note
The idl2ir command does not handle anonymous arrays or sequences properly. To work around this problem, typedefs must be used for all sequences and arrays.
Defines a preprocessor macro foo, optionally with a value bar.
Generates a warning if a #pragma is not recognized.
Specifies deep (rather than shallow) merges. If you specify -deep, only differences between the new contents and the existing contents will be merged. In a -shallow merge, all existing content is replaced with new content if the new content defines the same names. The default is off.
Specifies the instance name of the interface repository to which idl2ir will attempt to bind. If no name is specified, idl2ir will bind itself to the interface repository server found in the current domain. The current domain is defined by the OSAGENT_PORT environment variable.
ir2idl
This command allows you to create an Interface Definition Language (IDL) source file with objects from an interface repository.
Syntax
ir2idl [options]
Example
The following example dumps the contents of the IR named foo into the file named foo.idl:
ir2idl -irep foo -o foo.idl
Description
The ir2idl command extracts the contents of an IR and prints it out as IDL.
Options
The following options are available for ir2idl.
idl2wsc
The idl2wsc command generates C++ code similar to Axis C++ v1.5 WSDL2Ws server-side generated code, and it also generates the necessary CORBA calls to the CORBA server. This constitutes the C++ Web Services CORBA Bridge Code.
Given an IDL name “Foo.idl”, by default the idl2wsc tool will generate the files “Foo_ws_s.cc, Foo_ws_c.hh, Foo.wsdl, corba.wsdl and Foo.wsdd”. Note that the “*.cc, *.hh, *.wsdl” files should not be modified. The generated WSDD file can be modified by the user to point to the compiled shared library that will be loaded by the C++ Web Services Run-time Library.
Options
The options available to idl2cpp are also available to idl2wsc. In addition to the idl2cpp options, the following are specific to idl2wsc:
Usage
Before passing any IDL file to idl2wsc to generate the C++ bridge code, you must pass the IDL file to idl2cpp to generate the CORBA stub code. Note that you should apply the same idl2cpp options that you use to generate the CORBA stub code to the idl2wsc tool because the idl2wsc tool references names of files and/or signatures that should have been generated by idl2cpp.
Note that any changes to the idl2cpp generated code or to a new version of “\include\vbws.h” requires a recompilation of the idl2wsc-generated code.
Limitation of idl2wsc
Note that the Axis C++ v1.5 WSDL2WS tool does not support a WSDL file that defines more than one “portType” and it will only generate only one of the “portTypes” defined. This itself is a limitation of Axis C++ v1.5 and therefore an IDL file containing more than one interface is not supported.