Summary: For an IDL valuetype derived from other valuetypes or that supports
interface types, several C++ inheritance scenarios are possible:
...

• Interface classes supported by the IDL valuetype are not inherited. Instead,
  the operations on the interface (and base interfaces, if any) are mapped to
  pure virtual functions in the generated C++ base value class. In addition to
  this abstract base value class and the OBV_ class, the IDL compiler generates
  a POA skeleton for this value type; the name of this skeleton is formed by
  prepending the string "POA_" to the fully-scoped name of the valuetype. The
  base value class and the POA skeleton of the interface type are public virtual
  base classes of this skeleton.

Consider this example:

// IDL
interface I {};
abstract valuetype A supports I {};
valuetype B : A {};

Is a POA skeleton generated for A? Is one generated for B?

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 C++ mapping for CORBA::Object does not specify the mappings for
hash, is_equivalent, is_a and non_existent methods. I am assuming
these map to _hash, _is_equivalent, _is_a and _non_existent. Is this
correct ?

duplicate of issue # 800, closed

Summary: Sec 3.13.2 para 25 describes freebuf. It doesn"t specify if storage associated with each element is released, i.e deep-free. Sun prefers that freebuf deep-free...

Close no change. This issue is already addressed in the CORBA 2.3 specification.

Summary: Is it legal to split IDL module declarations and to re-open a module similarly to what is done with C++ namespaces?

obsolete, cloe issue

Many ORBs provide ostream insertion for exceptions as an extension to C++
mapping. Typically, applications are required to use them (there is not really
a usable alternative) to write code in the following style:

try

catch (CORBA::Exception & ex)

This breaks portability as not all ORBs provide the functionality in the same
way. Therefore ostream insertion should be part of the standard.

closed issue, duplicate of 266

the spec currently is extremely vague about how _var types for fixed-length
underlying types are supposed to work. The only words are:

The T_var types are also produced for fixed-length structured
types for reasons of consistency. These types have the same
semantics as T_var types for variable-length types. This allows
applications to be coded in terms of T_var types regardless of
whether the underlying types are fixed- or variable-length.

This has long been a source of confusion to me. In particular, it doesn't
answer questions such as

• Can a _var for a fixed-length type be initialized with a pointer
  to the fixed-length type? If so, does the _var adopt it?

• Can a _var for fixed-length type be initialized with a value?

• What does assignment between _vars for fixed-length types do?

• Does the _var for a fixed-length type work like a reference
  and remain bound to the same block of memory?

• What does default-initialization of such a _var do?

• etc, etc.

duplicate of issdue 1521...close issue

Summary: For string sequences, new string elements, that are created when the
sequence length is increased, should be initialized to the empty string.

I therefore raise this herewith as an official issue.

I also don"t think it makes sense to vote on issue 2234 before we
decided on the issue above. As I already pointed out, I raised issue
2234 in the believe that the spec already says that new string sequence
elements are initialized as empty string. But this assumption was wrong.

closed and fixed

Summary: The first bullet point at the bottom of page 20-61 is incorrect. It
states that Boolean, Char, and Octet can be extracted using >>=. However,
on page 20-66, the mapping requires a compile-time error for attempts
to extract these types with >>=.

Proposal:

Delete Boolean, Char, and Octet from teh list of types at
the bottom of page 20-61.

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

Summary: There is a problem with the C++ mapping which requires excessive memory copying in order to be exception safe while constructing a return value.

This issue was fixed by Portability Submission

Summary: The C++ mapping uses a Bounds exception in the PIDL for NVList (page 17-6). This is the first time that the Bounds exception is mentioned (as far as I can see). There is no exception declaration for Bounds in the PIDL. This raises the questions:
1) Does Bounds have data members or not?
2) At what scope should Bounds be defined?
Given that the Bounds exception is also used by the
Request interface, I suspect what is meant is CORBA::Bounds.
The TypeCode interface also uses a Bounds exception. It is explicitly
declared in the scope of the TypeCode interface (page 17-15):
It would be nice to only have one of these, probably CORBA::Bounds, and
to add the missing declaration.

