Re: [orbitcpp-list] idl compiler has arrived

[Phil d. <ph...@us...>]

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.