orbitcpp-list Mailing List for orbitcpp (Page 38)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Phil,

why isn't ORB_var defined in terms of the _var template? i could not
find any difference between the template and the ORB_var implementation.
(in orbitcpp_orb.hh)

andy

Hi again Phil,

the only difference between String_var and String_mgr i have been able
to detect was that _mgr does not free anything in its destructor. in the
comment above its declaration, you state it also initializes to an
empty, rather than a null string, but this does not appear to be the
case. what exactly should be done differently? (since i'm integrating
the _mgr with my _var templates, the only difference being made by a
bool template parameter)

andy

Hi Phil,

in CORBA::string_*() you say

// TODO: need to deal with exceptions here!

what kind of exceptions do you mean? the spec says those methods may not
throw any, so where's the issue?

andy

Hi Phil,

what's the exact purpose of orbitcpp_corba.hh? What is it supposed to
contain? why is ORB_init in orbitcpp_corba.cc instead of
orbitcpp_orb.cc? am i missing something?

andy

> For the orb directory at least, I'd like to keep m_ember. 

okay, i'd say this is the convention for the entire project then.

andy

Andreas Kloeckner wrote:
> 
> 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.
> 

I like this idea, and the implicit cast should do the thunking required
for virtual inheritance. I agree that we should go with this design.

Phil.

Andreas Kloeckner wrote:
> 
> 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?
> 

For the orb directory at least, I'd like to keep m_ember. 

Phil.

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)

> > * why the extra op_marshaller method in the skels? why not everything in
> > one skel wrapper?
> 
> It's a multiple inheritance issue:
> For each call the skeleton operation needs to cast the void* pointer
> into the appropriate C++ skeleton type. With multiple inheritence
> (virtual inheritance) C++ relies on the cast to do the appropriate
> vtable thunk. This means that you need a function per interface per
> operation to ensure that the void* c++ servant pointer gets casted to
> the right C++ servant type (you cant share them).
> The marshalling code for inherited operations is common across all the
> interfaces, and so gets factored out into a single op_marshaller
> function.
> 
> If you grab a copy of ORBit-C++ and compile the diamond-inheritance test
> and look at the skels file, you will see how this works. (mail me if you
> want me to send you the C file and save you faffing about with
> PYTHON_PATHs ;-)

Got that. In o2cpp, I chose to generate all the marshalling code for
every inheriting interface, leaving a "*** FIXME we might save code
here" (it's still there - see pass_stubs.cc :). Of course, this was a
kludge. I also had the two-method solution in mind (yet didn't remember
it yesterday), but i wondered whether there was some more efficient way
than to re-pass all those parameters. i thought of doing it by messing
with the servant struct in some tricky way, but obviously this couldn't
survive diamond-shaped inheritance. something else i thought of was
having sort of a widening function for every interface, pointed to by
the servant struct, but this is neither faster nor more elegant. can you
think of a better way? if not, the two-method thing is the way to go.

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.

> > * are you sure the environment singleton does not cause reentrancy
> > problems (e.g. a calls b and b calls a back before returning) apart from
> > being not thread-safe (aka: is creating the env on the stack much more
> > inefficient?)
> 
> You're righ, it will cause reentrancy problems and it isn't thread safe.
> I wrapped it in an accessor method in order to defer the decision on how
> to create/manage environments until later. e.g. maybe some pooling will
> yield the best performance/thread safety compromise.
> Creating and initialising envs on the stack may be more efficient as
> well.

Have a look at the cEnvironment thing from old o2cpp
(o2cpp_exception.hh) and tell me what you think of it.

cu
andy

Phil dawes wrote:
> 
> Hi Andreas & everyone,
> 
> The orbitcpp compiler is a bolt-on to the orbit-idl compiler. I have a
> couple of questions:
> 
> 1) Currently you must install the plugin C++ backend library before you
> can use the compiler. Is there anyway around this?
> Ideally I'd like to be able to run the compiler with the library in the
> build directory so that the tests can be run without installing the
> compiler. (Otherwise this will break nifty things like make distcheck)
> Do I have to patch the orbit-idl compiler to supply a backend directory
> as an argument?

at least. but libtool won't make your job that easy.
(you might try libtool --mode=execute ...)

> 
> 2) Currently you must issue 2 commands to generate the stubs/skels:
>         orbit -l c blah.idl
>         orbit -l c++ blah.idl
> How easy is it to integrate the call to the C compiler into the C++
> backend, thus reducing it to
>         orbit -l c++ blah.idl

