Alex,
> I doubt it would be easier to do in C++. It's just e question of designing
> it and coding a lot.
I think for the average C++ user, it is always easier to program in C++
than C. C++ is just a much richer language that does a lot of things
for you (along with the C++ standard template library) if you know to use
them.
There are actually many many freeware projects out there that are done in C
rather than C++ for what I'm sure are simliar reasons as to why you chose
C. IMHO, this is going to make maintaining the popular freeware programs
that change project ownership in the future more work than would be necessary
if they were done in languages that lend themselves better towards reuse
and have a richer set of code structuring capabilities.
> You are of course welcome do do whatever you want with Dia, but i don't
> feel like starting from the beginning, using a language i choose not to
> choose from the start. Although C++ has matured a lot since then i still
> think i would have choosen C, had i started today. Peoples opinion differ,
> such is life.
I am against causing a branch in the dia project just as much as I am
a supporter of redoing it in C++. That's what's so frustrating about it
for me.
I should have said before that I agree with you that you have a done a
good, straight-forward, not overly complicated design for Dia in C.
In fact, for being done in C, I'd have to say I'm pretty impressed.
But you're so close! A lot of the structure you've imposed could be
automated simply by using C++, and could be amazingly elegant if done
right.
objects/UML/note.c is 379 lines long. 300 lines of code just for the
specifics to draw a note on a diagram. Don't you think that's a bit
much? I would have to say that you've done a lot of structuring for
the objects such that there's almost as much defining of types and
functions as one would do for implementing a CORBA interface.
A lot of up-front structural code could be avoided. For instance,
like Stefan suggested, polymorphism could be used to eliminate the
need for the ObjectOps tables. If you define an Object superclass that
has virtual functions: draw(), copy(), save(), etc., you
don't have to fill in a special table to tell the part of the system
that is invoking an object's methods what functions to invoke. It would
simply know that since, for instance, a Note object is derived from the Object
superclass, it provides an implementation of draw(), copy(), save(), etc,
and that those are the functions to invoke.
Another way we could be saved from having to write redundant code is with
functions like this:
static void
note_select(Note *note, Point *clicked_point,
Renderer *interactive_renderer)
{
text_set_cursor(note->text, clicked_point, interactive_renderer);
text_grab_focus(note->text, (Object *)note);
element_update_handles(¬e->element);
}
You know the number of objects that use the same code in their select
function! In an OO language, if you implement that one function
in a superclass, you don't have to reimplement it in all the subclasses,
but if you need to circumvent the superclass method, you can.
> Well, i don't know. Exactly what would using C++ to derive objects buy
> you, except for some syntactical differences? This is not just a complaint
> against C++, could you try to describe what you think this would buy you
> in the context of Dia.
I hope my examples above helped answer this question. In general, though,
what I think C++ helps out with over C is maximizing the amount of code
reuse possible, especially if you know how to use C++ templates in the
right circumstances. It also helps give you simpler structure to your
code (if you do it right), although you've done a very good job at
providing a good structure in C.
-Ben
--
Ben Hochstedler http://www.mei.com GE Marquette Medical Systems
[EMAIL PROTECTED] Phone: 414-362-3317 Fax: 414-362-3389
