Re: [orbitcpp-list] idl compiler has arrived

[Andreas K. <ak...@ix...>]

Hi Phil, Hi Braden,

> So I propose we attempt to do the following (in the short term at
> least):
> 
> 1) We use the C++ language mapping style (underscores etc..) for the
> runtime:
>         - All the code in the orb directory
>         - The generated stubs and skeletons
> 
> 2) We use Andreas' coding style (but not indentation style ;-) for the
> idl compiler since it appears to be fairly complete, and changing it
> represents a fairly large and tedious task.
> 
> I'd add that if somebody wants to change the idl-compiler style to match
> the c++ language mapping later then I think that may be a good thing(tm)
> from a maintenance point of view.

i fully agree. (finally :) what is the convention for data members then?
Uppercase or m_ember?

remember this passage from my last mail?

8<----------------------------------------------------------------------
one improvement for the two-method thing just came to my mind: keep the
*_marshaller as well as the *_callback (i would call it *_caster for
clarity) static methods and thus be able to put the *_marshaller into
the epv. this saves an extra call in a non-inheritance setting.
8<----------------------------------------------------------------------

it came to me that this is not as clear as i had thought. clarified
version:

* for the interface A declaring foo(), have the static foo_marshaller in
the epv, reverted to the original foo(servant,env) arguments.
foo_marshaller does not use any servant member except cpp_servant.

* for inheriting interface B, create a *_caster like

foo_caster(servant,env) {
  B *typed_servant = 
  AServant fake_servant;
  fake_servant->cpp_servant = typed_servant; // causes cast
  return foo_marshaller(&fake_servant,env);
  }

and put this in B's epvs.

cya
andy

(oh my, i'll never get to my math stuff, really)