Issue 1271:  Section 7 C++ Language mapping (obv-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: According to the object-by-value C++ mapping, the value type that is
   not boxed results in an abstract C++ class. Basically, the reference
   counting methods are not provided (abstract). It is the responsibility of
   application developer to define/implement a concrete class. Althought
   this can be done, there are some issues:
 

Resolution: 
Revised Text: 
Actions taken:
April 28, 1998: received issue
February 24, 1999: closed issue
Discussion: 
 no action, changed suggested would make c++ mapping consistent
End of Annotations:=====
Issue 1271 (Stephane Carrez)
------------------------
Section 7 C++ Language Mapping

  According to the object-by-value C++ mapping, the value type that is
  not boxed results in an abstract C++ class. Basically, the reference
  counting methods are not provided (abstract). It is the
responsibility of
  application developer to define/implement a concrete
class. Althought
  this can be done, there are some issues:


  Complexity:
  -----------
       This means that value types are not directly usable with the
C++
       mapping. Application developers have a non negligeable work
       when they want to use the value type. The cost is:

	   - Define a new class
	   - Implement _copy_value() (This is not required but
	     probably necessary)
	   - Implement a factory for the ORB to create the value
instance.

	This is ok when there is one or two IDL value types,
	this becomes painful when there are more.


  Inconsistency:
  --------------
       This creates an inconsistency between the boxed values and
       non-boxed values. Boxed values are ready-to-use: developers
       will use the type specified in the IDL. Non-boxed values need
       really to be implemented by application developers. The
progamming
       scheme is different.

	The Java mapping does not require application developers do
"complete
	the job" of the IDL compiler. Java classes are ready-to-use.

  Use of OBV by OMG:
  -----------------
	Another important issue I see, is the use of object-by-value
by OMG
	to specify services or parts of the ORB. For example, further
OMG
	services might define value types. With the C++ mapping, the
	corresponding classes will not be usable because they are
abstract.

	For example:

		module CosNewService {
		   value TaggedService {
			public long id;
			public string name;
		   };
		   interface Service {
			void register(in TaggedService new_service);
			TaggedService get(in string name);
			...
		   };
			...
		};

	C++
		namespace CosNewService {
		   class TaggedService : public virtual
CORBA::ValueBase { ... }
		   ...
		};

	The CosNewService::TaggedService class is not directly usable
by
	applications because it is abstract. In other words, this
means that
        applications will need to implement their own class to use
this type.
	This creates portability problems and complexity problems:

		1/ The service itself becomes difficult to use. This
forces
		   developers to implement new classes for each value
types
		   that is defined by the service. This must be made
before
		   starting to use the service.... Example:

			using CosNewService; using CORBA;
			class MyTagged : public TaggedService,
					 public
DefaultValueRefCountBase {...}


		   and there will be dozen of such 'MyTagged'
implementation
		   class (one for each developer in the World).

		2/ To solve this, service/ORB vendors will probably
provide
		   specific classes that solve this problem. Which
means that
		   this will not be portable.

		3/ To cope with the above 2 problems, each service
		   specification might consider to change the
object-by-value
		   mapping by saying that their value types are mapped
to
		   concrete C++ classes. An alternative could be to
specify
		   C++ classes as part of the C++ mapping for the
service (but
		   that's painful...)

To conclude, I suggest that some simplification for application
developers be made.

Basically, the specification should not require application
developers to define/implement the concrete class to use the
value. The C++ object-by-value mapping should provide a ready-to-use
implementation of values. Application developers can still derive
and override the C++ value mapping but they will do so only when they
really need to do this.

This may be done by providing a default reference counting in the
CORBA::ValueBase class. This class is still abstract due to the
_copy_value() method. This default reference counting can still be
overriden due to the virtual methods.