[omniORB] operator * for _var types?

[Michael Teske]

Hi!

Hopefully this hasn't been asked again, but I can't get google to search
explicitly for "operator*", it always gives hits for "operator"...

While trying to port code from an other orb to omniorb I encountered the following
problem. Suppose we have this IDL:

module X {
struct Y {
string Name;
};
};

and this code:

#include <xx.hh>

int main ()
{
X::Y_var f = new X::Y();
X::Y y = *f; // error, no operator *

return 0;
}


I always get the "no operator *" error message on the indicated line. The other
orb in question does provide such an operator and in my corba book i see it
mentioned, too.

I know I could write X::Y y = f, but this would mean changing a LOT of code, which
I'd like to avoid. Is there any reason this operator is not there or is this a bug?

Greetings,
Michael

[Clarke Brunt]

Post by Michael Teske
I always get the "no operator *" error message on the indicated line. The other
orb in question does provide such an operator and in my corba book i see it
mentioned, too.

Perhaps tell us the context in which it is mentioned and which book. I
see no sign of the operator in the copy of the C++ Language Mapping for
CORBA which I'm looking at.

Post by Michael Teske
I know I could write X::Y y = f

I might be wrong, but could you?? I wouldn't have expected that to work
either.

I guess you're hoping for a deep copy of the structure in y? It seems an
unusual requirement. You could easily create another _var with such a
statement, i.e. X::Y_var y = f.

The horrid construct:
X::Y y = *(f.operator->()) would presumably work.

Clarke Brunt
TRAFFICMASTER PLC
UNIT 22 / ST. JOHN'S INNOVATION CENTRE
COWLEY ROAD / CAMBRIDGE / CB4 0WS
T: 01223 422469
F:
E: ***@trafficmaster.co.uk


Please consider the environment before printing this email. --------------------------------------------------------

Trafficmaster PLC is a limited Company registered in England and Wales.
Registered number: 2292714 Registered office: Martell House, University Way, Cranfield, BEDS. MK43 0TR

This message (and any associated files) is intended only for the use of omniorb-***@omniorb-support.com and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not omniorb-***@omniorb-support.com you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author ***@trafficmaster.co.uk and do not necessarily represent those of the company.

Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--------------------------------------------------------

[Michael Teske]

Hi!

Post by Michael Teske

Post by Michael Teske
I always get the "no operator *" error message on the indicated line.

The other

Post by Michael Teske
orb in question does provide such an operator and in my corba book i

see it

Post by Michael Teske
mentioned, too.

Perhaps tell us the context in which it is mentioned and which book. I
see no sign of the operator in the copy of the C++ Language Mapping for
CORBA which I'm looking at.

This is in Chapter 4 of PURE CORBA by Fintan Bolton in the context of deep copy.
It also references the _var types as "smart pointers" (which usually can be
dereferenced). But books can be wrong, of course.

Post by Michael Teske

Post by Michael Teske
I know I could write X::Y y = f

I might be wrong, but could you?? I wouldn't have expected that to work
either.

At least it compiles with gcc 4.3...

Post by Michael Teske
I guess you're hoping for a deep copy of the structure in y? It seems an
unusual requirement. You could easily create another _var with such a

This is not exactly where it's used in our code, I probably oversimplified.
What is done in our code is, suppose you have a function

void foo (const X::Y &x)
{
// whatever
}

and a
X::Y_var y;
one would call
foo(*y);

here
foo(y) compiles as well.

another example is if X::Y is a sequence type, I see
(*y)[n] being used a lot...

But anyway, if this is really nonstandard, I'll have to change the code in question.

Post by Michael Teske
statement, i.e. X::Y_var y = f.
X::Y y = *(f.operator->()) would presumably work.

This would be really horrible :)

Greetings,
Michael

[Jonathan Biggar]

Post by Michael Teske

Post by Clarke Brunt
X::Y y = *(f.operator->()) would presumably work.

This would be really horrible :)

X::Y y = f.in();

is much cleaner.

[Michael Teske]

Hi,

Post by Jonathan Biggar

