[omniORB] string_dup() behavior

[baileyk@schneider.com]

--0__=86256BF4004D848B8f9e8a93df938690918c86256BF4004D848B
Content-type: text/plain; charset=us-ascii


My guess is the problem is caused by a mix of different runtime libraries
too.  I don't run omniORB on Windows but I've done enough Windows DLL
programming to know how easy it is to fall into that trap.

I don't agree that one needs to cast all string literals.  If you use
CORBA::string_dup, you don't need to also cast the argument.  If you are
constructing a String_var directly, then yes.

CORBA::String_var theString("name"); // not a good idea on all platforms

CORBA::String_var theString((char const*)"name"); // more reliable

But I always just use CORBA::string_dup() to make it clear that a copy is
being made.

Kendall



                                                                                                            
                    "Visscher, Bruce"                                                                       
                    <VISSCHB@rjrt.com>         To:     "Lionel Gilet" <lgilet@san-jose.tt.slb.com>,         
                    Sent by:                    "OmniOrb List" <omniorb-list@realvnc.com>                   
                    omniorb-list-admin@r       cc:                                                          
                    ealvnc.com                 Fax to:                                                      
                                               Subject:     RE: [omniORB] string_dup() behavior             
                                                                                                            
                    07/11/2002 08:08 PM                                                                     
                                                                                                            
                                                                                                            




> {
>   CORBA::String_var the String = CORBA::string_dup("name");
> }

I don't really see why this should be a problem (except for the obvious
typo in the variable name).

Are you sure you used consistent compiler options?  If you link against the
omniORB DLLs you must configure your project to compile
and link against the multi-threaded DLL version of the MSC run time.

In any case, you should always cast literal strings to "pointer to const
char" to be on the safe side.  The C++ standard mandates
that string literals are of this type already so the cast wouldn't be
needed with a standards conforming compiler.

The CORBA C++ mapping made some unfortunate choices regarding pointers to
non-const char.

HTH,

Bruce
(See attached file: InterScan_Disclaimer.txt)


--0__=86256BF4004D848B8f9e8a93df938690918c86256BF4004D848B
Content-type: application/octet-stream; 
	name="InterScan_Disclaimer.txt"
Content-Disposition: attachment; filename="InterScan_Disclaimer.txt"
Content-transfer-encoding: base64

Q09ORklERU5USUFMSVRZIE5PVEU6ICBUaGlzIGUtbWFpbCBtZXNzYWdlLCBpbmNsdWRpbmcgYW55
IGF0dGFjaG1lbnQocyksIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGNvbmZpZGVu
dGlhbCwgcHJvdGVjdGVkIGJ5IHRoZSBhdHRvcm5leS1jbGllbnQgb3Igb3RoZXIgbGVnYWwgcHJp
dmlsZWdlcywgYW5kL29yIHByb3ByaWV0YXJ5IG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uICBJZiB5
b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBtZXNzYWdlIG9yIGFuIGF1
dGhvcml6ZWQgYXNzaXN0YW50IHRvIGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2FnZSBhbmQgdGhlbiBkZWxldGUg
aXQgZnJvbSB5b3VyIHN5c3RlbS4gIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBv
ciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGFuZC9vciBhbnkgb2YgaXRzIGF0dGFjaG1l
bnRzIChpZiBhbnkpIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBh
bmQgbWF5IGJlIHVubGF3ZnVsLg0KDQo=

--0__=86256BF4004D848B8f9e8a93df938690918c86256BF4004D848B--