Re: [orbitcpp-list] idl compiler has arrived

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

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