i asked elliot about this. currently, we would either have to duplicate
code (10 lines or so) from orbit-idl or patch it to make those calls
easier. neither seems worth the trouble, since they consider their
backend interface "rather a joke". i believe we should go with the two
commands until they rewrite their compiler. 

cu
andreas

Andreas Kloeckner wrote:
> 
> "Braden N. McDaniel" wrote:
> >
> > It seems to me that for a project like this it just makes a Whole Lot Of
> > Sense to use the same naming convention as the C++ binding to CORBA. I've
> > found that I can adjust to just about any naming convention after staring
> > at it long enough, but consistency is *important*.
> 
> yes it is, but one needn't interpret this so stiffly. With the CORBA
> spec naming convention on the one side and some other convention on our
> side (which would never be visible to an outside user of the package, of
> course) it would be extremely easy to determine from the code which is
> implementation detail and which is outside interface. Likewise, the
> compiler is almost completely disjoint from any corba spec namespace, so
> there's well some space to choose. phil?

2 forces affect the decision:

1) Consistency
2) Amount of work to change it

Re (1): I agree with Braden that (a) it is desirable for all the code to
be consistent, and (b) the coding standard should mirror the C++
language mapping standard since that's the thing we can't change. I
don't agree with the idea that we should encourage inconsistency due to
the split between proprietary code and spec compliant code, since we
implement spec methods using proprietary code and the whole thing could
get very confusing to a newcomer. 

Re (2): I don't want to spend time converting the compiler code to meet
the C++ language mapping coding style.

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.

Does this sound like a good plan. (At least for the short term future?)

Cheers,

Phil.

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> 
> * do you still have a copy of o2cpp handy? if yes, have a look at the
> following:

I've got o2cpp-0.10

> - lang_c.cc: duplicateGuarded,releaseGuarded. prevents missing
> exceptions.

Yep. That's good.

> - o2cpp_smartptr.hh: what about taking this implementation instead of
> all the "nicked from mico&omniorb" stuff? (pro: wchar support, nice and
> consistent; con: breaks existing code)

<glances through code>
Is it completely spec compliant? Tested? (I spent very little time
looking at the mico code - I nicked it because it was already fairly
complete and tested)

It looks good to me, I have no problem with replacing the existing code
with this (s/o2cpp/orbitcpp/g etc..) in an orbitcpp_smartptr.hh file or
something.
How does this break existing code? What stops us from just bolting this
in?

> - o2cpp_exception.hh: looks more complete than yours

Yep, and I like the cEnvironment class. Feel free to replace the
exception code with this.

Cheers,

Phil.

Hi Andreas & everyone,

The orbitcpp compiler is a bolt-on to the orbit-idl compiler. I have a
couple of questions:

1) Currently you must install the plugin C++ backend library before you
can use the compiler. Is there anyway around this?
Ideally I'd like to be able to run the compiler with the library in the
build directory so that the tests can be run without installing the
compiler. (Otherwise this will break nifty things like make distcheck)
Do I have to patch the orbit-idl compiler to supply a backend directory
as an argument?

2) Currently you must issue 2 commands to generate the stubs/skels:
	orbit -l c blah.idl
	orbit -l c++ blah.idl
How easy is it to integrate the call to the C compiler into the C++
backend, thus reducing it to
	orbit -l c++ blah.idl

Cheers,

Phil.

Hi Braden,

"Braden N. McDaniel" wrote:
> 
> I've been kinda eyeballing this project for a while, lurking. I'd like to
> participate, but my current project load really won't accommodate it. As a
> non-participant, I realize my comments on these issues might well be
> dismissed, and I can't say I'd blame you terribly for doing just that. But
> if you'll humor me, and entertain the viewpoint of a *potential*
> contributor...

Good to hear.

> Please don't use tabs. Quite contrary to the claim here, they *don't*
> scale well. When you indent code at a particular tab width, it isn't
> particularly likely that things will continue to line up well using
> a different tab width. Furthermore, I don't want to have to reconfigure my
> editor just to make someone else's code readable.

i'd like to object that. after struggling with my emacs config for about
half an hour yesterday, i found out how well tabs _do_ scale. The
freshly indented thing looked consistent with tab-width=4,2 and even 8.
(though not too pretty at 8 because of its level of nesting) 

could you give an example of a situation where tabs become a "BAD THING"
(tm)?

