[omniORB] Problem inserting an array of structs

Brian Neal bgneal at gmail.com
Wed Jan 11 19:08:55 GMT 2006


On 1/10/06, Brian Neal <bgneal at gmail.com> wrote:
> > From: Duncan Grisby <duncan at grisby.org>
> > On Friday 6 January, Brian Neal wrote:
> >
> > > Test::TestStructArray_forany fa;
> > > if (a >>= fa) {
> > >    std::copy(&fa[0UL], &fa[0UL] + numElems,
> > >                   std::ostream_iterator<Test::TestStruct>(std::cout, "\n"));
> > > }
> > >
> > > Notice the 0UL. If I don't, and use plain old int 0 to index into the
> > > forany, g++ 3.4.4 gives me the following error:
> > >
> > > main.cpp:46: error: ISO C++ says that these are ambiguous, even though
> > > the worst conversion for the first is better than the worst conversion
> > > for the second:
> >
> > I don't know why gcc thinks it's ambiguous, but I've added the operators
> > for int as for the fixed length struct case.
> >
>
[...]
>
> I don't know if g++ is right or wrong...I will go off and try this on
> a few more compilers. Again, we are using g++ 3.4.4...I'd like to see
> what 4.0 does. I'll try it on the Comeau compiler, which is lauded for
> being very standard compliant. I may post on one of the c++ newsgroups
> about this as well.
>

I did some research on this and I think g++ is correct in reporting
the ambiguity. It would seem that the C++ mapping is kind of messed up
if it mandates both an operator T*() and an operator[](CORBA::ULong).
That causes problems if you index with a plain old int.

The Comeau compiler also reports ambiguity.

I looked at the C++ mapping document and saw that it required
operator[] but didn't say anything about operator T*(), but I assume
that is needed...?

Adding operator[](int)'s seems like the best you can do.

Thanks,
BN



More information about the omniORB-list mailing list