orbitcpp-list

[orbitcpp-list] Strings and sequences

[Phil D. <ph...@us...>]

Hi All,

Once again, strings are causing headaches:

CORBA 2.3 requires that strings in structs and sequences be
initialised to "". This is solved for structs by using the String_mgr
class, whose constructor allocates an empty string.  However,
sequences present problems for the current implementation because we
use the ORBit C alloc functions for allocating sequences, and there is
no such 'empty string' requirement in the latest C spec.


Candidate solution:

We redefine operator new[] each time we create a sequence, which
invokes the underlying C allocation function. We then use the operator
new[] in allocbuf() instead of calling the C allocation function
direct. This should insure that the String_mgr constructor gets called
appropriately.

There is still a problem with this, since sequences and arrays have
seperate C allocation functions for variable length types, and you can
only define one operator new[] for each type in C++. I suggest we
remedy this by creating a version of String mgr for arrays and
sequence types - e.g.

struct orbitcpp_SequenceString_mgr : public String_mgr {
  static void *operator new[](size_t size);
};

struct orbitcpp_ArrayString_mgr : public String_mgr {
  static void *operator new[](size_t size);
};

Which allows us to create two operator new[]s.

Note that this approach must be used with any variable length type
containing a string. e.g.:


-------------- idl ----------------

struct foo {
  string str;
};

typedef sequence<foo> fooseq;

-------------- c++ ----------------

struct foo {
  String_mgr str;
};

struct orbitcpp_SequenceFoo : public foo {
  static void *operator new[](size_t size);
}

typedef _orbitcpp::SequenceTmpl<
orbitcpp_SequenceFoo,_orbitcpp::c::CORBA_sequence_foo> fooseq;

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

Any comments, suggestions? Andreas - you're doing arrays; can you
forsee any problems with this approach?

Cheers,

Phil.

Re: [orbitcpp-list] Strings and sequences

[Andreas K. <ak...@ix...>]

On Tue, Apr 18, 2000 at 05:34:47PM +0000, Phil Dawes wrote:
> CORBA 2.3 requires that strings in structs and sequences be
> initialised to "". This is solved for structs by using the String_mgr
> class, whose constructor allocates an empty string.  However,
> sequences present problems for the current implementation because we
> use the ORBit C alloc functions for allocating sequences, and there is
> no such 'empty string' requirement in the latest C spec.

I do not yet have the 2.3 spec. Arrays have no such requirement, right?
Whereas every other aggregate (e.g., union, exception) falls under the 
struct'n'sequence rule?

In that case, arrays is the special case and I think we'd like to name the
new _mgr types you mention below like _mgr and _arraymgr.

> Candidate solution:
> 
> We redefine operator new[] each time we create a sequence, which
> invokes the underlying C allocation function. We then use the operator
> new[] in allocbuf() instead of calling the C allocation function
> direct. This should insure that the String_mgr constructor gets called
> appropriately.

why not use the c allocation func in _allocbuf and do a placement new 
afterwards?

> Note that this approach must be used with any variable length type
> containing a string. e.g.:

I can already see a needsConstructorInAggregates() method materialize
in front of my eyes :[

> Any comments, suggestions? Andreas - you're doing arrays; can you
> forsee any problems with this approach?

On first sight, no. But wait till I sleep over it :)

cya
andy

Re: [orbitcpp-list] Strings and sequences

[Phil D. <ph...@us...>]

Andreas Kloeckner wrote:
> 
> On Tue, Apr 18, 2000 at 05:34:47PM +0000, Phil Dawes wrote:
> > CORBA 2.3 requires that strings in structs and sequences be
> > initialised to "". This is solved for structs by using the String_mgr
> > class, whose constructor allocates an empty string.  However,
> > sequences present problems for the current implementation because we
> > use the ORBit C alloc functions for allocating sequences, and there is
> > no such 'empty string' requirement in the latest C spec.
> 
> I do not yet have the 2.3 spec. Arrays have no such requirement, right?
> Whereas every other aggregate (e.g., union, exception) falls under the
> struct'n'sequence rule?

I'm afraid arrays do have that requirement in 2.3:

Page 46 of the cpp mapping:
"If the array element is a string, wide-string or an object reference,
then the mapping uses the same type as for structure members. That is,
the default constructor for string elements and wide string elemnts
initializes them to the empty string"



> In that case, arrays is the special case and I think we'd like to name the
> new _mgr types you mention below like _mgr and _arraymgr.
> 
> > Candidate solution:
> >
> > We redefine operator new[] each time we create a sequence, which
> > invokes the underlying C allocation function. We then use the operator
> > new[] in allocbuf() instead of calling the C allocation function
> > direct. This should insure that the String_mgr constructor gets called
> > appropriately.
> 
> why not use the c allocation func in _allocbuf and do a placement new
> afterwards?

What's a placement new?
If you mean iterate over the sequence newing each element, then this
wont work because the seqence is an array of values (i.e. String_mgrs)
not pointers.

> 
> > Note that this approach must be used with any variable length type
> > containing a string. e.g.:
> 
> I can already see a needsConstructorInAggregates() method materialize
> in front of my eyes :[
> 

I'm using isVariableLength() to deduce this, since both sequences and
strings must initialise their members.

I've written an implementation which uses operator new[], by extending
the sequence template class hierarchy so that a new Elem type is defined
in the variable length sequence template on instansiation. This elem
type has its own operator new[] defined.

I've now got problems with operator new[], which I'll explain in the
next email.

Cheers,

Phil.