resolved, close issue

Summary: A variable-length in parameter is read-only in the
server, and a variable-length out parameter or return value is read-only
in the client. I believe the restriction is too harsh to be useful, and the optimization
permitted by the restriction is not worth it.

Clarifying text added, fixed

Summary: The C++ mapping states that "wchar" is not required map onto a
unique C++ type. Yet in 18.17.4, the mapping fails to define the
from_wchar and to_wchar struct types and associated <<= and >>=
operators for inserting and extract wide chars into anys. This
also needs to be fixed in appendix A.6 of section 18.

No Data Available

Summary: According to C++ mapping spec in the POA document (table 2, section 16.18.1) the signature for an object reference in argument should be "objref_ptr", not the more likely "const objref_ptr". this is an conflict with the convention for all other in args except numeric, and is in contrast with the table 3, that specifies "const objref_var&".

Duplicate of issue 188 - closed

Summary: Most ORBs provide overloaded operators to inject String_var values into ostream, istream, on ifstream. Problem: C++ does not make these operators mandatory, so every time I use one of them, I am writing non-portable and proprietary code. Nail those operators down and make them mandatory in the spec

Fixed, requirements added

Summary: There is no statement about the terminating zero value. Is room allocated for it or not?For symmetrie with string_alloc() I suggest that wstring_alloc() also should allocate more room.

Fixed with issue 722

Summary: When this IDL is mapped into C++ for a non-EH target compiler, won"t this method end up having 2 environment parameters?. This is only IDL in current spec that takes environment parameter

Duplicate of issue 191 - closed

Summary: If C++ compiler doesn"t support namespaces or templates defined inside classes, POA_*_tie classes in 18.1.4 cannot be supported within specified scopes.

resolved, close issue

Summary: CORBA::Boolean can be mapped to totally non-sensical things such as structs, class, type double, type long etc. There are no guarantees about size of underlying type given to implementor

resolved, close issue

Summary: There are some serious inconsistencies in the union mapping. Spec. (page 16-18, para4 and page 16-19, para 1) The 2 paragraphs appear to be in conflict with each other.

Fixed as suggested by submitter

Summary: Section states that _this() can implicitly activate servant if IMPLICIT_ACTIVATION applies. _this() does not have a way to specify which POA is to be used for the activation

resolved, close issue

Summary: PortableServer::ObjectId_to_wstring() and string_to_ObjectId() are written (*in section 18.4) using the "wchar_t" type. Shouldn"t they use the CORBA::wchar type instead?

Fixed in CORBA 2.2 editing process

Summary: The BOA interface defined a method called set_exception(). This is not present in the IDL in section 17.17. Does the BOA support this method or not?

clarified

Summary: The Object IDL contains a release() mmethod that is not mapped in the C++ mapping. This method should be added in the mapping

clarified

Summary: There is no wstring_dup(). For symmetrie with string_dup(), I would suggest to create wstring_dup() as well

closed issue, fixed

Summary: The C++ mapping basically ignores bounded strings and maps them to char* What should happen if I assign a string that is too long to a bounded string? No statement is made

resolved, close issue

Summary: Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"?

fixed, close issue

Summary: A_var may be identical to A_ptr, so a conforming program cannot overload operations using these types solely. This may clash with statement of different behaviour between the two.

fixed

Summary: Return value of maximum() for unbounded sequences must be specified.

resolved, close issue

Summary: Sec 16.11 Pg 16-23 CORBA2.0 p. 39, Sec. 3.13 para 15 Why are you passing string buffers as char ** and object references as T_ptr*. There already is a type used for overloading assignment.

Addressed by resolution to issue 75

Summary: Sec 16.11 Pg 16-23 CORBA2.0 p.38,sec 3.13 para 13 There is no auto extend, no inset,append, delete. It doesn"t seem like a sequence. Seems more like a resizable array. Could call it so.