> 
> Spaces offer consistency. The more aggressive indentation requirements of
> C++ (relative to C) make a large indentation level impractical--IME, 2 or
> 4 spaces work adequately.

tabs offer the right to choose.

> It seems to me that for a project like this it just makes a Whole Lot Of
> Sense to use the same naming convention as the C++ binding to CORBA. I've
> found that I can adjust to just about any naming convention after staring
> at it long enough, but consistency is *important*.

yes it is, but one needn't interpret this so stiffly. With the CORBA
spec naming convention on the one side and some other convention on our
side (which would never be visible to an outside user of the package, of
course) it would be extremely easy to determine from the code which is
implementation detail and which is outside interface. Likewise, the
compiler is almost completely disjoint from any corba spec namespace, so
there's well some space to choose. phil?

> Now, that said, in case I have some time coming up (I might), are there
> any relatively small, well defined tasks that would be well-suited to
> someone getting his feet wet with this project?

after we got the compiler and the runtime reasonably lined up, adding a
new type or implementing some specific ORB or POA feature might be such
a job.

cya
andy

On Wed, 1 Mar 2000, Phil dawes wrote:

> "Braden N. McDaniel" wrote:
> > 
> > Please don't use tabs. Quite contrary to the claim here, they *don't*
> > scale well. When you indent code at a particular tab width, it isn't
> > particularly likely that things will continue to line up well using
> > a different tab width. Furthermore, I don't want to have to reconfigure my
> > editor just to make someone else's code readable.
> > 
> 
> As far as I can see, this only becomes a problem if people mix spaces
> and tabs in their code.

Which is an inevitability, IME. Of course, I am very likely biased by my
own coding style, where I've found that indentation schemes are good
*guidelines* which should occasionally be bent a bit to do things like
keeping lines from getting Way Too Long or line up a bunch of related
assignments, all in order to accommodate the higher goal of readability. I
also do things like

  void Class::method(Type arg1,
                     Type arg2)
  {}

> > It seems to me that for a project like this it just makes a Whole Lot Of
> > Sense to use the same naming convention as the C++ binding to CORBA. I've
> > found that I can adjust to just about any naming convention after staring
> > at it long enough, but consistency is *important*.
> 
> I agree with this. The problem is that Andreas' compiler uses Java-ish
> style conventions (no underscores), where as the C++ language mapping
> uses underscores. Making all of this consistent will be quite a lot of
> work. 

Yes, but it will be tedium rather than thought-intensive work. Sounds like
a good introductory task, perhaps. If you all decide to do this, I offer
to help with the conversion.

-- 
Braden N. McDaniel
br...@en...
<URL:http://www.endoframe.com>

"Braden N. McDaniel" wrote:
> 
> Please don't use tabs. Quite contrary to the claim here, they *don't*
> scale well. When you indent code at a particular tab width, it isn't
> particularly likely that things will continue to line up well using
> a different tab width. Furthermore, I don't want to have to reconfigure my
> editor just to make someone else's code readable.
> 

As far as I can see, this only becomes a problem if people mix spaces
and tabs in their code. This has never been a problem for me in the past
(a single keypress in emacs sorts it out).

> Spaces offer consistency. The more aggressive indentation requirements of
> C++ (relative to C) make a large indentation level impractical--IME, 2 or
> 4 spaces work adequately.
> 

I think I agree about the indentation level of 2 or 4 being more
practical, but I don't see using tabs being a problem at this stage. If
it turns into a problem, then we'll switch to spaces.

> 
> It seems to me that for a project like this it just makes a Whole Lot Of
> Sense to use the same naming convention as the C++ binding to CORBA. I've
> found that I can adjust to just about any naming convention after staring
> at it long enough, but consistency is *important*.

I agree with this. The problem is that Andreas' compiler uses Java-ish
style conventions (no underscores), where as the C++ language mapping
uses underscores. Making all of this consistent will be quite a lot of
work. 

Maybe we should have one standard for the compiler, and one for the
runtime (and generated stubs/skels). Is this madness?! (I think it
probably is).

Andreas, would you be really upset if we went with the C++ language
mapping convention? It is the only thing we *can't* change!

> Now, that said, in case I have some time coming up (I might), are there
> any relatively small, well defined tasks that would be well-suited to
> someone getting his feet wet with this project?
> 

There will be in a few (2 maybe) weeks. At the moment things are up in
the air again while we stablise the new runtime with the new compiler.

Cheers,

