Re: Gtk--: G_List quirks



> > Of course I'm probably missing some advantage to them, but even so, they
> > are just a fancy way of saying 'I spent a lot of time coding my linked
> > list', when the same thing could be accomplished without them.
> 
> All I can add to the two previous replies is that I very strongly
> suggest you learn about the STL (I have a few pointers among my
> bookmarks on my homepage). You are missing something indeed. The only
> valid reason for not using the STL when writing C++ today would be
> being forced to use an obsolete compiler.

I took your advice and checked out the bookmarks (nice page by the
way, i'm still looking for that virus :), and you were right (well
actually, I was right :) - I was missing something. I guess I'm
still a C programmer at heart... I don't like the way all those
operators are switched around, too confusing. But I agree, there
are some pretty nifty advantages to using STL-like iterators. The
problem is, to use those advantages sometimes can produce code bloat,
because of the heavy use of templates. I still think templates are
evil, since if you use them for more than one data type you get a
copy of all the functions for each data type used. Void*'s are much
more handy for things like linked lists.

Back to the subject of G_List, it seems to me that if you can
accomplish the "lptr = lptr->next" task with iterators, that
G_List::next() and other functions don't need to increment the list,
only give a sneak peek. I don't see any problem with returning GList*
(as opposed to G_List) for all functions, since this provides more
functionality. That way, you can do something like "list->next()->data"
instead of "list->gtkobj()->next->data"  or "list->next_data()". It
also provides a way to get a G_List object, like so:
   G_List list;
   G_List lnext = G_List(list->next());
(in my opinion, G_List should not be used as a pointer, G_List*, since
it contains a GList*. That's like having a GList**, and only using
GList[0][0]).

And this concludes my ramblings. Thanks for tuning in.
---
Matt Perry [guy@mikepery.linuxos.org]

If two wrongs don't make a right, try three.
                -- Laurence J. Peter
---



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]