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: 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: 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.

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: 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

The CORBA 2.3 C++ spec says (1.11):

"The Fixed(char*) constructor converts a string representation of a
fixed-point literal into a real fixed-point value, with the trailing 'd'
or 'D' optional."

However, the CORBA 2.3 spec for a fixed point literal says (3.2.5.5):

"A fixed-point decimal literal consists of an integer part, a decimal
point, a fraction part and a d or D. The integer and fraction parts both
consist of a sequence of decimal (base 10) digits. Either the integer
part or the fraction part (but not both) may be missing; the decimal
point (but not the letter d (or D)) may be missing."

This means that the following call is illegal:

CORBA::Fixed f("-1.0");

Even though this can be rewritten (legally) as:

CORBA::Fixed f(-CORBA::Fixed("1.0"));

I think it would be a good idea change the definition of the constructor
to also allow an optional sign (+ or -).

closed/resolved

The code example has a "ServantBaseBase_var".

closed, editorial fix

Summary: - The factories" names in the example IDL on page 1-88 are incomplete

• Page 1-90: should be CORBA::CustomMarshal rather than
  CORBA::CustomerMarshal. Nice freudian slip. Might it be that the OBV
  mapping was done by marketeers rather than technicians?

Close as duplicate of 2354.

Issue 1776 was supposed to change all T_out classes so that their copy
constructor and assignment operators took a "const T_out &". The _out
class in 1.3.6 didn't get updated with this change.

closed/resolved

Sections 1.32.2 and 1.41.20 have TypeCode::type_modifier() returning a
ValuetypeModifier. It should be ValueModifier instead.

–

editorial fix...isssue closed

Summary: 2. Should it be legal to assign a null pointer to a string member of a
struct, sequence, array or exception?

closed/resolved

Summary: 1. What is the contents of a string member of a struct, sequence, array
or exception after out() or _retn() has been called? Is it a null
pointer, or an empty string?

I think that for best consistency, it should be an empty string, which
is the same state after default construction.

closed/resolved

Summary: CORBA 2.3 added the requirement (1.7 & 1.8) that string extractor
operators be defined for String_var & string member classes, for
example:

std::istream& operator >>(std::istream &, CORBA::String_var &);

However, the semantics of the extractor operations is undefined. Does
the extractor operator extract characters until the first whitespace?
until a newline? until the default width of the stream? until eof?

The same applies to wide strings.

closed/resolved

The constructors for CORBA::Exception, CORBA::SystemException and
CORBA::UserException should be protected, not public, since there is no
reason for a direct instance of these classes ever to be instantiated.

Close no change. Base exception classes are abstract, so this change is not necessary.

Summary: There is no reason that the _raise() function for CORBA::Exception
should not be const. We should change it"s signature to:

class Exception

;

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

Summary:
The mapping for string members has modifier functions for "char *",
"const char *", and "String_var". Shouldn"t there also be a modifier
function that takes the unnamed struct string member and array string
member types?

closed/resolved

Some of the unary operators for the Fixed class have the wrong return
type:

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

1. The resolution that we seemed to be converging on for issue 674
allows programmers to inherit servant implementations like this:

// IDL

interface A {
};

interface B : A {
};

// C++

class MyA : public virtual POA_A {
};

class MyB : public virtual POA_B, public virtual MyA {
};

However, this paradigm breaks when using abstract interfaces:

// IDL
abstract interface A {
};

interface B : A {
};

since the spec does not require a POA skeleton be generated for A.

I think we should change the spec to state that POA skeletons for
abstract interfaces are generated, but that these skeletons do not
inherit from ServantBase, and do not contain a _this() member function.
This will allow inheritence of implementations, even for abstract
interfaces.

I considered just having POA_B just inherit directly from the abstract
class A, but that would allow POA_B skeletons to be widened implicitly
to an abstract interface pointer (for implementations which define A_ptr
as A *), and that seems to be too trouble prone. If someone can think
of a way to do this and prevent implicit widening, then this would be
better, since it would even allow sharing of implementation between a
servant and a valutype that both inherit from the same abstract
interface.

resolved/closed

In formal/99-07-41 section 1.28 "NamedValue" it says "NamedValue is used
only as an element of NVList, especially in the DII." but this is not
correct. Note the remark in section 1.33.3 "Differences from C-PIDL" which
describes other uses: "Added create_named_value, which is required for
creating NamedValue objects to be used as return value parameters for the
Object::create_request operation."

