Re: ORBit2 and const char *



On Friday, July 27, 2001, at 11:18  AM, Michael Meeks wrote:

> On Fri, 27 Jul 2001, Darin Adler wrote:
>> I recently took a look at the CORBA C mapping documentation. I noticed
>> that it requires use of "char *" for string, not "const char *".
>
> 	Hmm, the CORBA C mapping spec is old and stale. I would hope to
> see a better approach to this in the new spec.

I'm not sure exactly what you mean by that. I like using const in my 
programs, but wishing that there was a new CORBA spec. that mandates use 
of const won't make it so.

>> 1) get fancy somehow so that we use const char * instead of const 
>> MyModule_MyString

This would be my preference. I don't like the fact that you can't pass 
"const char *" parameters to functions that take a Nautilus_URI, for 
example. And you could pass them to functions that take a string.

>>      2) abandon use of const char * in ORBit2 to comply with the OMG 
>> spec.
>
> 	This would loose us a lot of useful protection.

I'm not sure I agree, but that's the reason I asked.

>>      3) avoid typedefs for string types in IDLs
>
> 	This sucks too :-)

This is what I've been doing for now.

>>      4) change the casting to get rid of the warnings when compiling 
>> skels
>
> 	_impl_copy ? surely we can fix it by doing:
>
> 	*(const MyString *) = _args [n];
>
> 	instead ?
>
> 	This makes more sense - do you have time to look into it ? we just
> need to get the skel's arg munging and the prototype code to agree on the
> types I would imagine. The headers, and skel prototype look correct to me.

The headers don't look right to me. It doesn't make any sense to have a 
parameter declared as:

     const Nautilus_URI uri

we really want something else that actually is equivalent to a const char 
*. I do agree that we can get rid of the skel problem just by generating 
the right kind of cast when writing out the skels.

I'm not sure I'm the best guy to hack on the IDL compiler. I don't really 
understand the code, and I don't have any easy way to test it. But if no 
one else is going to volunteer, I'll try to tackle my solution #1 above. I 
don't think it's terribly difficult.

     -- Darin




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]