Phil.

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> got some questions regarding the runtime:
> 
> * why the extra op_marshaller method in the skels? why not everything in
> one skel wrapper?

It's a multiple inheritance issue:
For each call the skeleton operation needs to cast the void* pointer
into the appropriate C++ skeleton type. With multiple inheritence
(virtual inheritance) C++ relies on the cast to do the appropriate
vtable thunk. This means that you need a function per interface per
operation to ensure that the void* c++ servant pointer gets casted to
the right C++ servant type (you cant share them).
The marshalling code for inherited operations is common across all the
interfaces, and so gets factored out into a single op_marshaller
function.

If you grab a copy of ORBit-C++ and compile the diamond-inheritance test
and look at the skels file, you will see how this works. (mail me if you
want me to send you the C file and save you faffing about with
PYTHON_PATHs ;-)

> * are you sure the environment singleton does not cause reentrancy
> problems (e.g. a calls b and b calls a back before returning) apart from
> being not thread-safe (aka: is creating the env on the stack much more
> inefficient?)

You're righ, it will cause reentrancy problems and it isn't thread safe.
I wrapped it in an accessor method in order to defer the decision on how
to create/manage environments until later. e.g. maybe some pooling will
yield the best performance/thread safety compromise.
Creating and initialising envs on the stack may be more efficient as
well.

> * what specifically was the problem with keeping servants on the stack?
> (it worked for o2cpp)

I can't remember the specific reason. The symptom was that when the c++
implementation object was created on the stack, we got a segfault.
Creating the C servant on the heap fixed this.
If we can get away with creating c servants on the stack then this is
obviously preferable from a performance standpoint.

> * shouldn't we prefix every non-spec method in public inheritable
> classes by something like _orbitcpp to reduce the risk of name clashes?

Sounds reasonable.

> * shouldn't we reindent this with indent-namespaces on? (if yes, go
> ahead, see .astylerc from other mail)

Okay. I don't mind either way.

Cheers,

Phil.

Andreas Kloeckner wrote:
> 
> Hi again,
> 
> [ Rant about astyle snipped
> 
> snip ----------------------------------------------
> style=kr
> mode=c
> indent-classes
> indent-switches
> indent-namespaces
> indent=tab
> snip ----------------------------------------------
> 

Oops. Looks like I was a bit premature doing the commit last night. I'll
change things again if this is appropriate.

> >
> > I prefer not to use hungarian notation for classes and types. It's ugly
> > and the fact that it is a template class / normal class should be
> > obvious by the context.
> 
> hmmm. it is a bit ugly, but keeps types from clashing with other global
> identifiers (which start in upper case in my code), such as:
> 
> cState State;
> 

I tend to use singletons rather than global identifiers.

> > >         void eatThisApple(); // func naming just like java
> >
> > If you like, except that a lot of the corba methods don't apply to this
> > rule E.g. string_to_object() etc...
> 
> yes_but_underscores_are_so_damn_ugly :)
> 

Matter of opinion. I can't really get excited either way. (what I prefer
tends to depend on the day of the week ;-)

> > The indentation is like K&R, but without the aligned braces for
> > functions. I'm quite happy to go with this indentation.
> >
> > I'm not really that fussed about all the other stuff as long as the code
> > is readable - most of the corba spec breaks it anyway. I think we should
> > start with indentation, and leave the rest up to the developer writing
> > the code.
> 
> maybe i'm too pedantic - sorry if that is so.
> 

I'd rather err on the side of less rules, if only to keep things fun for
the people hacking the code. 

> > I usually use m_ to refer to member variables.
> 
> For me, this distinction was upper case (members/globals) vs. lower case
> (locals).
> 

Oh right. For me it's typically:
Foo     = class
m_foo   = data member (instance scope)
foo()   = method
foo     = method scoped variable

Personally, I'm quite happy to stop using underscores for method names
etc.. (Have to do that when hacking java at work anyway), but I'd rather
not have to use Hungarian notation for classes etc..

Cheers,

Phil.

I've been kinda eyeballing this project for a while, lurking. I'd like to
participate, but my current project load really won't accommodate it. As a
non-participant, I realize my comments on these issues might well be
dismissed, and I can't say I'd blame you terribly for doing just that. But
if you'll humor me, and entertain the viewpoint of a *potential*
contributor...

On Tue, 29 Feb 2000, Andreas Kloeckner wrote:

> > Why not just use tabs? That way people can change their editors to use
> > the amount of indentation appropriate to their display (19 inch monitor
> > or 80 char teletype).
> 
> agreed.