editorial fix, issue closed

4. Is there any merit in adding narrow operations to AbstractBase that
would allow the programmer to narrow to ValueBase or Object_ptr?

closed/resolved

"Both interfaces that are derived from one or more abstract interfaces,
and valuetypes that support one or more abstract interfaces support
implicit widening to the _ptr type for each abstract interface base
class. Specifically, the T* for valuetype T and the T_ptr type for
interface type T support implicit widening to the Base_ptr type for
abstract interface type Base. The only exception to this rule is for
valuetypes that directly or indirectly support one or more regular
interface types (see Section 1.17.9, Valuetype Inheritance, on page
1-83). In these cases, it is the object reference for the valuetype, not
the pointer to the valuetype, that supports widening to the abstract
interface base."

This seems to prohibit widening from a valuetype pointer to an abstract
interface _ptr if the valuetype happens to support a normal interface.
I don't understand the restriction. This seems to prohibit the
programmer making a choice of using value or reference semantics in the
case of diamond inheritence of an abstract interface:

// IDL
abstract interface A {
};

interface I : A {
};

valuetype V1 : supports A {
};

valuetype V2 : supports I {
};

This means that I must always pass V2 valuetypes by reference to
operations expecting an A, and cannot choose to pass V2 valuetypes by
value instead. Why was this restriction added and what would be the
problem with relaxing it in this case?

see below

currently it is not possible to pull an exception out of an Any generically,
that is, I cannot write:

const CORBA::SystemException * sep;
CORBA::Any a;

// assume a contains a system exception...

a >>= sep;

Normally, I won't need this. However, it's come up as part of portable
interceptors. For example, I might want to write an interceptor that
logs things, including system exceptions. Now, if I have a system exception
in an Any, the only way to get it out is to successively try to extract
every possible system exception until I find one that works.

That's rather tedious. It would be nicer if I could extract a base
pointer to the actual exception, so I can print the minor number and
completion status.

I would like to suggest adding the following extraction operator:

Boolean operator>>=(const SystemException * &);

closed/resolved

Given that we have Any::to_object and Any::to_abstract_base, shouldn't
there be an Any::to_value_base as well?

closed/resolved

2. I do not understand this bullet in section 1.18.2:

"o Inserting an abstract interface reference into a CORBA::Any operates
polymorphically; either the object reference or valuetype to which the
abstract interface reference refers is what actually gets inserted into
the Any. Because abstract interfaces cannot actually be inserted into an
Any, there is no need for abstract interface extraction operators,
either. The CORBA::Any::to_abstract_base type allows the contents of an
Any to be extracted as an AbstractBase if the entity stored in the Any
is an object reference type or a valuetype directly or indirectly
derived from the AbstractBase base class. See Section 1.16.6, Widening
to Abstract Interface, on page 1-62 for details."

This seems to make no sense. It seems to state that the actual
reference or valuetype is inserted into the Any, which means that the
TCKind associated with the any will be tk_objref or tk_value, not
tk_abstract_interface. This seems to have particularly bad implications
with the DII & DSI. How does the DII know to encode an abstract
interface correctly in CDR if the Any it receives doesn't have a
tk_abstract_interface TypeCode? It also means that an application which
only knows the abstract interface type must handle the case where the
Any has a tk_objref or tk_value instead, use Any::to_abstract_interface
and then a narrow call to get the abstract interface pointer it needs.

This seems needlessly complex and unnecessary. This bullet should be
replaced with one that just states that abstract interfaces have
inserters and extractors generated for them just like normal interfaces.

closed/resolved

quite some time ago, we added the _var_type and _ptr_type definitions
to proxies to make it easier to write templates. Similarly, we have
the _whatever_seq typedefs for recursive structs and unions, to avoid
problems with anonymous types.

What's missing at the moment is a similar feature for _var types.
When I'm writing a template that does it's job in terms of _var types,
I also quite often want to do something to the underlying target type
of the _var. However, I can't do that unless I pass in an extra template
parameter (which, in turn, doesn't always work if I also want to use
STL standard binders and such...)

So, why not add a typedef for the target type to every _var type?

No Data Available

The description of Any::to_abstract_base does not have any information
about its memory managment implications. It should have the equivalent
semantics to Any::to_object, and require the resulting reference to be
released by the caller.

closed/resolved