Beyond scope of RTF - closed

Summary: get principal() needs an Environment parameter, but object implementations using C++ EH do not have them. Spec should clarify this.

resolved, close issue

Summary: The spec does not define how anonymous types defined within constructed types should be named (as the C mapping does)

Duplicate of issue 52

Summary: "Default constructor for a bounded sequence always allocates a contents vector.."-> Bad effect for sequences such as CORBA::ReferenceDatawhich allocates 1024 octets of storage

resolved, close issue

Summary: Section 16.14.5-implies that a CORBA::Object reference extracted from Any must share memory with actual interface stored in Any.Better: results of Any::to_object require explicit release()

resolved, close issue

Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p. 32, Sec. 3.11 A comment nothing can be done about at thisstage. This section is way too complex. Goal is not to be natural C++ programmers !!!!

Beyond scope of RTF - closed

Summary: Implementation dependent: Type of string & object reference members of struct, union, sequence

Withdrawn by submitter

Summary: Sec 16.11 Pg 16-22 CORBA2.0 If release is FALSE under these circumstances, old storage will not be freed before reallocation is performed. After realloc release TRUE or FALSE?

Addressed by resolution to issue 75

Summary: {sec 16.11 Pg 16-22 CORBA2.0 p.38, Sec 3.13 para 7: Must an implementation REALLY implement a sequence as a contigous chunk of memory?

Addressed by resolution to issue 75

Summary: Sec 16.11 Pg 16-23 CORBA2.0 What happens to refs returned by operator[] when a realloc occurs? Are these invalid?

clarified

Summary: Sec 16.11 Pg 16-22 CORBA2.0 p.38 Section 3.13 para11: It"s not clear how maximum()call is supposed to be used.

Duplicate of issue 185 - closed

Summary: Sec 16.8 Pg 16-22 CORBA2.0, p. 28, Section 3.10, para 2: Devastating to programmers. Simple change to IDL an IDL file will require a complete rewrite of application code

Duplicate of issue123

Summary: Implementation dependent: Implementation scheme for Interface _var & _ptr types

Duplicate of issue189

Summary: Does the Any string extractor (>>=) return a pointer that is still managed by the Any or a copy? The spec appears to be silent about this.

Clarifying text added

Summary: It would be useful if the C++ mapping for IDL arrays also generated a T_copy() function to go along with T_alloc(), T_dup(), and T_free().

Fixed as suggested by submitter

Summary: There is currently a heated discussion in comp.object.corba about
interoperability (Subject: Naming Service Interoperability).

In a nutshell, the argument is about whether, if I send an object reference
created by ORB A as a parameter to ORB B, whether or not ORB B is

a) obliged to accept that reference as a valid parameter

b) obliged to return me the same reference I sent (in the sense
that the reference is functionally equivalent) when it returns
that reference as a parameter to me

c) obliged to preserve the contents of the reference if it goes
though a cycle of object_to_string/string_to_object in ORB B.

Now, my argument in this thread is that if an ORB doesn"t behave in line
with the above three points, interoperability is completely lost because
I could never be guaranteed that I can, for example, expect to be able
to store an IOR in a Naming Service and have that work.

issue split into issues 3234 and 3235

Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking
the non_existent pseudo-operation with a compliant CORBA 2.3 server.
We have observed this problem in practice with at least one other
commercial Java ORB, who changed from the Corba 2.2 marshalling to the
Corba 2.3 marshalling when they changed the version of their product,
thereby breaking our existing customer"s code.

Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR
marshalling for pseudo-operation non_existent in Object
pseudo-interface to be _non_existent. The spec is worded in such a way
that it implies that this marshalling applies for all GIOP clients,
not just GIOP 1.2 client

However, p. 13-23 of the CORBA 2.2 specification defines the mapping
of the same pseudo-operation as _not_existent.

see below