Post by Michael Teske

Post by Clarke Brunt
X::Y y = *(f.operator->()) would presumably work.

This would be really horrible :)

X::Y y = f.in();
is much cleaner.

Yeah. I've read the chapter again, and there's no mentioning of an operator*,
except in the example code. And
X::Y y = f;
should work, too, because of implicit conversions. And even
X::Y_var g;
g = f;
would do a deep copy (in the book they wrongly wrote *g=*f; ).
What a pity the stuff compiled under the old orb****, so I'll have to fix it now.

Greetings,
Michael

[Clarke Brunt]

Post by Michael Teske
This is not exactly where it's used in our code, I probably

oversimplified.

Post by Michael Teske
What is done in our code is, suppose you have a function
void foo (const X::Y &x)
{
// whatever
}
and a
X::Y_var y;
one would call
foo(*y);
here
foo(y) compiles as well.
another example is if X::Y is a sequence type, I see
(*y)[n] being used a lot...
But anyway, if this is really nonstandard, I'll have to change the code in question.

Indeed. Both those uses of '*' are unusual. The _var types are designed
to make standard CORBA argument-passing easy, without the need for extra
'*' or '&'.

And for the sequence example, if you had an actual pointer to an array,
you'd use it with [] without dereferencing it first - same with the
_var.

Jonathan Biggar mentions using the in() method of the _var to
'dereference' it. I didn't mention it myself yesterday because in my
mind I thought that an 'in' struct parameter was passed as 'const S*',
but of course it's 'const S&', so in() (designed for use when you want
an 'in' parameter, but your compiler won't cooperate) is just what's
wanted.

Your 'foo' function above has the same signature are a real CORBA
implementation function, taking the struct as an 'in' arg. Therefore
foo(y), or foo(y.in()) if needed, are correct whether calling the
function internally, or calling a similar CORBA method.

Clarke Brunt
TRAFFICMASTER PLC
UNIT 22 / ST. JOHN'S INNOVATION CENTRE
COWLEY ROAD / CAMBRIDGE / CB4 0WS
T: 01223 422469
F:
E: ***@trafficmaster.co.uk


Please consider the environment before printing this email. --------------------------------------------------------

Trafficmaster PLC is a limited Company registered in England and Wales.
Registered number: 2292714 Registered office: Martell House, University Way, Cranfield, BEDS. MK43 0TR

This message (and any associated files) is intended only for the use of omniorb-***@omniorb-support.com and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not omniorb-***@omniorb-support.com you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author ***@trafficmaster.co.uk and do not necessarily represent those of the company.

Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--------------------------------------------------------

[Michael Teske]

Post by Michael Teske

Post by Michael Teske
This is not exactly where it's used in our code, I probably

oversimplified.

Post by Michael Teske
What is done in our code is, suppose you have a function
void foo (const X::Y &x)
{
// whatever
}
and a
X::Y_var y;
one would call
foo(*y);
here
foo(y) compiles as well.
another example is if X::Y is a sequence type, I see
(*y)[n] being used a lot...
But anyway, if this is really nonstandard, I'll have to change the code

in question.
Indeed. Both those uses of '*' are unusual. The _var types are designed
to make standard CORBA argument-passing easy, without the need for extra
'*' or '&'.
And for the sequence example, if you had an actual pointer to an array,
you'd use it with [] without dereferencing it first - same with the
_var.
Jonathan Biggar mentions using the in() method of the _var to
'dereference' it. I didn't mention it myself yesterday because in my
mind I thought that an 'in' struct parameter was passed as 'const S*',
but of course it's 'const S&', so in() (designed for use when you want
an 'in' parameter, but your compiler won't cooperate) is just what's
wanted.
Your 'foo' function above has the same signature are a real CORBA
implementation function, taking the struct as an 'in' arg. Therefore
foo(y), or foo(y.in()) if needed, are correct whether calling the
function internally, or calling a similar CORBA method.

Yes. Now it's all clear, thanks for your explaining.
An it turns out that it's not _that_ much change in our code, anyway ;-)

Greetings,
Michael