Please don't use tabs. Quite contrary to the claim here, they *don't*
scale well. When you indent code at a particular tab width, it isn't
particularly likely that things will continue to line up well using
a different tab width. Furthermore, I don't want to have to reconfigure my
editor just to make someone else's code readable.

Spaces offer consistency. The more aggressive indentation requirements of
C++ (relative to C) make a large indentation level impractical--IME, 2 or
4 spaces work adequately.

> > > snip ---------------------------------------------------------
> > >
> > > template <class T>
> > > class tplApple : public cPear { // <-- opening brace here
> > > // "tpl"/"c" class prefixes if we may choose
> > 
> > I prefer not to use hungarian notation for classes and types. It's ugly
> > and the fact that it is a template class / normal class should be
> > obvious by the context.
> 
> hmmm. it is a bit ugly, but keeps types from clashing with other global
> identifiers (which start in upper case in my code), such as:
> 
> cState State;
> 
> > >         void eatThisApple(); // func naming just like java
> > 
> > If you like, except that a lot of the corba methods don't apply to this
> > rule E.g. string_to_object() etc...
> 
> yes_but_underscores_are_so_damn_ugly :)

It seems to me that for a project like this it just makes a Whole Lot Of
Sense to use the same naming convention as the C++ binding to CORBA. I've
found that I can adjust to just about any naming convention after staring
at it long enough, but consistency is *important*.

Now, that said, in case I have some time coming up (I might), are there
any relatively small, well defined tasks that would be well-suited to
someone getting his feet wet with this project?

-- 
Braden N. McDaniel
br...@en...
<URL:http://www.endoframe.com>

Hi Phil,

got some questions regarding the runtime:

* why the extra op_marshaller method in the skels? why not everything in
one skel wrapper?
* are you sure the environment singleton does not cause reentrancy
problems (e.g. a calls b and b calls a back before returning) apart from
being not thread-safe (aka: is creating the env on the stack much more
inefficient?)
* what specifically was the problem with keeping servants on the stack?
(it worked for o2cpp)
* shouldn't we prefix every non-spec method in public inheritable
classes by something like _orbitcpp to reduce the risk of name clashes?
* shouldn't we reindent this with indent-namespaces on? (if yes, go
ahead, see .astylerc from other mail)

* do you still have a copy of o2cpp handy? if yes, have a look at the
following:
- lang_c.cc: duplicateGuarded,releaseGuarded. prevents missing
exceptions.
- o2cpp_smartptr.hh: what about taking this implementation instead of
all the "nicked from mico&omniorb" stuff? (pro: wchar support, nice and
consistent; con: breaks existing code)
- o2cpp_exception.hh: looks more complete than yours

that's it for tonight. i'm getting some sleep.

cya
andy

Hi again,

> or just a plain "make". If you don't want "make" to build the tests then
> we'll build the option in as a  ./configure parameter (in fact the old
> ORBit-C++ archive does this).

good idea.

> BTW, If you add the line
> TEST=foo
> to a Makefile.am, then foo is executed when you run make check.

... that makes me wonder what i did with all those
mother-in-law-comes-around-hook things :)

> Agreed - I think I've found the tool: astyle. I got it from redhat
> powertools.

i got this some time ago, but i found it too crappy to use. now that you
brought it up, i re-got it, and yes, it is crap, but it is all we have
*shrug*. for example, it does make those

some::spuriously::scoped::method(
  with,really,really,many,arguments,and,even,
  more,and,more,and,more,arguments
  );

look like

some::spuriously::scoped::method(

with,really,really,many,arguments,and,even,
                                 more,and,more,and,more,arguments
                                );

which makes a reasonably readable line a particularly ugly one.
ugh-yuck. i tried to change the source to remedy this, but this thing is
so heavily obfuscated that i doubt the author ever fully understood what
his program did.

for now i believe that the following .astylerc does (partially) do what
we want:

snip ----------------------------------------------
style=kr
mode=c
indent-classes
indent-switches
indent-namespaces
indent=tab
snip ----------------------------------------------

> Why not just use tabs? That way people can change their editors to use
> the amount of indentation appropriate to their display (19 inch monitor
> or 80 char teletype).

agreed.