The CORBA 2.3 spec needs to make it clear that for dynamic
implementations, invocations of the standard object operations
(get_interface, is_a, non_existent) call the virtual functions defined
in PortableServer::ServantBase, and do not call
PortableServer::DynamicImplementation::invoke().

closed/resolved

Minor editorial issue:

In Section 1.9.2, "T_out Types":

class T_out {
public:
//...
T_out(const T_out& p) : ptr_(p.ptr_) {}
T_out& operator=(const T_out& p)

};

Note the missing "const" in 1.7. I suspect String_out should do the
same as T_out and pass const references.

closed/resolved

Name: Bruce McIntosh
Company: Boeing Australia
mailFrom: bruce.mcintosh@boeing.com
Notification: Yes
Specification: C++ Language Mapping
Section: 1.36.2
FormalNumber: ptc/01-06-07
Version: Proposed Available Revision
RevisionDate: 01/26/2002
Page: 1-136
The example given has a couple of small typographical problems: (1) the function signature specifies a void return type, but returns a Foo* (2) the function returns "foo_servant->this;" which I think should be "return foo_servant->_this();"

Perhaps the example should read:

Foo* some_function (/.../)

Updated the example code as suggested

What should allocbuf() for a bounded sequence return if I ask for more
elements than the sequence bound? The spec doesn't say. I think it should
return null in this case.

Also, what should allocbuf() return if I ask for zero elements?

closed/resolved

The Fixed::round() and Fixed::truncate() functions do not mention what to
do if their scale argument is larger than the current scale. I figure they
shouldn't do anything – for example, "truncating" by making something have
more digits doesn't seem to make sense. I propose adding the sentence below
after the sentence reading "The round and truncate functions convert a
fixed value to a new value with the specified scale." (page 23-32 of
ptc/99-03-04):

If the new scale is equal to or larger than the new scale, no rounding or
truncation is performed and the result is equal to the target object.

closed/resolved

Summary: The C++ mapping says:

A compliant mapping implementation shall provide overloaded operator<<
(insertion) and operator>> (extraction) operators for using String_var
and
String_out directly with C++ iostreams.

>From this definition it"s no clear whether operator>> allocates memory
or not. That is, is the following code correct?

CORBA::String_var str;
cin >> str;

closed/resolved

Summary: I"m trying to work out how valuetypes interact with My question is what should the two reference counts be, and why?
>From my understanding, myVal"s reference count should be 1, and myPtr"s
reference count should be 0.

Is this correct? Perhaps an example _out type for valuetypes should be
included in the spec to clear this up for future reference.

Close no change. The submitter of the issue misunderstood _var semantics.

Summary: Suggestion: generate concrete classes and factories
for valuetypes that do not have any initializers. If a
value type does not have any initializers, it should
be safe to use the default constructor for all members.

This would reduce the size of the code that needs
to be written by the application programmer.

Similarly, concrete factories could be generated for
value boxes

resolved/closed

Summary: full_desc: The C++ mapping for CORBA 2.3 introduces reference
counting on servants and provides the
PortableServer::ServantBase_var class for automated
reference counting. However, this class can not be
used if a more specific type of the servant is needed.
Proposal: add a _var type for each servant type, for
example POA_FooBar_var.

see below

Summary: After all the recently past work getting servant reference counting, it
just occurred to me that this doesn"t work with TIE. Or am I missing
something?

As things stand, to make it work it is necessary to derive a new class
from both the instantiated tie template and RefCountServantBase. This
then requires all the constructors to be redefined - ugh!

See resolution for issue 4114, which addresses this issue as well.

Summary: Section 20.38.3 of the CORBA 2.3 draft states:
I believe that the intent of this paragraph is to forbid the user from
calling invoke() and _primary_interface() directly, not to forbid the
POA from calling _primary_interface() in circumstances other than
processing a request.

The paragraph should be reworded to say:

"The invoke() and _primary_interface() methods will be called by the
POA, and should never be explicitly called by the application."

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

Summary: Valuetypes can be used to form arbitrary, potentially circular graphs.
This means that reference counts may never drop to zero and that more
advanced garbage collection is required, which does not come natural to
C++.

An ORB may keep track of circularity by traversing a graph and can detect
if the last outside reference is lost. However, the overhead is significant,
and the solution would be incomplete, as users need not use "proper" refe-
rence counting on graph nodes by ignoring both OBV_* classes and default
reference counting.

Possible solution: restrict CORBA::DefaultValueRefCountBase to
non-circular graphs. Users can decide much better when a graph is safe
to be cleaned up.

