typedef char* problem

[Niels Basjes]

On 28 Aug 1997, Sai-Lai Lo wrote:

> Niels,
> 
> In the example you provided, the function signature generated by omniORB is
> correct. It is *not a bug*. In fact, this is the *only case* in the C++
> mapping for IN arguments where one cannot use the typedef name in the
> stub's function signature. Let me explain:
> 
> The C++ mapping (table 24) specifies that an IN string argument is mapped to
> const char*.
> 
> In C++, a const char* means that the object of type char points to by the
> type is a constant. The pointer itself *is not a constant*.
> 
> On the otherhand, 'const SomeValue' means that the object SomeValue is a
> constant. In your example, SomeValue is a pointer (char*). In otherwords,
> 'const SomeValue' makes the pointer itself a constant.

Exactly why the compiler complained they weren't the same.

> Therefore, using const SomeValue in the function signature is not a correct
> mapping. One has to use the real type of SomeValue instead.
> 
> Besides, our version of Orbix (2.2 MT) generates the same mapping as
> omniORB. 

Hmmm,

I tried this IDL:
  typedef string SomeValue; 
  interface MyObject {
    boolean SetNewValue (in SomeValue new_value);  
  }; 

omniORB generated:
  typedef char* SomeValue;
  class _sk_MyObject :  public virtual MyObject {
    virtual CORBA::Boolean  SetNewValue ( const char *  new_value ) = 0;
  };

Orbix 2.0.1 MT generated:
  typedef char* SomeValue;
  class MyObject: public virtual CORBA::Object {
  virtual CORBA::Boolean SetNewValue (const SomeValue new_value,
              CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ())
              throw (CORBA::SystemException);
  };

So what you are saying is that this is a bug in the Orbix 2.0.1 which they
solved in a later version.

Why don't you generate a "#define SomeValue char*" instead of the typedef?
This would make the code more readable and better to maintain. What if
you decide to change SomeValue into an other type, you would have to
search all your source code for problem situations.

Niels.

================================================================
| ir. Niels Basjes             | National Aerospace Laboratory |
| Phone      : +31-20-5113626  | Anthony Fokkerweg 2           |
| E-Mail@NLR : Basjes@NLR.nl   | 1059 CM Amsterdam             |
| E-Mail@Home: Niels@Basjes.nl | The Netherlands               |
================================================================