Re: idl compiler with c++ backend
- From: Bowie Owens <bowie owens csiro au>
- To: Jure Petrovic <fonz siol net>
- Cc: orbitcpp-list gnome org
- Subject: Re: idl compiler with c++ backend
- Date: Tue, 05 Dec 2006 09:55:22 +1100
Jure Petrovic wrote:
Hello,
hmmm...last release of orbitcpp is from may 2004.
Is nobody interested anymore in this project?
It is not under active development at the moment. I am happy to answer
emails to the best of my abilities and apply the occasional patch when
they come in. But I haven't had time to do adequate testing to make me
happy to do a new release in a long time.
I guess everybody is using Java and webservices...
Too many alternatives. But if it fits your needs orbitcpp can work quite
well.
I was looking around some files in idl-compiler directory and noticed
pass_skels.cc and pass_stubs.cc. Would those two need implementing?
How is the actual design? I didn't take time to browse all of the code...
What methods do get called when you run orbit-idl-2 --lang=cpp ?
I can't say off the top of my head. Generally the way things work is
that the parser builds up a model of the IDL kind of like a DOM tree is
a model for a html file. Then virtual functions are called on
appropriate objects for each thing that needs to be produced. Such as
the skeletons and other code. You would need to make sure the right
virtual functions are implemented on the right classes. Most likely this
would have to do with the object that represents a function. It is all
done in a fairly object oriented way so if understand that approach the
design should make sense relatively quickly. The problem is making sure
you have implemented all the necessary virtual functions.
In examples, there are two additional files: interface_impl.h and
interface_impl.cc.
Is that how it is supposed to be generated, or should the derived
class be implemented
in one of the already existing files like interface-cpp-skels.cc or
something?
I would think that they should be in separate files. If you put
everything in the same file, it is less clear what the user should edit
and what they shouldn't. I'm pretty sure that is the way ORBit does it
too so it would be good to be consistent with them.
Bowie
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]