Hi,

what is the exact type of the return value of the Server_impl::_this
function?


From the C++ Language Mapping, Version 1.2, page 125:

Assuming A_impl is a class derived from POA_A that implements the A
interface, and assuming that the servant’s POA
was created with the appropriate policies, a servant of type A_impl can
be created and implicitly activated as follows:
// C++
A_impl my_a;
A_var a = my_a._this();

The A_var is (in terms of writing anyway) the same type as I would use
on the client side. Is it actually the same type? If so, does that mean
that I would always have to link the client code to my server code
(which is indeed what lots of examples do)? If not, suppose I have an
application that is both a server and a client for the same interface.
How do I distinguish between the two?

Part of the confusion is 4.41.1 which says, and where it look clear to
me that a A_ptr on the servers is a different type than the "same" A_ptr
on a client, although they both implement the same interface:

4.41.1 Skeleton Derivation From Object
In several existing ORB implementations, each skeleton class derives
from the corresponding interface class. For
example, for interface Mod::A, the skeleton class POA_Mod::A is derived
from class Mod::A. These systems therefore
allow an object reference for a servant to be implicitly obtained via
normal C++ derived-to-base conversion rules:
// C++
MyImplOfA my_a;                    //   declare impl of A
A_ptr a = &my_a;                   //   obtain its object reference
                                   //   by C++ derived-to-base
                                   //   conversion
Such code can be supported by a conforming ORB implementation, but it is
not required, and is thus not portable.


TIA

Joost

Hi Joost,

>what is the exact type of the return value of the Server_impl::_this
>function?

Assuming you have an interface Foo, the return value of _this should
be Foo_ptr, which can convert to CORBA::Object_ptr.

Doug

>From the C++ Language Mapping, Version 1.2, page 125:
>
>Assuming A_impl is a class derived from POA_A that implements the A
>interface, and assuming that the servant’s POA
>was created with the appropriate policies, a servant of type A_impl can
>be created and implicitly activated as follows:
>// C++
>A_impl my_a;
>A_var a = my_a._this();
>
>The A_var is (in terms of writing anyway) the same type as I would use
>on the client side. Is it actually the same type? If so, does that mean
>that I would always have to link the client code to my server code
>(which is indeed what lots of examples do)? If not, suppose I have an
>application that is both a server and a client for the same interface.
>How do I distinguish between the two?
>
>Part of the confusion is 4.41.1 which says, and where it look clear to
>me that a A_ptr on the servers is a different type than the "same" A_ptr
>on a client, although they both implement the same interface:
>
>4.41.1 Skeleton Derivation From Object
>In several existing ORB implementations, each skeleton class derives
>from the corresponding interface class. For
>example, for interface Mod::A, the skeleton class POA_Mod::A is derived
>from class Mod::A. These systems therefore
>allow an object reference for a servant to be implicitly obtained via
>normal C++ derived-to-base conversion rules:
>// C++
>MyImplOfA my_a;                    //   declare impl of A
>A_ptr a = &my_a;                   //   obtain its object reference
>                                   //   by C++ derived-to-base
>                                   //   conversion
>Such code can be supported by a conforming ORB implementation, but it is
>not required, and is thus not portable.
>
>
>TIA
>
>Joost
>
>
>
>
>


-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt@vanderbilt.edu

Douglas C. Schmidt wrote:
> Hi Joost,
> 
>> what is the exact type of the return value of the Server_impl::_this
>> function?
> 
> Assuming you have an interface Foo, the return value of _this should
> be Foo_ptr, which can convert to CORBA::Object_ptr.

OK, than my understanding is that I effectively must include the code
from the client in the server if the Servant does not inherit from the
interface class (which is not the case in e.g. TOA afaics).

Thanks,

Joost

Hi Joost,

>> Assuming you have an interface Foo, the return value of _this should
>> be Foo_ptr, which can convert to CORBA::Object_ptr.
>
> OK, than my understanding is that I effectively must include the code
> from the client in the server if the Servant does not inherit from the
> interface class (which is not the case in e.g. TAO afaics).

I'm not sure what you mean by "include the code from the client" since
you certainly don't need to include the client application code!  If
you mean "include the generated client stubs with the generated
skeleton code you link to create the server application" then that's
correct.  Speaking of TAO, if you download it from

http://download.dre.vanderbilt.edu

you'll find lots of examples that illustrate how all of this stuff works.

Thanks,

        Doug
-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt@vanderbilt.edu

Douglas C. Schmidt wrote:
> I'm not sure what you mean by "include the code from the client" since
> you certainly don't need to include the client application code!  If
> you mean "include the generated client stubs with the generated
> skeleton code you link to create the server application" then that's
> correct. 
Yes, that is what I meant.

 Speaking of TAO, if you download it from
> 
> http://download.dre.vanderbilt.edu
> 
> you'll find lots of examples that illustrate how all of this stuff works.
Yes, I have downloaded (and installed) it. Al thought some people think
that source is everything, explanation/meaning counts for something also ;-)

Thanks,

Joost

Hi Joost,
>Douglas C. Schmidt wrote:
>> I'm not sure what you mean by "include the code from the client" since
>> you certainly don't need to include the client application code!  If
>> you mean "include the generated client stubs with the generated
>> skeleton code you link to create the server application" then that's
>> correct. 
>Yes, that is what I meant.

Ok, great.

> Speaking of TAO, if you download it from
>> 
>> http://download.dre.vanderbilt.edu
>> 
>> you'll find lots of examples that illustrate how all of this stuff works.
>Yes, I have downloaded (and installed) it. Al thought some people think
>that source is everything, explanation/meaning counts for something also ;-)

Yes, indeed!  I recommend you check out 

http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/documentation.html

for information on good resources (some free, some not) that describe
CORBA/TAO very thoroughly (and more intuitively than reading the CORBA
spec).

Thanks,

        Doug
-- 
Dr. Douglas C. Schmidt                       Professor and Associate Chair
Electrical Engineering and Computer Science  TEL: (615) 343-8197
Vanderbilt University                        WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203                          NET: d.schmidt@vanderbilt.edu

Hi,

>> you'll find lots of examples that illustrate how all of this stuff works.
> Yes, I have downloaded (and installed) it. Al thought some people think
> that source is everything, explanation/meaning counts for something also 
> ;-)

That is why people also deliver courses, to explain it ;-)

Johnny