> > snip ---------------------------------------------------------
> >
> > template <class T>
> > class tplApple : public cPear { // <-- opening brace here
> > // "tpl"/"c" class prefixes if we may choose
> 
> I prefer not to use hungarian notation for classes and types. It's ugly
> and the fact that it is a template class / normal class should be
> obvious by the context.

hmmm. it is a bit ugly, but keeps types from clashing with other global
identifiers (which start in upper case in my code), such as:

cState State;

> >         void eatThisApple(); // func naming just like java
> 
> If you like, except that a lot of the corba methods don't apply to this
> rule E.g. string_to_object() etc...

yes_but_underscores_are_so_damn_ugly :)

> The indentation is like K&R, but without the aligned braces for
> functions. I'm quite happy to go with this indentation.
> 
> I'm not really that fussed about all the other stuff as long as the code
> is readable - most of the corba spec breaks it anyway. I think we should
> start with indentation, and leave the rest up to the developer writing
> the code.

maybe i'm too pedantic - sorry if that is so.

> I usually use m_ to refer to member variables. 

For me, this distinction was upper case (members/globals) vs. lower case
(locals).

> > tonight, i'll be looking into the string test and perhaps start adapting
> > the compiler a bit.

probably not tonight. i got to get this math stuff done... some time...
perhaps i'll get to it after midnight... when i should be in bed... uhh.

> Cool. BTW, what is CET in relation to GMT? - I reside in the UK so my
> evenings start at ~ 7.00 GMT. I'm a bit worried that If I go and run
> astyle over the code while you're changing it, then cvs will have
> problems merging. What time do you think you'll start hacking?

i'm in karlsruhe, germany. (CET=Central European Time=GMT+1) 

bye
andy

Hi all,

I ran astyle against all the code, using the following command:
astyle --style=kr -t *.hh *.cc

Everything still builds, although there may be some braces miss-aligned
in some inline functions. I noticed some lines like this:
	blah() {} 
rather than this:
	blah() {
	}

I have tagged the archive prior to this change just in case we need to
revert it.

Hope this is okay,

Phil

hey all,

     been out of the loop for a bit over here.  Filled to the brim
with work work work.  Hopefully at some point today or tommorow I'll
pick up the new tree and give it a whirl

ron

mostly lurking right now...

Hi Andreas,

Andreas Kloeckner wrote:
> 
> [...]
> so building the tests should be done by normal "make all"?
> 

or just a plain "make". If you don't want "make" to build the tests then
we'll build the option in as a  ./configure parameter (in fact the old
ORBit-C++ archive does this).

BTW, If you add the line 
TEST=foo
to a Makefile.am, then foo is executed when you run make check. 

> > It's not just your code - I've been lazy and used about 3 or so
> > indentation styles during the course of developing ORBit-C++ so the code
> > isn't at all consistent.
> > I think we should choose one of the standard indentation styles and go
> > with it. I'll send a post later addressing this once I've found what I
> > did with that C++ indentation tool.
> 
> okay, we might delay this until we stumble across some tool to do the
> job. doing this by hand sucks big time. 

Agreed - I think I've found the tool: astyle. I got it from redhat
powertools.

> proposal:
> 
> 8 spaces base indent
> 

Why not just use tabs? That way people can change their editors to use
the amount of indentation appropriate to their display (19 inch monitor
or 80 char teletype). 

Linus' reasoning for using 8 spaces in the linux code was that more than
3 nests deep is an indication of bad code, but this isn't really
appropriate to C++ header files which may be nested in numerous
namespaces.