Close as duplicate of 2309.

Summary: The C++ mapping for Objects by Value requires factories for marshalling
valuetypes. Therefore, it needs to specify default factories for the
standard StringValue and WStringValue types.

Close no change. Valueboxes do not have factories.

Summary: From the C++ spec (CORBA2_3-c++.pdf) pg: 20-132

For static skeletons, the default implementation of the _get_interface
and _is_a functions provided by ServantBase use the interface associated
with the skeleton class to determine their respective return values. For
dynamic skeletons (see Section 20.37), these functions use the
_primary_interface function to determine their return values.

Does this mean that a dynamic implementation needs the IFR?
If not, then how can _is_a be implemented for sub-types?

I note that the java mapping includes the method _all_interfaces in Servant
for precisely this reason...

Already resolved.

Summary: The C++ mapping for valuetype includes a typesafe _narrow generated
for all values. The specification states that the caller
of _narrow must invoke _remove_ref once on the returned value
from _narrow (just like object reference _narrow).
f

Already resolved.

Summary: The passing of valuetypes as parameter to operations needs more
consideration. Section 20.22 of ptc/98-09-03 (98/11/06) specifies
that the callee should receive a deep-copy of each valuetype to
preserve location transparently.

Now, does this apply only to operations of interfaces, or also to
valuetype operations? With the current phrasing, this applies just
the same (meaning that valuetype operations also receive a deep-
copy). And then there are abstract interfaces, which may incarnate
a remote interface or a local valuetype.

Close no change. The specification is already clear about valuetype argument passing semantics.

Summary: Does it make sense to add the AbstractBase base
type to the IDL language, so that operations could
receive an AbstractBase parameter?

close with no change

Summary: Should it be possible to narrow an abstract interface
class to a concrete Object, or to downcast it to a
Valuetype?

closed/resolved

Summary: This is a new issue for the C++ RTF.

The mapping for sequences mandates a get_buffer() accessor for read/write
access to the members of the sequence. It is mentioned that an implemen-
tation is not required to store sequence elements in continuous memory
for efficiency reasons, but may choose to do so only when get_buffer()
is called.

However, this introduces coherency problems if sequence elements are
accessed and modified using both get_buffer() and operator[].

get_buffer() is not possible for recursive sequences anyway.

Close no change. The submitter of the issue misread the specification.

Summary: Sequence allocbuf functions should be specified such that passing zero for
their arguments is illegal. Allocating a sequence buffer of zero elements
is rather pointless because nothing useful can be done with such a buffer.
The result of passing zero to allocbuf should be implementation-defined,
since throwing an exception is not a good way to handle programming logic
errors (similar to how indexing past the end of a sequence is a logic error
for which an exception is pretty useless).

Close no change. Discussion of this issue determined that a zero parameter to allocbuf is legal and

Summary: In the latest spec (98-09-03) the Any class appears to be missing
insertion extraction operators for LongLong, ULongLong, etc.

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

Summary: C++ mapping should make available the exception id for each exception type.. Sun would like to revise sec. 3.17 to add following function: static const char * _exception_id();

closed/resolved

Summary: The base exception class should include an accessor to get the exception id of an exception.It"s obtained from environment.Ability to get exception id is desirable in C++

closed/resolved

Summary: Exceptions could be formatted onto ostreams using operator<<..Examples available on /archives/issues/issue266

closed/resolved

Summary: Isn"t it the mappings responsibility to decide how to project the semantics to the underlying "wire rep". You don"t need to put NULL on the wire. Sec 16.18 Pg 16-46 para 11 CORBA2.0

Close no change. This change is too intrusive and would break too much existing code

Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Since lifetime of the value is independent of value passed to operator<<=, Any must contain a copy of value.

close with no change

Summary: Generated C++ (example) ends up with redefinition errors. This is not addressed in current C++ mapping. Options are to amend IDL or to simply state that such IDL cannot be translated.

close with no change

Summary: identifiers containing a double underscore[..] are reserved for use by C++ implementations and standard libraries and shall be avoided by users. IDL could be amended to prohibit double undersc.

closed with no change

