Re: [Ayttm-devel] Function prototypes in .c files

[Philip S Tellis]

On Tue, 21 Jan 2003, Andy wrote:

> I don't understand how including a header can affect the .o size
> [unless it adds some junk for debugging with -g on or includes code?].  

try this:

#include <stdio.h>
int main() { printf("Hello, World!\n"); return 0;}

gcc -c

Next, add #include <gtk/gtk.h> to the top and gcc -c again.

> Regardless, I think when you resort to what you've done it's a symptom
> of poor design of the header files :-)

well, it has more to do with the fact that the headers started out one 
way and kept adapting to satisfy other needs.  True, there probably 
wasn't any formal specifications document before it started... but 
then... it wasn't started by Software Engineers.

> Great plan.  I'm all for working towards this.  Then can I have my Qt
> interface? :-)

And I can have my text only interface.  Also, on this note, has anyone 
had a look at ariyahoo?  It's a client that's used mainly by blind 
people.  Would be cool if we could have that kind of support.  A TTS 
interface would be great.

> > - All header files should be self sufficient.
[snip]
> 
> Can you explain this a bit?  Are you saying the opposite of the next
> point here for include files?

if(
a.h:
GList * accounts;
) then a.h must #include <glib.h>, even if a.h #includes b.h, which in 
turn #includes glib.h.  This is so because at some point we may not 
require a.h to depend on b.h.  That would suddenly make a.h not work.

> > ayttm.  Forward declarations are fine in this regard if the size of

forward declarations for types that we define.  (eg: struct contact;)

> repercussions.  The whole namespace thing is a mess in ayttm.  There
> seems to be no naming conventions whatsoever [please correct me if I'm
> wrong].

then I won't correct you ;)

ok, something else I found out yesterday.  In the service plugins, we 
can make almost all functions static.  Anything that is passed to ayttm 
through the service_callbacks struct can be static.

> Again header -> file size relation?  Is this a GTK thing?

very likely dependent only on Gtk.  I think the reason is that Gtk
defines so many types.  Also, Gtk includes Gdk - which again defines so 
many types, and glib - which although not that many, and not that big, 
also defines its own types.  glib on its own doesn't do that much 
damage, but we're really only using the GList from glib, so it makes 
sense to just write our own doubly-linked-list library (like yahoo_list 
in libyahoo2 or elist in eb-lite).

> I know that a variable called filename is global?  My preference is to
> use gFileName if it's truly a global and sFileName if it's a .c file

Ok, I'm ok with this, except that variable capitalisation reminds me too 
much of Visual Basic programs.  I'd rather use underscores if it's okay 
with everyone.  Also (and people may hate me for this, but) a very 
stripped down Hungarian notation <already starting to run> may help:

g - global to project
l - local to function
t - function parameter
s - file scope

I don't think we need type information specified... if the variable name 
doesn't offer a hint to that then it may have to be renamed.

> Which makes me think of another thing here.  There seems to be an
> awful lot of 'magic numbers' in this code.  I think this should be
> addressed as well.  We could also talk about preferring an enum over a
> bunch of defines....

Well, I prefer enums - as you can see from the yahoo code - so I'm with 
you on this.

The question now is ... where do we start?

Philip

-- 
Any program which runs right is obsolete.