> snip ---------------------------------------------------------
> 
> template <class T>
> class tplApple : public cPear { // <-- opening brace here
> // "tpl"/"c" class prefixes if we may choose

I prefer not to use hungarian notation for classes and types. It's ugly
and the fact that it is a template class / normal class should be
obvious by the context.

> public:
>         int *a; // rather than int* a;

I don't really care much about this. I tend to use int* because in C++
with it's OO types bias, the type is thought of as an "int pointer"
(where as in c it's a pointer to an int), but there are probably valid
reasons to use the other way.

>         void eatThisApple(); // func naming just like java

If you like, except that a lot of the corba methods don't apply to this
rule E.g. string_to_object() etc...

> // 4 blank lines between major source entities
> 

Don't care

> // tplApple -------------- < to column 79 > ----------------------
> // before every object implementation (see my code)
> template <class T>
> void // return type on extra line
> tplApple<T>::eatThisApple() {
>         chump(this);
> }
> 
> snip ---------------------------------------------------------
> 
> This is kind of compromise between your style and mine - does it
> resemble any standard way to do things?

The indentation is like K&R, but without the aligned braces for
functions. I'm quite happy to go with this indentation.

I'm not really that fussed about all the other stuff as long as the code
is readable - most of the corba spec breaks it anyway. I think we should
start with indentation, and leave the rest up to the developer writing
the code.

>  btw: i saw you prefixing
> variables with "m_" or "s_" (in those cases i believe they were _m_ember
> and _s_tring). could you give me the big picture?
> 

I usually use m_ to refer to member variables. This is just a way of
indicating to the reader which variables are function scoped and which
are instance scoped since this is important information and is not
obvious by context. If editors did this for me (by colouring variables
or something) then I probably wouldn't use it.
I don't think I use s_. Maybe it stands for 'static variable'?

> compiler's been modified, and the renaming you requested is done. (see
> last night's commit) i've also renamed the corresponding classes:
> 
> cIDLPass0 -> cIDLPassGather
> cIDLPass1 -> cIDLPassXlate
> cIDLPass2 -> cIDLPassStubs
> cIDLPass3 -> cIDLPassSkels
> 
> (i actually start liking sed...)
> 

Cool - many thanks for doing that.

> > As for who does what:
> > It'd probably be simpler if we split the compiler work into 'you do the
> > stubs, I'll do the skeletons' or something like that.
> 
> separating stubs and skeletons is not so well suited to the compiler
> design, as there are two routines for generic stub/skel generation that
> use types coming in by polymorphism. due to this, it is probably more
> natural to split work according to different types being added.
> 

Okay - I need to look at the code more closely.

> tonight, i'll be looking into the string test and perhaps start adapting
> the compiler a bit.
> 
> andy
> 

Cool. BTW, what is CET in relation to GMT? - I reside in the UK so my
evenings start at ~ 7.00 GMT. I'm a bit worried that If I go and run
astyle over the code while you're changing it, then cvs will have
problems merging. What time do you think you'll start hacking?

Cheers,

Phil.

hi phil,

> Sounds good. BTW, the 'check' target is meant to run the tests rather
> than build them - I couldn't get this to build so I've removed
> idl-torture and basic from the test Makefile.am so that the global check
> target runs.

so building the tests should be done by normal "make all"?

> I'd like to aim to keep the 'make' and 'make check' global targets
> always working, and we'll just add tests to them when they're finished
> and working.

ack. 

> It's not just your code - I've been lazy and used about 3 or so
> indentation styles during the course of developing ORBit-C++ so the code
> isn't at all consistent.
> I think we should choose one of the standard indentation styles and go
> with it. I'll send a post later addressing this once I've found what I
> did with that C++ indentation tool.

okay, we might delay this until we stumble across some tool to do the
job. doing this by hand sucks big time. proposal: 

8 spaces base indent

snip ---------------------------------------------------------

template <class T>
class tplApple : public cPear { // <-- opening brace here
// "tpl"/"c" class prefixes if we may choose
public:
	int *a; // rather than int* a;

private:
	int operator+(tplApple a1,tplApple a2) { 
		// no extra whitespace in parameters;
		return 2;
	}
	void eatThisApple(); // func naming just like java
};

// 4 blank lines between major source entities

// tplApple -------------- < to column 79 > ----------------------
// before every object implementation (see my code)
template <class T>
void // return type on extra line
tplApple<T>::eatThisApple() {
	chump(this);
}

snip ---------------------------------------------------------

This is kind of compromise between your style and mine - does it
resemble any standard way to do things? btw: i saw you prefixing
variables with "m_" or "s_" (in those cases i believe they were _m_ember
and _s_tring). could you give me the big picture?

> > (while
> > you're at it, you may also make a mess of my nice-and-plain (tm) source
> > file headers to keep things uniform) (if you tell me what to do, i will
> > help out) (call this stage "one" (tm))
> 
> I use the 'stick a gnu license (gpl/lgpl) in every file' because that's
> the way it has worked on other projects I've hacked with. This does mean
> that anybody wishing to pinch code from the file immediately knows the
> implications.

compiler's been modified, and the renaming you requested is done. (see
last night's commit) i've also renamed the corresponding classes: 

cIDLPass0 -> cIDLPassGather
cIDLPass1 -> cIDLPassXlate
cIDLPass2 -> cIDLPassStubs
cIDLPass3 -> cIDLPassSkels

(i actually start liking sed...)

> As regards copyrights, we've sort of used the informal 'the person who
> creates the source file has the copyright, and anybody ammending the
> file can add their name to the authors list in the file header' rule as
> we've been developing (although I don't think anybody decided this). I'd
> like to keep that if there isn't a good reason to change it.

ok.

> > tell me about your plans. i wanna get goin'!
> 
> Erm, good question!
> 
> I think:
> 
> 1) Get the 'string test' stubs and skeletons in a shape that we're happy
> with - that way we have an example of stubs and skeletons which allows
> gives us something to shoot at.
> Actually they are probably almost there now - I'd appreciate it if you
> could have a look and check that there aren't some obscene optimisations
> I'm missing or something that would make things much simpler.