Summary: String_var could refer to memory without assuming memory management responsibilities for it, like void String_var::value(const char*, Boolean release = 0

close with no change

Summary: p41,sec 3.13.3,para 24: These functions should return buffers, not T* If you wanted a T* provide a conversion on returned buffer. No need to lock down implementation in this manner

closed with no change

Summary: Class defined for ServerRequest shows op_def() operation. Seems not to be in IDL for ServerRequest and there is no description in the rest of the section (CORBA 2 spec, Sect. 18.4.1)

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

Summary: Sentence in IDL spec "An identifier can only be defined once in a scope.However,identifiers can be redifined in nested scopes" seems to allow interface Foo

;

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

Summary: Sec 4.10 para 2: pseudo object reference of form tc<type> made available for basic and IDL defined types. Sun wants replacements with global function of form TypeCode_ptr tc<type>

Close with no change

Summary: Sun would like to add the following accessors to Any: Boolean release(); void release(Boolean);

Close with no change

Summary: Sec 3.12 para1 describes union constructors.Sun would like to add new constructor that takes as its sole argument a discriminant value.It initializes union according to specified discr. value

Close with no change

Summary: SystemException class should contain a string name field for easy printing of error messages,or operator<< should be overloaded for each system exception

closed/resolved

Summary: Accessors that return a reference to a non-const object can be used for read-write access. They are provided only for following types: struct, union, sequence, any.Provede for all types..

Close no change. This change is too intrusive and would break too much existing code.

Summary: CORBA2.0 Sec 16.18 Pg 16-45 para 9 The caller has sufficient knowledge to release, but not sufficient knowledge to know if contiguous. ("to allow..we adopt the policy....")

Already resolved.

Summary: Struct Mapping: IONA that accessor functions be provided for struct members. Direct access to member variables still available. Enhancement affords the user a consistent interface.

Closed with no change

Summary: Sec 3.13.2 para 25describes allocbuf. Sun prefers that allocated sequence elements be initialized as if vector were allocated by sequence constructor

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

Summary: Sec 16.6 Pg 16-11 CORBA2.0: Sec D.12 states that client stub allocates buffer of specified size for bounded strings.This may result in unnecessary memory consumption.

close with no change

Summary: SystemException has accessor functions minor() and completed() rather than public data members like exceptions normally do. Normal mapping is to make exception data into public data members

Close with no change.

Summary: tables not present in CORBA2.0 What about structs, unions, exceptions, and arrays?

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

Summary: Sec 16.14.6 Pg 16-38 para 44 CORBA2.0 How are you supposed to delete/duplicate this void* value if you don"t know the type? Do we have to emulate a C++ compiler

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

Summary: If operation in an IDL spec. has a context spec, then a Context_ptr input parameter follows all operation specific arguments (OMGD 3.19) It should map to const Context_ptr

Close with no change. Object references are always passed as a plain _ptr parameter and never as a c

Summary: For structs and exceptions: Unions" access functions return primitives by value, not by refs.I need to use temporaries.Change them to refs

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

Summary: Tables not present in CORBA2.0 Aren"t anonymus sequences still allowed in structs, union, and exception?

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

Summary: Implementation dependent: Namespaces available/not available

Close no change. Issue withdrawn by submitter.

Summary: Please find example/discussion in corresponding archive file

closed and resolved

Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines

resolved, issue closed

Summary: Section 16.2: "A shown" should be "As shown". Section 16.6: The title is incorrect "TMapping" remove the "T"

Close as fixed. A search through the current draft does not locate either of the two typos mentioned

Summary: I was writing some C++ code and noticed that the following doesn"t work:

// IDL

interface A {
};

interface B : A {
};

// C++

B_var bv = get_b_from_somewhere();
A_var av = A::_duplicate(bv);

because there is no conversion defined from a B_var to an A_ptr. Is
there a way that this could be added to the language binding without
ambiguity problems?

close with no change

Summary: Should the C++ mapping for ServantBase also have _duplicate,
_var mappings ? For example if get_servant is called on POA, what
are the ownership rules for the returned Servant. It seems providing
a _duplicate, _release operations on ServantBase might be useful. These
operations could be used to ensure that the Servant is not released
while the caller has a reference to it.

resolved and closed in ptc/1998-09-03

Summary: If the same servant and ObjectId are registered with two POAs, _this() can"t know which object to return outside of a method invokation

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

Summary: It appears to be impossible to implement the policy objects using the root POA due to race conditions on the Polilicy::destroy() operation. There appears to be no safe time to delete servant

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

Summary: IDL for Object Interface differs from that provided by core specification in section 7.2 page 7.2

Close with no change. The relevant functions are shown in the latest C++ mapping.

Summary: Appendix E page E-2 and E-3: String_var and Any_var classes are missing T_ptr definition that occurs in the template for var types. These should be added for completness.

Close with no change. Only object reference types have _ptr type. They do not apply to strings or ty

Summary: IDL spec states that identifiers can have characters that are things like an A with accent aigu, or a german script B. Can IDL identifiers have these characters? How are they mapped ontoC/C++?

Close as non-issue. IDL no longer permits non-ASCII letters in identifiers.

Summary: C++ mapping spec should be clearer about the rules for inout strings.There are currently two possible interpretations of what server can do with an inout string (details in archive)

resolverd and closed

Summary: The discussion of how _this() operates is missing explicit information about what to do if there is no request context. Should _this() return nil reference, or should exception be thrown

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

Summary: IDL from Environment has an attribute called "exception" which is invalid. This member should be renammed to "ex"or some other name which is a legal identifier

Close no change. Environment is defined as PIDL, so this is legal.

Summary: C++ mapping for pseudo request class contains const member functions mapped from readonly attributes. IDL does not define C++ mapping for readonly attribs to const member functions.

close with no change

Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.

Close with no change. That's how the mapping was designed to work.

Summary: Sec 16.12 Pg 16-28 CORBA2.0 p. 44, sec 3.14 para 8: Why are these global functions rather than static methods of T_var?

closed/resolved

Summary: Sec 16.12 Pg 16-27 CORBA 2.0 Why is a Long Array_slice declared to be a typedef Long[]? Why are these locked down rather than allowing a slice to be a class?

resolved/closed

Summary: Sec 16.11 Pg 16-23 CORBA2.0 What is the semantics of the length() member? When can I do reallocation? Can it truncate? Can it realloc if length== current size?

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

Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p.32, Section 3.11 para 4: Seems to describe an implementation. Why is it specified. Is this how Sec. 3.10.1 para 14 issue is supposed to be addressed?

Close no change. We do not have enough context to determine what the issue is.

Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0] p.31, Section 3.10.1 para 12: How do I know if the T_var I"ve been passed (in C++) has been initialized?

