ROADMAP OF C++ STUBBER FILES (incomplete)

  ilucpp.hh    - ILU C++ parser types. A C++-friendly front end to iluptype.
                 Delcares classes/methods that are attuned to the CORBA C++
                 mapping requirements.

  <???>.cpp    - One or more files implementing ilucpp.h. (Note that much of
                 the functionality is implemented inline in ilucpp.h)

  ilucpgen.hh  - ILU C++ code generator types. Specializes classes declared
                 in ilucpp by adding code-generation specific methods.

  <???>.cpp    - One or more files implementing ilucpgen.h.

  ilucpstb.hh  - ILU C++ stub types. Templates and base classes for Objects
                 and constructed types. Note that much of the functionality
                 is implemented inline.

  <if>.hh      - Generated file for interface <if>. Declares abstract types
                 for Objects and constructed types declared in <if>.{isl,idl}.
                 The AT's instantiate/subclass from template classed declared
                 in ilucpstb.

  <if>cs.cpp   - Generated client stubs for interface <if>. Concretizes the
                 abstract types declared in <if>.h, by providing the client-
                 side proxy code

  <if>ss.cpp   - Generated server stubs for interface <if>. Concretizes the
                 abstract types declared in <if>.h, by providing the server-
                 side skeleton code.

  CORBA.hh     - Declares the CORBA namespace (actually, a class), as
                 proscribed by the CORBA C++ mapping.

============================================

Return-Path: sjohnson
Return-Path: <sjohnson@cp10.es.xerox.com>
Received: by tralfaz.cp10.es.xerox.com (4.1/SMI-4.1)
	id AA23610; Tue, 20 Feb 96 19:40:06 PST
Message-Id: <9602210340.AA23610@tralfaz.cp10.es.xerox.com>
X-Mailer: exmh version 1.6.2 7/18/95
To: ilu-core.parc@cp10.es.xerox.com
Cc: pmurray, rick, sjohnson
Subject: ILU C++ Binding: Some Issues
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Feb 1996 19:40:06 -0800
From: Swen Johnson <sjohnson@cp10.es.xerox.com>

All,

A list of issues, some resolved, some not. We will probably add a few before 
tomorrow morning.

In particular, I'd like to solicit opinions on the "SOPE", and agreement on 
the "C++ TARGET ENVIRONMENT FUNCTIONALITY" issues.

-- Swen

-----------------------
WHAT'S MISSING FROM PARSED IDL ?

Aside from "ANY", what is missing from IDL->ISL ?

Determining if a structured type (stuct, union, sequence) is fixed- or 
variable- length will probably require recursively tracing through parser 
structures. (cf 16.8, para 1 - 4).


SCOPE

Section 14.1.8 says "A language mapping must specify how [ORB-implemented] 
interfaces appear in the particular programming language." (Presumably), this 
includes things like the DII, which ILU does not support.

Are we supporting the following:

	DII. No.

	DSI. No.

	Pseudo Objects:

		NamedValue/NVList. Used primarily by DII, I think). (17.5, 17.6)

		Request. DII (17.7)

		Context. Deprecated ? (17.8)

		TypeCode (17.10). Is its principal purpose to support Any ?
		BOA (17.11). Yes, though likely simplified (most operations deal
		with ImplementationDef's).

		ORB (17.12). Yes, though I am not yet certain how operations
		map to ILU.

		Object (17.13). Yes, thought much of it has to do with DII and
		impl. repository

		Principal (17.9). yes

		General support for generating pseudo objects from IDL
		(ie, same addr. space objects). Transmissable pseudo-objects.

Any. Are we implementing Any (16.14) ?  It relies on TypeCodes.  Each 
IDL-derived type must support insertion/deletion operators for any.  Uses:

	1) Mapping for IDL Any
	2) Dynamic Invocation
	3) Application-defined uses
		:
	n) Other ?

Implementations may use reference counting to avoid copying (cf 16.8.1, para 
8). Suggest we not implement ref. counting for initial release.


C++ TARGET ENVIRONMENT FUNCTIONALITY

The spec assumes the full C++ language as documented in the ARM, plus 
exceptions, namespaces, and RTTI (15.1.2). Workarounds for compilers not 
supporting these features are documented in appendix D.

Namespace is almost a non-issue, can be easily faked with classes, as 
described in appendix D.

RTTI is useful for narrowing object refs of IDL-derived classes (16.3.4), and 
narrowing exceptions (16.15). The workaround is to implement _narrow methods. 
This is essentially already done for IDL-derived classes.

It appears that exception class heirarchy is limited to 2 branches of 3 
levels. If true, narrowing for exceptions should be manageable with virtual 
_narrow methods.

  class Exception
    class UserException
      <IDL-derived exception>
    class SystemException
      <standard exception>

Can we assume that C++ exceptions are now widely implemented ?  If not, 
suggest that we implement for both native and synthesised exceptions 
(Environment), with early development effort assuming native exceptions. 
Solaris and VC++ have exceptions.

A similar question about templates. The mapping does not rely on them, but I 
think they will make implementation and testing easier, especially in early 
development. Solaris and VC++ have templates. If necessary to support 
compilers without templates (likely), we can write an awk script to take 
template-like input and transform it to stubber functions with sprintf's.

An early implementation will be easier if we assume "modern" C++ compilers. 
Use of templates is suggested as an implementation strategy; easier to 
develop/test with them, then add in support for non-template compilers. Which 
of {Templates, namespaces, exceptions, RTTI} do Solaris, VC++ support ?

For some C++ compilers, under certain circumstances, the value of a constant 
must be used rather than the constant itself (cf 16.4 para 2). Need to first 
determine which compilers, and which circumstances; then how to detect those 
circumstances from the parsed ISL.


STRATEGY

The CORBA namespace must be automatically accessible when #including any 
IDL-generated headers (16.1.3). Do we want to have a switch to automatically 
generate a "using CORBA" statement ?  If so, working around lack of namespaces 
would require generating the CORBA:: stuff at a global level.

Conformance testing: the spec does not require checking for certain no-no's; 
eg, it is illegal to attempt conversion to void*, relational operations, etc 
on object references. Where easy (eg, by defining private operators), we will 
attempt to prevent such usage. Where difficult, make a note and punt.

A compliant program cannot hold or create instance of interface classes, or 
declare pointers or references to them (16.3). Suggests private constructors; 
how would we prevent pointers and references ?

In general, how do we handle cases where behavior is undefined by the spec, or 
where validity checking is not mandatory ? Possibilities:

	1) Pick a fixed policy & implement it.
	2) Set the policy dynamically:
		a) At ILU-build/configure time
		b) At stubber runtime
		c) At application runtime (MOPs ?)

Reference counting of object references ?

C/C++ same process interoperability. Impacted by operator new, delete, struct 
layout, etc (see 16.9, para 13 (pg 16-17)).

Unions (16.10). How to determine "base type" of descriminant, max/min of 
enumerateds ?

Inheritance vs Delegation (ties; cf 18.3.1, 18.3.2). ILU currently used 
delegation. How desireable is delegation ?


MISCELLANEOUS QUESTIONS

Is the special value for nil object reference a single, ORB-wide value, or can 
there be a different value for each object type ?  Indeed, is it a value, or 
merely a test ? (cf 16.3.3, para 11 - 15; 16.3.5).

Sequence memory management is still a bit unclear (cf 16.11, and recent 
message on cxx_revision concerning "orphaned elements".)

-----------------------