Summary: The last sentence of section 15.3.7 "The abstract encoding of value type
always includes RepositoryId information." needs to appear somewhere in
section 15.3.4.1.

see above

Summary: the spec doesn"t say what the type CORBA::WChar should map to. Presumably,
it should be wchar_t? If so, I think this should be stated.

It is important to nail this down because of overloading ambiguities. For
example, if CORBA::WChar * is allowed to be the same as char *, then
we cannot use the overloaded <<= operator to insert unbounded wide strings
into an Any.

Fix the mapping to specify what WChar maps to.

Summary: orbos/98-01-11 contains some stale references. For example, on page 20-18:

...
private:
// hidden assignment operators for var types to
// fulfill the fules specified in
// Section 19.3.2
};

The definition for the A_out type is the same as the one shown
in Section 19.3.6.

These should now refer to Section 20.

Close without change. Already fixed.

Summary: According to the IIOP protocol specification, it is possible to receive
an any with a TypeCode which doesn"t include names, member names and
repository ids.
However, it is not clear what the behaviour of the >>= operator is in the C++
mapping for these cases. What happens if I receive an any value from
a remote ORB which didn"t encode names, member names and repository ids ? Is
it posible to extract its value using the so-called "type-safe" operator >>= ?

closed with no change

Summary: On page 82 in 98-09-03 (Nov 6 1998), the sample code for a boxed
struct is using the type "BoxedS" where "S" should be used.
Specifically, the _value() and _boxed_XXX() functions.

Modify the sample code as indicated.

Summary: I recently encountered an issue regarding the assignment of
Object_vars (shorthand for any object reference _var) to object
reference members. While the spec explicitly forbids implicit widening
when assigning Object_vars, it does not explicitly forbid it when
assigning object reference members.

Clarify the text

Summary: In 98-09-03, SystemException has a pure virtual _raise() member
(Section 20.18). That member is not shown in Section 20.40.8.

Also, I think UserException also should have the pure virtual _raise()
member, but neither the text in Section 20.18 nor the summary in
Section 20.40.9 shows it.

Close as duplicate of 1923.

Summary: The CORBA 2.2 C++ binding has the SystemException class defined as a
concrete class, because it redefines _raise() as a non-pure virtual.

This seems to be a bad idea to me. It would be better to leave _raise()
as a pure virtual so that SystemException cannot be instantiated. This
prevents accidental programming errors in catching SystemExceptions by
value, which slices off the real exception type.

Add pure virtual _raise functions to CORBA::SystemException and CORBA::UserException.

Summary: Section 20.36.1, page 20-118 of orbos/98-07-12 says:

"Similarly, data allocated by the DIR and handed to the ORB (the NVList
parameters, the result value, and exception values) are freed by the ORB
rather
than by the DIR."

However, the signatures for the set_result() and set_exception() functions of
ServerRequest take arguments of type const Any&. How can the ORB adopt the
result and exception data from a const Any? Unless I am missing something,
either these signatures have to be changed to Any&, or the quoted sentence has
to change to remove the text "the result value, and exception values".

Change the text as suggested.

Summary: Are you looking at CORBA 2.2, document orbos/98-02-01?

Section 20.31.4 covers ORB_init and friends. The POA is an ordinary IDL
interface that just follows the ordinary C++ mapping rules, so it needs no
special mention. The C++ server side is explained in 20.33 through 20.38.

You are correct that resolve_initial_references is missing from the ORB
interface. This was because it used to be covered in another section, and
it appears to have been inadvertantly dropped by the editors at the OMG.
Juergen, this should be logged as a cxx_revision issue. However,
resolve_initial_references just follows the regular C++ mapping rules, so
there"s really no harm in it being missing.

Add the missing text.

Summary: The C++ language mapping for ValueBase is missing return
values on _add_ref and _remove_ref.

Fix the code.

Summary: The C++ mapping requires that strings are to be mapped to char *.

Unfortunately, with ANSI C++ compilers, this creates problems if
string literals are involved.