Close no change. This change is too intrusive and would break too much existing code.

Summary: Sec 16.8 Pg 16-13 CORBA2.0 p. 29, Section 3.10 example para 4. : This example looks incorrect. Example shown in 3.10.1 is inconsistent with the code in paragraph 4.

Close no change. We do not have enough context to determine what the issue is.

Summary: Sec 15.1.1 Pg 15-1 CORBA2.0 "Conforming client or server program is portable across all conforming implementations" We object the word "portable"being used in this context.

Close no change. We do not have enough context to determine what the issue is.

Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 p.41, section 3.13.2 para 21 Do I have to make an application level full copy? This doesn"t meet the performance goal outlined in the beginning

Already resolved.

Summary: Sec 16.11.2 Pg 16-24 CORBA2.0 p. 40 Section 3.13.2, para 17 Looks like C, not C++

Close no change. We do not have enough context to determine what the issue is.

Summary: [Sec 16.11 Pg 16-21 CORBA2.0 Since autoextension is not apparently supported, you should change "may" to "must"

resolved and closed

Summary: Sec. 16.14.3 Pg 16-34 para 30 CORBA2.0 p.48, sec 3.16.3, para 26 Why is this specified. Why are pointers treated differently from Values. Primitives are not set to NULL

Close with no change. It is no longer possible to identify the document to which the question refers

Summary: What happens if i assign a container of data I hold Does aliasing allow in more than simple temporary. Is there a restriction that there can be NO overlapping?

Close no change. We do not have enough context to determine what the issue is.

Summary: Do you anticipate end user"s instantiating the Array_forany class? Isn"t this a implementation detail? The name conflicts with IDL specifiable. Section should be removed.

closed/resolved

Summary: The POA does not properly define the behavior of POA operations
for requests that are currently executing in an object that
has been deactivated.

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

Summary: 2. The spec is silent on whether POA servant classes need to use
virtual inheritence when an IDL class inherits from the same base
interface more than once:

// IDL
interface A

;
interface B : A { };
interface C : A { };
value D : supports B, C { };

Must POA_B & POA_C inherit virtually from POA_A or can defined
independently with all of interface A"s operations? This makes a big
difference for values that support interfaces, since, for example, value
D is defined by the C++ language mapping to inherit from both POA_B and
POA_C. So, does value D inherit one or two versions of A::op()?

resolved

Summary: 2. The spec does not explicitly mention the existence of an Any_out
class. I believe that this class is necessary, following the same
pattern as the normal T_out class for variable length structured types.

resolved and closed

Summary: 1. The spec insection 20.9.2 does not specifically address the form of
T_out types for fixed length structured types. So, should the T_out
type be:

typedef T &T_out;

or should it follow the form of the T_out type for variable length
structured types and define as a "class T_out"? In this case, of course
the copy contructor operator from T_var would not delete the pointer
held by the T_var.

Since the "class T_out" solution for fixed length types does not appear
to have any advantages over the typedef, I recommend that the spec be
modified to state that T_out types for fixed length structured types
simply be a typedef of "T&".

see below

Summary: 3. The spec is too terse in defining the T_var types for fixed length
structured types as having "the same semantics as T_var types for
variable-length types." This is not quite true, since the signatures
for out and return values of these types are different, thus changing
the semantics of the implicit and explicit (out() and _retn())
conversion operations. The spec should show the definition of the out()
and _retn() operations for fixed length types as:

T &T_var::out()

closed/resolved

Summary: // IDL
typedef fixed<4,2> F;

interface foo

;

What should happen if at run time, I do the following?

F myf = "12345.678D";

foo_var fv = ...;
fv->op(myf); // ???

I think the operation should raise BAD_PARAM, because silent truncation
is too dangerous. Note that the operation cannot send a fixed<8,3> because
the operation expects a fixed<4,2> and will get a marshalling error if
what arrives over the wire does not match the IDL definition.

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

Summary: The fixed mapping in 98-07-12 shows:

Fixed operator > (const Fixed &val1, const Fixed& val2);
Fixed operator < (const Fixed &val1, const Fixed& val2);
Fixed operator >= (const Fixed &val1, const Fixed& val2);
Fixed operator <= (const Fixed &val1, const Fixed& val2);
Fixed operator != (const Fixed &val1, const Fixed& val2);
Fixed operator == (const Fixed &val1, const Fixed& val2);

I"m surprised at the return type – shouldn"t that be bool for ANSI
compilers and int for non-ANSI compilers?

Already resolved.

Summary: Section 20.13 states:

"For each different named OMG IDL sequence type, a compliant
implementation provides a separate C++ sequence type."

This certainly means that each declared sequence with a different bound
and component type maps to a unique C++ class. But how about this:

// IDL
typedef sequence<long> LongSeq1;
typedef sequence<long> LongSeq2;

Are LongSeq1 & LongSeq2 mapped to the same or different C++ classes?

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

Summary: Look at this code and tell me what is wrong with it (CORBA:: left off
for simplicity):
So, now the question is: Inside the
TypeCode_var::operator=(TypeCode_ptr tc)
assignment operator, when tc == this, what should happen?

Should this call release(this) to satisfy the requirements of code frag
#3? Or should it be a noop to satisfy the requirements of code frag #4?

Close no change. The submitter of the issue misunderstood _var reference counting semantics.

Summary: Since it is a native, the parameter passing rules for ValueFactory
must be specified so the register/unregister/lookup operations
can be mapped.

Already resolved.

Summary: There are a few minor editorial mistakes in the C++ language
mapping examples. These are included in this single issue for
brevity.

Already resolved.

Summary: 2. The mapping for the "_out" type for Fixed is broken. It is
specified as a typedef, for example "Fixed<3,1>" maps to:

typedef Fixed<3,1> &Fixed_3_1_out;

but the IDL grammar allows fixed types to be declared as attribute
types, operation parameters and return values. This causes problems
because it is no longer obvious where to declare the _out type for an
out parameter.

Close as fixed. The new Fixed mapping takes care of this.

Summary: the Any class shown on page 20-115 of 98-01-11 appears to be missing
support for some of the new IDL types. In particular, no operators
are shown for (unsigned and signed) long long and long double.

Also, there is no operator to insert an unbounded wide string.

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

Summary: The last paragraph of section 5.3.6.3 says the standard language mapping
rules are followed when determining these operation signatures. Since
one of the arguments/return values is a Native, this isn"t quite
possible.

Already resolved.

Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer?

Close no change. This change is too intrusive and would break too much existing code.

Summary: The operations duplicate and release work together to provide memory mgmt. functionallity. It"s desirable to use both via similar interface/syntax. nil/is_nil similar problem

close with no change