Summary: What happens when you pass a maximum argument that is less than the length
argument to the "T* data" constructor of an unbounded sequence? Should the
length argument be treated as equal to the max argument, or should an
implementation-defined error (such as an assert) be allowed?

What happens if you pass a null pointer for the buffer argument to the "T*
data" constructor of a sequence? Should the constructor create the sequence
as if it was created with the default constructor, or should an
implementation-defined error (such as an assert) be allowed? Should a null
pointer argument be allowed if the maximum and length arguments are zero?

No Data Available

Summary: What happens if I do:

Fixed f = "999999.999";
Fixed f2;

f2 = f.round(3, 1); // ???
f2 = f.truncate(3, 1); // ???

Should these throw DATA_CONVERSION? I think so – if we agree on this,
the spec should state it.

No Data Available

Summary: The Fixed mapping requires throwing DATA_CONVERSION if a value has more
than 31 integral digits:

Fixed f = 1E32; // DATA_CONVERSION

This raises the question of how to deal with Fixed types in environments
without C++ exceptions. Presumably, we need to add a CORBA::Environment
parameter everywhere. Unfortunately, that isn"t possible with the overloaded
operators that are currently defined.

Summary: The C++ mapping for the Portability Specification does not provide
reference counting for servants. This proposal adds reference
counting to the C++ mapping to ease memory management of
implementations. It borrows from the C++ language mapping from the
Objects by Value specification which does have reference counting for
values. Specifying the reference counting calls is important so that
both the Adapter implementation and multi-threaded application code
can cooperate to ensure that implementations are only deleted when no
longer used by any thread. Without specifying these calls, deadlocks
are extremely easy to introduce into the system.

No Data Available

Summary: 1. The C++ spec requires that all POA servant classes derive from
PortableServer::ServantBase as a virtual base class. For C++
environments without RTTI, it is then impossible for the programmer to
narrow a servant received from the POA via reference_to_servant() or
id_to_servant() back to the programmer"s specific servant class.

Proposal: Add a _narrow() operation to each POA servant class in the
same fashion that _narrow() operations are defined for exception
classes:

// IDL
interface A { };

// C++
class POA_A : public virtual PortableServer::ServantBase

;

The _narrow() operation will return a valid pointer if the servant isa
POA_A, otherwise it returns 0.

:ServantBase as a virtual base class. For C++

Summary: The question has arisen how the new Unicode escapes that were
introduced in the Java to IDL mapping should be mapped to C++.
There"s nothing about this in the C++ mapping chapter.

No Data Available

Summary: The following MIGHT be considered an issue for CosLifeCycle and/or
CosReference.

The inheritance of CosReference::Relationship and
CosCompoundLifeCycle::Relationship by CosLifeCycleReference::Relationship
creates a "Diamond of Death" inheritance structure, in which
CosRelationships::Relationship is inherited by two distinct paths:

CosRelationships::Relationship
/ \
/ \
CosReference::Relationship CosCompoundLifeCycle::Relationship
\ /
\ /
CosLifeCycleReference::Relationship

No Data Available

Summary: We currently have the _ptr_type and _var_type definitions for interface
classes. These are useful for template functions that need to deal with
the proxy type as well as the _ptr and/or _var references.

In a similar vein, we could add a typedef to the tie template for the
tied object class:

template<class T>
class POA_A_tie : public POA_A

;

No Data Available

Summary: It would be nice to have a trait in the Tie classes of the class that the requests are being forwarded to. Something like this:

template <class T>
class POA_Foo_tie : public POA_Foo

;

No Data Available

Summary: Here is a list of all the POA-related operations that deal with the Servant
type, and how I believe they need to act with respect to reference
counting. Because there aren"t that many operations in this list, I believe
that by spelling them out in detail rather than trying to capture their
behavior in general rules accomplishes two things:

1) We make it crystal clear to POA implementors and application developers
how each operation handles reference counting for the Servants it deals
with, and how the POA interacts with those servants.

2) We make it clear to future maintainers of the C++ mapping for the
PortableServer module that any new operations that deal with servants must
have their servant reference counting semantics explicitly specified.

Again, because there are so few operations to cover, explicitly specifying
rules for each one is simple and precise.

No Data Available

Summary: page 20-74 of orbos/98-01-11 shows the tables for the parameter passing
rules. There are six notes on page 20-76 that are meant to be referenced
by the tables. However, those references are no longer correct.

For example, the array parameter passing rules in table 19-2 (should be
table 20-2) have the index 2, but note 2 actually refers to the rules
for passing references.

Notes 3 to 6 are no longer referenced by the table, but should be.

No Data Available