Close no change. This issue is already addressed in the CORBA 2.3 specification

Summary: The C++ mapping requires that attempt to insert a Boolean, Octet, or
Char value into an any must generate a compile-time error:

CORBA::Any a;
CORBA::Char c = "x";
a <<= c; // Compile-time error

The spec says nothing about WChar and WChar *. This implies that no such
guarantee exists. However, I don"t think it would hurt to spell this out:

CORBA::Any a;
CORBA::WChar wc = L"x";
a <<= wc; // Undefined behavior

closed, fixed

Summary:
In 20.9.2, the T_out class has a copy constructor and assignment
operator that take non-const references to a T_out argument. These
should be changed to const references instead because the T_out class
still works correctly with the change, and many compilers issue errors
or warnings about non-const references arguments bound to temporary
values.

fixed, issue closed

Summary: The latest C++ mapping (document orbos/98-05-08) defines the
Any::from_string type as

struct from_string {
from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s),
bound(b) {}
...
};

In ANSI C++, this disallows the following code:

any <<= Any::from_string("string literal");

This is because string literals in ANSI C++ are const char[], not char[].
Therefore, from_string should have an additional constructor to allow
insertion of a const char* as well.

Close as duplicate of 2453.

Summary: The mapping for Any currently requires:

Any(TypeCode_ptr tc, void *value, Boolean release = FALSE);
void replace(TypeCode_ptr tc, void *value, Boolean release = FALSE);
const void *value() const;

The meaning of the void * parameters is never defined (and cannot ever
be defined because it would have to mandate a particular binary layout).

This means these three functions have completely undefined semantics. Even
for basic types, such as CORBA::Long, I cannot assume that the void *
will point directly at the long value, because the mapping implementation
is free to make the pointer point at some other value internal to an Any.

Proposal: Remove these three functions from the mapping. If vendors want
to retain them for backward compatibility reasons, they can.
However, functions with completely undefined semantics that are
inherently non-portable have no place in a standard mapping.

Leave the original text in place. Add a sentence saying that DynAny should be used instead.

Summary: I believe the spec should be updated to explicitly require the following
to be safe: a1.replace(a1.type(), a1.value(), false);
In other words, an Any should be obliged to detect assignment to self
for the passed void *. Reason: The above is the only way I can see
to get a tk_alias type code into an any, so the receiver can tell the
difference between a date and an address.

Close issue with no change – already resolved in section 20.16.8.

Summary: The C++ mapping currently lack mappings for is_a(), is_equivalent(),
hash(), and non_existent(). These need to be added. The question is, which of these operations can validly be invoked on
a nil reference, because that affects the mapping. My thinking is that
all of these should be allowed for nil references.

closed with no change

Summary: The mapping shows the signature for the _narrow static member
functions in exceptions as

static SystemException * _narrow(Exception *);

I think we should change this to

static SystemException * _narrow(const Exception *);

Otherwise, I cannot catch an exception as const and then narrow it
without a cast.

No Data Available

Summary: In coordination with the proposed resolution to the ORB Portability RTF
Issue #752, add the following operations to PortableServer::ServantBase
in section 20.34.1:

class ServantBase

;

and change the last paragraph of section 20.34.1 to:

The default implementation of the _default_POA() function provided by
ServantBase returns an object reference to the root POA of the default
ORB in this process — the same as the return value of an invocation of
ORB::resolve_initial_references("RootPOA") on the default ORB. Classes
derived from ServantBase can override this definition to return the POA
of their choice, if desired.

and add the following text at the end of section 20.34.1:

ServantBase provides default implementations of the _get_interface(),
_is_a(), and _non_existent() standard object reference operations that
can be overridden by the object implementation if the default behavior
is not adequate. These functions are called just like normal skeleton
operations by the POA, so the programmer can use _this() and and the
PortableServer::Current interface in the function bodies.

