[omniORB] operator * for _var types?

Michael Teske mteske-csk at t-online.de
Thu Jul 24 18:05:20 BST 2008


Clarke Brunt wrote:
> From: Michael Teske [mailto:mteske-csk at t-online.de] 
> 
>> 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.
> 
> 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









More information about the omniORB-list mailing list