i'll be getting into that tonight, i think.

> 2) Aim the compiler at that.
> 
> 3) Keep adding features...

accepted.

> As for who does what:
> It'd probably be simpler if we split the compiler work into 'you do the
> stubs, I'll do the skeletons' or something like that.

separating stubs and skeletons is not so well suited to the compiler
design, as there are two routines for generic stub/skel generation that
use types coming in by polymorphism. due to this, it is probably more
natural to split work according to different types being added.

tonight, i'll be looking into the string test and perhaps start adapting
the compiler a bit.

andy

1999	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (7)
2000	Jan (19)	Feb (45)	Mar (53)	Apr (64)	May (22)	Jun (6)	Jul (56)	Aug (11)	Sep (32)	Oct (27)	Nov (43)	Dec (25)
2001	Jan (11)	Feb (26)	Mar (16)	Apr (19)	May (19)	Jun (28)	Jul (16)	Aug (12)	Sep (7)	Oct (9)	Nov (1)	Dec (35)
2002	Jan (45)	Feb (66)	Mar (25)	Apr (20)	May (15)	Jun (1)	Jul (1)	Aug (3)	Sep (7)	Oct	Nov (2)	Dec (26)
2003	Jan (8)	Feb	Mar	Apr (4)	May (3)	Jun (2)	Jul (2)	Aug (1)	Sep	Oct	Nov (1)	Dec
2004	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec
2006	Jan (2)	Feb	Mar	Apr	May (2)	Jun (2)	Jul (4)	Aug (4)	Sep (4)	Oct (17)	Nov (23)	Dec (5)
2007	Jan (37)	Feb (20)	Mar (16)	Apr (23)	May (20)	Jun (12)	Jul (20)	Aug (25)	Sep (15)	Oct (8)	Nov (5)	Dec (3)
2008	Jan (9)	Feb (6)	Mar (37)	Apr (28)	May (12)	Jun (9)	Jul (30)	Aug (7)	Sep (20)	Oct (26)	Nov (50)	Dec (75)
2009	Jan (63)	Feb (46)	Mar (54)	Apr (53)	May (125)	Jun (102)	Jul (90)	Aug (46)	Sep (26)	Oct (32)	Nov (9)	Dec (29)
2010	Jan (9)	Feb (8)	Mar (45)	Apr (56)	May (74)	Jun (73)	Jul (34)	Aug (48)	Sep (23)	Oct (3)	Nov	Dec (3)
2011	Jan (5)	Feb (3)	Mar (17)	Apr (3)	May (2)	Jun (3)	Jul (4)	Aug (8)	Sep (17)	Oct (6)	Nov (5)	Dec (10)
2012	Jan (3)	Feb (15)	Mar (4)	Apr (2)	May (1)	Jun (2)	Jul (5)	Aug (3)	Sep	Oct (2)	Nov (1)	Dec (2)
2013	Jan (2)	Feb (3)	Mar (1)	Apr (4)	May (4)	Jun (3)	Jul (6)	Aug (52)	Sep (3)	Oct (5)	Nov (1)	Dec (8)
2014	Jan (1)	Feb (16)	Mar (9)	Apr (11)	May (16)	Jun (15)	Jul (13)	Aug (4)	Sep (2)	Oct (3)	Nov	Dec (3)
2015	Jan (5)	Feb (1)	Mar (5)	Apr (1)	May (5)	Jun (3)	Jul (4)	Aug (2)	Sep (1)	Oct	Nov	Dec (1)
2016	Jan (1)	Feb (2)	Mar (3)	Apr	May (2)	Jun (1)	Jul	Aug	Sep (1)	Oct	Nov (3)	Dec (1)
2017	Jan	Feb (1)	Mar (1)	Apr (5)	May (1)	Jun (2)	Jul (1)	Aug	Sep	Oct	Nov	Dec