On 05/24/2010 01:47 PM, torbenh wrote:
On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier
Guilyardi wrote:
then you
need to manage most memory yourself again....
Which may results in choosing a
simplified memory model, and thus optimization.
could you explain your reasons a bit more ?
First, it's not all about reasons, it's also a matter of taste. But what I
like
taste is one of the strongest reasons in my opinion.
I follow you here :-)
[...]
That said, in
the past I chose to write a GUI using pure C with Gtk, and this
was really a mistake I think. Adding simple features is really heavy now.
yes. thats what i referred to.
you cant simply derive from GtkWidget in C ... you need to write 50 locs
of boilerplate to do that.
Yes, I don't think that I'll ever choose C for the GUI part again, by the way.
But, as I previously meant, that is very likely to be the case for the low level
part.
But maybe
that, with experience and methodology, one can get as productive in C
as in C++? I suppose the guys at Gnome would agree with that..
there is a reason
why gob2 and vala emerged.
writing a GObject in C is a pretty big PITA.
Indeed, and that's why I
don't use Vala. To make any real use of it, you need to
write GObjects wrappers for the libraries or low level C/C++ routines that you
need, before you can bind them into Vala.
hmm... i actually view it from the other side.
if i want to derive from GtkWidget or somthing this is a huge PITA in C.
in vala this is easy and streight forward. and the vala code compiles to C
so i can go ahead and use my vala widget from my C code.
I understand that you use Vala solely as a GObject generator.. I didn't think
about this actually. I was talking about using Vala as the main language, or at
least the whole GUI part, and call native code from Vala through bindings.
you dont need to write GObject wrappers. but vala can
generate bindings
automatically through GObject introspection.
Yes I know about this, but if you need bindings for your low level stuff (jack,
etc..) or for a library for which the bindings do not exist, then you need to
write a GObject wrapper in C for this introspection to take place.
But using Vala to generate the wrapper skeleton could be the key.. I didn't
think about this actually.
[...]
Nevertheless,
Vala looks promising. But I don't like the GObject model. I made
my own OO constructs in C with inheritance and such, but if you want the whole
thing, with interfaces etc.., I think that C just isn't the way to go.
your own OO constructs dont really help you when you want to derive from a GObject.
and thats the whole point, i think.
Yes, but my constructs are very simple and readable to me :p They were never
meant to be coupled with GObject, they bring some OO features I need, and it's
just pure C, no code generation, etc.. Eg:
http://jackbeat.samalyse.org/browser/trunk/src/stream
gtkmm makes deriving easy. but the resulting object
cant be wrapped with pygtk
or other stuff. you lock yourself into the c++ domain.
or write your own wrappers.
If using Python and C/C++ (a great couple by the way), they I think the GUI part
should be written in Python anyway.
its probably possible to create the boilerplate out of
some kind of
template.
but i am not aware of some rails/paster like framework to create this
boilerplate with a single command.
Actually, I'm currently thinking about some
very clever IDE and intellisense
features for C. When I look at this Eclipse IDE, and all that it understands,
and thus automatically proposes, I think that similar aids could really be
useful in C.
hmm... when it comes to C i dont miss anything from vim. its pretty much smart enough.
c++ is another story. since the tags system isnt smart enought to
resolve x->write() to the right write() method of all those classes that support that
interface.
I've been using the tags system for C, then I stopped using it, tried again,
etc.. I'm not very confident with the exuberant thing and the like. I once tried
some vim intellisense system, I think that one sort of worked, but Googl'ing
about that it looks like it gained maturity:
http://insenvim.sourceforge.net/
I think that some day I need to seat and work a couple of days on optimizing my
Vim setup. Maybe even learn the scripting part..
if your still into vim you might want to have a look
at
http://eclim.org/
thats pretty awesome :)
I have to try this, especially the headless mode, thank you :-)
However, it's not that I really like the Eclipse Java machinery. But I'm
currently forced to use it, and I have to witness that source refactoring for
function, class renaming, and a couple of other features are awesome.
I'll give a try to Eclim to see what it has to offer in this regard.
--
Olivier