The default implementation of the _get_interface() and _is_a() functions
provided by ServantBase uses the interface associated with the skeleton
class if it is static to determine its return value. If the skeleton is
dynamic (see 20.36) it uses the _primary_interface() function to
determine its return value.

The default implementation of the _non_existent() function simply
returns false.

:ServantBase

Summary: There is no text in the C++ language mapping that describes how to map a
fixed point constant declaration.

No Data Available

Summary: Type Fixed has constructors for LongDouble and int. This causes
a few initialization problems. For example:

Fixed<8,2> x = 6.75;
Fixed<8,2> y = 10L;
Fixed<8,2> z = 10U;

None of these will compile because of the ambiguity as to whether to use
the int or the LongDouble constructor.

I think Fixed will need additional constructors to allow initialization
from float, double, long and unsigned values.

Summary: Page 20-34 of CORBA 2.2 shows member functions of the Fixed template:

CORBA::UShort fixed_digits() const;
CORBA::Short fixed_scale() const;

There are no semantics specified for these. I assume they return the
number of the respective digits passed to the template? For example, given

Fixed<5,2> x;

assert(x.fixed_digits() == 5);
assert(x.fixed_scale() == 2);

Is this the correct interpretation? If so, the spec should say so (otherwise,
I might, for example, expect that fixed_digits returns 3 and fixed_scale
return 2).

No Data Available

Summary: Add the following operation to CORBA::Any:

class Any

;

This will replace the internal typecode in the any with the specified
typecode. If the new typecode is not equivalent to the old typecode (as
defined by TypeCode::equivalent), then implementation will raise the
BAD_TYPECODE system exception.

No Data Available

Summary: There doesn"t appear to be any way to place an arbitrary exception into
an Any with the current C++ mapping. This is necessary to make the DSI
usefulThe spec needs to be extended to provide an inserter function to insert
a CORBA::Exception into an Any. I know that this has potential issue
for the inserter function to determine the correct typecode for the
exception, but I can"t think of any other way to get an exception into
the Any when all I"ve got is a CORBA::Exception * without having to
enumerate each possible exception by calling _narrow.

No Data Available

Summary: The fixed mapping says on page 20-35 of orbos/98-01-11:

One way to do this is to declare the result types with a macro
that evaluates to the approate values, based on the digits and
scale of the operands:

// Example of Fixed result type declaraction
// Fixed<_FIXED_ADD_TYPE(d1,s1,d2,s2)> -> Fixed<dr,sr>

I think the name of the macro for each rule needs to be nailed down.

No Data Available

Summary: page 20-34 of orbos/98-01-11 contains a few typos:

1)
template<CORBA::UShort d, Short s>

should be

template<CORBA::UShort d, CORBA::Short s>

2)
operator LongDouble() const;

should be

operator CORBA::LongDouble() const;

3)

template<unsigned short d1, short s1, unsigned short d2, short s2)

should use CORBA types and use a closing ">" instead of ")":

template<
CORBA::UShort d1,
CORBA::Short s1,
CORBA::UShort d2,
CORBA::Short s2
> // Note closing ">"

No Data Available

Summary: On page 20-36, near the top, the mapping says:

A T_out type for a Fixed type is defined as typedef to a
reference to the Fixed type, with the digits and scale added to
the name to disambiguate it. For example, the name of the T_out
type for the type Fixed<5,2> is Fixed_5_2_out:

// C++
typedef Fixed<5, 2>& Fixed_5_2_out;

This doesn"t appear to work for fixed types with negative scale. For example:

No Data Available

Summary: In section 5.6:

// PIDL
module CORBA {
interface ORB {
exception InvalidName {};
};
};

In section A.24:

// C++
class ORB {
public:
class InvalidName

;
};

The C++ mapping should be clarified to show that this is indeed a user
exception.

No Data Available

Summary: 3) Page 20-35: the +=, -=, *=, and /= operators are required by the
C++ language to be member functions, not global functions. They
should be moved into the Fixed class and should return a reference to
*this, not a value.

No Data Available