[omniORB] strings parameters passing rules.

[Tingle, Alex]

Jorge,

Here's my attempt to answer your questions:

> My questions are:
> 
>  The 1) is correct ? or always i have to do 2)
>  And what about 4) ? Who have to free this resource ?

1) and 2) are equivalent in this case, as in_val.s_mem is a
CORBA::String_member which means that it automatically calls string_dup()
when initialised with a const. str_in is 'const char*', so the String_member
takes a copy of it rather than just acting as a char*.

Personally I think it's safer to use method 2) anyway. It makes it clear
that s_mem owns its own copy of the string. Also, some compilers can play
fast and loose with the type of string literals, so you can't always
guarantee that a string literal will be const.

3) Is wrong. It's unfortunate that it should even compile. in_val.s_mem owns
its own copy of the string, and is responsible for 'delete[]'ing it when it
goes out of scope. Line 3) frees the memory, but doesn't tell in_val.s_mem
that it no longer owns the string. So when in_val is deleted, the memory
will be freed a second time!!

> 4) str_inout = inout_val.s_mem;

Line 4) is wrong for two reasons. Firstly, the name implies that str_inout
owns a string when it is passed into the my_func() method. You should free
this memory before you reassign the pointer. Secondly, inout_val will free
any strings owned by its members when it goes out of scope. So if you try to
use the value of str_inout after the my_func() method has returned, you will
seg fault (if you're lucky).

Finally, you fail to delete the out_val and ret_val structures that have
been allocated for you by the call to vls_op().

Here's my version:

void my_func( const char *str_in, char *str_inout )
{
  Foo_var fv = ...; // Get reference

  Vls in_val;
  Vls inout_val;
  Vls *out_val;
  Vls *ret_val;

  in_val.l_mem = 99;
  in_val.s_mem = CORBA::string_dup( str_in );

  inout_val.l_mem = 99;
  // inout_val.s_mem adopts contents of str_inout
  inout_val.s_mem = str_inout;

  ret_val = fv->vls_op( in_val, inout_val, out_val );

  // inout_val.s_mem yields ownership of contents to str_inout
  str_inout = inout_val.s_mem._retn();

  delete out_val;
  delete ret_val;
}

You've obviously based this example on Henning & Viniski section 7.14.8. Try
reading chapter 6 (mapping rules) before you dive into chapter 7. Henning &
Vinoski is a good book, but you really have to read it in order if you don't
want to get horribly confused. (That's what I found anyway.)

regards,

-Alex

--

> -----Original Message-----
> From: jorgefm at cirsa.com [mailto:jorgefm at cirsa.com]
> Sent: 08 October 2003 09:17
> To: omniorb-list at omniorb-support.com
> Subject: [omniORB] strings parameters passing rules.
> 
> 
> Hi all !
> 
> After reading 'Advanced CORBA programming with C++' i have 
> some questions
> about
> passing strings from a client to the server.
> 
> With the idl file:
> 
> struct Vls {
>   long l_mem;
>   string s_mem;
> };
> 
> interface Foo {
>   Vls vls_op( in Vls vls_in, inout Vls vls_inout, out Vls vls_out ) ;
> };
> 
> If i have a method:
> 
> void my_func( const char *str_in, char *str_inout )
> {
>   Foo_var fv = ...; // Get reference
> 
>   Vls in_val;
>   Vls inout_val;
>   Vls *out_val;
>   Vls *ret_val;
> 
>   in_val.l_mem = 99;
> 1)  in_val.s_mem = str_in;
> 2)  in_val.s_mem = CORBA::string_dup( str_in );
> 
>   inout_val.l_mem = 99;
>   inout_val.s_mem = CORBA::string_dup( str_inout );
> 
>   ret_val = fv->vls_op( in_val, inout_val, out_val );
> 
> 3) CORBA::string_free( in_val.s_mem );
> 4) str_inout = inout_val.s_mem;
> 
> ...
> 
> If i put 2) then i have to put 3).
> 
> My questions are:
> 
>  The 1) is correct ? or always i have to do 2)
>  And what about 4) ? Who have to free this resource ?
> 
> Any comment is welcome !
> Thanks in advance,
> Jorge
> ______________________________________________________________
> __________________
>   Este mensaje se dirige exclusivamente a su destinatario y 
> puede contener
> información CONFIDENCIAL sometida a secreto profesional o 
> cuya divulgación
> esté prohibida en virtud de la legislación vigente. Si ha 
> recibido este
> mensaje por error, le rogamos que nos lo comunique 
> inmediatamente por esta
> misma vía o por teléfono (34 93 739 67 00) y proceda a su destrucción.
> Nótese que el correo electrónico vía Internet no permite 
> asegurar ni la
> confidencialidad de los mensajes que se transmiten ni la 
> correcta recepción
> de los mismos.  En el caso de que el destinatario de este mensaje no
> consintiera la utilización del correo electrónico vía 
> Internet, rogamos lo
> ponga en nuestro conocimiento de manera inmediata.    This message is
> intended exclusively for its addressee and may contain 
> information that is
> CONFIDENTIAL and protected by a professional privilege or 
> which disclosure
> is prohibited by law. If this message has been received in 
> error, please
> immediately notify us via e-mail or by telephone (34 93 739 67 00) and
> delete it. Please note that Internet e-mail does not guarantee the
> confidentiality or the proper receipt of the messages sent.  If the
> addressee of this message does not consent to the use of 
> Internet e-mail,
> please communicate it to us immediately.
> ______________________________________________________________
> ___________________
> 
> 
> 
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>